On Sat, Jan 4, 2025 at 4:15 AM Chris Blume (ProgramMax) < 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?) 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 compare with the previous version, currently here: https://github.com/pnggroup/libpng/blob/libpng18/pngtest.png 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 >
Received on Saturday, 4 January 2025 19:39:13 UTC