Windows 无损压缩图片：什么是“已验证无损”
了解 Windows 上已验证的无损图片压缩：GIF 体积缩小 92%、PNG 精确副本回退、截图，以及 LocalFlux 1.0.7 的实测证据。
本页内容
如果你想在不改变图片内容的情况下减小体积，难点并不是选择一个名为 Lossless 的设置。难点在于证明新文件仍然表示相同的内容，并确定软件在无法证明这一点时应该怎么做。
LocalFlux 1.0.7 通过一种“验证不通过则保留原始字节”的流程处理这种不确定性。它先在本地创建优化候选文件，再检查格式特定的内容和元数据不变量；只有这些检查通过，才会发布修改后的候选文件。如果候选文件无法验证，或体积没有变小，LocalFlux 会将源文件精确复制到一个新的 _optimized 文件名下。
精确复制也要求源文件可读、目标位置可写。解码、验证或写入错误仍可能导致任务失败，请先检查每个文件的状态。
我使用存放在 C:\tmp 下的合成文件测试了这两个分支：
- 一个刻意低效的 12 帧 GIF 从 658,785 字节变为 54,329 字节，节省 604,456 字节（91.8%）。LocalFlux 报告 无损验证，并且全部 12 个渲染帧及每帧延迟都一致。
- 一个已经优化过的 PNG 仍为 8,290 字节。LocalFlux 报告 已优化；源文件和输出文件的 SHA-256 哈希相同，因此输出是逐字节完全相同的副本。
这些例子说明了这个标签的本意：LocalFlux 不会把“转换完成”等同于“结果无损”，也不会承诺每个输入文件都会变小。
实测示例，不代表普遍节省： 无损优化取决于源格式、容器结构、元数据、之前的编码方式，以及图片或动画内容。有效结果可能大幅变小、略微变小，也可能在没有任何体积减少的情况下成为精确副本。
简短答案
要在不刻意改变内容的情况下优化受支持的图片：
- 打开 LocalFlux，选择 压缩。
- 添加一个或多个受支持的 JPEG、TIFF、静态 PNG 或 WebP、GIF、APNG 或 SVG 文件。
- 打开 选项，选择 Lossless。
- 选择 优化。
- 查看每个结果，确认显示 无损验证，并且体积有所减少，或显示 已优化。
LocalFlux 会创建一个文件名中带 _optimized 的新文件。源文件会保留原位。处理在 Windows 电脑上运行；文件不会上传到在线转换服务。
界面截图于2026年10月使用根据已记录的 LocalFlux 1.0.10.0 发布源码重新构建的版本拍摄。下方历史测量值和下载资料仍保留原始测试范围。截图记录： 1
2026年10月复核：10种界面语言共生成20个输出，均与历史 GIF、PNG 输出逐字节一致。GIF 含12帧，每帧100 ms，渲染结果及循环设置一致；GIF 延迟值10表示10/100秒。界面的 KB 数值使用1024字节单位（KiB）。这些结果仅验证两个合成样本，不代表验证了所有格式或元数据字段。 2026-10
新截图中的选项卡仍显示英文：Lossless（无损）、Preset（预设）、Target size（目标大小）。
“已验证无损”是什么意思
“无损”常被用来描述编码器设置；“已验证无损”则描述了一份更严格的结果契约。
在 LocalFlux 的这一流程中，修改后的候选文件必须满足三个条件：
- 受支持的内容检查通过。 根据格式不同，这可能包括解码后的像素、动画的每个渲染帧、每个 TIFF 页面、时序、尺寸或几何信息。
- 受支持的内嵌元数据检查通过。 具体字段因容器而异。LocalFlux 会比较它为该路径承诺保留的元数据，而不是假设成功编码就保留了全部元数据。
- 候选文件确实更小。 如果已验证的候选文件没有节省字节数，替换源文件表示方式就没有实际优化价值。
只要有一个条件不满足，修改后的候选文件就不会作为优化结果发布。LocalFlux 会把源文件字节恢复到新的输出路径，并报告 已优化。
最后这一点很重要。工具很容易生成一个不同但在快速预览中看起来相同的文件。要证明差异在像素、页面、帧、时序和元数据层面都没有问题，则要困难得多。当证据不完整时，LocalFlux 的策略选择保守结果。
LocalFlux 按格式验证的内容
不同图片容器需要不同的不变量。单纯“比较宽度和高度”的规则会遗漏太多内容。
| 格式 | LocalFlux 1.0.7 的验证重点 | 重要的回退行为 |
|---|---|---|
| JPEG | 解码像素签名，以及原始 APP 和 COM 元数据段 | 编码表优化可能在某些输入上改变解码值，因此无法证明等价时会回退为精确副本。 |
| 静态 PNG | 解码像素签名，以及受支持的颜色、EXIF、XMP、文本和物理元数据块 | 最终比较前会保留必需的辅助元数据；无法验证的候选文件会被丢弃。 |
| 静态 WebP | 解码像素签名，以及受支持的内嵌元数据块 | 只有内容和元数据比较通过且文件更小时，才会发布候选文件。 |
| TIFF | 每个解码页面、像素签名、页面几何信息和受支持的元数据 | 包含已验证像素存储集合以外标签的 TIFF 会原样复制，而不会冒险造成标签静默丢失。 |
| GIF | 每个合并后的渲染帧、帧延迟、循环次数，以及保留的注释/应用程序/纯文本扩展 | 只有渲染动画和受支持扩展仍然等价时，才接受帧优化。 |
| APNG | 规范化的逐帧哈希、时序、帧数、循环次数，以及保留的 PNG 辅助元数据 | 任何不匹配或无法验证的结果都会触发精确源文件回退。 |
| SVG | 源文件字节本身 | Lossless 模式下 SVG 会逐字节复制。只有在接受保守移除注释和仅供编辑器使用的数据时，才使用单独的 Safe vector optimization 预设。 |
因此，也不应把 已验证 延伸解释为：每种文件格式中所有可想象的属性都已经在数学上证明等价。它指的是 LocalFlux 1.0.7 针对其受支持路径检查的明确内容和元数据不变量。
保护隐私的测试设置
测试使用 Windows 上实际运行的 LocalFlux 1.0.7.0 Microsoft Store 应用。没有使用个人照片、客户文件、用户名或项目文件夹。原始1.0.7测试使用下列文件夹；新截图使用 C:\tmp\LocalFluxBlogRefresh：
C:\tmp\LocalFlux-lossless-proof-v107\input
两个证据案例由合成的仪表盘图稿创建：
| 案例 | 输入 | 用途 |
|---|---|---|
| 可缩减动画 | dashboard-animation-repeated-frames.gif | 十二个相同的全尺寸帧刻意制造帧存储冗余，让已验证的动画优化器可以移除这些冗余。 |
| 已优化对照组 | already-optimized-icon.png | 使用紧凑 PNG 测试无节省和精确副本分支。 |
GIF 是刻意制作的人工文件。它很有用，因为预期内容没有歧义：12 帧，每帧都是相同的 1920 × 1080 渲染图像，并且每帧延迟值都是 10。它测试的是验证契约，而不是假装代表典型的动画压缩比例。
第 1 步：添加受支持的图片
打开 LocalFlux，选择 压缩，然后选择 添加文件，或将文件拖入队列。
1.0.7 的 Lossless 模式支持 JPEG、TIFF、静态 PNG 和 WebP 图片、GIF 和 APNG 动画，以及 SVG 文件。PNG 和 WebP 之所以强调静态，是因为动画内容需要具备动画意识的验证。APNG 和 GIF 也有各自受支持的路径。
你可以一次将多个兼容文件加入队列。LocalFlux 会在 压缩模式中保留每个文件的格式：PNG 仍为 PNG，GIF 仍为 GIF，依此类推。这不同于 转换模式，后者会为当前批次选择一种输出格式。
开始前，确认队列中是预期文件，并确认左下角模式显示 压缩。
第 2 步：选择 Lossless
打开 选项，选择 Lossless 标签页。
界面会直接说明这一契约：只有在内容和内嵌元数据验证通过后，才会优化受支持文件；不受支持的文件会被跳过。操作按钮会从 压缩 变为 优化。
本次测试不要启用 安全共享。安全共享 是另一种流程，目的是从交付副本中移除私密元数据。Lossless 优化则尝试保留受支持的内嵌元数据。这两个目标是有意区分的：
- 当你想在不刻意改变受支持内容或元数据的情况下获得更小的表示形式时，选择 Lossless。
- 当你想要经过清理的副本，并接受有意移除元数据时，选择 安全共享。
第 3 步：在本地运行优化
选择 优化，等待队列完成。当输出摘要显示 输出：与源文件相同 时，LocalFlux 会将输出写在源文件旁边。
例如：
dashboard-animation-repeated-frames.gif会变成dashboard-animation-repeated-frames_optimized.gif。already-optimized-icon.png会变成already-optimized-icon_optimized.png。
原始文件名仍然存在，因此可以进行比较；但这不能替代为重要工作保留适当的备份。
处理路径是本地的。安装、Microsoft Store 授权或更新仍可能涉及联网，但在此操作中源文件不会发送到远程转换服务器。
结果 1：真正变小且已验证的文件
12 帧 GIF 产生了明显的缩减案例：
| 测量项 | 源文件 | LocalFlux 输出 |
|---|---|---|
| 精确大小 | 658,785 bytes | 54,329 bytes |
| 显示大小 | 643.3 KB | 53.1 KB |
| 帧数 | 12 | 12 |
| 尺寸 | 1920 × 1080 | 1920 × 1080 |
| 每帧延迟序列 | 100 ms × 12 | 100 ms × 12 |
| 节省字节数 | 不适用 | 604,456 bytes |
| 缩减比例 | 不适用 | 91.8% |
源文件和输出文件的 SHA-256 哈希不同，这是容器表示发生变化时的预期结果：
- 源文件：
202D74DFBBEA150AE514BBE064602F73F150BAB438B39269371013D71F68B0D2 - 输出文件：
BE4170949D86B8E0819A181A25DDD3718BF2AD79E7C1E80F8B9D4D60017B2C02
不同的哈希并不与无损验证矛盾，它们证明文件字节发生了变化。相关问题是解码后的动画和受支持的元数据是否仍然等价。LocalFlux 报告内容和内嵌元数据得到保留；单独的渲染帧比较也发现前后帧签名相同。
为什么缩减幅度如此之大？源文件刻意存储了 12 个完整的重复帧。优化后的 GIF 可以更高效地表示这种重复。真实动画如果每一帧的大部分区域都在运动，节省的体积可能小得多。
结果 2：精确副本回退
8,290 字节的 PNG 没有产生任何通过契约检查且更小的候选文件。LocalFlux 报告：
无损验证 · 8.1 KB → 8.1 KB · 已优化
结果并不是因为显示单位四舍五入后恰好相同。两个文件都精确地是 8,290 字节，并且都有以下 SHA-256 哈希：
F287BBCE8EB98A9F19416DCE1A74A759F3AC8DDA69ADB338022CB1B8F90BD937
匹配的哈希证明输出是输入的逐字节副本。LocalFlux 仍会创建 _optimized 输出，这样批处理就能以可预测的目标路径完成，但它不会声称存在并不存在的节省。
“已优化”可能表示编码器找不到更小的候选文件，也可能表示修改后的候选文件无法满足验证契约。从用户角度看，安全结果相同：源文件字节成为输出文件字节。
为什么一些看起来低效的文件仍会变成精确副本
文件看起来低效，并不意味着它一定能产生可发布的已验证候选文件。体积本身并不够。
例如，重新编码器可能会：
- 将解码后的某个像素值改变极小的一点；
- 以不等价的方式重写颜色信息；
- 删除或重新排列验证器要求保留的元数据；
- 改变 GIF 时序或处置行为；
- 遗漏不熟悉的 TIFF 标签；或者
- 创建一个有效但更大的容器。
传统优化器可能接受其中一些取舍。经验证的无损 模式不会。它宁可使用精确副本，也不会发布未经证明的修改。
这也解释了为什么 JPEG 经常进入回退分支。JPEG 通常与有损编码相关。LocalFlux 的无损尝试会聚焦于编码表优化，同时要求解码像素签名和原始 APP/COM 元数据保持等价。如果捆绑的编码器改变了解码值，即使在正常缩放下看起来完全一样，候选文件也会被拒绝。
无损、预设与目标大小的区别
LocalFlux 提供三种不同的压缩意图。不要把它们当作“让文件变小”的同义标签。
| 策略 | 主要目标 | 图片内容是否可能有意改变？ | 是否保证结果更小？ |
|---|---|---|---|
| Preset | 平衡视觉质量和体积 | 是，取决于格式和预设 | 否 |
| Target size | 尝试低于选定的字节数上限 | 是；质量，有时还有尺寸，可能会在策略允许范围内降低 | 否。目标可能无法实现 |
| Lossless | 保留已验证的内容和受支持的元数据 | 除非验证通过，否则不会发布修改后的候选文件 | 否。精确副本回退是有效结果 |
当你可以接受小幅且可控的视觉取舍时，用预设制作网站交付副本。需要满足上传表单或附件大小上限时，用目标大小。保留已验证的内容契约比最大化缩减更重要时，用 Lossless。
可以批量进行已验证的无损优化吗？
可以。第一张截图展示了队列中混合的两个受支持文件。同一策略会应用于兼容的待处理项目，同时每个文件保留当前格式。
批处理的价值不在于每个项目都得到相同的缩减比例，而在于每个项目都采用相同的决策政策：
- 尝试适用于该格式的优化；
- 验证受支持的不变量；
- 只有更小时才保留修改后的候选文件；以及
- 否则发布精确副本。
之后查看每个文件的行。一批结果中完全可以同时出现大幅缩减、小幅缩减，以及多个已优化副本。
查看证据
本文的发布材料包含合成输入、LocalFlux 输出、精确测量值，以及文章使用的哈希：
- 测试记录
- 逐文件结果和 SHA-256 值
- 隐私审查
- 包含文件大小和 SHA-256 值的媒体清单
- 可缩减的合成 GIF 输入
- 已验证的较小 GIF 输出
- 已优化 PNG 输入
- 精确副本 PNG 输出
所有可见路径和文件名都是合成的。截图已经过审查，排除了用户名、账户详情、个人文件夹、客户名称和其他可识别信息。
常见问题
已验证无损是否意味着每个文件都会变小？
不是。它表示 LocalFlux 只有在受支持的内容和元数据检查通过后，才会发布修改后的候选文件。如果候选文件没有变小，或无法验证，输出就是精确副本。
为什么无损结果的哈希可能不同？
无损描述的是解码内容和受支持的不变量，而不是完全相同的容器字节。成功的优化器可以在不改变解码像素或帧的情况下重新组织压缩数据。相反，精确副本回退具有相同哈希，因为每个字节都相同。
显示“已优化”是失败吗？
不是。任务已安全完成。这只表示没有找到值得发布的、更小且已验证的表示形式。
原文件会被覆盖吗？
在本次测试的流程中不会。LocalFlux 会创建同目录下带 _optimized 的文件。无论如何，对于无法替代的源文件都应保留备份。
Lossless 模式会移除 EXIF 或位置元数据吗？
它的目标是保留，而不是清理。想要创建并验证一个移除私密元数据的副本时，请使用 安全共享。始终检查你实际准备分享的确切文件。
这个流程完全离线吗？
受支持的优化在电脑上运行，不会将源文件上传到转换服务器。通过 Windows 或 Microsoft Store 进行的安装、授权和更新仍可能使用网络。
支持哪些格式？
LocalFlux 1.0.7 支持对 JPEG、TIFF、静态 PNG 和 WebP、GIF、APNG 以及 SVG 进行已验证的无损优化。不受支持的项目不会被静默地当作已验证项目处理。
实用检查清单
优化前：
- 使用已备份的源文件；
- 确认文件受支持；
- 选择 压缩，再选择 Lossless；
- 除非你的实际目标是移除元数据，否则关闭 安全共享；以及
- 在处理整个归档前，先测试具有代表性的样本。
优化后：
- 查看每个完成行是否显示 无损验证；
- 区分真正的缩减和 已优化；
- 对重要动画比较帧数和时序；
- 在实际接收结果的目标应用中打开文件；
- 在确认输出前保留源文件；以及
- 记录精确字节数，不要只依赖四舍五入后的 KB 标签。
结果
已验证的无损优化之所以有价值，是因为它让不确定性变得可见。在这次 LocalFlux 1.0.7 测试中，一个合成 GIF 在保留已验证动画不变量的同时缩小了 91.8%。一个已经高效的 PNG 则节省 0%，转而生成逐字节完全相同的精确副本。
两者都是成功结果。前者移除了冗余存储，后者拒绝未经证明或没有意义的重写。它们共同展示了一个比“每张图片都会变小”更有用的承诺：只有在受支持的内容和元数据检查通过时，才会发布修改后的文件；检查不通过时，精确源文件就是回退结果。
技术参考资料
有关文件格式的说明参考了以下独立规范和平台文档。