- From: John Bowler <john.cunningham.bowler@gmail.com>
- Date: Mon, 15 Apr 2024 14:34:19 -0700
- To: "Chris Blume (ProgramMax)" <programmax@gmail.com>
- Cc: "Portable Network Graphics (PNG) Working Group" <public-png@w3.org>
- Message-ID: <CAP7U39-DgYsDJsjMMahCi4j+qjrSFZQmTV1q6XK_WPQE9R56HA@mail.gmail.com>
> > libpng handles both reading and writing. I’m hoping to land the reading > patch first. > Writing feels trickier because of policy. I think it shouldn’t be written > by default > until enough decoders support it. This is why the methodology is to implement the proposal as a private chunk (or, in this case, three private chunks). The first thing to write is the *writing *side because that's easy to match to the specification and it allows the generation of test files. Without the test files the read side is just a bunch of untestable and untested code. Since the chunks are optional libpng is, in fact, completely conformant if it only has a *writing *side; libpng will automatically read them without complaint and will make them available to applications which look for them; this is how APNG is implemented at present in Chromium and WebKit, but youall don't want them to do that because that creates the apNG mess; using a private chunk properly avoids that problem. Once the whole shebang has been tested and everyone who cares to test it (frequently no one) is sure it's fine then it's a one character switch (1 bit in one character) in two places to turn it "on". When that happens any test images in the wild, possibly with broken or old chunk values, simply get ignored. This is good; test images are no more likely to be correct than new code. pngvalid is relevant to this because it generates test files internally so it requires a 'write' side. I'm not sure pngvalid should be modified for unit tests in this case but a similar approach can be used mapping current images encoded in PNG, including "HDR", to the new data encodings; a write side is still required. Some discussion is required here because the current gamma handling will completely destroy the data in the case of narrow range images. So will the 16<->8 bit transforms, so will alpha composition. So far as I can see everything else doesn't matter much; everything else is no worse than iCCP. For narrow range images the presence of signaling values the very clear spec requirement to handle them specially is a big deal. John Bowler
Received on Monday, 15 April 2024 21:34:34 UTC