Re: Discuss HDR at CSS WG next week ?

Hi Mark,

I hope things were cleared up at the CSS meeting yesterday [1].

Here's the link to the iccMax specification:
http://www.color.org/iccmax.xalter
and the link to a reference implementation:
https://github.com/InternationalColorConsortium/RefIccMAX

For now, it doesn't look like any changes are need to the color spec. Once
iccMax is sorted out, it should simply refer to that.

Rik

1: https://logs.csswg.org/irc.w3.org/css/2016-09-19/#e721928

On Mon, Sep 19, 2016 at 1:21 AM, Mark Watson <watsonm@netflix.com> wrote:

>
>
> On Sep 18, 2016, at 10:36 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>
>
> On Sun, Sep 18, 2016 at 10:19 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>>
>>
>> On Sep 18, 2016, at 6:23 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>>
>>
>>
>> On Sat, Sep 17, 2016 at 7:23 PM, Mark Watson <watsonm@netflix.com> wrote:
>>
>>>
>>>
>>> On Fri, Sep 16, 2016 at 12:22 PM, Rik Cabanier <cabanier@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Friday, September 16, 2016, Mark Watson <watsonm@netflix.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Sep 16, 2016 at 10:11 AM, Rik Cabanier <cabanier@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 15, 2016 at 12:22 PM, Rik Cabanier <cabanier@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Sep 15, 2016 at 11:57 AM, Mark Watson <watsonm@netflix.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Sep 15, 2016 at 11:25 AM, Rik Cabanier <cabanier@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Sep 15, 2016 at 11:01 AM, Mark Watson <watsonm@netflix.com
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Sep 15, 2016 at 10:41 AM, Rik Cabanier <
>>>>>>>>>> cabanier@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Sep 15, 2016 at 10:21 AM, Mark Watson <
>>>>>>>>>>> watsonm@netflix.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Sep 15, 2016 at 9:58 AM, Rik Cabanier <
>>>>>>>>>>>> cabanier@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Sep 15, 2016 at 7:35 AM, Mark Watson <
>>>>>>>>>>>>> watsonm@netflix.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> > On Sep 14, 2016, at 10:05 PM, Rossen Atanassov <
>>>>>>>>>>>>>> Rossen.Atanassov@microsoft.com> wrote:
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> >> On Wed, Sep 14, 2016 at 16:53:53, Mark Watson wrote:
>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>> >> I have some use-cases and issues / questions related to
>>>>>>>>>>>>>> High Dynamic Range
>>>>>>>>>>>>>> >> graphics / images and how they could be supported in CSS.
>>>>>>>>>>>>>> I wondered if this
>>>>>>>>>>>>>> >> topic was or could be on the agenda for next week ?
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > Are you referring to our TPAC agenda? If so, we don't have
>>>>>>>>>>>>>> the topic scheduled and looking through everything we have it is doubtful
>>>>>>>>>>>>>> we could get to it.
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > Could you summarize your proposal? Is this something
>>>>>>>>>>>>>> proposed at WICG already?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, TPAC. I've raised the issue of HDR a few times on the
>>>>>>>>>>>>>> CSS list,
>>>>>>>>>>>>>> but with no real response. We had a breakout at TPAC last
>>>>>>>>>>>>>> year, but no
>>>>>>>>>>>>>> one from CSS attended. I imagine that is because people do
>>>>>>>>>>>>>> not yet
>>>>>>>>>>>>>> have real hardware / platform APIs with which to play with
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> functionality. Those will soon be available, so it seemed
>>>>>>>>>>>>>> good timing
>>>>>>>>>>>>>> to raise it again and explain the various problems.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I only have problems, not a proposal. The basic problem (as I
>>>>>>>>>>>>>> understand it) is that with HDR displays, users are unlikely
>>>>>>>>>>>>>> to want
>>>>>>>>>>>>>> the peak white for regular sRGB to map to the peak luminance
>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>> display. That would make desktops blindingly bright. So there
>>>>>>>>>>>>>> needs to
>>>>>>>>>>>>>> be a way for pages to signal when they are providing data in
>>>>>>>>>>>>>> the sRGB
>>>>>>>>>>>>>> luminance space (where peak white is what the user has set as
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>> comfortable luminance for their desktop according to current
>>>>>>>>>>>>>> ambient
>>>>>>>>>>>>>> light) and when they are providing data in a different
>>>>>>>>>>>>>> luminance
>>>>>>>>>>>>>> space, where peak white is brighter (exactly how bright is
>>>>>>>>>>>>>> one of he
>>>>>>>>>>>>>> questions to be answered.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is defined in the CSS color spec [1]. If no profile is
>>>>>>>>>>>>> provided, peak white is peak sRGB white.
>>>>>>>>>>>>> The fact that you get blindingly white is a browser bug. (I
>>>>>>>>>>>>> believe only Safari does this right today)
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ​I think there is a mis-understanding here and that is why I
>>>>>>>>>>>> think the issue deserves discussion.
>>>>>>>>>>>>
>>>>>>>>>>>> As far as I can tell, [1] is entirely about color gamut. Whilst
>>>>>>>>>>>> there are many ways to identify colors, the specification does not seem to
>>>>>>>>>>>> treat dynamic ​range. The section you reference regarding profiles,
>>>>>>>>>>>> says "Others are more human-friendly to write and understand, *and
>>>>>>>>>>>> are converted to an sRGB color by CSS*".
>>>>>>>>>>>>
>>>>>>>>>>>> sRGB peak white will appear at the brightness the user prefers
>>>>>>>>>>>> for their environment (because most of the graphics they see are sRGB and
>>>>>>>>>>>> they will adjust the brightness control on their display).
>>>>>>>>>>>>
>>>>>>>>>>>> My point is that for capable displays, it should be possible to
>>>>>>>>>>>> make graphics brighter than that.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes, you can by either providing an image with an embedded
>>>>>>>>>>> profile that has a higher gamut than sRGB, or by specifying a CSS color [1]
>>>>>>>>>>> with an HDR profile.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ​Could you give an example of how you would specify an HDR
>>>>>>>>>> profile with CSS ?​ For example, if I wanted some white text that was twice
>>>>>>>>>> as bright as sRGB(255,255,255) text ? I don't see that in the css-color
>>>>>>>>>> specification.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dean wrote a blog about this: https://webkit.org/blog/
>>>>>>>>> 6682/improving-color-on-the-web/
>>>>>>>>>
>>>>>>>>
>>>>>>>> ​This is great, but it is all about gamut alone.​
>>>>>>>>
>>>>>>>> I don't know what profile is twice as bright as sRGB, but
>>>>>>>>> color(rec2020 255 255 255) would be brighter than rgb(255, 255, 255)
>>>>>>>>>
>>>>>>>>
>>>>>>>> ​Why would you think that ?
>>>>>>>>
>>>>>>>> In video, at least, the Rec.2020 color space is used for both SDR
>>>>>>>> and HDR, with a variety of transfer functions. I don't know if Rec.2020
>>>>>>>> defines a default transfer function, but if it does it is likely a gamma
>>>>>>>> function like sRGB, which is scene-referred.
>>>>>>>>
>>>>>>>> Someone has to decide, or signal, how the luminance range of that
>>>>>>>> 2020 data relates to the luminance range of sRGB data. It's not implied by
>>>>>>>> the color profile alone.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Note that I am not talking about a wider gamut - that seems to be
>>>>>>>>>> well covered - but a different dynamic range (i.e. a larger color volume,
>>>>>>>>>> not just larger color gamut).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> What do you mean by "color volume". Are you talking about higher
>>>>>>>>> bit depths for compositing?
>>>>>>>>>
>>>>>>>>
>>>>>>>> ​No, but higher bit depths are important too.
>>>>>>>>
>>>>>>>> As far as I can tell, CSS and ICC profiles deal with color gamut:
>>>>>>>> subspaces of the 2-dimensional CIE color space. A color in that space can
>>>>>>>> be described by two coordinates.
>>>>>>>>
>>>>>>>
>>>>>> This is incorrect. ICC profiles use 3 dimensions. Most charts show
>>>>>> color spaces as 2D projections which is probably why you think this.
>>>>>>
>>>>>>
>>>>>>> An actual pixel color has 3 coordinates and res​ides in a *color
>>>>>>>> volume*: a three-dimensional space where the intersection of this
>>>>>>>> space and a plane is the CIE space.
>>>>>>>>
>>>>>>>
>>>>>> Color volume is part of ICC.
>>>>>>
>>>>>>
>>>>>>> The problem we have can be thought of as a backwards compatibilty
>>>>>>>> one. You *could* specify luminance on the same scale for all image
>>>>>>>> / graphics data sources. And, indeed, I expect this is what the graphics
>>>>>>>> plane APIs of all devices will look like. In that case an RGB pixel in any
>>>>>>>> color space with linear values ( 1.0, 1.0, 1.0 ) will be rendered display
>>>>>>>> peak luminance (or close). I believe this is the case with CSS as things
>>>>>>>> stand.
>>>>>>>>
>>>>>>>
>>>>>> According to the spec, rgb(255,255,255) is rendered on as peak sRGB
>>>>>> luminance which isn't necessarily the peak of what your devices is capable
>>>>>> of.
>>>>>> This is why you can now specify a profile (which controls the
>>>>>> brightness) so you can attain what your display is capable of.
>>>>>>
>>>>>>
>>>>>>> This would support any and all HDR images / graphics, but the
>>>>>>>> problem would be that peak white in both SDR and HDR data would be rendered
>>>>>>>> the same. Most importantly, peak white in desktop graphics would be the
>>>>>>>> same as specular highlights in HDR images.
>>>>>>>>
>>>>>>>
>>>>>> No since peak white is controlled by the ICC profile.
>>>>>>
>>>>>>
>>>>>>> Since most desktop applications are going to stay sRGB, we need some
>>>>>>>> new way for authors to specify pixels that are brighter than that.
>>>>>>>>
>>>>>>>
>>>>>> Why do you think that desktop apps are staying in sRGB? Most graphics
>>>>>> applications support ICC today and the good ones support HDR.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>> Those colors are then mapped to the "device" color which usually
>>>>>>>>>>> is the monitor's colorspace. If you have an HDR monitor and specify an HDR
>>>>>>>>>>> image, you will get colors that are brighter than sRGB white.
>>>>>>>>>>>
>>>>>>>>>>> Safari is already doing this for images so you can try this for
>>>>>>>>>>> yourself if you have a capable device.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> If you do provide a profile, it will be used to map to the
>>>>>>>>>>>>> display.
>>>>>>>>>>>>> Is there a way to embed a profile in a video stream?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ​Here I am not talking about video. But, yes, video metadata
>>>>>>>>>>>> specifies not only color gamut (primaries) but a transfer function which is
>>>>>>>>>>>> used to map between encoded luminance and actual luminance and is different
>>>>>>>>>>>> for HDR and SDR video.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think we need to specify what is done with video. It seems
>>>>>>>>>>> that this information needs to be used so the browser knows how to manage
>>>>>>>>>>> the video's colors.
>>>>>>>>>>> what happens today with video?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ​Well, this is all rather new, so I doubt there is any
>>>>>>>>>> consistency. On the various devices we have seen which composite sRGB
>>>>>>>>>> graphics with HDR video it's highly variable. I expect when we see this on
>>>>>>>>>> devices with desktop-class browsers, the operating system will have made
>>>>>>>>>> some decision as to what luminance to map sRGB to, relative to the HDR
>>>>>>>>>> images. I've heard 80 nits. I've also heard of people planning to map sRGB
>>>>>>>>>> peak white to panel peak white.​
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> To obtain CSS use-cases, imagine first a still image extracted
>>>>>>>>>>>> from an HDR video, encoded in some still image format which carries HDR
>>>>>>>>>>>> metadata and which is supported by the browser.
>>>>>>>>>>>>
>>>>>>>>>>>> It should be possible to specify in CSS any color+luminance
>>>>>>>>>>>> that appears in that image. If the video or still image pixels are
>>>>>>>>>>>> constrained to be no brighter than the sRGB peak white (the luminance the
>>>>>>>>>>>> user prefers for their desktop), then you will not get any improvement in
>>>>>>>>>>>> appearance: for example specular highlights in the video / image would be
>>>>>>>>>>>> no brighter than for an SDR video / image, even though the display may be
>>>>>>>>>>>> capable of that.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes, extract the transfer function and other information from
>>>>>>>>>>> the video stream and use it to construct a profile. Then embed that profile
>>>>>>>>>>> in your still image.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ​What about actually specifying one of those colors in CSS ? So
>>>>>>>>>> that I can have text or graphics matching ​the colors in the image ?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You can place the profile on your web server,load it with css
>>>>>>>>> using @color-profile and use the name with the css color property.
>>>>>>>>>
>>>>>>>>
>>>>>>>> ​Like I said, I don't think the profile is enough, since it is
>>>>>>>> addressing gamut.​ Certainly, Rec. 2020, for example, does not tell me how
>>>>>>>> much brighter than sRGB it's peak white should be. In video we have
>>>>>>>> additional metadata for that.
>>>>>>>>
>>>>>>>
>>>>>>> It seems that there are some differences between the video and
>>>>>>> desktop world.
>>>>>>> I'm going to talk to some of our color experts to learn more about
>>>>>>> this subject.
>>>>>>>
>>>>>>
>>>>>> I talked to our people that deal with color for our video application
>>>>>> (premiere and after effects) and they say there's no difference between
>>>>>> video and desktop profiles.
>>>>>>
>>>>>
>>>>> In video, signals are accompanied with data including, separately, the
>>>>> color gamut and the transfer function. If I look at BT.2020, for example,
>>>>> it specifies color primaries and a scene-referred transfer function mapping
>>>>> ​the quantized tristimulus values to linear in the range 0-1. BT.2020 does
>>>>> not tell you "how bright" (1,1,1) should be.
>>>>>
>>>>> It does say:
>>>>>
>>>>> "In typical production practice the encoding function of image sources
>>>>> is adjusted so that the final picture has the desired look, as viewed on a
>>>>> reference monitor having the reference decoding function of Recommendation
>>>>> ITU-R BT.1886, in the reference viewing environment defined in
>>>>> Recommendation ITU-R BT.2035."
>>>>>
>>>>> and BT.1886 specifies a peak luminance of 100 nits (the standard for
>>>>> SDR TV).
>>>>>
>>>>> For HDR video, we use the BT.2020 color gamut (primaries), with the
>>>>> SMPTE ST.2084 Transfer Function (PQ) which specifies mapping from quantized
>>>>> tristimulus values to absolute luminance (from 0 to 10,000nits).
>>>>>
>>>>> So, I still have the problem that specifying "rec2020" or "dci-p3" in
>>>>> CSS does not tell me how the luminance of those pixel values should be
>>>>> rendered relative to the luminance of "srgb". Indeed, if I look at Section
>>>>> 10.2, it specifies the mappings associated with these color spaces to a
>>>>> linear [ 0, 1 ] space. A natural assumption is that all three have the same
>>>>> peak luminance (whatever you map 1.0 to, determined by the brightness
>>>>> control on the display).
>>>>>
>>>>> I do see that ICC profiles can include a luminanceTag field,
>>>>> specifying "absolute luminance of emissive devices in candelas per square
>>>>> metre as described by the Y channel". So perhaps what I am looking for is a
>>>>> variant of the "rec2020" profile with this luminanceTag set to 10,000 and
>>>>> somehow specifying the PQ transfer function instead of the one in BT.2020.
>>>>>
>>>>>
>>>>>
>>>> I'm unsure about the video case. For images and artwork, all the
>>>> information you need should be covered by the ICC workflow.
>>>>
>>>> If you want, I can put you in touch with one of our color experts since
>>>> they are more familiar with the details.
>>>>
>>>
>>> ​Yes, that would be great, thanks. But I would also like an opportunity
>>> to discuss the problem with the wider CSS group. At a minimum, even if
>>> profiles solve this, the specification is unclear as to what the rec2020
>>> profile refers to, since the 2020 colorspace is used for both SDR and HDR
>>> in video.​
>>>
>>
>> I got a reply from our color people:
>>
>> [snip]
>>
>> iMac now supports HDR, with a peak of 500 nits.
>>
>> Classic SDR content is not mapped to 500 nits.
>> Instead it maps to a brightness set by the user, often around 200 nits.
>> Classic SDR content includes all legacy apps, such as Safari, MS Word,
>> email…
>> For these apps, MacOS maps their diffuse white (1.0, 255 etc)  to this
>> 200 nit setting.
>>
>> In order to display HDR content above 200 nits, an app must produce frame
>> buffer values > 1.0.
>> Classic apps don’t know how to do that.
>>
>> HDR aware apps know that the peak of all non-HDR color spaces (sRGB,
>> BT.2020…) should be mapped to 1.0, which OS maps to 200 nits.
>> And for HDR spaces, they know that the diffuse white point in the HDR
>> space is also mapped to 1.0.
>> The diffuse white point for PQ-encoding is at 100-200 nits, not max code
>> value.
>> AFAIK both Apple and Msft maps PQ for 100 nits to diffuse white.
>>
>> If you want something brighter than sRGB white, then use a proper HDR
>> color space.
>> BT.2020 is not an HDR space.
>> HDR10 is an HDR space, with same primaries as BT.2020.
>>
>>
>> If you combine this with Simon Fraser's email:
>>
>> Compositing happens in 10-bit or half-float textures which may contain <
>> 0 or > 1 values. A P3 image is mapped into this unclipped sRGB space for
>> compositing, then the final result is mapped into Display-P3 at the end.
>>
>> then it looks that if you can tag something with HDR10 and the color
>> values are high enough, the result will be brighter than than 200 nits at
>> least on system that support HDR. (The unclipped sRGB space does sound a
>> bit weird.)
>>
>>>
>>>
>>>> I just use profiles as a black box. 😀
>>>>
>>>
>>> ​The full power of iCC profiles may solve this. But what seems unclear
>>> to me is whether the profiles defined in CSS (sRGB, rec2020, dci-p3) are
>>> well enough defined for it to be clear how their luminance ranges should be
>>> mapped to ​actual physical luminance, *relative to each other*.
>>>
>>> For example, whilst sRGB, at least as defined in [1], defines peak white
>>> to be 80nits, BT.2020 (as I noted above) does not specify a peak luminance
>>> and at least with video is used with different transfer functions with peak
>>> luminance 100nits (SDR) or 10,000nits (HDR with PQ). So, what does it mean
>>> when you specify rec2020 in CSS ? And, if it means 100nits, because 2020
>>> notes that this is a "typical" usage, how do I specify a profile where 2020
>>> colorspace is used with 10,000nits peak ? Do implementations *actually*
>>> map the 2020 luminance range to 125% of the sRGB range and is that even the
>>> right thing to do ?
>>>
>>> (and this is before we even start talking about how video metadata can
>>> influence tone mapping and how one might be able to get the same tone
>>> mapping applied to graphics / images).
>>>
>>> If there is not time on the CSS agenda (which is see is rather full) for
>>> this, I wonder if there would be interest in a break-out session on
>>> Wednesday ?
>>>
>>
>> We could. The hard part would be to track down the experts. It's easy to
>> get confused by all the different color standards.
>> Your questions seem more about quality of implementation than the w3c
>> color specification.
>>
>>
>> I think your answer above demonstrates that there is a spec issue, not
>> just quality-of-implementation issues, since it is by no means clear from
>> the specification that the approach taken by Apple is the only one.
>>
>
> Currently, the spec chooses not to specify how a document should be
> rendered. This could be added once implementations and other specs (such as
> ICC) progress.
>
> However, if you follow the proposed color spec and tag everything the way
> you'd like it to render, the ICC conversions will give you the best output
> per the current output device.
>
>
> I think it's still under specified, as I explained above. Specifically the
> relative luminance of SDR and HDR color spaces as well as the issue below
> which you seem to agree with.
>
>
>
>
>> The approach described above - where the value 1.0 always means the same
>> thing independent of color space, seems reasonable, but also it would be
>> reasonable that if a color is tagged as being from an HDR space that the
>> peak white of that space is also 1.0.
>>
>
> Yes, that would be nice.
>
>
>> The question of what luminance value in an HDR space should be mapped to
>> the same as sRGB diffuse white (the 1.0 value) is not answered in the HDR
>> specifications I am aware of.
>>
>> Also, it would be nice to have a shorthand for 2020 color primaries used
>> with an HDR transfer function, for example as defined in BT.2100 with PQ.
>>
>
> These 3 issues are about HDR ICC profiles; not with the CSS color spec or
> anything that is controlled by w3c.
>
>
> I disagree. The first issue is relevant wherever you have compositing of
> data specified in multiple color spaces, SDR and HDR. The relative
> luminance mapping needs to be defined somewhere and I would expect each
> environment where this can happen to do so (and CSS is one such
> environment).
>
> The other issue is a straightforward request for CSS to define a shorthand
> for a specific HDR color space, as has been done for sRGB and 2020 in the
> color spec. This is certainly in scope.
>
> Maybe you should take this up with that organization?
>
>
>
>> These issues at least deserve discussion.
>>
>
> Yes. Let's have a meeting on Wednesday morning. Leonard is familiar with
> this ares and agreed to attend.
>
>
>>
>>> ​[1] https://www.w3.org/Graphics/Color/srgb​
>>>
>>>
>>>
>>>>
>>>> If more is needed than what is already specked, we can bring it back to
>>>> the list.
>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> I will be at TPAC next week as well so maybe we can have a short
>>>>>>> get-together.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> If the WICG is the appropriate place to raise these problems,
>>>>>>>>>>>>>> I can do
>>>>>>>>>>>>>> that, but the experts are in CSS WG so I wondered if there was
>>>>>>>>>>>>>> interest in learning about these issues.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks ... Mark
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1: https://drafts.csswg.org/css-color/#color-type
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> 1: https://drafts.csswg.org/css-color/#icc-colors
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> 1: https://drafts.csswg.org/css-color/#at-profile
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>