Magick.NET PNG - Warning: [minor] Empty XMP

[hawkeye77]

I'm relatively new to exiftool and Magick.NET - I know, bad combination... 

I posted on the Magick.NET GitHub discussions in case they can help from their end, since it seems it's a problem with how I'm using that library.  But since it's exiftool that is reporting the problem even though other tools are able to interpret it, I felt it best to get your thoughts.  I attached a ZIP file to the GitHub discussion.

https://github.com/dlemstra/Magick.NET/discussions/1603

Basically, Directory Opus supports star Rating for PNG files (Windows 11 and File Explorer do not - yet).  I reverse engineered how they are doing it and replicated it with exiftool and with Magick.NET.  Directory Opus recognizes the star Rating even with Magick.NET output file.  But exiftool doesn't.  It gives the warning about the Empty XMP and does not extract the Rating value.  Even if I use Magick.NET to embed metadata into files, I still want to be able to use exiftool from the command line to inspect and troubleshoot.

[StarGeek]

Direct link to files

Looking at your PNG with the -v3 (-verbose3) option, I can see that there is a Byte Order Mark (BOM) (ef bb bf) at the very beginning of the decoded XMP (which was saved as a zipped block).

Code Select Expand

+ [Decoded XMP_Profile directory, 537 bytes]
  |     0000: ef bb bf 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e [...<?xml version]
  |     0010: 3d 22 31 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d [="1.0" encoding=]
  |     0020: 22 75 74 66 2d 38 22 3f 3e 3c 3f 78 70 61 63 6b ["utf-8"?><?xpack]
  |     0030: 65 74 20 62 65 67 69 6e 3d 27 ef bb bf 27 20 69 [et begin='...' i]
  |     0040: 64 3d 27 57 35 4d 30 4d 70 43 65 68 69 48 7a 72 [d='W5M0MpCehiHzr]
  |     [snip 457 bytes]
Phil would have to verify, but I don't think that is supposed to be there.

It's a problem that has shown up here before with Directory Opus.  If you search the forums for "BOM Directory OPUS" and look for threads by user mazeckenrode, you'll find a series of posts going through this.

[Phil Harvey]

There is a leading BOM and a "<?xml" header that shouldn't exist for well-formed XMP.

ExifTool will tolerate this in a stand-alone file, but not in an embedded XMP packet.

- Phil

[hawkeye77]

Thanks to both of you for pointing me in the right direction!  I replied to the GitHub discussion with the solution that fixed the problem.  There is one more minor issue that I'm hoping you can help me figure out.  I described that in the GitHub discussion as well.  TL;DR - Magick.NET adds extra chunks to the PNG, and some of them `tEXt` appear after the last IDAT chunk and before the IEND chunk.

```
  chunk tEXt at offset 0xf33d5, length 37, keyword: date: create
  chunk tEXt at offset 0xf3406, length 37, keyword: date: modify
  chunk tEXt at offset 0xf3437, length 40, keyword: date: timestamp
```

[StarGeek]

From what I recall, this is allowed by the spec but as the message says, some programs would not read it in that position.  It became enough of a problem that Phil add the patch to take care of this.

I think this is the thread.

[hawkeye77]

The author of Magick.NET replied stating: "Writing the text chunks after the IDAT is something ImageMagick has done for many years. Moving it before the IDAT is probably not something that we will be going to change."

What are your thoughts on that Phil?  My concern with the warning is that I could suppress it, but then I might miss other legitimate warnings like the one that started this thread.  If I understand correctly, it's sort of an all or nothing approach to suppressing exiftool warnings, right?  Any chance you'd want to relax this specific one?  What do you suggest?

[Phil Harvey]

My thought is that the ImageMagick programmers are lazy.

But you can suppress individual warnings with the API NoWarning option.

- Phil

[hawkeye77]

You made me laugh.   

Thanks for the tip on the regular expression warning suppression.