-
Notifications
You must be signed in to change notification settings - Fork 978
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange behavior at higher DPI or Resolution #250
Comments
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 :-) |
Would "Inferior compression density" be a better word for the title than "Strange behavior" ? |
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. |
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. |
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: 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. |
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. 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. |
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.
The text was updated successfully, but these errors were encountered: