Re: XMP in PNG

If XMP itself is supposed to be unrelated to image decoding, it makes sense
to me that we register the existing keyword.

However, for the purpose of (dynamic) metadata including tone mapping, that
could affect the decoding process. This might be fine since it sounds like
this tone mapping metadata perhaps shouldn't be in XMP anyway. I think we
might want to create a new chunk for it so we can place datastream position
requirements on the chunk. It should go before the frame it affects.


That said, do we still feel like there is a need for XMP in PNG?
(I'm not doubting it. I just want to make sure we check ourselves here.)

Exif has plenty of existing users and is a noticeable gap in PNG compared
to other image formats. It would be easy to justify why we feel it should
be included.
Does XMP cross the threshold of enough demand & users & clearly should be
part of the standard?

On Tue, Nov 30, 2021 at 2:09 PM Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> There is nothing in the XMP that is supposed to influence rendering of the
> image. However, there is information there that may well be duplicative of
> information present elsewhere in the image file format – e.g., height,
> width, resolution.
>
>
>
> With the recent HTMLWG work to expose IPTC/XMP information into the UA
> does make that a bit fuzzier since a UA can now use specific parts of the
> metadata to influence the rendering by overriding other specified values
> for height/width/resolution.
>
>
>
> Leonard
>
>
>
> *From: *Chris Lilley <chris@w3.org>
> *Date: *Tuesday, November 30, 2021 at 2:04 PM
> *To: *public-png@w3.org <public-png@w3.org>
> *Subject: *Re: XMP in PNG
>
>
>
> On 2021-11-30 14:02, Chris Blume (ProgramMax) wrote:
>
> During the meeting, Chris Lilley mentioned that XMP in PNG could go inside
> the "iTXt" chunk
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2003%2FREC-PNG-20031110%2F%2311iTXt&data=04%7C01%7Clrosenth%40adobe.com%7C4d592d5168b14289092708d9b434398a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637738958660843223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rilgO4Um8Ja7wf8ah57VDvPt%2BoUxvv%2Bc6s9tctA3p4M%3D&reserved=0> [1]
> with an unregistered keyword "XML:com.adobe.xmp". This makes sense to me.
>
> To be clear - this was not a proposal from me, but a report on how it is
> currently done, for example in Adobe Photoshop, when you save as PNG
> (export as PNG strips all non-essential information).
>
> Other keywords represent other known metadata such as copyright, author,
> title, creation time...
>
> Perhaps we could add an official keyword for XMP.
>
> We could - or we could register the one already in use, which is a path of
> least resistance.
>
>
> However, the datastream placement of "iTXt" and similar chunks has no
> restriction, according to PNG spec part 5.6, Chunk ordering
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2003%2FREC-PNG-20031110%2F%235ChunkOrdering&data=04%7C01%7Clrosenth%40adobe.com%7C4d592d5168b14289092708d9b434398a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637738958660853174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AEvLGNGjnmLarDoCzNpeBmZL9dtoBkF6puhzQBv5Bco%3D&reserved=0>
> [2]. If the XMP data itself could affect how the image is decoded, we would
> want to enforce that it appears before the "IDAT" chunk in the datastream.
> Similarly, perhaps XMP would require a different (un)safe-to-copy property.
>
> Good point. Does it?
>
> --
>
> Chris Lilley
>
> @svgeesus
>
> Technical Director @ W3C
>
> W3C Strategy Team, Core Web Design
>
> W3C Architecture & Technology Team, Core Web & Media
>
>