Re: [EXTERNAL] Re: [PNG] Meeting discussion topics

Ah, you're right. I misunderstood that.
14.2 <https://www.w3.org/TR/png-3/#14Ordering> says "Ordinary image editors
are not PNG editors because they usually discard all unrecognized
information while reading in an image."
Thank you.

And now I see what you're saying about the ordering restriction, too.

I'll need to think about this a bit more. But thank you for helping me
understand.

On Sun, Sep 29, 2024 at 11:02 PM John Bowler <
john.cunningham.bowler@gmail.com> wrote:

> On Sun, Sep 29, 2024 at 6:54 PM Chris Blume (ProgramMax) <
> programmax@gmail.com> wrote:
>
>> I do agree there is a spec issue.
>> mDCv is currently safe-to-copy but I'm pretty sure it shouldn't be.
>> The safe-to-copy bit is used when someone opens the image in an unaware
>> editor and modifies it.
>>
>
> This is hard to explain.  I've had difficulty understanding it myself over
> the 25+ years the spec has existed.  The rules (section 14, originally
> section 10) are for the mysterious "PNG Editor".  A "PNG editor" is not
> something that can change the image in any material way, rather it is
> something that changes the format of the stream without changing the
> content in a meaningful way.  For example the PNG optimizers are "PNG
> editors" in that they may completely modify how the image data is
> *encoded* thus requiring handling or disposal of the "unsafe-to-copy"
> chunks without actually changing the image itself in a way that would
> create a new work.
>
> On the other hand something that loads a PNG image and modifies it is just
> something that loads an image in some arbitrary format (PNG in this case),
> handles all the information it can (safe or unsafe to copy, but I hope the
> copyright) then, perhaps, writes out a new image in a completely arbitrary
> format; maybe PNG, maybe not.
>
> All bets are off when a PNG is loaded into the GIMP or, for that matter,
> PhotoShop.  Check it out yourself; load a PNG with some ancillary chunks
> and see how many your favourite (or least favourite, but start with the
> favourite) image editor handles then see how many it saves when you save it
> as PNG.
>
> This is something that was not clear in the original spec and still isn't
> clear today.  Image editors are expected to handle all the ancillary chunks
> they can handle (which, bottom line, means none of them) and then, when
> writing a PNG, write the appropriate ancillary chunks.  "PNG Editors" are
> expected, required, to obey the rules in the spec for "PNG Editors".  Image
> editors are covered by the "Decoders" section; confusing!
>
>
>> If the editor is unaware of mDCv, *their* display effectively becomes the
>> new mastering display. The previous display's gamut was entirely ignored.
>> So it shouldn't be copied as if it was used.
>>
>
> Yes.
>
> ... so I wasn't talking about an image editor that makes changes to the
> image itself.  I was talking about that mysterious "PNG editor" that makes
> changes to the stream.  Such an editor by definition cannot change the CIE
> tristimulus data other than perhaps, and arguably, by clipping them.  By
> that I mean reducing the colour volume without changing (substantially) the
> values that remain in the reduced volume.  An example is taking a 16-bit
> RGB PNG and scaling it to 8-bit RGB; this massively reduces the colour
> volume possibly to the point of destruction of the image. However whatever
> remains is still the same image, the same author, the same copyright, the
> same mDCv (even though not much of it might be left!)
>
> In that case, the case of a "PNG editor", the mDCv is safe-to-copy.  To
> put it simply: Nothing a "PNG editor" can do can change the mastering
> environment because a "PNG editor" cannot, by definition, even remaster.
>
>
>> Alternatively, if the editor is aware of the mDCv chunk it could be
>> mindful during modification, using colors that match the original mastering
>> display. But if the editor is aware, it doesn't care about the safe-to-copy
>> bit anyway.
>>
>
> Exactly.  An image editor either uses it and chucks it or ignores it.
>
> (Although that said, I don't know any editors that follow the safe-to-copy
>> guidelines. That's a whole other topic, though.)
>>
>
> Maybe.  Those are the editors the spec refers to, "PNG Editors".  Examples
> are pngcrush, optipng, oxipng PNG editors I have written like pngcp, pngfix
> - often the handling can be controlled by the user but none of these
> programs modify the image data in a way that might even vaguely invalidate
> or, indeed, require mDCv.  netpbm might do in certain very limited
> transformations but even that is arguable.
>
> *magick (imagemagick and graphicsmacgick) might exist at the borderline.
> I don't know if Bob Friesenhahn is privy to this list so I bcc'ed him; he
> knows at least as much about the history of how PNG got this way as I do.
> My impression is that "convert" might be the most widely used true "PNG
> editor" in existence and it is certainly widely used.  I don't know to what
> extent it preserves ancillary chunks rather than interprets them - it does
> convert between PNG and other formats.
>
> This also addresses the relative-to-PLTE requirement. If it is marked
>> unsafe-to-copy it can be relative to PLTE.
>>
>
> Yes.  However the more I understand about mDCv and cLLi the more I think
> they really are both metadata.  With regard to the PLTE placement the
> arguments and problems get an order of magnitude more complex.  If a
> workflow really needs to apply the mastering transformations when it first
> hits the PLTE rather than delaying this stuff until the first IDAT then
> there is an argument for mDCv being dMDV but the cost of that is that image
> optimizers will have to discard it if they don't understand it even though,
> if they did understand it, they would know that it is irrelevant to
> optimisation.
>
> John Bowler <jbowler @ acm.org>
>