Re: [PNG] Meeting discussion topics

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

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