图片压缩工具

在线图片压缩用于降低图片文件体积，从而加快网页加载、满足上传大小限制，并减少分享和传输时的带宽消耗。文件会上传到 ToolAct 的转换服务，由服务端的图像处理库（libvips、mozjpeg、libwebp 等）完成解码与重新编码，再把压缩结果回传到浏览器；处理完成后原文件会立即从服务器删除，不做归档，不用于训练。不同格式会涉及画质、元数据、色彩信息和编码参数的取舍，一张照片可能明显变小，但在正常展示尺寸下仍然保持可接受的观感。它适合博客配图、商品图、社交媒体图片、客服附件和不需要保留原始像素的草稿素材。若用于打印、长期归档或精细视觉检查，压缩后仍应确认文字、边缘和纹理是否受影响。请勿上传包含个人身份信息、内部资料或其它敏感内容的图片。

图片压缩沿有损/无损边界清晰划分。有损格式（JPEG、WebP 有损）利用人类感知限制：人眼对高频色度的敏感度远低于亮度，因此编码器在 8x8 或 16x16 块中丢弃微小的色彩细节，大多数观看者不会察觉。JPEG 自 1992 年以来一直使用这种基于 DCT 的路径；现代替代方案有 mozjpeg（在相同 SSIM 下比 libjpeg 小约 5-10%，编码器较慢）、libwebp（Google 的 VP8/VP8L 图像编解码器，2010 年）和 AVIF（开放媒体联盟，AV1 帧内编码，2019 年）。无损格式（PNG、GIF、WebP 无损）通过熵编码——LZ77 滑动窗口字典加霍夫曼或算术编码——来缩减字节，不会改变任何一个像素。 本工具的处理流程完全在服务端完成。浏览器把每张图片以签名鉴权的多部分上传发送到 ToolAct 的压缩接口（/image/compress）。服务端校验请求后将字节流交给 libvips——一款流式、按需求驱动的高性能、低内存图像处理库——它解码源文件，按需缩放长边以约束输出尺寸，再分别通过 mozjpeg（JPEG）、libwebp（WebP）或 libpng/oxipng（PNG）重新编码。编码后的字节直接以下载响应的形式回传浏览器，临时上传文件会在响应写出后立即从磁盘删除。流程中没有归档、没有训练管道、也没有人工查看上传内容。 JPEG 量化是格式的核心：质量 90 保留几乎所有 DCT 系数，75 开始丢弃中频系数（在红色文字黄色背景上可见），50 是明显的 JPEG 区域，平滑渐变上出现块状伪影，25 在人脸上产生可见的色阶断裂。PNG 压缩基于 zlib（DEFLATE）级别 0-9；级别 1 速度快但文件较大，级别 9 在纯色横幅上挤出最后几个字节但消耗 CPU。EXIF、ICC 配置文件、XMP 和 IPTC 元数据通常会在重新编码时被丢弃，因为编码器从零重建文件头部——这是 200 KB 的相机照片在相同分辨率下变成 60 KB 上传的真正原因，也是图像来源和色彩管理元数据如果重要的话应该单独保存的原因。

• libvips（John Cupitt，LGPL）是服务端的图像处理引擎：流式、按需求驱动的管道，即使处理 1 亿像素输入也能保持低内存占用，是 Sharp、ImageMagick 的 IM7 vips 委托以及本工具背后转换接口的基础。
• mozjpeg（Mozilla，libjpeg-turbo 分支，具有更好的心理视觉模型）在相同 SSIM 下比原版 libjpeg 产生小 5-10% 的文件，但编码速度慢约 3-5 倍——这是 2017 年以来大多数网站使用 JPEG 质量 80-85 默认值背后的权衡。
• PNG 是 LZ77 + 霍夫曼：编码器在 32 KB 滑动窗口内查找重复字节序列，输出（距离、长度）对，然后霍夫曼编码结果。WebP 无损（VP8L）使用类似思路加局部调色板补丁，通常比 PNG 在相同 RGBA 像素上节省 20-26%。
• libwebp 是 Google 的 WebP 参考编解码器；服务端用它输出有损 VP8（质量 0-100，默认 4:2:0 色度）或无损 VP8L（质量参数控制压缩力度而非像素保真度）。WebP 解码广泛可用（Chrome 32+ 2014 年、Firefox 65+ 2019 年、Safari 14+ 2020 年），转出的 WebP 几乎在所有现代浏览器中都能正常显示。
• JPEG 中 4:2:0 色度子采样的默认设置（每 4 个亮度采样 2 个色度采样）是质量 60 时黄色背景上的红色文字看起来模糊的原因——色度细节在亮度细节之前被丢弃。对于截图和 UI 截取等文字边缘重要的场景，切换到 4:4:4（无子采样）。
• EXIF（可交换图像文件格式，JEITA CP-3451）和 ICC 色彩配置文件在重新编码时默认会被剥离，因此 6.3 MB 的 iPhone JPEG 经过服务端处理后通常只有 1.8 MB。这就是消费级摄影师在每次通过 Web 工具往返后看到文件大小下降的原因。 实际的批量陷阱：当文件夹混合小图标（200x200 px 以下，带 alpha 的 PNG）、纯色 UI 截图（PNG，可压缩性极高）和手机照片（JPEG，主要是噪声内容）时，单一的质量滑块对三者都不合适。图标需要无损 PNG 或 WebP 无损；截图需要 4:4:4 JPEG 质量 85-90；照片需要有损 WebP 质量 75-80。全部用质量 60 压缩虽然节省字节，但会在图标上引入红色边缘、截图上出现振铃伪影、照片上出现色阶断裂。更智能的管道为每种类别运行不同的编码器路径，这就是接口允许为每个文件单独覆盖目标格式的原因。 展望未来，JPEG XL（ISO/IEC 18181，2022 年）是 Google 和 Cloudflare 自 2020 年以来一直在推动的 JPEG 继承者：相同质量下小约 20%、完整无损模式、无色度子采样、渐进式解码适合慢速网络。浏览器支持尚不完整（Chrome 在 110 版本禁用了 JPEG XL），因此目前的实际迁移路径是 WebP 质量 80，需要额外字节节省的首屏大图使用 AVIF，旧版 Safari 或较老的邮件客户端保留 JPEG 回退。页面暴露质量、最大尺寸和目标格式作为三个关键控制参数；其余都是实现细节。
• 服务端转换生命周期：每个上传文件仅在 libvips 解码 + 重新编码并将结果流式回传期间存在；无论转换成功还是失败，临时文件都会在响应关闭时删除。原本会让浏览器主线程卡顿 200-500 毫秒的 24 MP JPEG 完全在用户设备之外完成处理。
• 迁移方向：AVIF 是下一代目标（开放媒体联盟，AV1 帧内编码，支持 10/12 位、alpha、动画）。即便在服务端通过 libavif/aom 进行 AVIF 编码，速度仍比 WebP 慢 10-30 倍，因此大多数页面坚持使用 WebP 质量 80，将 AVIF 留给受益于额外 15-20% 字节节省的首屏照片。