Regressive JPEGs: when a developer reverses the algorithm to create images that regress

A tinkerer publishes a reverse exploration of the JPEG codec: generating images that, when decoded, produce deliberate artifacts by playing with DCT quantization. Curious, instructive, and an excellent exercise to understand the format.

The project

On the Hacker News homepage this week, an article titled "Regressive JPEGs" (maurycyz.com/projects/bad_jpeg/) caught our attention. Its author documents a reverse exploration of the JPEG codec: instead of optimizing an image for size and quality, it generates deliberately degraded JPEGs by manipulating quantization tables and DCT (Discrete Cosine Transform) blocks.

This is not a production tool, but an excellent pretext to understand how JPEG works under the hood - a format that most developers use without ever reading the spec.

Reminder: how JPEG encodes

JPEG (Joint Photographic Experts Group, ISO/IEC 10918-1 standard of 1992) follows a classic pipeline:

1. RGB → YCbCr conversion - separates luminance and chrominance
2. Chrominance subsampling (often 4:2:0)
3. Splitting into 8×8 blocks
4. DCT - transforms each block from the spatial domain to the frequency domain
5. Quantization - divides the DCT coefficients by a quantization table (the real compression lever)
6. Zig-zag scan + Huffman - encodes the coefficients into a binary stream

The perceived quality mainly depends on step 5: the more aggressive the quantization table, the more detail is lost in the high frequencies.

What "Regressive JPEGs" does

The author subverts this mechanism. By building exotic quantization tables (very high values on certain frequencies, abnormally low values elsewhere), it produces JPEGs that, when read by a standard decoder, exhibit:

• Visible 8×8 blocks (extreme blocking artifacts)
• Ringing patterns (oscillations around edges)
• Colors that "bleed" due to pushed chroma subsampling
• Or even images totally unrecognizable upon decoding

The educational interest is real: you can see with the naked eye what each parameter of the codec contributes to preserving.

Serious applications?

Beyond the pleasure of curiosity, there are a few legitimate uses:

1. Decoder robustness testing - a real JPEG decoder must handle malformed files without crashing. Deliberately generating weird JPEGs is a homemade fuzz-test.
2. Watermarking / steganography - finely understanding quantization helps hide information in DCT coefficients (technique used by F5, OutGuess).
3. Understanding ML artifacts - super-resolution models trained on JPEG must learn to distinguish content from artifacts. A dataset of "bad JPEGs" is useful.

At its core, what this kind of project shows is that a format we think is a black box always hides exploitable levers - for the best or for pure curiosity.

To go further

The original JPEG specification (ITU T.81 / ISO 10918-1) is verbose but readable - and it's the best entry point to understand what a decoder really sees. On the tooling side, libjpeg-turbo (Darrell Commander) allows inspecting the quantization tables of a file via djpeg -verbose: an excellent way to check what the codec has stored in a concrete JPEG.

To remember: file formats are not black boxes. Reading a bit of spec (JPEG, PNG, WebP) transforms any developer into a better user of the imaging tools they use every day.