[PNG] Meeting discussion topics

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?

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!