1
\$\begingroup\$

I'm working on a script that will keep metadata in derivative files in sync with the master file or it's sidecars.

One of the mechanisms for this is to give a unique ID to the master file, either as an EXIF field or an IPTC field. I'm trying to avoid using the keyword field for this as in a million picture archive it would add a million keywords.

The obvious unique one is to join camara model-serial-shuttercount, but this is NOT generally preserved by a lot of programs, and not all cameras support this.

So I'm looking for a reference for what metadata is/is not preserved by major players in the image editing/image management arena. I'm hoping that someone has already consolidated this.

ImageMagick and exiftool seem to be able to pull whatever metadata exists from almost every image format out there.

Improve this question
\$\endgroup\$
6
  • \$\begingroup\$ Do you have control over the initial naming convention of the actual filenames? \$\endgroup\$
    – Michael C
    Commented Dec 24, 2017 at 19:26
  • \$\begingroup\$ I'm not sure this is an answer, but it is applicable: The basic problem with using fields such as serial number or shutter count is that they are not "standardized" fields within the EXIF spec and are included in what is known as the 'maker note' section of the EXIF info. Each camera maker is free to include (or not include) any info they desire, in whatever form they desire, in the maker note section. The problem with using only standardized fields is that it's theoretically possible for two different examples of the same camera model to take a photo with identical standardized EXIF info. \$\endgroup\$
    – Michael C
    Commented Dec 24, 2017 at 19:30
  • \$\begingroup\$ That is, the same: camera model, lens, Tv, Av, ISO, date/time taken, etc. \$\endgroup\$
    – Michael C
    Commented Dec 24, 2017 at 19:31
  • \$\begingroup\$ Naming. I can rename on import. \$\endgroup\$
    – Sherwood Botsford
    Commented Dec 25, 2017 at 17:36
  • \$\begingroup\$ I’m aware of the maker note issue with shutter count. Most cameras are sufficiently decoded that this is recoverable with exiftool. The hope is to write a script that uses various tools to construct a unique id then store that Id in a field that is mung proof. My current quest is for the choice of fields that between them are proof against most editors. \$\endgroup\$
    – Sherwood Botsford
    Commented Dec 25, 2017 at 17:49

2 Answers 2

Reset to default
1
\$\begingroup\$

About the unique image ID thing: One solution that could work would be to use a unique number and write it in all files - and perhaps add a f0f0f0 (or something like that) to the original file:

  • 01234567890123456789f0f0f0: the original file
  • 01234567890123456789: any of the derivative files

For the unique number, you would either need some kind of database - or any other way to provide unique/consecutive numbers. You could, for example, calculate the hash of the original file - be it SHA1, SHA-256 or even MD5 - and then write that hash into whatever EXIF-/IPTC-/XMP-field you like.

Note that if you change some none-sidecar data (EXIF, IPTC) later on, the hash will change, too - so therefore, it would be best too calculate it as soon as possible, or at least it requires you to know that re-calculating the unique field later on (e.g. because you accidentally deleted it) will lead to a new hash.

As to what field would be best: I do not think there is a definitive answer. Write it to any of the fields that is prominent in all the programs you use at the moment - and perhaps in some of the not-so prominent ones, too. That way, you can always copy it to some other fields later on if needed, and also, you have a backup of the actual data if something bad happens to one field.

I would take one string-able field of each supplied metadata-standard - so one for EXIF, one for IPTC and optionally, one for XMP.

Improve this answer
\$\endgroup\$
5
  • \$\begingroup\$ For the sake of portability and robustness I'd like the string to be identical on all hosts. e.g. if you have multiple people using multiple computers to write to a NAS, the ID should be unique for all files, and identical on all computers. A hash of the preview image is another possibility. \$\endgroup\$
    – Sherwood Botsford
    Commented Jan 28, 2018 at 16:12
  • \$\begingroup\$ Care has to be taken in choosing fields: They have to be ones that are normally not used, but that editing programs don't discard. It can be a string within another field, with the rest of the field ignored. e.g. Copyright blah blah blah -- ID:stringID I want to avoid using as a keyword so that keyword indexing doesn't get filled with strings of random stuff. \$\endgroup\$
    – Sherwood Botsford
    Commented Jan 28, 2018 at 16:16
  • \$\begingroup\$ @SherwoodBotsford No - you just calculate the hash of the original file and write that to all derivatives. the hashis just used as a source for a unique string - it is completely unrelated fo anything else. you could just as well use timestamps or literally anything else that willnot lead to duplicated strings in the near future. theoretically, you can even change the string-source in between - as long as your old SHA-256 hashes don't collide with your new source, for example. \$\endgroup\$
    – flolilo
    Commented Jan 28, 2018 at 16:17
  • \$\begingroup\$ @SherwoodBotsford well - if your program deletes metadata that it cannot see, then your program basically sucks ;-) really, if that is one of your design goals, you have to hope that all programs from the ones you use now to those you use in 20 years take the same fields into account. I wouldn't bet a penny on still having JPEGs in 20 years time, so basically, you will have to make sacrifices. \$\endgroup\$
    – flolilo
    Commented Jan 28, 2018 at 16:21
  • \$\begingroup\$ The ID string is irrelevant. The issue is to find a subset of exif and IPTC fields such that at least one is left intact by the top N most used photo editors. \$\endgroup\$
    – Sherwood Botsford
    Commented Jan 29, 2018 at 18:28
0
\$\begingroup\$

This is NOT an answer to my question, but it may save someone some grief.

This is a dated report comparing features of photo cataloging programs.

This gives a partial list, and only covers IPTC fields. It does not list the individual fields covered or not covered.

Fairly large list, but does not cover software that edits images.

Gives an illustration of the problems that can arise, in this case interaction between Photo Supreme and Windows Photo Gallery.

Improve this answer
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.