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

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.

Received on Sunday, 29 September 2024 19:08:33 UTC