Re: [csswg-drafts] [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)

The CSS Working Group just discussed `[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%)`, and agreed to the following:

* `RESOLVED: Bake the smoothing into non-int changes in current pixelated value. Add a new value for nearest neighbor jaggedness`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [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%)<br>
&lt;astearns> zakim, open queue<br>
&lt;Zakim> ok, astearns, the speaker queue is open<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/5837<br>
&lt;dael> TabAtkins: image rendering prop controls how browses render when scalling. Smooth or pixelated. pixelated uses nearest neighbor. Great so long as scaling up by int multiple of size. 2.5 times as big it's terrible<br>
&lt;dael> TabAtkins: You don't get consistent line weight. Something could be 2 or 3 px depending on precise details.<br>
&lt;dael> TabAtkins: At least 2 people in this issue brought up the problem. Want to remain pixel-ness but don't want it to look bad. Minor smoothing okay.<br>
&lt;dael> TabAtkins: Prop is a value that does nearest neigbor scaling and use smooth scaling to close gap.<br>
&lt;florian> Proposal makes sense to me.<br>
&lt;dael> TabAtkins: Use cases seemed reasonable. Canvas-based using pixel art and you don't want jaggies but you don't want to force canvas. You want to scale as you can<br>
&lt;smfr> q+<br>
&lt;dael> TabAtkins: Reasonable to me. Happy to add if reasonable to others<br>
&lt;dael> fantasai: Overall makes sense. I think we should allow overshoot and scale down. If you're 2.8px might make sense<br>
&lt;astearns> ack smfr<br>
&lt;dael> TabAtkins: Right. Should test, but we should scale to nearest multiple and then go up or down smooth<br>
&lt;vmpstr> q+<br>
&lt;dael> smfr: Does image-render pixelated apply to canvas<br>
&lt;dael> TabAtkins: It's supposed to. It's an image source<br>
&lt;dholbert> q+<br>
&lt;dael> smfr: With houdini? That's only way to get it in<br>
&lt;dael> TabAtkins: canvas element is an image element. It's a replaced element with a raster display of content. Intended to be effected by image rendering<br>
&lt;dael> smfr: For a UA to impl it means painting image would be 2 step. pixelated and then nearest neighbor to desitnation. Has cost. Fine feature request, but additional cost<br>
&lt;astearns> ack fantasai<br>
&lt;dael> TabAtkins: I think you're right. Obj or a note about don't use too much<br>
&lt;astearns> ack vmpstr<br>
&lt;dael> smfr: Note in spec about perf is good<br>
&lt;dael> vmpstr: Suggesting to mandate an algo or allow a different?<br>
&lt;dael> TabAtkins: Pixelated madates nearest neigbor. This mandates to nearest int and use whatever smoothing<br>
&lt;astearns> ack dholbert<br>
&lt;dael> vmpstr: Yeah. This would add cost<br>
&lt;fantasai> generally people don't use pixelated unless they really want it, it's not the default<br>
&lt;dael> dholbert: I think we have this behavior in spec for scale of less than 1. You do default image scaling. nice to harmonize.<br>
&lt;dael> dholbert: Also, not clear. Is this prop for new value or change to pixelated<br>
&lt;dael> TabAtkins: Asked in thread. Authors thought different value. I proposed merge into default. I could go either<br>
&lt;jfkthame> q+<br>
&lt;dael> dholbert: If we did keep pure nearest neighbor, might be nice to remove &lt;1 special case and have pixelated scaling separate. You can see as you spec<br>
&lt;astearns> ack jfkthame<br>
&lt;dael> jfkthame: My understanding of last comment in issue is the suggestion is this should be what pixelated does and true nearest neighbor would be new. That makes sense to me. This would be true pixelated and acutal nearest neighbor would be special<br>
&lt;fantasai> +1 jfkthame<br>
&lt;dael> astearns: Then you make current use of pixelated take the harder path<br>
&lt;dael> jfkthame: True, but I think it's the better result. Arguable<br>
&lt;dael> fantasai: I imagine it's not that common unless you want that effect<br>
&lt;dael> TabAtkins: You want for int. If you use it inbetween is variable.<br>
&lt;dael> TabAtkins: dholbert where are you seeing scale down? I'm looking at spec and there is no such difference between up and down<br>
&lt;fantasai> Comment jfkthame was referring to: “Personally, I agree with baking this into pixelated. Yes, pixelated should mean pixelated, but I don't think nearest neighbor interpolation with 150% scaling ratio looks pixelated: Squares that vary in size from 1*1 to 2*2 do not look like pixels. I think it would be better to add a new keyword nearest-neighbor, which means nearest neighbor.”<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/5837#issuecomment-776951044<br>
&lt;dael> dholbert: I haven't looked at spec for a couple years. It was there a few years ago. If it's been removed, that's great<br>
&lt;dael> TabAtkins: I'll research. not in current ED<br>
&lt;dael> astearns: Do you want resolution?<br>
&lt;dael> TabAtkins: Add this with caveats discussed in chat<br>
&lt;dael> fantasai: New value or adding into pixelated and nearest is new<br>
&lt;dael> TabAtkins: Also agree with jfkthame. If vmpstr and smfr don't think it would be problematic I would like to do that<br>
&lt;dael> astearns: Smoothing only nec for non-int values?<br>
&lt;dael> TabAtkins: Yea<br>
&lt;fantasai> s/is new/as new? I personally agree with jfkthame /<br>
&lt;dael> astearns: Prop: Bake the smoothing into non-int changes in current pixelated value. add a new value for nearest neighbor jaggedness<br>
&lt;dael> myles: Flip the names?<br>
&lt;dael> fantasai: I don't think so. Last commentor pointed out having a variety of squares doesn't look pixelated. You want each pixel same size. I think naming is better where pixelated is same size<br>
&lt;dael> astearns: Is that okay myles?<br>
&lt;dael> myles: No comment<br>
&lt;fantasai> s/squares/squares and rectangles representing source pixels/<br>
&lt;dael> astearns: Objections?<br>
&lt;dael> RESOLVED: Bake the smoothing into non-int changes in current pixelated value. Add a new value for nearest neighbor jaggedness<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5837#issuecomment-785259691 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 24 February 2021 17:54:05 UTC