Re: [PNG] Meeting discussion topics

> 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 <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://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!

Received on Sunday, 29 September 2024 13:46:50 UTC