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> wrote:

>
>
> On 28 Sep 2024, at 14:38, Chris Blume (ProgramMax) <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> wrote:
>
>>
>> Sent from my iPhone
>>
>> On Sep 28, 2024, at 12:25, Chris Blume (ProgramMax) <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://github.com/w3c/png/pull/466>.
>>    - mDCv & cLLi are safe-to-copy
>>    <https://www.w3.org/TR/png-3/#5Chunk-naming-conventions>. 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://github.com/pnggroup/libpng/issues/509>, mDCv
>>    <https://www.w3.org/TR/png-3/#mDCv-chunk> doesn't specify how the
>>    bytes are encoded. It references SMPTE-ST-2086
>>    <https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8353899>. 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!
>>
>>
>