W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

Re: [whatwg] WebGL and ImageBitmaps

From: Rik Cabanier <cabanier@gmail.com>
Date: Fri, 16 May 2014 14:42:40 -0700
Message-ID: <CAGN7qDAJABjmKzVurdqzEhivxX5XtR-SKzgq_hnmob-c6Y7h1w@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: Katelyn Gadd <kg@luminance.org>, "whatwg@whatwg.org" <whatwg@whatwg.org>, Glenn Maynard <glenn@zewt.org>, Ian Hickson <ian@hixie.ch>
On Fri, May 16, 2014 at 12:16 PM, Justin Novosad <junov@google.com> wrote:

>
>
>
> On Fri, May 16, 2014 at 12:27 PM, Ian Hickson <ian@hixie.ch> wrote:
>
>> On Fri, 16 May 2014, Justin Novosad wrote
>> > Blink/WebKit uses output-referred color space, which is bad for some
>> > inter-op cases, but good for performance. Calling drawImage will produce
>> > inter-operable behavior as far as visual output is concerned, but
>> > getImageData will yield values that have the display color profile baked
>> > in.
>>
>> I'm not quite sure what you mean here. If you mean that you can set
>> 'fillStyle' to a colour, fillRect the canvas, and the get the data for
>> that pixel and find that it's a different colour, then that's
>> non-conforming. If you mean that you can take a bitmap image without
>> colour-profile information and draw it on a canvas and then getImageData()
>> will return different results, then again, that's non-conforming.
>>
>> If you mean that drawing an image with a color profile will result in
>> getImageData() returning different colour pixels on different systems,
>> then that's allowed, because the colour space of the canvas (and the rest
>> of the Web platform, which must be the same colour space) is not defined.
>>
>> Yes the later is what I mean. It is allowed, and it is causing headaches
> for many web developers. One possible solution would be to impose that
> ImageData be in sRGB color space. Unfortunately, that would imply loss of
> precision due to color space conversion rounding errors in a
> getImageData/putImageData round trip.
>

Can you explain why that is? Presumably, the image data is converted to
sRGB before you use it to composite its pixels.


> But that is probably a lesser evil.  I wonder if making this change would
> break anything on the web...
>
>>
>> > Some web developers have worked around this by reverse-engineering the
>> > client-specific canvas to sRGB colorspace transform by running a test
>> > pattern through drawImage+getImageData.  It is horrible that we are
>> > making devs resort to this.
>>
>> I'm not really sure what this work around achieves. Can you elaborate?
>>
>
> For example, if a web app wants to apply an image processing algorithm, it
> would use getImageData to retrieve the original pixel values, process the
> data, and display the results using putImageData.  The color space of the
> image data is undefined and it affects the behavior of the image processing
> algorithm.  In order to standardize the behavior of the image processing
> algorithm, the image data must be converted to a known color space.  The
> required color space transformation can not be queried but it can be
> determined experimentally by taking an <img> that is in a known color space
> and contains known color values.  You draw that image to a canvas using
> drawImage, and read it back using getImageData.  The color values returned
> by getImageData and the known corresponding color values of the original
> image provide a set of color-space correspondences that can be used to feed
> a curve fitting algorithm in order to reverse-engineer the parameters of
> the color space conversion that maps the unknown ImageData color space to
> the known color space of the test image.
>

I agree. That is horrible!


> If you just want to do everything in sRGB, then putting all your images in
>> sRGB but without giving color space information (or setting the option to
>> 'strip', if we add these createImageBitmap() options) would result in what
>> you want, no?
>>
>
> Only if the canvas backing store is forced to be in sRGB.
>

Is the Web page not composited in sRGB? If so, it seems the backing store
should be sRGB too.


> You'd have to manually (or on the server) convert images that were in
>> other colour spaces, though.
>>
>>
>> > Adding a colorspace option to createImageBitmap is not enough IMHO. I
>> > think we need a more global color-management approach for canvas.
>>
>> If we need colour management, we need it for the Web as a whole, not just
>> for canvas. So far, though, implementations have not been implementing the
>> features that have been proposed, so...:
>>
>>    http://www.w3.org/TR/css3-color/#dropped
>>
>>
> I think think CSS and HTML can survive well without  color management
> features, as long as the color behavior is well defined, which seems to be
> the case except for <canvas>
> ImageData is problematic because it stores data that in an undefined color
> space.
>
>
>
>>  --
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>>
>
>
Received on Friday, 16 May 2014 21:43:07 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:20 UTC