Embedding IPTC to RAW files is bad practice?

[JobWellDone]

I have seen some options around the internet that embedding IPTC tags to RAW files can get them corrupted and not able to open in some applications is this true cause for concern?

Also that IPTC are not supported in some RAW files, does ExifTool check weather particular RAW file format can handle IPTC tags before writing them?

[StarGeek]

First, you need to differentiate between IPTC IIM, which is the older legacy standard, and ITPC Core/Ext/IPTC Photo Metadata Standard, which are XMP.

Some of the more recent file type, such as CR3 and HEIC do not support the IPTC IIM tags and exiftool will never attempt to write IPTC IIM tags to a file type that doesn't support it.  See the Supported File Types table for which file types support IPTC, EXIF, and XMP.

I have seen some options around the internet that embedding IPTC tags to RAW files can get them corrupted and not able to open in some applications is this true cause for concern?

It really depends upon the program.  For example, you pretty much should never use the software that Nikon ships with their cameras.  They have messed up so many times that Phil had to make a script to correct the problems.

But a lot of people heard that you should never change your RAW files in any way and took that as scripture. They just repeat it without ever having tested it and will argue about it and be absolutely immovable in their opinion.

Exiftool rarely has a bug so serious that it can't be recovered from. The usual problem is user error, such as completely removing the EXIF block from a RAW file, which you should never do, as  there are tags in the EXIF and MakerNotes that are required in order to properly display the image.

When it comes down to it, you have to decide for yourself.  But on my end, I've run exiftool over literally millions of files of various types over the (*checks profile*) past 12 years and never damaged a file so that it was unviewable.

[obetz]

Backup (and synchronization) efficiency is another argument to use sidecars. Storing or modifying metadata in (large) raw files results in large backups (unless your backup software uses block based deduplication) each time you change metadata.

Regarding corruption: Even if ExifTool embeds metadata correctly, there are broken tools not dealing correctly with such changes. IIRC, Sony and Nikon had problems in the past.

Therefore I prefer sidecars now, but I have also a lot of raw files with embedded metadata.

[JobWellDone]

Backup (and synchronization) efficiency is another argument to use sidecars. Storing or modifying metadata in (large) raw files results in large backups (unless your backup software uses block based deduplication) each time you change metadata.

Perhaps that's a concern if metadata constantly change, i want to write the location and other description that will stay permanently inside file and help me filter trough lots of files, so nothing will change after backup.

At present i don't use Rating, Color labels and Tagging, however if i will i also want that stored in RAW file itself because .xmp files are easy to loose and they clutter the filesystem too much in my opinion and are recipie for disaster, i don't want to find myself in situation where i forget about .xmp files and use tool like PhotoMove v2.5 or else and then lose all my file settings.

[StarGeek]

i also want that stored in RAW file itself because .xmp files are easy to loose and they clutter the filesystem too much in my opinion and are recipie for disaster, i don't want to find myself in situation where i forget about .xmp files and use tool like PhotoMove v2.5 or else and then lose all my file settings.

@obetz point is very valid, but in my case, I do the same as you.  For backup, I use Duplicati locally, and Backblaze for offsite.  Both do deduplication and versioning.  I currently 2.65 TB of pictures taken by me and some people I knew.  There is 215 versions dating back a couple of years that total 3.17 TB. (edit: Dates back to May 4, 2021)


On Backblaze, I have 3.31 TB, with one year of versioning.