支持的图片格式与尺寸限制
把一张图交给工具之前,先确认它落在可处理的范围内。这一页把所有会影响结果的规则集中列出,包括格式、尺寸、透明通道、动图与元数据。
格式支持一览
| 格式 | 能否读入 | 处理后的变化 |
|---|---|---|
| JPEG / JPG | 可以 | 重新编码为质量 100 的 JPEG |
| PNG | 可以 | 透明区域合并为白色,输出 JPEG |
| WebP(静态) | 可以 | 输出 JPEG,体积通常变大 |
| WebP / GIF(动图) | 可以,只取第一帧 | 动效丢失,变为静态图 |
| BMP | 可以 | 无损位图会显著变小 |
| AVIF | 较新浏览器可以 | 输出 JPEG |
| SVG | 部分浏览器可以 | 矢量图会被光栅化,且尺寸可能异常,不建议 |
| HEIC / HEIF | 多数桌面浏览器不可以 | 请先转成 JPEG |
| 相机 RAW(CR2/NEF/ARW 等) | 不可以 | 请先用图像软件导出 JPEG |
尺寸上限怎么算
共有三条约束,任意一条被突破,图片就会在导入阶段被等比缩小:
- 像素总数不超过 8,000,000(约 800 万);
- 宽度不超过 4000 像素;
- 高度不超过 4000 像素。
缩放倍数取三条约束算出的最小值,因此不会出现拉伸变形。下面是一些常见尺寸的判定结果:
| 原始尺寸 | 像素数 | 是否缩放 | 处理尺寸 |
|---|---|---|---|
| 1080 × 1920(手机竖屏) | 207 万 | 否 | 保持原样 |
| 1920 × 1080(桌面截图) | 207 万 | 否 | 保持原样 |
| 3024 × 4032(常见手机主摄) | 1219 万 | 是 | 约 2999 × 4000 |
| 4000 × 3000(相机 JPG) | 1200 万 | 是 | 约 3266 × 2449 |
| 6000 × 4000(全画幅) | 2400 万 | 是 | 约 3464 × 2309 |
| 8000 × 1000(超宽长图) | 800 万 | 是(单边超限) | 约 4000 × 500 |
还原操作恢复的是“处理时那张图”的排布,而不是你最初的文件。如果你需要的是原始分辨率, 请先用本地软件裁到上限以内,再交给工具处理。
透明通道与动图
输出格式固定为 JPEG,它没有透明通道:PNG 里的透明区域在与白色背景合成后会变成白块。 如果你的图片依赖透明(例如 logo、贴纸、图标),混淆后的结果会有明显白底,这是格式决定的,不是算法问题。
动图同理:画布只读取第一帧,GIF 与动图 WebP 会变成一张静态的混淆图。 如果你需要处理动图,请先把它拆成单帧图片,逐帧处理后再重新合成。
元数据的去留
| 信息 | 处理后 | 说明 |
|---|---|---|
| 像素内容 | 保留(顺序被重排) | 颜色值本身没有被修改 |
| 拍摄时间、机型、光圈等 EXIF | 丢弃 | 画布重绘不会带回原文件的元数据 |
| GPS 位置 | 丢弃 | 同样因为不写入 EXIF |
| 色彩配置文件(ICC) | 丢弃 | 颜色按浏览器解码结果写入 sRGB 字节流 |
| 图片方向标记 | 烘焙进像素 | 手机竖拍照片不会颠倒,但方向标记本身不再存在 |
| 色深(16 位 / HDR) | 降为 8 位 | 画布接口按 8 位每通道处理 |
为什么统一导出 JPEG
三个原因:一是 JPEG 的兼容性最好,任何聊天软件、社交平台、办公软件都不会拒收; 二是重排后的画面是均匀噪声,这类内容的 JPEG 压缩效率很高,体积通常比原图更小,发送更快; 三是画布接口对 JPEG 的支持在所有浏览器上都稳定,不需要为不同格式写分支逻辑。
代价是有损。质量参数已经开到最高,正常观看完全看不出差别,但它终究不是逐位无损。 如果你需要严格无损,本站不适合作为最终产物,可以只把它用于“快速遮挡”这一环节。
超大图的处理策略
- 先裁再处理。全景照片往往只有一小块是重点,先裁掉无关区域,画质与速度都会更好。
- 分批处理。超过 20 张大图时,用批量处理页分几批走,避免同时占用大量内存。
- 优先用桌面端。手机的可用内存只有桌面的几分之一,800 万像素在手机上属于压力测试。
- 关闭其他标签页。浏览器内存吃紧时,最先被系统回收的就是占用最大的页面。
处理前检查清单
- 文件是浏览器能解码的格式吗?(HEIC、RAW 请先转换)
- 像素数在 800 万以内、单边在 4000 像素以内吗?
- 图片里有依赖透明通道的元素吗?
- 是动图吗?需要保留动态效果吗?
- 原图有单独备份吗?
- 真的不该用加密而是用混淆的场景吗?(见安全边界说明)