Hacker News new | past | comments | ask | show | jobs | submit login

Unfortunately both the article and the code suffer from a crucial misunderstanding of JPEG -- the 8x8 blocks do actually undergo a 2-dimensional DCT. Zig-zag scanning down to 1D comes later, after quantization, and is applied to the quantized DCT coefficients in order to maximize runs of zero for the benefit of RLE.

The code and the article assume that the scan is applied earlier, to the spatial data, in preparation for a 1D DCT and as a consequence mistakenly performs all of its operations in scan order. In reality, a 1D DCT of zigzag-scanned samples differs dramatically from a zigzag scan of 2D frequency coefficients.

The technique still works to an extent as it's still processing edges (only diagonally), creating a similar effect in some cases to the desired one, but likely less effective than a row-column or other 2D approach which models the actual transform and the intended behavior outlined in the blog post.

Surprisingly this code was accepted into mozjpeg nearly a year ago and remains as in the blog post.




Surprisingly this code was accepted into mozjpeg nearly a year ago and remains as in the blog post.

Why not? The examples seem to work and show improvements. Anyone is welcome to submit an improved version if they like.


> creating a similar effect in some cases to the desired one, but likely less effective than a row-column or other 2D approach

I have actually implemented and tested a 2D overshoot, and it gave worse quality/filesize ratio.

Perhaps by accident (or less obvious correlation), but this order seems to give most compressible pattern.


Thanks for your comment; I wrote a JPEG codec years ago and was now beginning to doubt my sanity.

It would be interesting to see how far this technique would take if implemented with correct assumptions.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: