Intent to Ship: image-rendering: pixelated

[Jack Hou]

Contact emails

jac...@chromium.org

Spec

http://dev.w3.org/csswg/css-images/#the-image-rendering

Summary

"image-rendering: pixelated" indicates that image should be scaled "so that the image appears to be simply composed of very large pixels", e.g. using nearest-neighbour.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Q8N6FoeoPXI

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

Demo link

http://jsfiddle.net/zda24/147/

Compatibility Risk

Similar functionality is supported on other browsers in the following forms:

Firefox: "image-rendering: -moz-crisp-edges"

Webkit: "image-rendering: -webkit-optimize-contrast"

IE: "-ms-interpolation-mode: nearest-neighbor"

The implementation in Blink conforms to the spec. Without this feature, Chrome is the only major browser where it is not possible to achieve the desired effect.

OWP launch tracking bug?

None.

Link to entry on the feature dashboard

None.

[Adam Barth]

What is the status of the specification?  You've linked to an editor's draft above.

On the implementation side, it sounds like every implementation has a different name for this feature.  How confident should we be that everyone will agree to paint the bike shed this particular color?

Adam

[PhistucK]

Is any other browser going to support the final standardized property name and value?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mike Lawther]

CSS Images Level 4 is currently a Working Draft. cc'ing Tab as an editor to answer the question about other browser support for the name.

[Jack Hou]

Oops, the working draft is here: http://www.w3.org/TR/css4-images/

[Tab Atkins Jr.]

On Thu, Jun 26, 2014 at 12:30 AM, 'Adam Barth' via blink-dev
<blin...@chromium.org> wrote:
> What is the status of the specification? You've linked to an editor's draft
> above.

WD, but the feature is stable - it was punted from Images 3 only
because there wasn't enough implementation interest at the time to
justify taking it to CR.

> On the implementation side, it sounds like every implementation has a
> different name for this feature. How confident should we be that everyone
> will agree to paint the bike shed this particular color?

It's had these name for well over a year, and it's survived a few
rounds of bikeshedding in the CSSWG already. These names are stable
(and we'll ensure that by shipping them).

~TJ

[Adam Barth]

Ok.  LGTM 

[Dirk Schulze]

Survived doesn’t mean that the members agreed that it is the right name. Beside the name, are other implementations really interoperable? Are there tests that compare the behavior across browsers?

Greetings,
Dirk

>
> ~TJ

[Mike Lawther]

On 27 June 2014 06:29, Dirk Schulze <dsch...@chromium.org> wrote:

[...] are other implementations really interoperable? Are there tests that compare the behavior across browsers?

The MDN page https://developer.mozilla.org/en-US/docs/Web/CSS/image-rendering as well as this other test page http://phrogz.net/tmp/canvas_image_zoom.html tell developers to use the combination of

  image-rendering:-moz-crisp-edges; /* Firefox */ 

  image-rendering:-o-crisp-edges; /* Opera */ 

  image-rendering:-webkit-optimize-contrast; /* Safari */ 

  image-rendering:optimize-contrast; /* CSS3 Proposed */ 

  image-rendering:crisp-edges; /* CSS4 Proposed */ 

  image-rendering:pixelated; /* CSS4 Proposed */ 

  -ms-interpolation-mode:nearest-neighbor; /* IE8+ */

to achieve interoperable results. So I reckon we can pretty safely say that all other browsers have the ability to do nearest neighbour scaling in an interoperable way, modulo the name.

[Elliott Sprehn]

On Thu, Jun 26, 2014 at 4:18 PM, Mike Lawther <mikel...@chromium.org> wrote:

On 27 June 2014 06:29, Dirk Schulze <dsch...@chromium.org> wrote:

[...] are other implementations really interoperable? Are there tests that compare the behavior across browsers?

The MDN page https://developer.mozilla.org/en-US/docs/Web/CSS/image-rendering as well as this other test page http://phrogz.net/tmp/canvas_image_zoom.html tell developers to use the combination of

  image-rendering:-moz-crisp-edges; /* Firefox */ 

  image-rendering:-o-crisp-edges; /* Opera */ 

  image-rendering:-webkit-optimize-contrast; /* Safari */ 

  image-rendering:optimize-contrast; /* CSS3 Proposed */ 

  image-rendering:crisp-edges; /* CSS4 Proposed */ 

  image-rendering:pixelated; /* CSS4 Proposed */ 

  -ms-interpolation-mode:nearest-neighbor; /* IE8+ */

Oh the -vendor-prefixed-huge-manatee, can we get them to all agree on a name so this isn't required?

- E

[Mike Lawther]

On 27 June 2014 09:57, Elliott Sprehn <esp...@chromium.org> wrote:

Oh the -vendor-prefixed-huge-manatee, can we get them to all agree on a name so this isn't required?

Yes - the status quo sucks. Agreement is what is Tab and the CSS Images spec is trying to do by standardising the feature.

[Eric Seidel]

It seems clear something like this is desired. It's not clear to me
from reading the spec what the difference between crisp-edges or
pixelated means, but LGTM.

[Mike Lawther]

On 27 June 2014 10:34, Eric Seidel <ese...@chromium.org> wrote:

It seems clear something like this is desired.  It's not clear to me
from reading the spec what the difference between crisp-edges or
pixelated means, but LGTM.

'crisp-edges' is intended to allow the UA to use advanced pixel art scaling algorithms such as described here http://research.microsoft.com/en-us/um/people/kopf/pixelart/. Demos here http://research.microsoft.com/en-us/um/people/kopf/pixelart/supplementary/multi_comparison.html and here http://research.microsoft.com/en-us/um/people/kopf/pixelart/supplementary/video_multi_comparison_4x_h264.mp4. In the absence of anything more advanced, a UA can fall back to nearest-neighbour. 

'pixelated' requires the use of nearest-neighbour scaling.

[Dirk Schulze]

This is not clear from the spec though. Your examples use nearest neighbor for pixel art. The specification says pixel art should use crisp-edges which is nearest neighbor for most implementations but the CSS Image spec — even for WebKit. Your pasted snippet is not entirely correct. WebKit implements optimize-contrast and crisp-edges and treats them both the same. (Both as kCGInterpolationLow for OS X. Apple doesn’t say which interpolation algorithm it is using but it is likely nearest neighbor.)

So we have interoperability for "nearest neighbor like algorithm" == crisp-edges in Firefox, Opera (old), Safari. However, the spec says that crisp-edges is something different without being specific. Actually the spec seems to be intentionally unspecific. (Visual examples would probably help to understand the intention of the keywords.)

‘pixelated’ as term is not implemented by any browser but Blink IIRC and faced public skepticism before. The functionality is unquestioned though. Here an example: http://jsfiddle.net/4X9LL/ Visually there is no difference between all browsers.

How is Blink’s status for ‘crisp-edges’? How would Blink implement ‘crisp-edges’ as specified?

Greetings,
Dirk

[Mike Lawther]

On 27 June 2014 16:48, Dirk Schulze <dsch...@chromium.org> wrote:

On Jun 27, 2014, at 2:57 AM, Mike Lawther <mikel...@chromium.org> wrote:

> On 27 June 2014 10:34, Eric Seidel <ese...@chromium.org> wrote:
> It seems clear something like this is desired.  It's not clear to me
> from reading the spec what the difference between crisp-edges or
> pixelated means, but LGTM.
>
> 'crisp-edges' is intended to allow the UA to use advanced pixel art scaling algorithms such as described here http://research.microsoft.com/en-us/um/people/kopf/pixelart/. Demos here http://research.microsoft.com/en-us/um/people/kopf/pixelart/supplementary/multi_comparison.html and here http://research.microsoft.com/en-us/um/people/kopf/pixelart/supplementary/video_multi_comparison_4x_h264.mp4. In the absence of anything more advanced, a UA can fall back to nearest-neighbour.
>
> 'pixelated' requires the use of nearest-neighbour scaling.

This is not clear from the spec though.

The spec says: 
   "pixelated - When scaling the image up, the "nearest neighbor" or similar algorithm must be used [...],"

 

That seems pretty clear to me. 

Lower down, it says "with 'image-rendering: crisp-edges', a user agent might scale images with nearest-neighbor interpolation by default, and switch to EPX interpolation in low-load situations."

That also seems pretty clear to me. Note that EPX  is http://en.wikipedia.org/wiki/Image_scaling#EPX.2FScale2.C3.97.2FAdvMAME2.C3.97

However, I suggest that discussion of clarity of spec text should be moved to www-style.

Your examples use nearest neighbor for pixel art. The specification says pixel art should use crisp-edges which is nearest neighbor for most implementations but the CSS Image spec — even for WebKit.

I don't understand. The Microsoft Research examples showed several different pixel art scaling algorithms, including nearest neighbour. 

 

Your pasted snippet is not entirely correct. WebKit implements optimize-contrast and crisp-edges and treats them both the same.

I didn't make claim as to the exhaustive correctness. I gave it as an example of what web devs were being told to use to achieve their goal. To be strict though, WebKit implements them as vendor prefixed: '-webkit-optimise-contrast' and '-webkit-crisp-edges'. I'm sure MDN would be appreciative if you updated their page to add that WebKit also supports -webkit-crisp-edges.

 

(Both as kCGInterpolationLow for OS X. Apple doesn’t say which interpolation algorithm it is using but it is likely nearest neighbor.)

It is.

So we have interoperability for "nearest neighbor like algorithm" == crisp-edges in Firefox, Opera (old), Safari. However, the spec says that crisp-edges is something different without being specific. Actually the spec seems to be intentionally unspecific. (Visual examples would probably help to understand the intention of the keywords.)

The current behaviour of these vendor prefixed 'crisp-edges' implementations is compliant with the current spec text. Suggestions for improving the spec should be sent to www-style (I'm not an editor, I can't help here).

 

 ‘pixelated’ as term is not implemented by any browser but Blink IIRC and faced public skepticism before.

This has already been answered earlier in this thread. Tab as spec editor has said the term has already been through several rounds of CSSWG bikeshedding and is stable.

 

How is Blink’s status for ‘crisp-edges’? How would Blink implement ‘crisp-edges’ as specified?

Blink does not implement crisp-edges right now. We would implement it as the spec suggests - nearest neighbour by default, and something more advanced if we decide it is useful. I can't see how we could do anything else.

[Dirk Schulze]

On Jun 27, 2014, at 9:35 AM, Mike Lawther <mikel...@chromium.org> wrote:

> (Both as kCGInterpolationLow for OS X. Apple doesn’t say which interpolation algorithm it is using but it is likely nearest neighbor.)
>
> It is.
>
> So we have interoperability for "nearest neighbor like algorithm" == crisp-edges in Firefox, Opera (old), Safari. However, the spec says that crisp-edges is something different without being specific. Actually the spec seems to be intentionally unspecific. (Visual examples would probably help to understand the intention of the keywords.)
>
> The current behaviour of these vendor prefixed 'crisp-edges' implementations is compliant with the current spec text. Suggestions for improving the spec should be sent to www-style (I'm not an editor, I can't help here).
>
> ‘pixelated’ as term is not implemented by any browser but Blink IIRC and faced public skepticism before.
>
> This has already been answered earlier in this thread. Tab as spec editor has said the term has already been through several rounds of CSSWG bikeshedding and is stable.

That the name is stable is Tab’s opinion, not a fact.

>
>
> How is Blink’s status for ‘crisp-edges’? How would Blink implement ‘crisp-edges’ as specified?
>
> Blink does not implement crisp-edges right now. We would implement it as the spec suggests - nearest neighbour by default, and something more advanced if we decide it is useful. I can't see how we could do anything else.

As you say, the specified version of crisp-edge does not require a specific algorithm beside the default nearest neighbor. Most implementations will implement crisp-edges as nearest neighbor and many do so today already. It is very likely that no implementation will implement crisp-edges any different than that. If they would, authors would be unhappy about the inconsistency. You just confirmed that it is likely the case for Blink as well. So why not go ahead with crisp-edges instead of pixelation then?

Greetings,
Dirk

[Vincent Scheib]

There has been broad desire for nearest neighbor upscaling for some time. (search wha...@whatwg.org)

I'm skeptical of crisp-edges which appears to target a particular use case for which users are often given configuration options because results are often a matter of taste and source content. I would propose avoiding implementing crisp-edges as nearest neighbor for the reason Dirk points out of possibly adding friction to implementing it as intended in the future. It seems better to omit support for crisp-edges rather than provide it as nearest-neighbor.

 

[Mike Lawther]

I like this reasoning. It does seem better to not support crisp-edges as nearest neighbour.

[webm...@crystala.net]

Is it possible to apply pixelated to the underlying scaling done on retina displays? Here's an example that must be run on Canary with the experimental web features flag on a retina display:

http://jsfiddle.net/25zZ4/1/ 

[Mike Lawther]

That looks like a bug. I filed http://crbug.com/391351 and credited you with the find and the repro. Thanks!

[webm...@crystala.net]

Awesome, thanks!

[TAMURA, Kent]

Sounds reasonable. LGTM to ship.

--
TAMURA Kent
Software Engineer, Google

[PhistucK]

Following some feedback by Mozilla, the specification has recently changed with regards to downscaling (previously, nearest neighbor was to only be applied when upscaling) - will Blink align with it (in Chrome 38 already? in Chrome 39?)?

https://groups.google.com/d/msg/mozilla.dev.platform/0KYBjCdUMJw/NkXF-AjLJ-0J

☆PhistucK

[Jack Hou]

Sounds reasonable. The various methods for setting nearest-neighbor on the other browsers don't distinguish between up- and downscaling. So hopefully this means they can just alias to pixelated.

39 branches this week, but it should be a fairly easy change for 40.

Also, this still needs to be implemented in the compositor (https://code.google.com/p/chromium/issues/detail?id=134040#c47).

[PhistucK]

What is "this"? Downscaling? Or image-rendering: pixelated in general?

☆PhistucK

[Jack Hou]

Sorry. By "this still needs to be implemented in the compositor", I mean image-rendering:pixelated. It currently does not work correctly for accelerated canvases.

[PhistucK]

Then perhaps it should not be shipped yet?

☆PhistucK

[Mike Lawther]

Should just require reverting this patch https://src.chromium.org/viewvc/blink?revision=176957&view=revision :)

On 24 September 2014 17:55, PhistucK <phis...@gmail.com> wrote:

[PhistucK]

For the implementation to align with the specification regarding downscaling, yes.

Regardless, shipping a buggy version with regards to the accelerated canvas looks pretty bad to me...

☆PhistucK

[Jack Hou]

I've reverted it here. https://codereview.chromium.org/604683003/

We originally thought the bug only occurred in rare cases, but it appears to affect accelerated images too. I'll request for this to be merged into 38 once it's verified on canary. https://code.google.com/p/chromium/issues/detail?id=417592

[PhistucK]

Thank you for the update!

☆PhistucK

[dhol...@gmail.com]

On Wednesday, September 24, 2014 12:56:20 AM UTC-7, PhistucK wrote:

Following some feedback by Mozilla, the specification has recently changed with regards to downscaling (previously, nearest neighbor was to only be applied when upscaling) - will Blink align with it (in Chrome 38 already? in Chrome 39?)?

https://groups.google.com/d/msg/mozilla.dev.platform/0KYBjCdUMJw/NkXF-AjLJ-0J

Note: after that (editor's draft) spec-change, the CSSWG ended up resolving on something slightly different, allowing either behavior. Quoting http://lists.w3.org/Archives/Public/www-style/2014Sep/0384.html :

  - RESOLVED: Allow nearest neighbor for image rendering in both
      directions but allow browsers to do prettier in the down
      directions.

So, I don't believe any downscaling code-change is needed here, to align with the spec.

~Daniel

[PhistucK]

The Chrome 38 beta blog post mentions this feature, so it should be updated to drop it -

http://blog.chromium.org/2014/08/chrome-38-beta-new-primitives-for-next.html

☆PhistucK

[Alex Komoroske]

Thanks, we'll get that removed.

[Chadtech]

Hi,

I've been following this thread for the last month or so since it was linked to in this stack overflow post. I made a MS Paint clone in browser called 'CtPaint' ( ctpaint.us ). Zoom is a pretty critical feature that I had it sorta working with image-rendering : pixelated in the Chrome 38 Beta. It currently works great in firefox, and not at all in Chrome.

Anyway thanks for all your hard work on this Jack Hou. I look forward to what gets shipped out.

Thanks,

-Ct

[PhistucK]

Looks like it is fixed in Chrome 40.

☆PhistucK

[chadst...@gmail.com]

Oh cool! Well Ill just wait for Chrome 40 then.

Thanks,

-Ct

[chadst...@gmail.com]

So was this shipped? I have Chrome 40 now and image-rendering: pixelated isnt working (http://imgur.com/a/BseWA).

Thanks,

-Ct

[webm...@crystala.net]

I added image-rendering: pixelated to ctpaint's canvas and it works on Canary, so that's something at least.

[Jack Hou]

No, it's back behind the enable-experimental-web-platform-features flag for now. I'll update this thread when it's ready to ship again.

[chadst...@gmail.com]

Alright, thanks Jack.

-Ct

[Jack Hou]

Hi all, the CL to re-ship this just landed: https://codereview.chromium.org/806413006/

It'll have about 4 weeks to bake before the M41 branch point.

[chadst...@gmail.com]

I just noticed that image-rendering: pixelated works perfectly in Chrome 41.

Thanks again Jack for this excellent addition to Chrome,

-Ct