Re: [EXTERNAL] Re: [PNG] Meeting discussion topics

Regarding ST-2086 and ACES.  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.

How can ST 2086 be applied to ACES workflows (besides color primaries themselves)?

I’m not that knowledable about ACES, but the basic working space is scene-referred with my understanding.

Best,

Chris Seeger
Director, Advanced Content Production
Office of the CTO
C: 551-238-3768
[signature_163783873]
[signature_2794606205]
[signature_631082593]


From: Chris Blume (ProgramMax) <programmax@gmail.com>
Date: Sunday, September 29, 2024 at 1:41 PM
To: Leo Barnes <lbarnes@apple.com>
Cc: public-png@w3.org <public-png@w3.org>
Subject: [EXTERNAL] Re: [PNG] Meeting discussion topics
Oh. I had misunderstood the problem.
Given what Chris Lilley showed, it seems well specified. That was my concern.
(And it seems like we match ISOBMFF, which is good.)

It sounds like perhaps the problem is with SMPTE-ST-2086's ability to represent ACES AP0. But that means it isn't a PNG problem, per se.
Maybe there is no intention to support AP0. After all, CIE 1931's Y component is luminance. And it is pretty far-fetched for a mastering display to be able to produce negative luminance.
We can still discuss it. If it would make sense for PNGs to support AP0, we will need another solution.
(SMPTE-ST-2086 says "...and the y coordinate shall be in the range [0.0001, 0.8400]" which doesn't allow for negative values.)

But that said, PNG is well specified and is implementable as-is, as far as mDCv. So the main problem here is solved.


Chris Lilley, do you have any thoughts on the meeting topics that I can make sure we address? I feel like the generic non-RGB image data idea will need a lot of discussion. But perhaps our best bet is to start with a strawman doc and follow up with discussion. I'll try to keep thorough meeting minutes.

On Sun, Sep 29, 2024 at 9:45 AM Leo Barnes <lbarnes@apple.com<mailto:lbarnes@apple.com>> wrote:



On 28 Sep 2024, at 14:38, Chris Blume (ProgramMax) <programmax@gmail.com<mailto:programmax@gmail.com>> wrote:

That would be convenient if it is big-endian.
PNG uses network byte order, which is big-endian.
*crosses fingers*

ISOBMFF has this:
class MasteringDisplayColourVolumeBox extends Box('mdcv'){
for (c = 0; c<3; c++) {
unsigned int(16) display_primaries_x;
unsigned int(16) display_primaries_y;
}
unsigned int(16) white_point_x;
unsigned int(16) white_point_y;
unsigned int(32) max_display_mastering_luminance;
unsigned int(32) min_display_mastering_luminance;
}


And since everything in ISOBMFF is big-endian unless explicitly called out as not being so it should match the mDCv chunk I think.
HEIF and MP4 both just refer to ISOBMFF when it comes to this box, so this then applies to both of them as well.

Cheers,
//Leo



On Sat, Sep 28, 2024 at 7:37 AM Leo Barnes <lbarnes@apple.com<mailto:lbarnes@apple.com>> wrote:

Sent from my iPhone


On Sep 28, 2024, at 12:25, Chris Blume (ProgramMax) <programmax@gmail.com<mailto:programmax@gmail.com>> wrote:

Hello everyone,

We will be holding a meeting this coming Monday, Sep 30th, 2024.
I apologize for not getting the mail out sooner.
I've gathered some topics we need to discuss.

  *   Some of us were added as "authors", but I believe we should be in the "editors" list. I have a PR out for this<https://urldefense.com/v3/__https:/github.com/w3c/png/pull/466__;!!PIZeeW5wscynRQ!sRjdT5QnRWwUX2dPrq-xxV4FSwfHORdPcoL_XaAhQqykp5pX0NYCxJgUZse3Uj0gnh6bQQOBYea1AngsUVy4$>.
  *   mDCv & cLLi are safe-to-copy<https://urldefense.com/v3/__https:/www.w3.org/TR/png-3/*5Chunk-naming-conventions__;Iw!!PIZeeW5wscynRQ!sRjdT5QnRWwUX2dPrq-xxV4FSwfHORdPcoL_XaAhQqykp5pX0NYCxJgUZse3Uj0gnh6bQQOBYea1Arf6k3D2$>. But perhaps they shouldn't be. If a user opens an image in an old editor, modifies the file by drawing on top (with color values that ignored mDCv & cLLi chunks because it was an old editor), the saved file shouldn't keep mDCv & cLLi, right?
  *   Brought up in libpng issue 509<https://urldefense.com/v3/__https:/github.com/pnggroup/libpng/issues/509__;!!PIZeeW5wscynRQ!sRjdT5QnRWwUX2dPrq-xxV4FSwfHORdPcoL_XaAhQqykp5pX0NYCxJgUZse3Uj0gnh6bQQOBYea1AnSxfOO6$>, mDCv<https://urldefense.com/v3/__https:/www.w3.org/TR/png-3/*mDCv-chunk__;Iw!!PIZeeW5wscynRQ!sRjdT5QnRWwUX2dPrq-xxV4FSwfHORdPcoL_XaAhQqykp5pX0NYCxJgUZse3Uj0gnh6bQQOBYea1AkgaNbPc$> doesn't specify how the bytes are encoded. It references SMPTE-ST-2086<https://urldefense.com/v3/__https:/ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8353899__;!!PIZeeW5wscynRQ!sRjdT5QnRWwUX2dPrq-xxV4FSwfHORdPcoL_XaAhQqykp5pX0NYCxJgUZse3Uj0gnh6bQQOBYea1AqoH_YkL$>. But that only specifies values, not storage. My default is to go with existing png byte definitions. However, perhaps there are other specs using SMPTE-ST-2086 which already define a storage format that is different. Do we know of any?
mdcv is used in ISOBMFF for both HEIF stills and MP4 videos. I don’t have the spec in front of me right now, but ISOBMFF tends to store stuff as big-endian.

Cheers,
//Leo



If we want to consider future editions:

  *   PNG is already used for components outside of RGB for things like games (normals, reflectivity, etc). We're about to add gain mapping. And if we can store YUV, we unlock some future compression improvement. Rather than make a chunk specific to gain mapping, should we be generic about other image data? Should we consider breaking the "IDATs are consecutive" rule so this data can be interleaved? I'll perhaps write a longer doc for this and look into if any tools enforce "IDATs are consecutive".
Thanks, everyone! See you Monday!