Re: [EXTERNAL] Re: [PNG] Meeting discussion topics

I do agree there is a spec issue.
mDCv is currently safe-to-copy but I'm pretty sure it shouldn't be.
The safe-to-copy bit is used when someone opens the image in an unaware
editor and modifies it.
If the editor is unaware of mDCv, *their* display effectively becomes the
new mastering display. The previous display's gamut was entirely ignored.
So it shouldn't be copied as if it was used.
Alternatively, if the editor is aware of the mDCv chunk it could be mindful
during modification, using colors that match the original mastering
display. But if the editor is aware, it doesn't care about the safe-to-copy
bit anyway.

(Although that said, I don't know any editors that follow the safe-to-copy
guidelines. That's a whole other topic, though.)

This also addresses the relative-to-PLTE requirement. If it is marked
unsafe-to-copy it can be relative to PLTE.



On Sun, Sep 29, 2024 at 3:08 PM John Bowler <
john.cunningham.bowler@gmail.com> wrote:

>
>
>
> On Sun, Sep 29, 2024 at 10:57 AM Seeger, Chris (NBCUniversal) <
> Chris.Seeger@nbcuni.com> wrote:
>
>>
>>  The luminance characteristics of ST.2086 required display referred
>> values (in cd/m2) and ACES is scene-referred which would only describe
>> relative values of luminance.
>>
>
> Ok.  So you seem to be saying that mDCv can only be used where there is a *real
> *device with three (primary) colours that effectively limited the colours
> shown in the image or image sequence.  So (to answer the question I just
> asked ChrisB on github) an image with an ACES AP0 or AP1 colour space could
> appear in the workflow but the mDCv would specify the *intent* of rendering
> for that workflow which might, as a result, not include quite a lot of the
> colours or dynamic range in the PNG.  ACEScg or similar would appear in a
> cHRM chunk (or ICC profile) and the mDCv would say how the author expected
> it to be adapted.
>
> That's safe-to-copy metadata; it records the "intent" and it is not
> required to actually decode or display the image.  Indeed if the image is
> used with a different physical mastering device a different colour volume
> might be selected; the sequence could be remastered.
>
> The spec issue is that the spec says two different things; in one place it
> says that safe-to-copy chunks cannot have an ordering with result to PLTE
> (14.3.2) but in the mDCv and cLLi specification it specifies a contrary
> (and more strict) ordering requirement (5.6).  Like I said the ambiguity in
> the spec is not related to the chunk contents; those latter issues are just
> a lack of clarity.
>
>