Wanted: Perceptual adaptive JPEG encoder (optimizer)

[LigH]

Do you know any other, preferably free, software which is able to save JPEG images with perceptual per-macroblock adaptive quantization — except the good old "xat.com JPEG Optimizer 3.15" (which is not freeware, though, except I missed the official public release of the installer code)?

No, please do not post the code here. Although it is not exactly "secret" anymore, anyway...

[LigH]

After hearing about "Pingo": No, I don't believe this tool can compete.

MagiCompress™ in xat.com JPEG Optimizer 3.15 is lossy and adaptive to the visual complexity per block. This is what I want.

https://frupic.frubar.net/thumbs/36680.png (https://frupic.frubar.net/shots/36680.png) — https://frupic.frubar.net/thumbs/36681.png (https://frupic.frubar.net/shots/36681.png) — https://frupic.frubar.net/thumbs/36682.png (https://frupic.frubar.net/shots/36682.jpg)

[GMJCZP]

I do not know if it serves you:

Here (https://arxiv.org/abs/1703.04421)

[LigH]

Yes, this sounds promising. I hope it is also publicly useable. If there is at least a CLI encoder with moderate CPU instruction set requirements, I may test it. Let's see what Jamaika published in the last months in "Crazy family JPEG formats (https://forum.doom9.org/showthread.php?t=174300)".

[LigH]

I compiled a guetzli JPEG encoder successfully. To compare the quality/size ratios of different optimizers, I wonder if there is a tool similar to MSU VQMT, just for a pair of still images, which would report PSNR, SSIM, MSE, and other metrics. Somehow I feel the more keywords I give Google, the more it derails the results away from image comparison tools and towards video comparison. And creating 1-frame video clips to be able to use VQMT would be a detour if simpler tools for still images exist.

[Klementh]

Hey, here's some related information from Cédric, the creator of Pingo: https://css-ig.net/support/messages/special-kind-jpg#comment-title

[LigH]

Nice, thank you for pointing at it. I already tested guetzli, and it takes a lot of time to optimize a JPEG really thoroughly. It took several tries to produce a guetzli JPEG with a similar size as a xat.com MagiCompress™ result, and it had a better SSIM value (according to ffmpeg), and the difference image (bias grey128) appeared visually "flatter". In case of Lenna, guetzli -q93 had a similar size, guetzli -q92 had a similar SSIM value as xat q98 with probably 50% MagiCompress (one button click), compared to an original libJPEG -q100 (YUV 4:2:0). I will have to check more different material (especially some with low contrast and low sharpness, e.g. smoky/cloudy areas) to get a better feeling where advantages or disadvantages of different methods are. I believe xat MagiCompress may more probably produce obvious artifacts (banding) in such areas, or reduce details with faint regular patterns. That will cost some efforts ... but I thank you for good suggestions.

[dipje]

As a side question (my curiosity), what does MozJpeg do to optimize a JPEG and how is that different to what you're looking for ?

[LigH]

I read that MozJpeg provides a lossless compression optimization based on jpgcrush; I would allow lossy compression with variable quantization across all DCT blocks in the image.

[dipje]

MozJpeg is lossy... 'just' an optimized libjpeg

[smok3]

Read the whole mozjpeg build instructions and guetzli is still doing it's first 1920x1200 px png.... Build mozjpeg. Converted about 10 images from png to jpeg using mozjpeg (cjpeg) and guetzli still working...

This one https://transfer.sh/iSwqb/test.png
seems good (maybe transparent) with
mozjpeg -quality 90 -rgb test.png > out.jpg
edit: Not even close to transparent, heavy banding in bottom-left quadrant. edit2: Looks pretty much the same as default libjpeg (assuming imagemagick uses that) at same size, so I'am probably missing some magic switch?

Edit: This is what guezly did eventually (Way to slow to be useful)
https://transfer.sh/mHlK7/testguetzli.jpg

Links will only be alive for a week or so.

[LigH]

@dipje: With "lossless", here I mean "no additional loss compared to libjpeg with the same quality level", no coarser quantization. But I would allow a coarser quantization as long as it won't be easily noticed. MagiCompress definitely raises the quantization, by different amounts for each DCT block. The result will not have the same quantizer all over the whole image.

The goal is adaptive quantization per DCT (macro?) block.

[LigH]

I found that there is now a fork of gützli supporting primarily Nvidia CUDA, or alternatively OpenCL, for a massive parallelisation (https://github.com/doterax/guetzli-cuda-opencl/). On my Ryzen-7 the vanilla build by Google took a few minutes on a FullHD image, the CUDA build (attached in issue 11 is a version with pre-enabled auto method choice) (https://github.com/doterax/guetzli-cuda-opencl/issues/11) managed the same in a few dozen seconds.

[LigH]

Aaaand... it's gone. Gützli may already have been replaced by Jpegli (https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html), a module developed together with JPEG-XL (https://github.com/libjxl/libjxl/tree/main/lib/jpegli). Time to test more.