Re: [PNG] Meeting discussion topics

I'm on travel back from W3C TPAC, so won't be able to make this meeting.

On 2024-09-28 03:24, Chris Blume (ProgramMax) 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.
>
What is undefined about

 > The color primaries are encoded as three pairs of PNG two-byte 
unsigned integers, in the order /x/ and then /y/, each representing the 
x or y primary chromaticity value divided by the divisor value. They are 
ordered starting with the primary with the largest x chromaticity, 
followed by the primary with the largest y chromaticity, followed by the 
remaining primary. For RGB color spaces, this corresponds to the order 
R, G, B.

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

-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media