Re: XMP in PNG

If you want to read the core XMP spec w/o paying ISO, you can read the Adobe version at https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart1.pdf

The technical details of how to embed XMP in PNG come from the Adobe XMP specification, Part 3, section 1.1.5 - https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart3.pdf

And my intent was to basically copy/integrate the text that is present there into the PNG spec, most likely just adding to the iTXt section.

Leonard

From: Chris Blume (ProgramMax) <programmax@gmail.com>
Date: Tuesday, November 30, 2021 at 7:06 AM
To: public-png@w3.org <public-png@w3.org>
Subject: XMP in PNG
Solicited feedback:
Chris Seeger, are you allowed to tell us what extra metadata you foresee coming around the corner? It would help us plan.
Everyone, feel free to weigh in.


Thoughts:
In our last meeting, we discussed adding XMP to PNG.
In this email thread we can talk about how we would like to accomplish that.

The motivation is from Chris Seeger, who asked if extra metadata could be added to Exif. Apparently, Exif is rigid and will not allow extra metadata. Leonard Rosenthol proposed XMP as an extensible metadata solution.

Here is the latest Exif standard (translated to English): https://www.cipa.jp/std/documents/e/DC-X008-Translation-2019-E.pdf<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cipa.jp%2Fstd%2Fdocuments%2Fe%2FDC-X008-Translation-2019-E.pdf&data=04%7C01%7Clrosenth%40adobe.com%7Cbf629fc824834b1db96308d9b3f94b60%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637738708041881486%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=FA90m4GGqoS6Sfi5iQSqjCPDxBWjghusKg0y8RzTmY4%3D&reserved=0>
Here is a link to purchase ISO 16684-1, the XMP standard: https://www.iso.org/standard/75163.html<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iso.org%2Fstandard%2F75163.html&data=04%7C01%7Clrosenth%40adobe.com%7Cbf629fc824834b1db96308d9b3f94b60%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637738708041891443%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=cA1lujM0yllWrOuO5B7JhdxXiQyRY3fd3ZoO0Egnpx4%3D&reserved=0>



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%7Cbf629fc824834b1db96308d9b3f94b60%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637738708041891443%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g%2Bgf4xOnqWzbL7vUL124zaoa8fH%2F0MegHVhCDk3DAsY%3D&reserved=0> [1] with an unregistered keyword "XML:com.adobe.xmp". This makes sense to me. Other keywords represent other known metadata such as copyright, author, title, creation time...
Perhaps we could add an official keyword for XMP.

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%7Cbf629fc824834b1db96308d9b3f94b60%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637738708041901397%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2fmnT%2BRNZOCcrAGbc88pKDKGU56j8Qhfl7UzKm4eNw8%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.

If we need strict chunk ordering or different chunk properties, we might want XMP to appear in a new chunk.



I do not know enough about XMP or the future extra metadata that we might be adding. So I cannot make a judgement call about this. I'll spend some time reading about XMP.


Interestingly, PNG spec part 12.10, Text chunk processing<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2003%2FREC-PNG-20031110%2F%2312Text-chunk-processing&data=04%7C01%7Clrosenth%40adobe.com%7Cbf629fc824834b1db96308d9b3f94b60%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637738708041901397%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QHGML7WHKDYVl2xrFjWsogZ%2FNa2m7cDp8Y58qpmAJRk%3D&reserved=0> [3] suggests scenarios where text chunks might want to appear before or after the "IDAT" chunk.

[1] https://www.w3.org/TR/2003/REC-PNG-20031110/#11iTXt<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%7Cbf629fc824834b1db96308d9b3f94b60%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637738708041911359%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TGYm%2FZ3pI09QbT0hzDr3f%2FlHUcI1QvKnYWONNw59wck%3D&reserved=0>
[2] https://www.w3.org/TR/2003/REC-PNG-20031110/#5ChunkOrdering<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%7Cbf629fc824834b1db96308d9b3f94b60%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637738708041911359%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7Yw%2BXVKqelZL%2FQM071hyhD0%2Fuby4xnGgS2M4ZIFl6Mo%3D&reserved=0>
[3] https://www.w3.org/TR/2003/REC-PNG-20031110/#12Text-chunk-processing<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2003%2FREC-PNG-20031110%2F%2312Text-chunk-processing&data=04%7C01%7Clrosenth%40adobe.com%7Cbf629fc824834b1db96308d9b3f94b60%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637738708041911359%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4KqjLkvhVVubBrewv5Fh0GT3nsyPrg2KsPsFmVHxKCI%3D&reserved=0>

Received on Tuesday, 30 November 2021 12:56:42 UTC