[css-images-3] Is "image-rendering: crisp-edges" still worthwhile to keep separate?

[tabatkins]

Currently, image-rendering: crisp-edges is defined somewhat abstractly to just be:

The image must be scaled with an algorithm that preserves contrast and edges in the image,
and which does not smooth colors or introduce blur to the image in the process.
This is intended for images such as pixel art or line drawings.

It's allowed for this to just be identical to pixelated, but it can use more advanced upscaling algorithms if desired, like hq2x (I have no idea what the state of the art here is).

Is there any actual interest in making this do something different from pixelated? Or should I just fold it in as a legacy alias, like the older SVG keywords?

/cc @dholbert especially

[tabatkins]

Or rather, now that we're making pixelated use the "NN to nearest integer multiple, then smooth", maybe we can use crisp-edges to mean "strictly NN" rather than introducing a new nearest-neighbor keyword.

[dholbert]

Or rather, now that we're making pixelated use the "NN to nearest integer multiple, then smooth", maybe we can use crisp-edges to mean "strictly NN" rather than introducing a new nearest-neighbor keyword.

I'd favor this option, because:

• It happens to be what -moz-crisp-edges legacy value already does, in Firefox (straightforward nearest-neighbor).
• It concisely expresses what nearest-neighbor actually does (there's no guarantee that pixel sizes will be preserved, but edges will stay crisp; there won't be any fuzzy scaling artifacts).
• It seems like this "crisp" scaling behavior is indeed a behavior that authors do want, whatever it's called (separately from some fancier pixelated scaling behavior), per [css-images-3] image-rendering:pixelated should not force "nearest neighbor" (or similar) when the scale factor is far from an integer (e.g. 150%) #5837 (comment) .
• It's trivial to implement.

[dholbert]

(I'm also happy using nearest-neighbor as the value that does this thing; but crisp-edges seems more intuitively readable/understandable, and it also has the benefit of already existing in browsers & presumably on the web, & being already specced to do approximately the right thing.)

[tabatkins]

Cool, sounds good to me. My hope that we could get better pixel-scaling algos into browsers seems like it hasn't succeeded in any case. ^_^

[Marat-Tanalin]

For what it’s worth, I would prefer straightforward nearest-neighbor (i used to say neighboUr though) if it means exactly that anyway. Nearest neighbour is a well-known algorithm while crisp-edges is an abstract thing invented specifically for CSS.

[fantasai]

Reopening. This requires broader discussion and a CSSWG resolution.
See also #5837

[fantasai]

Note: This is blocking republication.

[css-meeting-bot]

The CSS Working Group just discussed [css-images-3] Is "image-rendering: crisp-edges" still worthwhile to keep separate?, and agreed to the following:

• RESOLVED: Revert the definition of crisp edges to allow for more advanced algorithms

The full IRC log of that discussion

TabAtkins: fantasai pointed out this needs a resolution. I took it on editors discretion, dholbert agreed on this. image-rendering controls how images are upscaled / downscaled has a combination of value that vaguely try to keep things pixelated
TabAtkins: pixelated, crisp-edges and nearest edges
TabAtkins: we ended up deciding that ?? allowed slightly blurred edges. There was also nearest which could result in slightly different sizes because of grid mismatches
s/??/pixelated/
TabAtkins: and nearest edges allowed for higher quality resampling. Nobody bit and implemented so I propose merging crisp-edges and nearest-neighbor
TabAtkins: I removed crisp-edges and defined it to be equivalent to nearest-neighbor which keeps edges crisp even if resized a little
chris_: I think this is right thing to do, the intent was for crisp-edges to do nearest neighbor
ack fantasai
fantasai: I don't like this change, because crisp-edges to me suggests you get crisp looking edges rather than jagged edges on diagonal lines
fantasai: there's lots of art for which this isn't appropriate. I.e. you want something upscaled in a way to maintain edge boundaries
fantasai: I can see a reason to want nearest neighbor but think this should just be called nearest neighbor since that's what you're requesting
TabAtkins: the edges are exceedingly crisp, jaggedness was present in original image
q+
fantasai: I feel the name doesn't imply make this roughly pixelated
fantasai: i think we could do better
astearns: is crisp edges something we have to support for web compat?
TabAtkins: moz has it prefixed, maybe still, not sure about other impls
ack smfr
smfr: I think browser want to map crisp edges to pixelated because that's easier, but maybe now with machine learning algorithms we'd have better ways to upscale line art and keep the door open to use these options
+1 crisp-edges seems to me like it would be appropriate for line art
TabAtkins: i'm fine either way, can define to be flexible or not
TabAtkins: if we leave it open, do we leave nearest neighbor as an explicit algorithm, or have a value that's something like nearest neighbor
fantasai: I think for most people they'd be happy with pixelated which does almost this
TabAtkins: I suspect so as well
with better handling of non-integer multiples
TabAtkins: proposal is that we partially revert, keep the merging of crisp edges and nearest neighbor, default to nearest neighbor but allow impls to use better algorithms
fantasai: i think the text before did this more nicely
TabAtkins: problem was it referenced nearest neighbor algo
fantasai: we can put that as a definition in the property and reference from two values
TabAtkins: agreed
fantasai: i'm happy with crisp edges with original definition
RESOLVED: Revert the definition of crisp edges to allow for more advanced algorithms