Why tiny JPEGs look different in Chrome

PetitPrince

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.

debazel

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.

smallnix

Would be nifty if they only did that partial scaling when there's little memory available.

muizelaar

The work for decompressing at a lower scale in Firefox is happening here: https://bugzilla.mozilla.org/show_bug.cgi?id=2033250

bluedino

Reminds me of digging into HTML Canvas scaling, especially when HiDPI Macs came out.

jonathanlydall

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.

LoganDark

Not sure why one would use JPEG for a little digital icon anyway. It is indeed only acceptable for photos. SVG is a good choice for icons, PNG or WebP for other digital content.

Theodores

You can over ride lib-jpeg-turbo with the moz-jpeg 'update' if you want much nicer jpeg things going on. Mozilla wringed out more from JPEG for Meta/Instagram about a decade or so ago, and their library would be noteworthy in this article, for comparison. The basic idea was that JPEG was devised when CPU cycles were expensive and displays were analogue, meaning that only a limited effort was made to optimise, resulting in things like banding, that OG CRTs handled well, unlike modern digital displays (on systems with 1000000 more CPU). Regardless of what tools you are using, going from 'gigapixels' to a thumbnail is going to be a two or more step process, with a colourful item rendered a grey mush, when you really needed some of the colours in the original. Few respect the pixel blocks of JPEG (8 x 8) and most graphic artists have no knowledge of the powers of two. Once upon a time it was necessary to align image dimensions with important binary numbers, particularly if working with texture maps for early 3D graphics. The other thing going on in the article is that practically every web screen should be considered 'retina' resolution, with everything apart from the lamest office PC having a pixel resolution equivalent to 1.5x the amount of pixels shown 'nominally'. If the web stats say '1280 x 720' as a oft-used resolution, regardless of device, that will be a 1920 x 1080 screen at 1.5x, with Chrome and other browsers packing in 1920 rather than 1280 pixels across, if the image has the pixels in it for that.

hnv9j3vudy

Been meaning to look into this

iknowstuff

Thoroughly enjoyed reading this! In other news, AVIF is at 95%: https://caniuse.com/avif so it's probably time to give it the first preference over jpg.

advisedwang

> Really, the moral here is that you should not use JPEG for icons and the like And, more importantly, you should use images that are an appropriate resolution for the size they will be displayed. Even if you switch to PNG, using a 2000x2000 image for a icon displayed 20x20 is a waste.

altairprime

15px suggests that using an ICO file, horrifying as that sounds, might be a very successful solution here. Yes, I know PNG and GIF would also work, but if ICO format is still support for favicons at multiple resolutions with clean scaling, then wouldn’t it be support for doc images as well?

kccqzy

If you care about the rendered quality, you should never use the browser itself to downscale images. Browsers don’t consistently use the state-of-the-art algorithm for downscaling, which is Lanczos 3-lobe. This is independent of partial IDCT. Browsers generally favor performance. And the algorithm chosen could even depend on the specific GPU in use. That said if you are using the web to develop UI, it’s accepted that different browsers and users get slightly different renderings, unless you write your own image renderer with canvas. If you do care that much you should probably write native code.

edflsafoiewq

The DCs giving you a 1/8 downscale is well known, but the interesting part to me was this generalizes so you can get 1/4 (resp. 1/2) downscales by using only the 2x2 (resp. 4x4) block of LF coefficients.

gwittel

Sometimes you can control this with the “image-rendering” CSS attribute. It lets you control the scaling algorithm used. Different browsers seem to choose the algorithm in different ways. Came across this when an image looked different between two browsers, but only on high DPI monitors.

scotty79

People who usually complain about AI write ups apparently aren't interested in this topic.

talon8635

I had a hell of a time rendering svg to print sanely in chrome, no issues in ff