回归 JPEG

回归 JPEG：2026-07-17 JPEG 文件的一项很酷的功能是可以选择首先保存低频分量。这意味着部分下载的图像将以低分辨率显示而不是被切断。在文件中，这是通过将压缩数据分解为多个“扫描”来实现的，每个“扫描”都带有一个标头前缀。这是代表性图像的第一次扫描： FF DA - “扫描开始”标记 00 0C - 大端长度字段（12 字节）包括自身 03 - 扫描中的通道数 (3) 01 - 第一个包含通道的全局 id 00 - 霍夫曼表索引 #1 (DC: 0, AC: 0) 02 - 第二个包含通道的全局 id 10 - 霍夫曼表索引 #2 (DC: 1, AC：0) 03 - 第三个包含通道的全局 ID 10 - 霍夫曼表索引 #2（DC：0，AC：0） 00 - 开始 DCT 仓（DC） 00 - 结束 DCT 仓（也是 DC） 01 - 精度：一半，无预先存在的数据。 f8ad 512d d3f1 cd96 - 霍夫曼编码的 DCT 系数 bcb0 58df 53d5 5d97 [...以及更多] ...这包括所有三个颜色通道的最低 (DC) 傅立叶箱。三个颜色通道是 YCbCr，而不是通常的 RGB。亮度 (Y) 是分开的，因为它必须是高质量的，但颜色在看起来不错的同时可能会被篡改很多。非常粗略地说：Y = G、Cb = B - G、Cr = R - G 之后，文件包含另外八次扫描来填充其余数据： 扫描数量 通道 DCT bin 范围 精度 0 Y Cb Cr 0 - 0 Half (-1 位) 1 Y 1 - 5 Quarter (-2 位) 2 Cb 1 - 63 Half 3 Cr 1 - 63 Half 4 Y 6 - 63 Half 4 Y 6 - 63 Quarter 5 Y 1 - 63 半 6 Y Cr Cb 0 - 0 全 7 Cr 1 - 63 全 8 Cb 1 - 63 全 9 Y 1 - 63 全扫描 #0 包含图像的分辨率非常低的预览。扫描 #1 为亮度添加了一些细节。第二到第五次扫描包含完整的低精度数据。扫描 4 具有不寻常的光谱范围，因为它填补了#1 留下的空白。这样，数字 5 就有了完整的四分之一精度数据可供构建。扫描六到九次添加最后缺失的位，使图像达到完整的质量。鉴于我所说的颜色不太重要，我的示例首先具有颜色数据可能看起来很奇怪：这是有效的，因为色度以一半分辨率（四分之一像素数）保存。因此，全色度数据 (Cr + Cb) 的重量仅为亮度数据的一半。由于每次扫描都明确设置其光谱范围，因此应该可以构建一个 JPEG 文件，其中未来的扫描将覆盖已经渲染的图像数据。实际上，这很容易做到：连接多个具有相同分辨率的图像并过滤掉图像开始、帧开始和图像结束标记。这可以在十六进制编辑器中完成，但我使用了一个快速而肮脏的 C 程序。当通过慢速网络提供服务时，这个串联文件将在多个图像之间切换：单击在新选项卡中打开但是，大多数解码器会在一定次数的扫描后放弃：我认为这样做是为了避免 zip 炸弹样式问题......但它阻止了它在超过 9 帧上工作，这对于正确的动画来说是不够的。为此，我必须最大限度地减少每帧中的扫描次数。最简单的想法是从只有一次扫描的基线 JPEG 开始。 ...但它不起作用：在渐进模式下，扫描不能同时包含 AC（高于 0 的 bin）和 DC（bin 0）数据。基线模式不存在此限制，但基线解码器在第一次扫描后停止。由于交流数据必须遵循直流数据，因此尽可能最小的“逐行”JPEG 包含单个仅直流扫描。由于 DCT 在 16x16 块上运行，因此此类图像不会是纯色：它将是原始分辨率的 1/16。扫描数量 通道 DCT bins 精度 0 Y Cb Cr 0 - 0 Full 这样做，我可以让 Chrome 在放弃之前渲染大约 90 帧。其他浏览器（例如 Firefox）有更多的耐心，但 90 度扫描图像似乎几乎在任何地方都可以工作。作为奖励，这避免了天真的尝试的重影：发生这种情况是因为 AC 扫描应该精炼旧数据。通常，这允许图像包含多个精度级别，而不会增加文件大小......但不能很好地发挥我的技巧。如果文件仅包含 DC 扫描而没有实际进展，则这不是问题。由于“仅 DC”帧是符合标准的图像，因此创建它们不需要任何特殊内容： cat > frame.scans < 标签的纯 HTML 视频： badapple.rose.systems 当然，没有规定数据必须进行硬编码：这是一个没有 CSS 或 JavaScript 的交互式单页应用程序。涉及