Hi,
I am trying to write a filename (including path) to one of the ITPC fields. If I write the data into an XMP file, read into Capture One and export the JPG, it works fine no problem, with no apparent limit on the text length. C1 and all the downstream software all respect the data regardless of being slightly over the official field length.
However I also need to be able to write the same data direct to an existing JPG file using Exiftool. If I try to do this, I get a warning "Warning: [Minor] IPTC:Source exceeds length limit (truncated)", and the data is truncated.
Is there any way to instruct Exiftool to ignore/override the official field length and write the whole string?
Thanks
Andrew
Last edit: Andrew Johnston 2026-08-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you check the IPTC tags page, the third paragralph says
This specification dictates a length for ASCII (string or digits) and binary (undef) values.
<snip>
When writing, ExifTool issues a minor warning and truncates the value if it is longer than allowed by the IPTC specification. Minor errors may be ignored with the IgnoreMinorErrors (-m) option, allowing longer values to be written, but beware that values like this may cause problems for some other IPTC readers.</snip>
Technically, according to the standard, there is a limit on how long the data can be in an IPTC block. But most modern readers/writers ignore that standard, so there isn't a problem with longer text. But exiftool will enforce the standard unless told not too.
My advice though, unless you have a specific need for IPTC metadata, it is best to simply drop it. XMP is a superior format and most decent programs that read/write metadata support it. I kept IPTC metadata for a long time and it was a pain to keep the data in sync. I personally don't think it's worth the trouble.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. I use XMP as well, although that has its own many complexities, such as namespaces which get changed randomly by other programs in the pipeline. Also I need something which is embedded in the output JPG. ITPC is perfect for this purpose, Hopefully - m will do the trick.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
although that has its own many complexities, such as namespaces which get changed randomly by other programs
That shouldn't happen with modern, standards-compliant software. Any program that follows the IPTC Photo Metadata Standard shouldn't be moving data to other namespaces. I'm curious about what programs might be doing that.
Also I need something which is embedded in the output JPG
XMP can be embedded in a JPEG. Most programs that I know of will usually do this by default. XMP sidecar are usually associated with RAW file types.
The the -m (-ignoreMinorErrors) option should work, though it will also ignore other minor errors. But those will almost always be ignored anyway by most programs. That's why they're minor errors.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
XMP can be embedded in a JPEG. Most programs that I know of will usually do this by default
Ok, I may be wrong about this. I just updated Darktable and going through the setup, it seemed to indicate that it will be using sidecars by default no matter the file type.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Capture One is a good example of a well-known program whichif you round-trip XMP data (i.e. sync from source XMP, make a metadata change and re-sync) changes both the namespace and whether data is presented as XMP attributes or elements! I've been battling with that for years...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Happy to oblige. The "before" XMP is generated by my own software, and includes geotags and "wildlife" tags as attributes which are readable by Capture One. The "After" version is after doing a "metadata sync" in C1, and has both changed attributes to elements, and in a couple of cases changed the namespace. The namespaces in my version have been carefully chosen so that the metadata is read by both C1 and ACR.
What is the source of XMP-photoshop:Caption? Because for exiftool, that is a non-standard tag. Checking the XMP tags page, there isn't any sign of it (though XMP-photoshop:CaptionWriter is). There isn't anything in my notes or my offline copy of the forums that mentions it. Google doesn't return any pages.
Is this actually something created by ACR or Capture One?
The standard place for a caption would be XMP-dc:Description as shown in the after file. If Capture One is reading it from XMP-photoshop:Caption, that would be impressive, as nearly always, unknown tags are ignored by programs in general.
An additional problem is that XMP-photoshop:Caption appears twice in the file. Once in the XMP Shorthand format, and then again in the older XMP format.
The XMP-photoshop:Urgency tag is incorrectly formatted, consisting of a line feed/carriage return followed by spaces when it should be an integer ranging from 0-9 (1-8 if you hold to the XMP standard).
Just my opinion, but XMP-photoshop:Caption is ending up in XMP-dc:Descriptionis the most future proof outcome, as the latter is covered by specs (such as the IPTC Photo Metadata Standard). And since the value of XMP-photoshop:Urgency is non-standard, I would think it would be a tossup between removing it and setting it to 5 (normal urgency).
Of course, what matters the most is the needs of your own workflow. If you need XMP-photoshop:Caption, then great. But if Capture One is reading it and saving it as XMP-dc:Description, then that would be the correct outcome by most standards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to Google, photoshop:Caption is an established synonym for dc:Description, and I've found it more reliable to write the wildlife information to there. Capture One reads it no problem, as does my DAM software XnView. It's not an issue for me that it gets copied into Description, but just a prime example of how Capture One re-organises incoming metadata, potentially so it then can't be read by the software which wrote it.
Last edit: Andrew Johnston 4 days ago
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I am trying to write a filename (including path) to one of the ITPC fields. If I write the data into an XMP file, read into Capture One and export the JPG, it works fine no problem, with no apparent limit on the text length. C1 and all the downstream software all respect the data regardless of being slightly over the official field length.
However I also need to be able to write the same data direct to an existing JPG file using Exiftool. If I try to do this, I get a warning "Warning: [Minor] IPTC:Source exceeds length limit (truncated)", and the data is truncated.
Is there any way to instruct Exiftool to ignore/override the official field length and write the whole string?
Thanks
Andrew
Last edit: Andrew Johnston 2026-08-27
tl;dr Add the
-m(-ignoreMinorErrors) optionIf you check the IPTC tags page, the third paragralph says
Technically, according to the standard, there is a limit on how long the data can be in an IPTC block. But most modern readers/writers ignore that standard, so there isn't a problem with longer text. But exiftool will enforce the standard unless told not too.
My advice though, unless you have a specific need for IPTC metadata, it is best to simply drop it. XMP is a superior format and most decent programs that read/write metadata support it. I kept IPTC metadata for a long time and it was a pain to keep the data in sync. I personally don't think it's worth the trouble.
Thanks. I use XMP as well, although that has its own many complexities, such as namespaces which get changed randomly by other programs in the pipeline. Also I need something which is embedded in the output JPG. ITPC is perfect for this purpose, Hopefully - m will do the trick.
... Apologies for the double reply. Interesting bug if you accidentally double-click "Post" 😂
Fixed
That shouldn't happen with modern, standards-compliant software. Any program that follows the IPTC Photo Metadata Standard shouldn't be moving data to other namespaces. I'm curious about what programs might be doing that.
XMP can be embedded in a JPEG. Most programs that I know of will usually do this by default. XMP sidecar are usually associated with RAW file types.
The the
-m(-ignoreMinorErrors) option should work, though it will also ignore other minor errors. But those will almost always be ignored anyway by most programs. That's why they're minor errors.Ok, I may be wrong about this. I just updated Darktable and going through the setup, it seemed to indicate that it will be using sidecars by default no matter the file type.
Capture One is a good example of a well-known program whichif you round-trip XMP data (i.e. sync from source XMP, make a metadata change and re-sync) changes both the namespace and whether data is presented as XMP attributes or elements! I've been battling with that for years...
Any chance you can give me a before and after xmp sidecar? Now I'm really curious.
Happy to oblige. The "before" XMP is generated by my own software, and includes geotags and "wildlife" tags as attributes which are readable by Capture One. The "After" version is after doing a "metadata sync" in C1, and has both changed attributes to elements, and in a couple of cases changed the namespace. The namespaces in my version have been carefully chosen so that the metadata is read by both C1 and ACR.
What is the source of
XMP-photoshop:Caption? Because for exiftool, that is a non-standard tag. Checking the XMP tags page, there isn't any sign of it (thoughXMP-photoshop:CaptionWriteris). There isn't anything in my notes or my offline copy of the forums that mentions it. Google doesn't return any pages.Is this actually something created by ACR or Capture One?
The standard place for a caption would be
XMP-dc:Descriptionas shown in the after file. If Capture One is reading it fromXMP-photoshop:Caption, that would be impressive, as nearly always, unknown tags are ignored by programs in general.An additional problem is that
XMP-photoshop:Captionappears twice in the file. Once in the XMP Shorthand format, and then again in the older XMP format.The
XMP-photoshop:Urgencytag is incorrectly formatted, consisting of a line feed/carriage return followed by spaces when it should be an integer ranging from 0-9 (1-8 if you hold to the XMP standard).Just my opinion, but
XMP-photoshop:Captionis ending up inXMP-dc:Descriptionis the most future proof outcome, as the latter is covered by specs (such as the IPTC Photo Metadata Standard). And since the value ofXMP-photoshop:Urgencyis non-standard, I would think it would be a tossup between removing it and setting it to 5 (normal urgency).Of course, what matters the most is the needs of your own workflow. If you need
XMP-photoshop:Caption, then great. But if Capture One is reading it and saving it asXMP-dc:Description, then that would be the correct outcome by most standards.According to Google, photoshop:Caption is an established synonym for dc:Description, and I've found it more reliable to write the wildlife information to there. Capture One reads it no problem, as does my DAM software XnView. It's not an issue for me that it gets copied into Description, but just a prime example of how Capture One re-organises incoming metadata, potentially so it then can't be read by the software which wrote it.
Last edit: Andrew Johnston 4 days ago