- From: Chris Blume (ProgramMax) <programmax@gmail.com>
- Date: Fri, 4 Oct 2024 10:30:05 -0400
- To: "Portable Network Graphics (PNG) Working Group" <public-png@w3.org>
- Message-ID: <CAG3W2KfnbpaK6togBpGBC-VWCs-JAr7tXeykRVJrOoVxA8iMxQ@mail.gmail.com>
Quick follow up: I'm currently researching the safe-to-copy bit's history, usage, etc. I noticed that the eXIf chunk might also change to eXIF, along side mDCv & cLLi changing to mDCV & cLLI. The quick summary so far is all chunks are safe-to-copy unless they depend on some data and that data might change. If a chunk depends on stored color values, a change to those stored color values will invalidate those dependent chunks. This means a program like optiPNG which doesn't change stored color values will see all existing chunks as safe-to-copy. However, optiPNG changes the DEFLATE data. Any chunks that depend on the DEFLATE data will be invalidated. This scenario is proposed for a future chunk, which would mark where DEFLATE reset markers are inserted into the DEFLATE stream. This would allow parallel decoding. On Mon, Sep 30, 2024 at 12:07 PM Chris Blume (ProgramMax) < programmax@gmail.com> wrote: > Attached is a PDF of the meeting minutes from Sep 30th, 2024. > > Attendance was low but that is expected so close to TPAC ending. > > Executive summary: > > - A surprising amount of sudden work completed. > - mDCv & cLLi might be changing to unsafe-to-copy. > - Pending more clarity on the meaning of "safe-to-copy", which > itself is pending clarity on the definition of "PNG editor". > - The broadcast industry has specs blocked on PNG Third Edition > becoming recommended. Rally the troops! > > Our next meeting is Oct 14th, 2024. > See you there! >
Received on Friday, 4 October 2024 14:30:22 UTC