Re: [PNG] Patch up for Chromium eXIf support

XMP can include colorspace info as well.  For example. It enables the full set of Exif tags including orientation & resolution (https://developer.adobe.com/xmp/docs/XMPNamespaces/exif/)/ & there are other potential cases for conflict between the two.

Check out the enclosed PNG, created (well, just transcoded and scaled) by Photoshop from an image that I took on my iPhone.  You can see in it (or in the enclosed screen shot) all sorts of values that potentially conflict with other PNG chunks including iCCP, sRGB, Exif, etc.

[A screenshot of a computer  Description automatically generated]

Leonard

From: John Bowler <john.cunningham.bowler@gmail.com>
Date: Wednesday, January 31, 2024 at 4:10 PM
To: public-png@w3.org <public-png@w3.org>
Subject: Re: [PNG] Patch up for Chromium eXIf support
EXTERNAL: Use caution when clicking on links or opening attachments.


On Wed, Jan 31, 2024 at 12:14 PM Leonard Rosenthol <lrosenth@adobe.com> wrote:
>
> Do we have an equivalent test for when the Exif data is present in the XMP in a PNG?   And if both are present, which wins (to John’s comment)?

IRC it was discussed before, possibly in the context of EXIF, on
png-mng-misc.  In reality, however, the behavior is implementation
defined.  It's the same as if the PNG has two gAMA chunks.  This
certainly should be documented clearly in the spec but I don't think
it is.  In the libpng implementation out-of-place or malformed chunks
are ignored (with a diagnostic) while valid but inconsistent
information (e.g. two significantly *different* gAMA values)
invalidates the whole colorspace (gAMA, cHRM, sRGB, iCCP and any new
chunks which define colorspace information).

This can be extended to duplicate EXIF data although so far as I can
see XMP is not being written to PNG, at least by PhotoShop when sRGB
is written (PhotoShop does not include any color space information in
that case.)

The downside is that this is quite a lot of code and, indeed, in
libpng I didn't manage to work out a way of validating iCCP against
cHRM or, for that matter, gAMA (I am NOT a colour scientist and
fitting an arbitrary lookup table to a gamma function is very
non-trivial.)  Comparing two blocks of EXIF data strikes me as
intractable.  Some basic information can be validated, maybe, but
other information may overlap in functionality yet not be the same;
EXIF "time" data is far more useful than the tIME chunk (which only
stores "last modification time").  If nothing else the EXIF time
information has relevance to law enforcement (people know to delete
the GPS info but not so much the time info!)

This is an issue but it wasn't my point; I'm concerned about the case
where the EXIF says something which is incompatible with PNG.  The
same thing can happen with iCCP and as a consequence libpng checks the
header as well as it can with my knowledge.  See the comments here:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpnggroup%2Flibpng%2Fblob%2Flibpng16%2Fpng.c%23L2063C1-L2082C7&data=05%7C02%7Clrosenth%40adobe.com%7C7c1a678a405e40a4d84a08dc22a0fe17%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638423322058932627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=xmhqMYT6d7C6jH4kF4mtG6aof4RbBN%2BOnT8%2BEa%2BTtO0%3D&reserved=0<https://github.com/pnggroup/libpng/blob/libpng16/png.c#L2063C1-L2082C7>

The function following the one with that comment also shows how libpng
checks the raw format of an ICC profile.  It is to be noted that
libpng does not do the same for EXIF data; it just stores it without
parsing it.  This gives rise to potential crashes within apps and
libraries.  The same thing happened with malformed colorspace data,
leading to the very extensive checking of, for example, the cHRM
chunk.

John Bowler