Re: [css-color] Safari 7 is color-managing CSS colors?

Hello Tab,

Saturday, December 7, 2013, 6:07:50 AM, you wrote:

> On Sat, Dec 7, 2013 at 3:31 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>> Can you tell me where the color workflow is defined?
>> For instance, it is defined that all CSS colors should be tagged with an
>> sRGB profile. Image can optionally have a tag as well.

> Not quite.  It's currently allowed for CSS colors to be unmanaged, if
> untagged images are also unmanaged, and so they just get blasted into
> the monitor's gamut without adjustment.  It's just tagged images that
> have to be managed right now.

To clarify: its defined (since CSS1) that the colours are in the sRGB
colourspace. In CSS1, the minimum level of management required was not
screwing up the gamma (this was when Macs and SGIs used a non-2.4
gamma). It turned out that even that was not reliable. So yes, the
source data is defined to be in sRGB and the minimal conformance level
is treating that as device RGB and throwing it at the screen.

The advent of wide gamut monitors (plus the generally better color
management capabilities of platforms and the increasing awareness of
colour quality (remember that when CSS1 came out, most people still
used indexed, 256-colour screens)) has meant that throwing data at the
screen results in an eye searing experience.

So if the monitor has a gamut less than or similar to sRGB, treating
sRGB as device RGB is not tooo bad. If the gamut is wider, treating
sRGB as sRGB is a much better idea (and gives more consistency). Once
you can do that, its a small step to allowing, say, images in AdobeRGB
to be actually displayed correctly and then, allowing authors to
specify colours in other colour spaces, like AdobeRGB.

>> How are those colors actually mapped when going to screen?
>> I believe that in the case of Core Graphics, everything is drawn into a sRGB
>> device which is then mapped to the output device.
>> So, a tagged imaged would go: Image profile -> sRGB -> monitor profile.
>> Assuming that the output device is properly calibrated, you would get the
>> same colors everywhere.
>>
>> Is this how it's supposed to work? Or is a tagged image supposed to go to
>> the monitor profile directly?

Currently, that is how its supposed to work (modulo some hand-waving
about supporting sRGB colours with components < 0.0 or greater than
1.0, which is underspecified  in terms of transfer function and not
actually compatible with modern CMS). Clearly is the source and
destination spaces are large compared to sRGB this results in gamut
clipping which need not have been done.

That is why SVG2 introduces the idea of other intermediate spaces for
computation (including LAB, so there will be no clipping except what
is actually needed for the destination gamut).


> That's how it's supposed to work, yes.  Anything else is really bad,
> because it means you're leaking color profiles all over intermediate
> stages.

> Colors should be treated like Unicode is.  Good hygiene means
> converting bytes to codepoints as soon as they enter the system, and
> not turning them back into bytes until they leave.  Same with colors -
> bytes should be turned into a managed colorspace as soon as they
> enter, and not turned into monitor profile until they leave the
> system.

>> Can you specify the rendering intent anywhere?

> I don't think there's a need to?

There is a need to specify the rendering intent, yes. Either
explicitly in the style sheet or implicitly in the specification, as a
default.

Its currently unspecified and needs to be. For testability and
consistency, i would say the default rendering intent should be
relative colorimetric. There should also be an option to specify a
different intent.

> ~TJ



-- 
Best regards,
 Chris                            mailto:chris@w3.org

Received on Sunday, 8 December 2013 05:53:19 UTC