[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

<flackr> 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
<flackr> TabAtkins: pixelated, crisp-edges and nearest edges
<flackr> 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
<astearns> s/??/pixelated/
<flackr> TabAtkins: and nearest edges allowed for higher quality resampling. Nobody bit and implemented so I propose merging crisp-edges and nearest-neighbor
<flackr> TabAtkins: I removed crisp-edges and defined it to be equivalent to nearest-neighbor which keeps edges crisp even if resized a little
<flackr> chris_: I think this is right thing to do, the intent was for crisp-edges to do nearest neighbor
<astearns> ack fantasai
<flackr> 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
<flackr> 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
<flackr> 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
<flackr> TabAtkins: the edges are exceedingly crisp, jaggedness was present in original image
<smfr> q+
<flackr> fantasai: I feel the name doesn't imply make this roughly pixelated
<flackr> fantasai: i think we could do better
<flackr> astearns: is crisp edges something we have to support for web compat?
<flackr> TabAtkins: moz has it prefixed, maybe still, not sure about other impls
<astearns> ack smfr
<flackr> 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
<fantasai> +1 crisp-edges seems to me like it would be appropriate for line art
<flackr> TabAtkins: i'm fine either way, can define to be flexible or not
<flackr> 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
<flackr> fantasai: I think for most people they'd be happy with pixelated which does almost this
<flackr> TabAtkins: I suspect so as well
<fantasai> with better handling of non-integer multiples
<flackr> 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
<flackr> fantasai: i think the text before did this more nicely
<flackr> TabAtkins: problem was it referenced nearest neighbor algo
<flackr> fantasai: we can put that as a definition in the property and reference from two values
<flackr> TabAtkins: agreed
<flackr> fantasai: i'm happy with crisp edges with original definition
<flackr> RESOLVED: Revert the definition of crisp edges to allow for more advanced algorithms