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

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>