浏览器图像处理的工作原理 - Canvas API、ImageData 与 Web Workers 指南
浏览器图像处理概述 - 无服务器图像编辑时代
浏览器图像处理是指完全在客户端（用户的浏览器中）执行图像编辑和转换操作，无需将图像上传到服务器。这种方式在隐私保护、响应速度和离线可用性方面具有显著优势。
现代浏览器提供了多层图像处理能力：Canvas 2D API 用于像素级操作，WebGL 用于 GPU 加速的滤镜处理，Web Workers 用于后台线程处理以避免 UI 冻结，以及 WebAssembly 用于接近原生的处理速度。
典型的浏览器图像处理应用场景包括：上传前的图像压缩和缩放、实时滤镜预览、格式转换（如 HEIC 转 JPEG）、元数据剥离以保护隐私，以及基于 AI 模型的背景去除等。这些操作过去需要服务器端处理，现在都可以在浏览器中高效完成。
Canvas API 与像素操作 - 基础技术
Canvas API 是浏览器图像处理的核心。通过 getImageData() 获取像素数据后，可以对每个像素的 RGBA 值进行任意操作。
基本工作流程：将图像绘制到 Canvas，获取 ImageData 对象，遍历像素数组进行处理，然后将结果写回 Canvas。ImageData.data 是一个 Uint8ClampedArray，每 4 个元素代表一个像素的 R、G、B、A 值（0-255）。
常见的像素操作包括：灰度转换（使用亮度公式 0.299R + 0.587G + 0.114B）、亮度/对比度调整、颜色通道分离、阈值化处理等。这些操作的核心都是遍历像素数组并修改各通道值。
性能方面，直接操作 Uint8ClampedArray 比逐像素调用方法快得多。对于 1920x1080 的图像（约 830 万像素），优化后的循环可在 50ms 内完成基本滤镜处理。使用 TypedArray 的 set() 方法进行批量复制也能显著提升性能。
使用 Web Workers 进行离线程处理 - 防止 UI 冻结
图像处理涉及大量计算，在主线程执行会导致页面无响应。Web Workers 允许在后台线程中执行计算密集型任务，保持 UI 的流畅响应。
将图像处理移至 Worker 的基本模式：主线程获取 ImageData 后，通过 postMessage() 将像素数据发送给 Worker。为避免数据复制的开销，使用 Transferable Objects 进行所有权转移：worker.postMessage(imageData, [imageData.data.buffer])。
Worker 中完成处理后，将结果以同样的方式传回主线程。整个过程中 UI 保持响应，用户可以继续与页面交互。对于需要显示进度的长时间处理，Worker 可以定期发送进度消息。
注意事项：Worker 中无法访问 DOM 和 Canvas 2D 上下文（但可以使用 OffscreenCanvas）。数据传输本身有一定开销，对于非常小的图像，Worker 的启动和通信成本可能超过处理本身的时间。建议仅对处理时间超过 16ms（一帧）的操作使用 Worker。
利用 OffscreenCanvas - 在 Worker 中进行 Canvas 操作
OffscreenCanvas 是不绑定 DOM 的 Canvas，可以在 Web Worker 中使用，实现完整的 Canvas 绑图和像素处理能力。
创建方式有两种：直接创建 new OffscreenCanvas(width, height)，或从现有 Canvas 转移 canvas.transferControlToOffscreen()。后者允许 Worker 直接渲染到页面上可见的 Canvas。
在 Worker 中使用 OffscreenCanvas 的典型流程：接收 ImageBitmap，绘制到 OffscreenCanvas，执行 getImageData/putImageData 操作，最后将结果作为 ImageBitmap 返回主线程。
OffscreenCanvas 还支持 WebGL 上下文，这意味着可以在 Worker 中执行 GPU 加速的图像处理。结合 WebGL 着色器，可以实现复杂滤镜的实时处理而不影响主线程性能。
浏览器兼容性方面，Chrome、Edge、Firefox 均已支持 OffscreenCanvas。Safari 从 16.4 版本开始支持。对于不支持的浏览器，可以回退到主线程处理。
WebGL GPU 加速 - 使用着色器进行高速滤镜处理
WebGL 利用 GPU 的并行计算能力，可以同时处理数百万像素，比 CPU 逐像素处理快数十倍。特别适合卷积滤镜、颜色变换等可并行化的操作。
WebGL 图像处理的基本原理：将图像作为纹理上传到 GPU，编写片段着色器（Fragment Shader）定义每个像素的处理逻辑，GPU 并行执行着色器处理所有像素，最后从帧缓冲区读取结果。
片段着色器使用 GLSL 语言编写。例如灰度转换着色器：float gray = dot(color.rgb, vec3(0.299, 0.587, 0.114));。GPU 会对每个像素并行执行这段代码。
多通道处理（Multi-pass）允许链式应用多个滤镜：将一个着色器的输出作为下一个着色器的输入纹理。通过帧缓冲对象（FBO）实现渲染到纹理，构建复杂的滤镜流水线。
WebGL 的局限性：初始化开销较大（编译着色器、上传纹理），对于单次简单操作可能不如 Canvas 2D 高效。最适合需要实时预览的交互式滤镜调整场景。
性能优化技巧 - 基于测量的加速方法
图像处理性能优化应基于实际测量而非猜测。使用 performance.now() 精确计时各处理阶段，找出真正的瓶颈。
关键优化策略：
- 减少内存分配：预分配输出缓冲区并重复使用，避免在循环中创建新数组
- 查找表（LUT）：对于点操作（亮度、对比度、伽马），预计算 256 个输出值的数组，将乘法运算替换为数组查找
- 分块处理：将大图像分成小块处理，利用 CPU 缓存局部性提升性能
- 降采样预览：编辑时使用缩小版图像实时预览，确认后再对全尺寸图像应用
- requestAnimationFrame 节流：滑块调整等连续操作使用 rAF 限制处理频率
内存管理也很重要。大图像的 ImageData 可能占用数十 MB 内存。处理完成后及时释放不再需要的 ImageData 引用，让垃圾回收器回收内存。对于超大图像（4K 以上），考虑分块加载和处理以避免内存溢出。