- From: John Bowler <john.cunningham.bowler@gmail.com>
- Date: Sun, 29 Sep 2024 12:08:18 -0700
- To: "public-png@w3.org" <public-png@w3.org>
- Message-ID: <CAP7U399c-+3TTPOZy8WRuQDiyrgNstALHajGCR8x=f+Kgj5e4Q@mail.gmail.com>
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