主 题：做一个跑在浏览器里的图片处理工具，我改过几次主意
发 布 者：Lank
标签分类： 技术
时 间：2026-08-24 10:33:53
内容预览：上次在 Dev 板块有朋友发过一次 imging.cn，这回不聊功能，说说做的过程。一开始觉得这事不难——浏览器有 canvas，有 WebAssembly，把图读进来处理完写出去，能有多复杂。真做下去发现，我以为对的地方基本都不对。随手记几个。我以为没报错就是成功了canvas.toBlob(cb, 'image/webp') 如果浏览器不支持 WebP 编码，它不报错，也不给你 null，直接返回一个 PNG，文件名还是你写的 .webp。我是收到反馈说文件打不开，拿十六进制一看魔数是 89 50 4E 47，才发现的。翻规范才知道这是标准要求的行为：不支持就用 PNG 生成，还不用通知调用方。唯一能看出来的地方是 blob.type。顺手把几个格式在桌面 Chrome 上试了一遍：WebP、JPEG 正常，AVIF、HEIC、TIFF、GIF 全部回退成 PNG，而且四个返回的 blob 大小一模一样，都是 95 字节——本来就是同一张图。只判断 blob 是不是 null 的话，六个格式全部"成功"。顺带一提，桌面 Chrome 编不出 AVIF，虽然它解码 AVIF 毫无压力。我一直以为这是移动端才有的毛病。我以为查找表是标准答案PNG 减到 256 色，每个像素得在调色板里找最近的颜色。160 万像素乘 256 个候选，4 亿次距离计算，实测 958 毫秒，在浏览器里基本等于卡死。教科书做法是做个高位量化查找表。试了一下 12 毫秒，快 77 倍，正高兴，顺手验了下正确性——14.57% 的像素选错了颜色，因为查找表本身是近似的。后来数了数那张图：160 万像素，唯一颜色只有 18 万种，89% 的计算是重复劳动。改成按完整 RGB 缓存，153 毫秒，比暴力快 6 倍，误差为零。绕一圈才明白，问题不是要更聪明的数据结构，是我压根没意识到重复率这么高。我以为帧间
直达链接： https://www.nodeseek.com/post-890820-1
发 布 者：Lank
标签分类： 技术
时 间：2026-08-24 10:33:53
内容预览：上次在 Dev 板块有朋友发过一次 imging.cn，这回不聊功能，说说做的过程。一开始觉得这事不难——浏览器有 canvas，有 WebAssembly，把图读进来处理完写出去，能有多复杂。真做下去发现，我以为对的地方基本都不对。随手记几个。我以为没报错就是成功了canvas.toBlob(cb, 'image/webp') 如果浏览器不支持 WebP 编码，它不报错，也不给你 null，直接返回一个 PNG，文件名还是你写的 .webp。我是收到反馈说文件打不开，拿十六进制一看魔数是 89 50 4E 47，才发现的。翻规范才知道这是标准要求的行为：不支持就用 PNG 生成，还不用通知调用方。唯一能看出来的地方是 blob.type。顺手把几个格式在桌面 Chrome 上试了一遍：WebP、JPEG 正常，AVIF、HEIC、TIFF、GIF 全部回退成 PNG，而且四个返回的 blob 大小一模一样，都是 95 字节——本来就是同一张图。只判断 blob 是不是 null 的话，六个格式全部"成功"。顺带一提，桌面 Chrome 编不出 AVIF，虽然它解码 AVIF 毫无压力。我一直以为这是移动端才有的毛病。我以为查找表是标准答案PNG 减到 256 色，每个像素得在调色板里找最近的颜色。160 万像素乘 256 个候选，4 亿次距离计算，实测 958 毫秒，在浏览器里基本等于卡死。教科书做法是做个高位量化查找表。试了一下 12 毫秒，快 77 倍，正高兴，顺手验了下正确性——14.57% 的像素选错了颜色，因为查找表本身是近似的。后来数了数那张图：160 万像素，唯一颜色只有 18 万种，89% 的计算是重复劳动。改成按完整 RGB 缓存，153 毫秒，比暴力快 6 倍，误差为零。绕一圈才明白，问题不是要更聪明的数据结构，是我压根没意识到重复率这么高。我以为帧间
直达链接： https://www.nodeseek.com/post-890820-1
