- From: Seeger, Chris (NBCUniversal) <Chris.Seeger@nbcuni.com>
- Date: Sat, 4 Jan 2025 14:39:54 +0000
- To: "Chris Blume (ProgramMax)" <programmax@gmail.com>, "jbowler@acm.org" <jbowler@acm.org>
- CC: Chris Lilley <chris@w3.org>, "Portable Network Graphics (PNG) Working Group" <public-png@w3.org>
- Message-ID: <BL0PR14MB379551BD9FAAD4EE9379D55AE6162@BL0PR14MB3795.namprd14.prod.outlook.com>
Hi Chris, …for info for folks and their concerns. The first paragraph is really the most important: The use of mDCV and cLLI color and light processing is left up to the device or software. Both are only metadata that represents what mastering display capabilities/settings are and the Min/Max light levels in the content itself. The metadata does not determine or provide algorithms that are used for color or light processing, nor does it force the device or software to use the metadata for remapping. It is informative. The values for mDCV are explicit and will be correct if the content creator authored correctly. The values for cLLI are often slightly different from the original specification. Specifically, professionals who know better, don’t measure single pixels for MaxCLL Min/Max. They typically average a few pixels around the darkest and brightest pixels. MaxFALL follows the spec explicitly. mDCV has metadata for light and color: * For mastering display color primaries and white point capabilities. It’s typical benefit for broadcast is when color primaries of the content is BT.2020, but the mastering display is only capable of P3. In this case, the pre-filtered P3 content colors are placed in a BT.2020 “container” so that most displays which aren’t capable of 100% of BT.2020 don’t display artifacts (hue shifts). mDCV indicates the limits of the mastering display against the content. * For mastering display capabilities to display blacks and peak whites luminance levels (Min/Max), this metadata can assist displays with inferior capabilities to tone-map vs clip. This can potentially improve detail preservation by applying a knee at the upper end of the signal. Since chroma will be affected here, there is some effect on perception of color. cLLI has metadata for light ONLY: * MaxCLL: This metadata standard specifies the single-pixel peak luminance level during the entire length of the content. It should be noted that most make this measurement by averaging several adjacent pixels to avoid aggressive tone mapping based on a single bright pixel. * MaxFALL: This metadata value represents the measures average luminance of each frame and then an average of those values over the entire length of the content itself. * cLLI uses the actual content light levels to improve tone mapping that would occur using the Min/Max values of mDCV. As with mDCV Min/Max, chroma can be affected during tone mapping. Chris Seeger From: Chris Blume (ProgramMax) <programmax@gmail.com> Date: Saturday, January 4, 2025 at 7:16 AM To: jbowler@acm.org <jbowler@acm.org> Cc: Chris Lilley <chris@w3.org>, Seeger, Chris (NBCUniversal) <Chris.Seeger@nbcuni.com>, Portable Network Graphics (PNG) Working Group <public-png@w3.org> Subject: Re: [EXTERNAL] Re: [PNG] Meeting topics - Jan 6, 2025 IIUC (I am not a color expert so please fill in my knowledge gaps) HDR processed with mDCV and cLLI will produce different colors than HDR processed without. Perhaps that is the breakage concern? If that is the concern, this would only affect PNGs with one/both of those chunks. All other PNGs would be fine. And cICP would be beneficial for WCG and HDR PNGs that don't use those chunks. But like John said, if we can land mDCV and cLLI quickly (they're relatively simple since they just feed the raw values to the client app) perhaps it is fine. So maybe the way we could handle this is give a month for the mDCV/cLLI patch to land before releasing the libpng update? That way if the patch lands in a week we're barely delaying cICP anyway. And if the patch ends up taking a while for some unforeseen reason, we can release without it having made a reasonable tradeoff between benefit and harm for PNGs. On Sat, Jan 4, 2025 at 2:02 AM John Bowler <john.cunningham.bowler@gmail.com<mailto:john.cunningham.bowler@gmail.com>> wrote: On Fri, Jan 3, 2025 at 5:12 PM Chris Lilley <chris@w3.org<mailto:chris@w3.org>> wrote: I agree with John that delaying cLLI and mDCV would be unfortunate and produce breakage. I've just submitted pull request https://github.com/pnggroup/libpng/pull/635<https://urldefense.com/v3/__https:/github.com/pnggroup/libpng/pull/635__;!!PIZeeW5wscynRQ!vw04xFHSM_1W26JmzMBbYJZ-JozAmgVP2tsRkTZenxs7kip6bCWqea5cdmU-R77r_xiLPWTkr--6QmveBPeY$>. If Cosmin accepts that this is moot because it provides full support for the two chunks. John Bowler
Received on Saturday, 4 January 2025 14:40:22 UTC