Re: [EXTERNAL] Re: [PNG] Meeting topics - Jan 6, 2025

More info inline below.  I’ve posted the same info in Issue #319 so it’s documented:

From: John Bowler <john.cunningham.bowler@gmail.com>
Date: Saturday, January 4, 2025 at 2:39 PM
To: Chris Blume (ProgramMax) <programmax@gmail.com>
Cc: jbowler@acm.org <jbowler@acm.org>, 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
On Sat, Jan 4, 2025 at 4:15 AM Chris Blume (ProgramMax) <programmax@gmail.com<mailto:programmax@gmail.com>> wrote:
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?

I think the spec as currently written (the latest author's draft from the W3C web site) is unambiguous.  Though there does seem to be some confusion, from issue #319:

>If present, mDCv and cLLi SHALL completely define the tone mapping algorithm used by the decoder when rendering the image to a display.

I guess, if nothing else defines the tone mapping, however I assume that REC-2020 (and 2021) define the tone mapping for any conformant device because no device available currently covers all of the colour gamut of 2020 and I rather suspect very few if any match the dynamic range of PQ (how many 10,000cd/m2 OLEDs are there?)

mDCV and cLLI do not define a tone mapping algorithm.  They are INFORMATIVE to the tone mapping that a manufacturer decides to use. The algorithm applied is entirely subjectively and determined by each manufacturer for their product.  Its purpose was for implemention (tone mapping) on the final display side only. It forms are relationship between the content creation characteristics and the final target display.

BT.2020 describes location of color primaries and white point (D65) only (no tone mapping).  BT.2446 has some mention of tone mapping but it’s not meant for source to target display tone mapping.

Please take a look at SMPTE ST 2067-21 and CTA 861.3.  There's not mention of a specific algorithm that will be implemented to tone map.

So what the spec says in the latest authors draft (at least) is what I've always assumed.

BTW, it was about half a day writing code, testing code, generating a (crude) test file, here:

https://github.com/jbowler/libpng/blob/pngv3-mDCV%2BcLLI/pngtest.png<https://urldefense.com/v3/__https:/github.com/jbowler/libpng/blob/pngv3-mDCV*2BcLLI/pngtest.png__;JQ!!PIZeeW5wscynRQ!sFBGQQx6BUCfcsfmNbyunoUEUfohkbgVObrX5J9jmvwzvmeuFb8SwMmH37Dk1Q3oXjMSwoEfWNoO8-By98q8fepL7HrS$>

compare with the previous version, currently here:

https://github.com/pnggroup/libpng/blob/libpng18/pngtest.png<https://urldefense.com/v3/__https:/github.com/pnggroup/libpng/blob/libpng18/pngtest.png__;!!PIZeeW5wscynRQ!sFBGQQx6BUCfcsfmNbyunoUEUfohkbgVObrX5J9jmvwzvmeuFb8SwMmH37Dk1Q3oXjMSwoEfWNoO8-By98q8fQHr7efS$>

The issue for me isn't writing code.  That never takes any time.  The problem is testing it.  Fortunately mDCV and cLLI are normally metadata and, anyway, none of the apps out there that support the three chunks will use the new support in libpng16.  What we have to worry about is that we don't produce bogus data as a result of the new support code.  That is precisely what happened with cICP - libpng shifted it to the wrong place.  That harms apps which do support cICP (etc) even if they don't use the libpng16 support because **anything which used the new support would write bogus PNG files**.  Well, that known problem is fixed.  I hope Cosmin gets the final part in soon so that apps can simply swap to the new support, rather than half-swapping, and test all of it.

John Bowler