Re: XMP in PNG

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