I'm pretty sure the same issue happens with PNGs, which being lossless are generally good for icons as they don't land up with compression artifacts like what happens in JPEGs (which the author points out are really for photographs), they also support alpha blending.
When Chrome introduced this "optimization" and it made it through to an Electron release which we were upgrading to, it really messed up the icons in a lot of places in our product such that we had to hold off the upgrade until we had SVGs to replace them.
SVGs also have the advantage of being able to respond to light/dark mode. We just needed to put each icon in its own shadow DOM to avoid styles clashing between the different SVGs if they happen to be named the same which was a bit of an annoyance for our graphic designer.
Chrome and Firefox uses two different scaling algorithms that is probably contributing a lot more to this difference. Chrome is more blurry in general while Firefox is sharper but has slightly more ringing artifacts. Personally I prefer the Firefox version.
That's why you should prefer LPIPS to PSNR. LPIPS is a learned metric that uses subjective human input.
That said, it's limited due to the training set, iirc. So we still use PSNR regularly — it's an easily-understood metric with widely-understood limitations, which is in practice not too bad. Devil you know, etc.
I do prefer the firefox look too! I'd be curious to hear your take on what could be the root cause of this. I'm far from a image rendering expert. But I remember when inspecting the edges and curves of the images in a DCT visualizer they were all in the AC coefficients which is what led me to the conclusion of the post.
I wonder if this is a gamma correction related. JPEG encodes directly in a non linear color encoding (full-range YCbCr), so the partial decoding may be effectively scaling without gamma correction.
So is Firefox doing a full rendering then scaling, or is it also doing a partial rendering but in another way? You're only telling one side of the story.
Firefox doesn't decode the image into a full-resolution buffer and then downscale either, instead it does a streaming decode and applies downscaling on the fly. They call it downscale-during-decode[0]. I guess it doesn't do partial decoding of the 8x8 blocks though.
Ah! It took a fair bit of digging to get there. Maybe I'll look into the firefox pipeline and make another post. In the mean time if anyone know the internals and how firefox does it, I'm eager to hear about it!
ahah, yeah surprising considering how Chrome is RAM hungry, 20mb isn't that much of a win. On another end when trying to reproduce the glitch, it was quite hard! basically invisible on photos and not all icons were affected. So it does work very well. It was kind of our fault to use a jpg for an icon ahah.
I'm pretty sure the same issue happens with PNGs, which being lossless are generally good for icons as they don't land up with compression artifacts like what happens in JPEGs (which the author points out are really for photographs), they also support alpha blending.
When Chrome introduced this "optimization" and it made it through to an Electron release which we were upgrading to, it really messed up the icons in a lot of places in our product such that we had to hold off the upgrade until we had SVGs to replace them.
SVGs also have the advantage of being able to respond to light/dark mode. We just needed to put each icon in its own shadow DOM to avoid styles clashing between the different SVGs if they happen to be named the same which was a bit of an annoyance for our graphic designer.
The work for decompressing at a lower scale in Firefox is happening here: https://bugzilla.mozilla.org/show_bug.cgi?id=2033250
Thanks, I knew it was much more efficient, but seeing the numbers in the benchmarks make me appreciate this "trick" even more!
Chrome and Firefox uses two different scaling algorithms that is probably contributing a lot more to this difference. Chrome is more blurry in general while Firefox is sharper but has slightly more ringing artifacts. Personally I prefer the Firefox version.
I've noticed that a lot of objective measures of image quality prefer blur to ringing, but many subjective measurements tilt the other way.
That's why you should prefer LPIPS to PSNR. LPIPS is a learned metric that uses subjective human input.
That said, it's limited due to the training set, iirc. So we still use PSNR regularly — it's an easily-understood metric with widely-understood limitations, which is in practice not too bad. Devil you know, etc.
I do prefer the firefox look too! I'd be curious to hear your take on what could be the root cause of this. I'm far from a image rendering expert. But I remember when inspecting the edges and curves of the images in a DCT visualizer they were all in the AC coefficients which is what led me to the conclusion of the post.
I wonder if this is a gamma correction related. JPEG encodes directly in a non linear color encoding (full-range YCbCr), so the partial decoding may be effectively scaling without gamma correction.
So is Firefox doing a full rendering then scaling, or is it also doing a partial rendering but in another way? You're only telling one side of the story.
Firefox doesn't decode the image into a full-resolution buffer and then downscale either, instead it does a streaming decode and applies downscaling on the fly. They call it downscale-during-decode[0]. I guess it doesn't do partial decoding of the 8x8 blocks though.
[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1045926
Ah! It took a fair bit of digging to get there. Maybe I'll look into the firefox pipeline and make another post. In the mean time if anyone know the internals and how firefox does it, I'm eager to hear about it!
Reminds me of digging into HTML Canvas scaling, especially when HiDPI Macs came out.
Would be nifty if they only did that partial scaling when there's little memory available.
ahah, yeah surprising considering how Chrome is RAM hungry, 20mb isn't that much of a win. On another end when trying to reproduce the glitch, it was quite hard! basically invisible on photos and not all icons were affected. So it does work very well. It was kind of our fault to use a jpg for an icon ahah.