Re: [PNG] Meeting minutes - Apr 15th, 2024

I don't follow what you're saying about the writing side is needed first
to test. Would you mind helping me align with your thoughts?
We could have writing code and manually confirm the data looks correct.
We can also have reading code and manually write the chunk.
Or we could do both and have automated tests.

If I assume I'll make mistakes, I would rather the reader be there to catch
my mistake. If the writer has a bug but I make a mistake while reviewing
it, my mistake is less likely to be caught.
(I realize it is possible to make both code and manual mistakes in both
cases. I feel like it is easier to make a mistake in the manual portion.
That is why I want the code portion to be in a catching position.)

Also, I'm not strongly opposed to starting with the lowercase bit for
testing. But I think that solves a problem for a different stage of
development.
That lowercase bit can be a placeholder while the chunk itself is being
reviewed for adoption into the standard.
But once it is reviewed and adopted, the lowercase bit is no longer useful.
We've already reviewed and generated test files outside of libpng. The
testing is done. At this point, there is no need for test files to confirm
the theory or implementation.
So it would provide no real value, right? It would just be performative
caution to ease libpng into what has already been implemented elsewhere and
already approved. And the cost of this performative caution is generating
invalid files that are later problematic.
I'm not too worried about the invalid files. Nor the simple bit flip later.
So I'm willing to do it. I just don't think it helps.

This also loops back to the reading/writing side first. Since we already
have test PNG files, implementing the reader first means we can quickly
test & confirm that implementation. Then the writer portion can be tested
against the reader portion to confirm.

On Mon, Apr 15, 2024 at 5:34 PM John Bowler <
john.cunningham.bowler@gmail.com> wrote:

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