EraseMint 是怎么工作的

图片是怎么被载入的

一切都从你自己的设备开始。你选中文件后，浏览器直接从本地解码，同时按 EXIF 方向标记摆正画面——所以竖拍的照片不会横躺着出现。

长边超过 4096 像素的图片会先等比缩小到这个上限再处理，让内存占用在普通笔记本和手机上也可控。原图会另外保留，所以修复结果依然可以按原始分辨率导出。

涂抹的选区是怎么变成蒙版的

笔画记录的是**图片像素坐标**，不是屏幕坐标。这就是为什么放大缩小的时候画笔的物理尺寸保持不变，也是为什么调整窗口大小后选区不会跑偏。

开始修复时，工具会围绕你涂过的所有位置裁出一个正方形区域，并向四周多取 72 像素的真实画面作为参考。在这个区域里，笔画被栅格化成蒙版、按一个小半径膨胀，然后做面积校验：如果标记的区域超过整图的 60%，工具会请你重新选一个更小的范围，而不是硬猜。

最终会生成两份蒙版：模型收到的是二值化的硬蒙版；而羽化过的软蒙版只在把修复结果贴回画面时使用——接缝之所以看不出来，就是它的作用。

AI 是怎么重建这块区域的

模型拿到的是 512×512 的画面裁切加上蒙版，然后推断这里原本应该是什么。同一套接口后面有两个模型：默认使用的更大、质量更好的一个（约 208 MB），以及用于快速验证的轻量模型（约 28 MB）。界面刻意不显示模型名称，只谈“修复方式”——跑的是哪个模型不该由用户来操心。

用哪个计算后端是自动决定的。轻量模型在浏览器支持时优先用 WebGPU；默认模型则走 WebAssembly——它的结构在 WebGPU 执行后端上会命中一个已知问题：模型能加载，但真正运行时失败，直接选 WebAssembly 可以省掉一次缓慢的失败与重试。如果某个后端在运行时失败，工具会自动换另一个重试。

为什么本地处理很重要

因为图片是在你已经打开的标签页里解码和修复的，所以没有上传这一步，也不会在服务器上留下稍后需要删除的副本。这也让工具在慢速网络下依然可用：模型进入浏览器缓存之后，修复本身不再需要任何网络流量。

代价是计算由你自己的设备承担。内存有几个 GB 可用的手机，处理小图很轻松，处理超大图就比较吃力；内存不足时，工具会明确报错，而不是把标签页搞崩。

修复失败时会发生什么

每一种失败都对应一个具体的错误码和一句大白话说明，一共 12 条。常见的情况包括：格式不支持、图片无法解码、选区是空的、浏览器跑不了模型、设备内存不足。

其中三种——模型加载失败、WebAssembly 引擎启动失败、内存不足——会自动改用更轻量的模型重试一次。你会看到一条提示说明已改用更小的修复方式，并且依然能拿到结果。

这些失败信息不会被上传到任何地方。诊断面板只在你的设备上保存最近 50 条事件，并能复制成一段文本；在地址后加上 `?diag=1` 可以主动打开这个面板，方便你在愿意反馈问题时把细节发出来。

设备会怎样影响处理时间

模型文件只需要下载一次——默认模型约 208 MB，轻量模型约 28 MB——之后浏览器会把它存起来，再次访问就不必重新下载。

模型的初始化是另一笔开销，而且每次打开页面都要付一次：运行时必须解析模型结构并把权重读进内存。笔记本上实测，即使文件来自缓存，默认模型这一步也要约 7 秒。所以刷新页面后，第一次修复前会先等上几秒。

修复本身取决于所用模型和设备：轻量模型通常只要几秒；默认模型明显更慢，因为本站没有开启跨域隔离（COOP/COEP），WebAssembly 只能单线程运行——这是为了让第三方资源继续可用而做的取舍。相比之下，涂抹和编辑是纯画布操作，全程保持响应。

下载了什么、缓存了什么、保存了什么

• 模型文件从我们自建的资源域获取；如果该域名不可达，会依次回退到镜像站，再到 Hugging Face。
• 每个来源都会以短暂停顿重试两次，再尝试下一个来源；浏览器还会把下载到的字节数与预期值核对一次。
• 模型文件存放在浏览器的 Cache Storage 里，名称为 erasemint-models-v1。
• 清除本站的缓存数据会删掉已存的模型，下次修复会重新下载。
• 只有匿名使用事件（例如某次修复成功）会被记录；图片内容、蒙版和文件名从不包含在内。