"pixelated" resize quality allows bilinear interpolation.

[jakearchibald]

https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#dom-resizequality-pixelated

Taking this sprite:

Here's a nearest-neighbour upscaling vs bilinear upscaling:

It feels like an error to allow bilinear interpolation when the intent expressed is "pixelated".

[junov]

Agree 100% for upscaling. I think the more debatable issue is whether down-sampled images can be anti-aliased.

[tabatkins]

...the description of pixelated seems to be exactly opposite what it should be. pixelated does not "maximize the appearance of the image", and color-smoothing is 100% antithetical to the meaning of the keyword.

We should blame this and see where it came from, because it seems like a simple mistake.

[tabatkins]

Ah, and now that I'm looking at the CSS Images spec, I see that there was indeed some mistake, because the text here is almost identical to that which CSS provides for the smooth keyword.

HTML:

The "pixelated" value indicates a preference to scale the image that maximizes the appearance. Scaling algorithms that "smooth" colors are acceptable, such as bilinear interpolation.

CSS:

smooth
The image should be scaled with an algorithm that maximizes the appearance of the image. In particular, scaling algorithms that "smooth" colors are acceptable, such as bilinear interpolation. This is intended for images such as photos.

[tabatkins]

I think the more debatable issues is whether down-sampled images can be anti-aliased?

This was addressed for CSS in 2013, in the thread starting at https://lists.w3.org/Archives/Public/www-style/2013Apr/0019.html.

In short, the spec originally differentiated between upscaling and downscaling, but (a) it's not clear what case to treat it as when one axis grows while the other shrinks, and (b) tracking whether you're up- or down-scaling is apparently annoying in implementations. As a result, we removed the differentiation, and say to just use nearest-neighbor all the time. It doesn't look particularly great when downscaling, but oh well, it's not really intended for that case anyway.

[tabatkins]

Ah, found the issue. (Thanks for the blame, searchfox!)

This text was added as part of #1293. In a1d88cb, the resize options were added; at this point, pixelated was correctly defined to be nearest neighbor.

Later, in 2f1479e, there was some reshuffling to switch to using the CSS keyword names; as part of this, the "pixelated" value was moved to the end of the list, and the "auto" value was added in its place (this is what is now referred to in CSS as smooth; previously it was called auto).

Then in the final commit 13db9f0, the names were switched back to the original set. Here there was a mistake made - probably due to memory of how they were originally arranged, the first item in the list was changed back to "pixelated", but that value's text was left describing the "auto" keyword! (Or maybe they'd just intended to swap out the "auto" text for the "pixelated" one, but forgot to do so in the shuffle.)

So yeah, the entire thing was a mistake, it should always have been specified as nearest-neighbor.

[jakearchibald]

Let's tackle this once #3424 lands.

[schenney-chromium]

Given #3424 never landed, and this is still in the spec, I'm going to fix it. There is a complicating factor, however. When the screen pixel size is not 1-1, as with non-square pixels or non-integral zoom, pixelated can produce very nasty results. I still think the spec should be updated as it is the desired behavior.

[tabatkins]

pixelated can produce very nasty results.

This should, I think, be fixed by adopting the CSS definition of "pixelated", yeah? "Nearest-neighbor to the nearest integer multiple, then smooth to the final size" gives you the most pixelated appearance you can get, without the distortions caused by pure NN.

[schenney-chromium]

PR up: #10491