Repository navigation
[css-images-3] Is "image-rendering: crisp-edges" still worthwhile to keep separate? #6038
Description
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
Activity
tabatkins commentedon Feb 24, 2021
Or rather, now that we're making
pixelateduse the "NN to nearest integer multiple, then smooth", maybe we can usecrisp-edgesto mean "strictly NN" rather than introducing a newnearest-neighborkeyword.dholbert commentedon Feb 25, 2021
I'd favor this option, because:
-moz-crisp-edgeslegacy value already does, in Firefox (straightforward nearest-neighbor).dholbert commentedon Feb 25, 2021
(I'm also happy using
nearest-neighboras the value that does this thing; butcrisp-edgesseems 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 commentedon Feb 26, 2021
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. ^_^
[css-images-3] Merge crisp-edges and nearest-neighbor, retaining the …
Marat-Tanalin commentedon Jun 7, 2021
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 commentedon Nov 22, 2022
Reopening. This requires broader discussion and a CSSWG resolution.
See also #5837
fantasai commentedon Nov 22, 2022
Note: This is blocking republication.
css-meeting-bot commentedon Dec 7, 2022
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 algorithmsThe 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
[css-images-3] Per WG resolution, restore crisp-edges' ability to use…
[css-images-3] Bring prose more in line with original spec text, + ed…
[css-images-3] Per WG resolution, restore crisp-edges' ability to use…
[css-images-3] Bring prose more in line with original spec text, + ed…