Re: Discuss HDR at CSS WG next week ?

On Tue, Sep 20, 2016 at 1:30 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> 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.
>

​I think the two things which came up specifically with the color
specification were:
(i) the predefined "dci-p3" profile is mis-named. There should be some
changes to clarify that this is not DCI P3, but rather a profile defined in
this specification which makes used of the DCI P3 color primaries​. You
could call it "web-p3" or "display-p3" or whetever.
(ii) when the update to iccMax is done, it would be good to have at least
one predefined profile for HDR (e.g. BT.2100 / PQ), especially since I
heard at least one implementor say they did not intend to implement
arbitrary ICC profiles, but rather just the predefined ones

The question of where to map the SDR / sRGB luminance range when
compositing with HDR is unsolved. It may be that for consistent results
across platforms this needs to be specified. But there needs to be a period
of experimentation on that before we could conclude either that
specification is needed or that CSS color is a good place to specify it.

...Mark



> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>