Web Worker 图像处理基础知识
Web Worker 是一个独立的 JavaScript 执行上下文，它可以执行昂贵的计算，而不需要让编辑器的主线程完成所有工作。对于浏览器图像处理，这意味着模型设置和推理可以脱离负责按钮、进度消息、画笔输入和屏幕更新的线程。
结果不是“免费后台处理”。同一设备仍然执行计算并使用内存。架构的好处是分离：繁重的模型操作不太可能在运行时阻止每个接口响应。
主线程有一个用户界面作业
浏览器页面通常在主线程上运行 JavaScript。该线程还协调布局、绘制和输入。如果一项长时间的计算占用了它，点击可能会感觉延迟，动画可能会停止，并且浏览器可能会警告页面没有响应。
在推理开始之前，图像编辑器就具有大量主线程职责：
- 接收文件选择、粘贴或删除；
- 解码并显示图像；
- 更新进度和错误状态；
- 绘制预览画布；
- 处理添加和擦除画笔移动；
- 准备下载或剪贴板操作。
将分割模型的数值工作放在同一线程上将使这些任务直接竞争。工人创造了更清晰的界限。
基于消息的边界
编辑器和工作器不共享普通变量。他们通过发送消息进行交流。简化的流程如下所示：
- 编辑器创建或重用worker。 2.它要求worker初始化推理运行时和模型。
- 准备图像数据并发送推理请求。
- Worker 将数据转换为模型的预期输入。
- 工作人员运行模型并生成掩码值。
- 发回掩码或结果数据。
- 编辑器合成预览并启用细化或导出。
消息应包含足够的上下文以匹配对正确请求的响应。如果用户在上一个作业完成之前选择另一个图像，这一点很重要。界面必须避免在新源上显示旧结果。
复制和传输图像数据
发送一条小短信很便宜。如果浏览器必须复制整个缓冲区，则发送数百万像素值的成本可能会很高。 Web API 可以转移某些二进制缓冲区的所有权。传输的缓冲区可供接收方使用，而无需在发送方保留可用的副本。
这种优化存在设计限制：传输后，发送方无法继续使用相同的缓冲区，就好像它仍然拥有数据一样。编辑器可以保留单独的显示表示，创建专用的推理缓冲区，或者重建稍后需要的内容。
并非每个实现都在完全相同的位置使用传输。一般的教训是线程分离不会使数据移动消失。图像尺寸、缓冲区大小和转换次数仍然会影响延迟和内存。
Easy Background Remover 在工人中放入了什么
Easy Background Remover 使用带有浏览器推理运行时的 Web Worker 进行设备上分段。重型自动剪切步骤产生掩模。然后编辑器显示合成结果并支持CPU画布画笔细化。
这种分离为故障提供了更有用的边界。如果工作器无法初始化或在推理过程中崩溃，则界面可以报告与工作器相关的错误，而不是依赖永久冻结的选项卡作为唯一信号。
它还使本地处理声明易于理解。将像素从扩展页面发送到其自己的工作人员是浏览器环境内的通信，而不是上传到远程剪切 API。第一会话可以单独下载可复用的模型资源；请参阅为什么首次运行会下载模型。
Worker 不会立即进行计算
工作人员提高响应能力，而不是原始设备能力。该模型仍然根据浏览器可以提供的资源消耗 CPU、GPU 或其他运行时资源。较大的输入仍然比较小的输入花费更长的时间并且需要更多的内存。
仍然存在一些限制：
- 模型初始化有实际成本；
- 如果复制，像素缓冲区会占用两侧的内存；
- 调整大小和格式转换需要时间；
- 低内存设备可能难以处理大图像；
- 更多的工人可以增加争用而不是减少争用；
- 导出和画布更新仍然可以涉及主线程。
为五个图像启动五个推理工作器不会自动加快五倍。工人们共用同一台机器。并行作业可以竞争内存带宽和执行资源，而每个模型实例可能会承担自己的内存成本。
进度报告是合作的
工作人员可以发送状态消息，但它不会自动知道什么进度百分比会感觉准确。模型下载、运行时初始化、输入准备、推理、掩模转换和预览渲染是具有不同时序的独立阶段。
某些阶段具有可测量的字节数。单个模型执行可能只公开“开始”和“完成”。因此，均匀增长的平滑百分比可能只是装饰性的，而不是精确的测量。
有用的进度 UI 会尽可能命名阶段：准备模型、处理图像或构建结果。它还可以处理失败和取消，而不是让旋转器没有任何解释。
取消不仅仅是隐藏微调器
如果用户关闭图像或重新开始，界面可以忽略过时请求的最终响应。立即停止底层计算可能需要运行时的额外支持或终止并重新创建工作线程。
终止一个工作进程是决定性的，但它会丢弃其初始化状态。下一个作业可能需要再次加载并初始化模型。对于短期操作，将结果标记为陈旧可能比拆除所有内容更便宜。
正确的选择取决于内存压力、操作持续时间和运行时能力。从用户的角度来看，重要的规则是过时的工作不得覆盖当前的编辑。
错误也需要跨越边界
工作线程内部的异常不会成为正常的主线程异常。工作人员必须报告可用的错误，编辑器应该侦听工作人员级别的故障。
良好的错误处理至少可以区分：
- 模型资源不可用；
- 模型初始化失败；
- 图像解码或输入准备失败；
- 推理失败；
- 工人意外停下来；
- 结果不再属于当前请求。
这比一般的“出了问题”更具可操作性，特别是当首次运行设置和正常图像处理有不同的补救措施时。
Worker 输出仍然只是第一个掩码
线程架构本身并不能改善模糊边缘。工作人员可以退回技术上有效的面具，但仍然缺少毛皮、透明材料、窄带或所需的阴影。这些是细分和意图问题。
推理后，编辑器的工作继续进行：将蒙版缩放到工作坐标系中，合成预览，让用户对其进行细化，然后导出当前状态。 蒙版分辨率与预览尺寸 解释了为什么不应混淆这些坐标系。
简洁的心智模型
将工作人员视为消息窗口后面的本地专家：
- 编辑拥有互动；
- 工人承担繁重的推理任务；
- 二值图像数据跨越定义的边界；
- 工人返回一个掩模，而不是对每个边缘的最终判断；
- 编辑仍然负责当前状态、审查、完善和导出。
对于模型对像素本身的视图，请继续设备上剪切模型看到的内容。有关端到端的实用概述，请参阅本地背景删除的工作原理。