W3C home > Mailing lists > Public > www-style@w3.org > March 2016

Re: [css-color] wider/deeper colors

From: Rik Cabanier <cabanier@gmail.com>
Date: Tue, 22 Mar 2016 15:39:10 -0700
Message-ID: <CAGN7qDDMTBCKuBpwv9D-s5RARvUizigHTZEj9CE0rzmnuRxwug@mail.gmail.com>
To: Dean Jackson <dino@apple.com>
Cc: www-style list <www-style@w3.org>
On Mon, Mar 21, 2016 at 11:05 PM, Dean Jackson <dino@apple.com> wrote:

>
> On 21 Mar 2016, at 19:34, Rik Cabanier <cabanier@gmail.com> wrote:
>
>>
> But the developer is probably going to want to do that based on whether
>> the device supports wider gamut, so it would cause multiple nesting.
>>
>
> Let's take an example of a developer creating an SVG in Illustrator who is
> using a wide gamut iMac. Since he wants to use all the available colors, he
> sets the document space to the monitor profile.
> However regardless of the profile selected, the generated values in the
> SVG stay the same, so there needs to be a way to tag the SVG document
> profile as p3.
>
> With your proposal, each color will have include a reference to the "p3"
> profile. This is cumbersome but will work, as long as there is no alpha or
> color blending or filters.
> However, if you tag the inline SVG with the css property:
>    compositing-space: "p3"
> the document will look correct on a p3 or higher display and as good as
> possible on a lesser display.
>
>
> We definitely need something that allows an SVG to be tagged with a color
> space, but I think that's an SVG issue. Maybe we also need a CSS property,
> or HTML <img> attribute, that allows the referencing site to override the
> profile embedded in an image.
>
> These are both good topics for discussion, but don't change what we've
> decided on so far.
>
>
>
>> I don't want to make this too complicated.
>>
>
> From my experience, authors find it easier to deal with a document color
> space than specifying colorspaces in the content.
>
>
> Sure.
>
> The case we're trying to cover right now is a Web page that wants to use
> some colors outside sRGB, when the combination of browser+display can
> handle it. This might be to match a CSS color to a pixel in a photograph.
> Note the "some" colors.
>
> Maybe there should also be a way for the author to specify that the entire
> page should be tagged in a color space other than sRGB? I think that's also
> an interesting suggestion.
>

Yes, that is the usual way if you want color consistency between devices:
establish a common colorspace to render into and then map the pixels to the
output device.

For instance, originally InDesign encouraged a mixed content workflow but
> designers found it almost impossible to use.
>
>
>> I doubt that people are going to want to specify a huge number of colors
>> by hand that are outside sRGB, in the near future at least. It's more
>> likely going to be something like this:
>>
>> :root {
>>   --my-color: rgb(255, 0, 0);
>> }
>>
>> @media (color-gamut: p3) {
>>  :root {
>>      --my-color: color(p3, 100%, 0%, 0%);
>>   }
>> }
>>
>> Then var(--my-color) will be the brightest red on the display.
>>
>
> Only if you have a p3 display or one that matches sRGB.
>
>
> Exactly.
>
> What happens if someone releases a display with an even higher gamut than
> p3 or one that is close but not the same (like AdobeRGB)? Do pages have to
> be redesigned to select the p3 media query?
>
>
> I think you should go back and read the threads on this, plus the minutes
> of the meetings. I know this is a horrible thing to ask of any human, let
> alone a friend :) But we've discussed it a lot.
>

I believe you :-)
I did read the minutes and the threads and asked people that attended but I
still had questions


> Here's a summary.
>
> - No author can be expected to write content that supports all the
> possible color profiles
> - Displays that claim to support a profile nearly universally fall short
> of the entire gamut (e.g. Ultra HDTV displays are nowhere near 100% of
> BT.2020), so
> - It's probably reasonable for now to group displays into tiers: sRGB-ish,
> P3-ish and BT.2020-ish.
>
> Please don't argue against my summary. There was a lot more to the
> discussion.
>

No, this is perfectly reasonable.


> We have also asked Adobe to explain what the workflow and tooling is for
> these situations, but haven't got any details yet. Maybe you can provide
> that? What does InDesign do if you want to match a color in the page
> content to something in a photo?
>

This is the basic color workflow of InDesign (and most other Adobe
applications):
1 Content that you draw is always in the document color space. You can
select Lab, but it's also immediately converted.
2 Everything that is placed in the document is color managed regardless if
you choose to honor the embedded profile.
3 All this content is then converted to the document space and rendered to
a bitmap tagged with the document profile.
4 This bitmap is then mapped to the screen profile and displayed. If the
screen profile happens to match the document, this is a no-op.

For your case of matching a color with something in a photo, if you just
want to export the page to a flat bitmap, there's nothing you need to do.
You get the pixels from step 4.

For PDF/postscript output, there is a problem since the profile mismatch
will cause a color difference.
There are a couple of solutions:
a. convert the placed image to the document profile
b. on export, convert everything to the document profile. This is the
recommended way for prepress output.

Your example touches on the pitfalls of color management which caused a lot
of grief to our users:
it's not always clear when profiles are different so you will unexpected
color shift when displaying on or printing to a different device.
This is one of the main reasons for PDF/X:
https://en.wikipedia.org/wiki/PDF/X

If the intent is to create consistent color, it seems that this is
> accomplishing the opposite. Maybe I'm missing something...
>
>
> I don't understand how this is the opposite.
>

Per your example above, instead of having the same sRGB color on all
devices, there's a bright red color on p3 devices and a dull red one on all
others.

dialog.jpg
(image/jpeg attachment: dialog.jpg)

Received on Tuesday, 22 March 2016 22:39:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:01 UTC