What does HackerNews think of knusperli?

A deblocking JPEG decoder

Language: C++

If you want to remove banding from jpeg images, check out https://github.com/google/knusperli. When jpeg quantizes coefficients, there is an entire interval that quantizes to the same number. A traditional decoder uses the quantized value, the center of the interval. When there's is a subtle gradient, the low-order coefficients quantize to zero, and you get banding because the gradient disappears. Knusperli does not use the center of the interval, it picks the value in the interval that makes the block boundaries the least discontinous. This means that it can recover subtle gradients.
Knusperli is similar: https://github.com/google/knusperli

Instead of trying to smooth the entire image, it reduces blocking artifacts by finding plausible coefficients that reduce discontinuities at block boundaries (jpegs are encoded as a series of 8x8 blocks). "jpeg2png gives best results for pictures that should never be saved as JPEG", but knusperli works well on normal photographic content, since it only tries to remove blocking artifacts.

> A JPEG encoder quantizes DCT coefficients by rounding coefficients to the nearest multiple of the elements of the quantization matrix. For every coefficient, there is an interval of values that would round to the same multiple. A traditional decoder uses the center of this interval to reconstruct the image. Knusperli instead chooses the value in the interval that reduces discontinuities at block boundaries. The coefficients that Knusperli uses, would have rounded to the same values that are stored in the JPEG image.

A potential future option I only just learned about is JPEG XL (not XR!) which is proposed as a royalty-free successor to the JPEG we know. The draft is at https://arxiv.org/abs/1908.03565 and a little bit about what it has and why is at https://www.spiedigitallibrary.org/conference-proceedings-of... (but I haven't found nearly as much public detail on tools, reasoning behind choices, etc. as there is for e.g. AV1).

The most interesting bit of it is that it contains a JPEG1 recompressor that saves about 20% space but allows exact reconstruction of the original file. It uses more modern entropy coding and goes to more effort to predict coefficients than JPEG1. It has almost exactly the same gains as, and sounds a lot like, Dropbox's Lepton, described here: https://blogs.dropbox.com/tech/2016/07/lepton-image-compress... .

Seems like a big deal to plug seamlessly into all the JPEG-producing stuff that exists, without either doing a second lossy step (ick) or forking into two versions when you first compress the high-quality original. 20% off JPEG sizes is also a bigger deal than it may sound like; totally new codecs with slower encodes and a bucket of new tools only hit like ~50% of JPEG sizes. As Daala researcher Tim Terriberry once said, "JPEG is alien technology from the future." :)

For JPEG XL's native lossy compression, it has some tools reminiscent of AV1 and other recent codecs, e.g. variable-sized DCTs, an identity transform for fundamentally DCT-unfriendly content, a somewhat mysterious 4x4 "AFV" transform that's supposed to help encode diagonal lines (huh!), a post-filter to reduce ringing (that cleverly uses the quantization ranges as a constraint, like the Knusperli deblocker: https://github.com/google/knusperli ).

Interestingly it does not use spatial prediction in the style of the video codecs. A developer in a conference presentation mentioned that it's targeting relatively high qualities equivalent to ~2bpp JPEGs -- maybe spatial prediction just doesn't help as much at that level?

Don't know if AV1-based compression or JPEG XL will get wide adoption first, but either way we should actually have some substantial wins coming.

Maybe using https://github.com/google/knusperli as the JPEG decoder would give a fairer comparison?