Implement mDCv chunk described in PNG 3rd Edition (Priority 2) #509
Comments
|
Yet another broken link :-) The current draft spec is here: https://www.w3.org/TR/png-3/#mDCv-chunk The spec is, well, very wordy and not very useful; it's not a normative spec, it's pretty much a discussion. I'm sure this will change during review; proffering opinions in ISO specs is not normally acceptable! At present the spec is unimplementable simply because it does not define the encoding of the fields. It says how many bytes each contains but not how the bytes are encoded! It's possible to deduce that the CIExyY values are encoded in two bytes for x and y but it is not possible to deduce whether that is a signed or unsigned value given the error in cHRM (it erroneously uses unsigned values). The ACES AP0 color space has a negative "y" (and, as discussed, AP1 has a negative "z" but that's ok, as discussed.) The same problem may exist with cLLi because display relative images can, in fact, have negative luminance. This is a consequence of the need to offset colours to make them visible, so in display space a colour may end up with a negative luminance because it is below the level of perception in the viewing environment (the "black level"). |
|
Negative luminance values in narrow range can also contain pluge (which allows monitor setup for black levels)
Get Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: John Bowler ***@***.***>
Sent: Friday, September 13, 2024 11:28:30 PM
To: pnggroup/libpng ***@***.***>
Cc: Seeger, Chris (NBCUniversal) ***@***.***>; Author ***@***.***>
Subject: [EXTERNAL] Re: [pnggroup/libpng] Implement mDCv chunk described in PNG 3rd Edition (Priority 2) (Issue #509)
Yet another broken link :-) The current draft spec is here:
https://www.w3.org/TR/png-3/#mDCv-chunk<https://urldefense.com/v3/__https://www.w3.org/TR/png-3/*mDCv-chunk__;Iw!!PIZeeW5wscynRQ!o4a0hdot9Sz7xQWBGhep60fgNMq9nS2MR3t58Kkd0jgpPG4-I6eXJHqQTwSR7Y6gKpxXzO-xSsPrWVwNPiO6ZQzGUg$>
The spec is, well, very wordy and not very useful; it's not a normative spec, it's pretty much a discussion. I'm sure this will change during review; proffering opinions in ISO specs is not normally acceptable! At present the spec is unimplementable simply because it does not define the encoding of the fields. It says how many bytes each contains but not how the bytes are encoded!
It's possible to deduce that the CIExyY values are encoded in two bytes for x and y but it is not possible to deduce whether that is a signed or unsigned value given the error in cHRM (it erroneously uses unsigned values). The ACES AP0 color space has a negative "y" (and, as discussed, AP1 has a negative "z" but that's ok, as discussed.)
The same problem may exist with cLLi because display relative images can, in fact, have negative luminance. This is a consequence of the need to offset colours to make them visible, so in display space a colour may end up with a negative luminance because it is below the level of perception in the viewing environment (the "black level").
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/pnggroup/libpng/issues/509*issuecomment-2350811893__;Iw!!PIZeeW5wscynRQ!o4a0hdot9Sz7xQWBGhep60fgNMq9nS2MR3t58Kkd0jgpPG4-I6eXJHqQTwSR7Y6gKpxXzO-xSsPrWVwNPiPNTljpug$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AANIO6COSORWH326M5ORDHDZWOUN5AVCNFSM6AAAAABOGOIBL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJQHAYTCOBZGM__;!!PIZeeW5wscynRQ!o4a0hdot9Sz7xQWBGhep60fgNMq9nS2MR3t58Kkd0jgpPG4-I6eXJHqQTwSR7Y6gKpxXzO-xSsPrWVwNPiPHZgB5zg$>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Indeed, and I would expect a display application or editor which handles the cICP chunk to handle values outside the 16..235 range. Indeed any app that reads Kodak's PhotoCD already has to handle the negative values. PhotoCD is a 16..235 encoding, though (IRC) without the signaling values. Similarly image resampling produces RGB values outside the bounds of the original values even given perfectly sampled image data and perfect resampling (sinc, done correctly.) |
|
Another note; the current spec defines the fields thus: https://www.w3.org/TR/png-3/#mDCv-chunk-syntax To quote the table (table 19 at present):
The title line of the third column is wrong (the values are scale factors; multipliers not divisors). That's clear to me; for one thing the last two rows are dimensionally incorrect (luminance is measured in cd/m2, not 1/(cd/m2) but it will probably lead to some confusion. |
|
The standard SMPTE ST 2067-21 indicates them as "units of" in Annex B. I think all that needs to occur is moving cd/m2 to the name column. The store value is multiplied by the divisor to get the resulting luminance in cd/m2 |
|
Change has been posted to branch 464 in PNG 3rd Edition |
|
Ok. It would be useful to know the maximum values of all four fields; it's no problem with floating point but libpng also has fixed point APIs. |
|
Following up here, the mDCv chunk does specify the byte definition. So it can be implemented. Although negative luminance values in narrow range can act as a control signal, those signal values are separate from the display's color volume. I think some of the conversation here is mixing logical color spaces with the physical mastering display's color volume, right? |
|
ACES is intended for use in video workflows; it was originated (in 2014) by the film industry. It is a mastering color space. Clarification is required in the spec with regard to specifications like ACES. Are we meant to put the workflow space in cHRM (etc) or in mDCv? |
|
"Mastering Display" here is the monitor/display used while mastering. It would be possible to use ACES in the workflow and then render out to a final, non-ACES color space for the end user. The reason we care about the mastering display at all is for the end user's processing to try to match it. It is a way to provide a target for the end device. |
|
Hi John,
Mdcv requires a display-referred system so that there is a definitive luminance value.
ACES is a scene-referred and is therefore represents relative levels:
https://www.toodee.de/using-aces/display-referred-vs-scene-referred/
I don’t see how a relative system can represent absolute values that are required by MDCV (which describes a displays min/max luminance level capabilities).
MDCV describes the technical characteristics of the “Mastering Display Color Volume” itself. It is not a relative “mastering color space”.
The png working color space for video workflows would be described in CICP where the color primaries, transfer function (light mapping), matrix coefficient and signal range(quantization in full or narrow range) are described.
Best,
Chris
From: John Bowler ***@***.***>
Date: Sunday, September 29, 2024 at 2:26 PM
To: pnggroup/libpng ***@***.***>
Cc: Seeger, Chris (NBCUniversal) ***@***.***>, Author ***@***.***>
Subject: [EXTERNAL] Re: [pnggroup/libpng] Implement mDCv chunk described in PNG 3rd Edition (Priority 2) (Issue #509)
ACES is intended for use in video workflows; it was originated (in 2014) by the film industry. It is a mastering color space. Clarification is required in the spec with regard to specifications like ACES. Are we meant to put the workflow space in cHRM (etc) or in mDCv?
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/pnggroup/libpng/issues/509*issuecomment-2381453418__;Iw!!PIZeeW5wscynRQ!sYcV26t_39O2tJ3-96tve_RIBbyjCSLJiz99px1hxgbRvxWQeoixjVRh5XKxXmx4JlC1aS6dYcg7I3coCzvOH9PABg$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AANIO6DNYQSXHEZGYLEOLXTZZBA6LAVCNFSM6AAAAABOGOIBL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBRGQ2TGNBRHA__;!!PIZeeW5wscynRQ!sYcV26t_39O2tJ3-96tve_RIBbyjCSLJiz99px1hxgbRvxWQeoixjVRh5XKxXmx4JlC1aS6dYcg7I3coCzuFs-9f6A$>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
It is useful if the content was mastered with a display that had a higher luminance then a target display so a tone-mapping can be built to avoid simple clipping.
…very useful for HDR display or when remapping HDR to SDR…
Best,
Chris
From: Chris Blume ***@***.***>
Date: Sunday, September 29, 2024 at 2:44 PM
To: pnggroup/libpng ***@***.***>
Cc: Seeger, Chris (NBCUniversal) ***@***.***>, Author ***@***.***>
Subject: [EXTERNAL] Re: [pnggroup/libpng] Implement mDCv chunk described in PNG 3rd Edition (Priority 2) (Issue #509)
"Mastering Display" here is the monitor/display used while mastering.
That is separate from the image's color space. And the workflow color space could also be different.
It would be possible to use ACES in the workflow and then render out to a final, non-ACES color space for the end user.
The reason we care about the mastering display at all is for the end user's processing to try to match it. It is a way to provide a target for the end device.
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/pnggroup/libpng/issues/509*issuecomment-2381458428__;Iw!!PIZeeW5wscynRQ!tg3JgEAAkgS6ystXKlmAX3A_oxmmCYoca52UElNMNEDiLSsz3ji3hY8UPvIsRfyxdHKQCyeGZTLt1on7rgIes2tJ7g$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AANIO6ARPURM6W4FIG6C4VLZZBC7XAVCNFSM6AAAAABOGOIBL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBRGQ2TQNBSHA__;!!PIZeeW5wscynRQ!tg3JgEAAkgS6ystXKlmAX3A_oxmmCYoca52UElNMNEDiLSsz3ji3hY8UPvIsRfyxdHKQCyeGZTLt1on7rgJDqgX1XA$>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
mDCv or Mastering Display Color Volume (SMPTE ST 2086) stores static metadata which idenfies display characteristics of the mastering display and allows optimized tone and color mapping to a target (consumer display).
mDCv is helpful because the content creation display may have superior capabilities compared to the target display, therefore tone and color mapping may be necessary
The text was updated successfully, but these errors were encountered: