Regressive JPEGs: (Maurycy's blog)

Regressive JPEGs:

2026-07-17

One of the cool features of JPEG files is that there's the option to save low frequency components first.<br>This means that a partially downloaded image will be displayed at low resolution instead of being cut off.

In the file, this works by breaking up the compressed data into multiple "scans", each prefixed with a header.<br>This is the first scan of a typical image:

FF DA - "start of scan" marker<br>00 0C - Big endian length field (12 bytes) Includes itself<br>03 - Number of channels in scan (3)<br>01 - Global id of first included channel<br>00 - Huffman table index #1 (DC: 0, AC: 0)<br>02 - Global id of second included channel<br>10 - Huffman table index #2 (DC: 1, AC: 0)<br>03 - Global id of third included channel<br>10 - Huffman table index #2 (DC: 0, AC: 0)<br>00 - Starting DCT bin (DC)<br>00 - Ending DCT bin (also DC)<br>01 - Precision: half, no pre-existing data.

f8ad 512d d3f1 cd96 - Huffman coded DCT coefficients<br>bcb0 58df 53d5 5d97<br>[...and a lot more]

... this one includes the lowest (DC) Fourier bin for all three color channels.

The three color channels are YCbCr instead of the usual RGB.<br>Separated the luminance is used because it must be high quality, but the color can be fudged quite a bit while looking fine.

Very roughly: Y = G, Cb = B - G, Cr = R - G

After it, the file contains several more scans to fill in the rest of the image data:

Scan numberChannelsDCT bin rangePrecision<br>0Y Cb Cr0 - 0Half (-1 bit)<br>1Y1 - 5Quarter (-2 bits)<br>2Cb1 - 63Half<br>3Cr1 - 63Half<br>4Y6 - 63Quarter<br>5Y1 - 63Half<br>6Y Cr Cb0 - 0Full<br>7Cr1 - 63Full<br>8Cb1 - 63Full<br>9Y1 - 63Full

Scan #0 contains a very low resolution preview of the image.

Scan #1 adds some details to the luminance.

Scans number two through five contain full low precision data.

Scan 4 has an unusual spectral range because it's filling in the gap left by #1.<br>That way, number 5 has full quarter precision data to build on.

Scans six through nine add the final missing bit to bring the image to full quality.

Given what I said about color being less important, it might seem weird that my example has color data first:<br>This is because the the chrominance is saved at half resolution (quarter pixel count).<br>As a result, full chrominance data (Cr + Cb) only weighs half as much as luminance.

Since each scan explicitly sets its spectral range,<br>it should be possible to construct a JPEG file<br>where future scans overwrite already rendered image data.

Actually, it's very easy to do this:

Concatenate a few images with the same resolution and settings and filter out the start-of-image, start-of-frame and end-of-image markers.<br>This can be done in a hex editor, but I used a quick and dirty C program.

When served over a slow network, this concatenated fill will switch between multiple images:

Click to open in new tab

But, most decoders will give up after some number of scans:<br>I think this is done to avoid a zip bomb style problem...<br>but it prevents this from working on more than 9 frames, which is not enough for a proper animation.

To do that, I'd have to minimize the number of scans in each frame.<br>The simplest solution would be to start with baseline JPEGs that only have a single scan.

... but it doesn't work:

In progressive mode, a scan can't contain both AC (bins above 0) and DC (bin 0) data at the same time.<br>This limitation doesn't exist for baseline mode, but the baseline decoder stops after the first scan.

Since AC data must follow DC data, the smallest possible "progressive" JPEG contains a single DC-only scan.<br>Because the DCT runs on 16x16 blocks, such an image won't a solid color:

it'll be 1/16th of the original resolution.

Scan numberChannelsDCT binsPrecision<br>0Y Cb Cr0 - 0Full

Doing this, I can get a chrome to render around 100 frames before giving up.<br>Other browsers like Firefox have more patience, but a 90 scan image seems to work almost everywhere.

As a bonus, this avoids the ghosting seen in the naive attempt:<br>that happens because AC scans are supposed to refine old data.<br>Normally, this allows images can include multiple precision levels without inflating file size...<br>but doesn't play nicely with my tricks.

If the file only includes DC scans with no actual progression, this isn't a problem.

Since a "DC-only" frame is a standards-compliant images, creating them doesn't require anything special:

cat > frame.scans# DC only scan:<br>0,1,2:0-0,0,0;<br># and nothing else<br>EOF<br>jpegtran -scans frame.scans -outfile out.jpg in.jpg

Combining these together produces a video like this:

Click to open in new tab

Besides unconventional rickrolls and other trolling, this has no practical applications:<br>there's no way to add timing information so playback is entirely dependent on network delay.

... although there is a lot of fun to be had using partial rendering:

This is a pure HTML video using tags: badapple.rose.systems

Of course, there's no rule that the data must be hardcoded:<br>here's a interactive single-page application with...