For the record, the WebGL working group would like to see this option in the spec.

I would like to see better color correction and control options for web users, and canvas users.  I wondered how this proposal would interwork with CSS http://dev.w3.org/csswg/css-color-correction ?

This would be related to the 'color-correction' CSS property in that draft as currently specified, except that this would apply to images handled by scripts (to which CSS doesn't apply), while the property would be related to images handled by the CSS system (e.g. <img>s during composition).

Also, this bug proposed an option to ignore colour space information, while the proposed property provides a way to control the default colour space information for images that lack any such information, so they're kind of orthogonal. For images without colour space data, 'honor' and 'strip' both result in sRGB being assumed, whereas the property lets you decide between sRGB and some unknown other value chosen by the UA (probably also sRGB). For images with colour space data, the property always honours it, whereas this property lets you decide whether to honour that data or ignore it and treat it as sRGB data.

Additionally, there is desire to implement this feature on the Google Chrome team. Having it specified would make it easier to motivate adding it.

For this to be useful, we need canvas backing stores to be in sRGB color space, which is not currently the case.  AFAICT, the specification does not impose a colorspace.  I am guessing this is deliberate since behavior is currently not interoperable in this respect.  We should probably solve that problem first. Right now in Chrome canvas pixels are in output-referred colorspace, which is good for performance because it means no colorspace conversion is required when compositing the canvas onto the page. I believe there will be a desire to maintain this way of doing things for performance-critical applications.  With that in mind there should probably be 'display' ColorSpaceKind (which reflects current behavior).

When an imageBitmap is being create to be used with a given canvas rendering context, it would make sense to have a read-only colorSpace attribute on CRC2D to be able to do:
{colorSpace: context.colorSpace}

"output-referred colorspace", meaning the users screen color space?

(In reply to Noel Gordon from comment #6)
> "output-referred colorspace", meaning the users screen color space?

Yes. The screen or whatever the output device may be.  "output-referred" is the standard term defined in ISO 22028-1

In recent discussions with Apple Computer I understood (perhaps mistakenly) that as of Mac OS X 10.9, Safari is actually using the sRGB color space for all of its rendering. Apparently there were concerns about compatibility with existing web apps, but surprisingly, none broke during this transition. This should be confirmed with a representative from Apple, but it gives hope that other implementations can make the transition to using the sRGB color space for the canvas's backing store.

(In reply to Kenneth Russell from comment #8)
> In recent discussions with Apple Computer I understood (perhaps mistakenly)
> that as of Mac OS X 10.9, Safari is actually using the sRGB color space for
> all of its rendering. Apparently there were concerns about compatibility
> with existing web apps, but surprisingly, none broke during this transition.
> This should be confirmed with a representative from Apple, but it gives hope
> that other implementations can make the transition to using the sRGB color
> space for the canvas's backing store.

I would not expect such a change to break anything, but it could regress performance.  Maybe that concern is obsolete today, with GPUs being everywhere. I guess we don't need to wait for the spec to change to fix this in implementations, since the behavior is not defined in the spec.

(In reply to Justin Novosad from comment #9)
> (In reply to Kenneth Russell from comment #8)
> > In recent discussions with Apple Computer I understood (perhaps mistakenly)
> > that as of Mac OS X 10.9, Safari is actually using the sRGB color space for
> > all of its rendering. Apparently there were concerns about compatibility
> > with existing web apps, but surprisingly, none broke during this transition.
> > This should be confirmed with a representative from Apple, but it gives hope
> > that other implementations can make the transition to using the sRGB color
> > space for the canvas's backing store.
> 
> I would not expect such a change to break anything,

It does: plugins. Since all other browsers until Safari on OS X 10.9 were using the device color space, plugins used device color space. Now that Safari is using sRGB, we don't color match to plugins like Flash.

There is also no API for the browser to tell a plugin that it is using sRGB.

However, breaking is the right thing to do here. When other browsers start using sRGB, plugins will too.

Another thing that is possibly problematic is video. If the video goes through a plugin, you hit the problem above. If you implement video natively, you need to make sure that it is using sRGB, or respecting the video's embedded profile.

You might not notice it as much on video though. You're more likely to notice something is wrong when you are matching a color in the page, defined by CSS. E.g. a flash animation embedded into a page but looks like regular page content.

Then there are filters, which are defined to operate in a linear space. The spec defines how to do the input and output there. I think maybe WebGL should do the same.

> but it could regress
> performance.  Maybe that concern is obsolete today, with GPUs being
> everywhere. I guess we don't need to wait for the spec to change to fix this
> in implementations, since the behavior is not defined in the spec.

FWIW we didn't notice a significant regression, but we (Safari) were lucky in that our graphics system did much of the hard work for us.

https://github.com/whatwg/html/pull/741