IPTC Digest info

[ScannerBoy]

Now that the old IPTC data can/should be stored in the XMP data segment in image files, is there an equivalent digest of the data?
Or is there another way to check whether the metadata has been changed?

A related issue: if the IPTC data is changed by the user, how important is updating the old IPTC digest or any other XMP data field/tag?

[StarGeek]

Now that the old IPTC data can/should be stored in the XMP data segment in image files

Are you talking about something I might have missed? Because IPTC IIM data has (always?) had XMP equivalent tags.

is there an equivalent digest of the data?
Or is there another way to check whether the metadata has been changed?

The purpose of the IPTCDigest is to tell the program reading the data if it should ignore the XMP data. This will only happen if the IPTC data has been changed by a program that doesn't update the IPTCDigest.

It's important to note that the only comparison that a program might do is between the current MD5 hash of the IPTC data and the IPTCDigest. There is nothing that guarantees that the data is correctly in sync, as a program that edits only the XMP data and not the IPTC data will not change anything in regard to the IPTCDigest.

IMO, the IPTCDigest is an outdated tag that had use when XMP was new and IPTC IIM was the main standard, but most modern programs will use XMP, especially with RAW files, which very few programs will write to, favoring the XMP sidecar files instead.

A related issue: if the IPTC data is changed by the user, how important is updating the old IPTC digest or any other XMP data field/tag?

If the XMP data is important and in sync with the IPTC, then you would want to update it because otherwise the XMP data will be ignored if the program honors the IPTCDigest tag. Note that this is can be extremely important if the program follows the character limitations of the IPTC IIM data. An example would be Adobe Bridge, which obeys the character limitation (I do not know if this applies to other Adobe programs). If I set the "Sublocation" to Palais des Festivals et des Congrès, then Bridge will truncate the IPTC data. So it would be important to use the XMP data over the IPTC data.

Code Select Expand

C:\>exiftool -G1 -a -s -*location* y:\!temp\Test4.jpg
[XMP-iptcCore]  Location                        : Palais des Festivals et des Congrès
[IPTC]          Sub-location                    : Palais des Festivals et des Cong

[ScannerBoy]

I very much appreciate your extended answer, but for me, that is a lot to process and I am not sure how to proceed.
For now, I will stick with the issue that prompted this new question and was based on and a continuation of my previous post on the IPTC data only file aaa.jpg.

At the time, it was suggested that to fix the IPTC data being out of sequence, for instance assuming the character set spec not being first, where it can be used to decode the text according to the intended, albeit misplaced, character set specified.
Aside from the difficulty of determining the intended character encoding in the most general case - say a character set without any easily recognizable overlap with the ASCII alphabet, such a Ukrainian, Greek, Korean, Chinese... - the recommended action was to actually replace the poorly displayed string with some replacement that would 'fix' the bad decoding and display

My question really is would one also recalculate the IPTC hash/digest and write it to the image?
Would/should one also remove the Character Set spec?
Could one, instead, somehow force Exiftool(ET) force to 'move' the spec to the top of the list? Which would make all of the other changes unnecessary?

At the root of all my questions is the intention to understand what sort of issues to expect with existing metadata and how best to handle any new data without introducing more or worse issues.

As for the logic one ought to use to sort out which part of IPTC data to actually respect and use, which and how to update and record any changes as your answer tried to address, I'll start a new thread for that topic, probably as soon as tomorrow.