On Fri, May 16, 2014 at 12:16 PM, Justin Novosad <ju...@google.com> wrote:

> On Fri, May 16, 2014 at 12:27 PM, Ian Hickson <i...@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.   `._.-(,_..'--(,_..'`-.;.'

Reply via email to