guetzli icon indicating copy to clipboard operation
guetzli copied to clipboard

Strange behavior at higher DPI or Resolution

Open TiKevin83 opened this issue 6 years ago • 7 comments

Guetzli works really well for compressing some of the images in my library for the web. I've managed to find a compression sweet spot targeting a butteraugli distance of 1.15 for many of the smaller JPEGs I'm working with (around 200x300), where guetzli+JpegTran performs equal to or better than mozjpeg consistently past 2.5 bits/pixel.

However, the sweet spot seems to disappear when trying to compress larger resolution originals of the same image (around 450x650). Guetzli+JpegTran can produce an image at butteraugli 1.15 with roughly 2.25 bits/pixel at this resolution in my image library (roughly 10% fewer bits/pixel than the smaller size) while a similar quality mozjpeg encode is available with as little as 1.4-1.5 bits/pixel.

I could easily be missing something but it seems counter-intuitive that guetzli would be less efficient with higher DPI when it's explicitly tuned for high image quality.

TiKevin83 avatar Jun 13 '18 21:06 TiKevin83

Butteraugli has been optimized for the human vision at a viewing distance of 1000 pixels. When the viewing distance is more, some other approximations can be better. Also, it can be that your originals are in YUV420 and the higher resolution originals have the YUV420 compatible color characteristics. If that is the case, the YUV420 model in mozjpeg may be a better match than Guetzli's eagerness to apply YUV444.

Please send sample images for more informed speculation :-)

jyrkialakuijala avatar Jun 13 '18 22:06 jyrkialakuijala

Would "Inferior compression density" be a better word for the title than "Strange behavior" ?

jyrkialakuijala avatar Jun 13 '18 22:06 jyrkialakuijala

Without seeing the images, I suspect that these images have a certain level of noise that is present in the higher resolution images, but not in the lower resolution subsampled images. The noise is replicated by guetzli -- (as guetzli's philosophy is to be true to the original whatever it is), but cleaned by mozjpeg. Not having to replicate noise makes mozjpeg perform better.

jyrkialakuijala avatar Jun 13 '18 22:06 jyrkialakuijala

Yes that would be more accurate, thank you for your feedback! I'll see what I can do about images. The example here involves close-up (within a foot viewing distance) detail of a hand and a jar of coins with lots of ridge detail. The ridge detail appears to disappear in visible blocks as butteraugli distance goes from 1 to 2 instead of uniformly throughout the picture, and some blocks also tend to align vertically which is more readily visible than mozjpeg's degredation.

TiKevin83 avatar Jun 13 '18 22:06 TiKevin83

Here's the set of images that have been giving me the most trouble at high DPI. Mozjpeg 3.1 at Q85, Guetzli at Q86+JpegTran, and original:

mozjpeg85 guetzliq86 jpegtran cd-special-card670w

On the Guetzli image, ridge detail on knuckles and in the crease between the thumb+pointer finger is preserved compared to mozjpeg, but much more visible artifacts appear in the green between the 3rd stack of coins and the coin jar, and the shape of some of the background halos is distorted due to blocking. There's also blocking in the coin jar that creates noticeable vertical lines through the image, and the same at the base of the pointer finger and the middle finger. From what I can see, Guetzli+JpegTran begins to be visually competitive around Q92-93, but with 40% more bits/pixel.

TiKevin83 avatar Jun 14 '18 14:06 TiKevin83

I've made some progress troubleshooting the issue. I think in my case, many of the stock images we use were at some point 4:2:0 before being converted to pngs, so they're only efficiently compressed at 4:4:4 after being downsampled past 2x. When I switch force_420 to true in processor.h, the guetzli+jpegtran output at Q86 is much closer to what I would expect. cd-special-card670w-force420 However, I can see why force_420 is normally avoided, as it causes a large unavoidable butteraugli distance on 4:4:4 input.

I am still seeing though that 4:4:4 images ran through my auto-quality search to minimize filesize/butteraugli distance tradeoffs pretty consistently have lower BA distance with smaller and smaller subsampled input. I'm wondering if this is a consequence of targeting a 1000 pixel viewing distance or if something else is going on.

TiKevin83 avatar Jun 18 '18 16:06 TiKevin83

New encode targeting BA distance 1.632 + JpegTran for equivalent filesize as the previous Q86 (BA target 1.8057)+JpegTran: cd-special-card670q1 632

New Guetzli appears favorable mainly in the ringing around the plant, but it also appears to have introduced a new artifact pattern in the white lines above the tallest stack of coins. Both new and old have blockiness issues, primarily with how they degrade the ridge detail in the hand in general: where old has stripes of blocks that lose ridge detail, new Guetzli tends to have stripes of blocks that preserve some of the detail.

TiKevin83 avatar Jul 06 '18 17:07 TiKevin83