图片处理工具早就是红海了。PS 装着，美图秀秀装着，在线的 remove.bg、各种 AI 抠图站一搜一大把。我自己也这么以为，直到看见同事怎么处理商品图。

她要做的事很简单：一批商品图抠白底、换背景、压到平台限制的体积以内。两条路她都试过。

开 PS——机器上装着，但为了抠十几张图启动一次，等软件加载完人已经不想干了。何况她不是设计岗，PS 那套东西对她来说太重，会用的功能不到 5%。

用在线 AI 工具——传图、排队、等结果，一张图从上传到下载好几十秒。赶上高峰期更慢。等出来的图还不一定合心意，边缘没抠干净就得重来一遍，再等一轮。

她的原话大概是：就想快点弄完，不想为这点事装个软件，也不想干等着。

这句话里没有一个技术词，但它把问题说清楚了：现有方案要么太重，要么太慢。而这两件事，恰好都不是算法问题。

重和慢，卡在哪

先说慢。在线 AI 工具的链路是这样的：

选图 → 上传（受你的上行带宽限制）→ 排队（受服务器负载限制）
     → 处理 → 下载 → 拿到结果

真正干活的只有「处理」那一环，前后全是等待。上行带宽通常远小于下行，传一张几兆的图本身就要几秒；排队则完全看运气。

再说重。装机软件的启动成本是固定的——不管你要处理 1 张还是 100 张，都得先等它起来。对高频重度用户这个成本可以摊薄，对偶尔处理十几张图的人，它就是纯损耗。

所以我想的方案很朴素：能不能把处理这一步搬到用户自己的浏览器里。上传没有了、排队没有了、装机也没有了，剩下的只有处理本身。

这就是整个项目唯一的前提。后面所有的取舍——包括做不到的部分——都是从这一条推出来的。

（工具后来叫图映，英文名 ImgIng，地址是 imging.cn。下文提到具体实现时就直接用这个名字了。）

第一个连锁反应：能力得实测，不能查表

把处理放本地，第一件事是搞清楚浏览器到底能干什么。这里我踩了个坑。

想让 canvas 输出 WebP，代码是这样：

canvas.toBlob(blob => {
  download(blob, 'output.webp');
}, 'image/webp');

回调正常触发，blob 不是 null，大小也合理。看起来一切正常，除了它可能根本不是 WebP。

HTML 规范明确规定：如果用户代理不支持请求的类型，它必须用 PNG 格式来创建这个文件。不报错、不警告，静默换掉。我是收到用户反馈说文件打不开、拿十六进制一看开头是 89 50 4E 47（PNG 的魔数）才发现的。

那能不能查 UA 判断？不行。iOS 上所有浏览器内核都是 WebKit，微信里的 WebView 版本跟随系统，用户还能开「请求桌面网站」把 UA 变成 macOS。UA 回答的是「你是谁」，我要问的是「你现在能不能编这个格式」——中间隔着内核版本、系统版本、宿主 App、编译选项。

更麻烦的是，canvas 编码根本没有能力查询接口。音视频那边有 MediaRecorder.isTypeSupported()，图像这边什么都没有。

所以只能实测：真编一次，然后核对返回的类型。

const blob = await new Promise(r => canvas.toBlob(r, mime));
const ok = !!blob && blob.type === mime;   // 关键在后半句

我在桌面 Chrome 上把几个格式跑了一遍：WebP、JPEG 正常输出；AVIF、HEIC、TIFF、GIF 全部回退成 PNG，而且四个返回的 blob 大小一模一样——因为本来就是同一张图。只判断 blob 是否为 null 的话，六个格式全部「成功」。

界面上那三种颜色就是这么来的：实心是浏览器原生能干、零上传；描边是首次要下载 WASM 编解码器、之后仍在本地；灰框才是端侧确实做不了、要交服务端的。

读的方向同理，能读不等于能写。Safari 16 能解码 AVIF 但编不出来。所以我的规则是：输入能解、输出能编，两头都成立才走本地。图映界面上那个「即时 / 端侧⤓ / 服务端」标签，就是这么实测出来的，不是按浏览器型号查表填的。

往下推：能本地做的比我预想的多

原本只打算做格式转换和压缩，做着做着发现边界比想象中远。

压缩这块，PNG 减到 256 色需要给每个像素在调色板里找最近颜色，160 万像素乘 256 个候选是 4.1 亿次距离计算，我实测暴力算法要 958 毫秒——在浏览器里等于卡死。教科书做法是做高位量化查找表，12 毫秒，快 77 倍，但我验了一下正确性：14.57% 的像素选错了颜色，因为查找表本身是近似的。

后来数了下那张图：160 万像素只有 18 万种唯一颜色，89% 的计算是重复劳动。改成按完整 RGB 缓存，153 毫秒，比暴力快 6 倍，误差为零。绕一圈才明白，问题不是需要更聪明的数据结构，是我没意识到重复率这么高。

图映会自己判断内容类型给推荐画质——这张高纹理测试图被判成「纹理」档、默认 WebP 画质 80，3.19 MB 压到 280.6 KB，结果那行还写着用的是原生 libwebp 编码。

动图是意外收获。GIF、APNG、动图 WebP、动图 AVIF 四种格式的编码器最后都自己实现了，还能逐帧编辑——拖拽排序、调单帧时长、删帧。压已有动图时每帧时长和循环方式会读出来保真，不会压完节奏全乱。

AI 抠图是我原本最不看好的一块，觉得浏览器跑模型是个玩具。实际是：模型按需下载（快速档约 42 MB，另有 219 MB 和 447 MB 两档），推理优先走 WebGPU、不支持时降级 WASM。模型下完浏览器会缓存，之后再抠图是秒级的事。

这一条正好回应了同事那个「慢」的抱怨——链路里没有上传、没有排队，第二次开始连模型都不用下。

再往后还长出了多页在线做图（一个工程最多 24 页）、PDF 压缩、PDF 转 HTML。功能是一路加的，但加法的依据始终是同一条：这件事能不能在本地做完。

推到头的地方

约束往下推总会撞墙，撞到的地方也是这条约束的结果，得说清楚。

HEIC 只能读不能写。 读通过 libheif 的 WASM 版本在本地完成；写卡在 HEVC 编码——专利授权是明摆着的坑，能用的编码器编译成 WASM 体积也大，为一个使用频率不高的输出格式让所有人先下几兆，不划算。这块交服务端，界面上直接标出来。

PDF 压缩不做字体子集化，所以纯文字排版的 PDF 通常只有 5%–20% 的收益，这类文件专业排版工具更强。它的主场是扫描件和图文报告。

PDF 转 HTML 转出来可能更大。 它把页面重建成固定版式 SVG、文字可以选中，但内容流展开成静态 SVG 之后体积是有可能超过原文件的，工作台会把实际体积解释给你看。

这些都不好看，但藏起来更糟——用户用两次就会发现，那时候丢的是整个工具的可信度。

两个顺带的结果

第一个是图片没有上传过。这不是出发点，是把处理放本地之后自然得到的。常见格式的转换、压缩、抠图全程不产生上传请求，你可以按 F12 打开 Network 面板自己验：会看到 WASM 编解码器和 AI 模型下载下来，看不到图片传上去——这两件事方向是反的。

对同事那批还没上架的商品图来说，这个副产品比我想的有用。

第二个是没有服务器成本。处理跑在用户的机器上，我这边只是静态文件分发，你转一千张和转一张对我完全一样。所以没有理由去限次数、加水印、要注册。上传型工具不是不想免费，是每次转换对它们都是真金白银的 CPU 时间。

所以为什么还要再做一个

回到开头那个问题。图片处理工具确实成熟了，但成熟的是能力，不是获取能力的方式。

PS 的能力比图映强得多，代价是装机和学习成本；在线 AI 站的模型可能也不比图映差，代价是把图传出去然后等着。这两条路对「偶尔处理十几张图」的人来说都不划算——不是功能不够，是为了用上这些功能要付的代价太高。

把处理搬进浏览器，本质上是把这个代价降到接近零：打开网页就是全部安装过程，不排队不上传就是全部等待。至于能力上限受限于浏览器——那是这个选择必须付的价，我在上面几节里把它划清楚了。

图映的地址是 https://imging.cn ，打开就能用，不用注册，也没有次数限制。