Can't write fully qualified tag

[Hayo Baan]

When I retrieve the list of tags for e.g. TimeCreated with GetInfo, I correctly get its value. However, when I try to write to it using its fully qualified name (gotten by prefixing the tag name with GetGroup($tag, "0:1")), ExifTool warns me that the tag does not exist...

It must be noted that this file does contain an error in its metadata: Bad IPTC data tag (marker 0x5)

From the original file (name within brackets is the fully qualified name)

Code Select Expand

Found TimeCreated(IPTC:IPTC2:TimeCreated)=17:40:58+01:00

Output of running exiftool -'TimeCreated=17:40:58+02:00' on the file

Code Select Expand

Warning: [minor] Entries in IFD0 were out of sequence. Fixed. - TimeCreated.nef
    1 image files updated

Now GetInfo finds two versions of the tag:

Code Select Expand

Found TimeCreated (1)(IPTC:TimeCreated)=17:40:58+02:00
Found TimeCreated(IPTC:IPTC2:TimeCreated)=17:40:58+02:00

(Running exiftool with the -wm w flag prevented the creation of this extra tag)

The fact that the file contained an error in the IPTC metadata likely is the reason for the error. It is strange, however that you can update the tag via its non-qualified name, but not via the full name ExifTool reports for it...

Also, if you let exiftool create new tags (as in above test), ExifTool states it fixed the problem in the file, but you still can't access the reported IPTC:IPTC2:TimeCreated tag. (if you don't let it create new tags, the tag becomes IPTC:TimeCreated which you can then access just fine...).

Note: in my program I need to be able to update the exact versions of the different tags, hence my use of the fully qualified name of the tags (which works great otherwise).

[Phil Harvey]

Hi Hayo,

Yes.  This is one exception when a family 1 group tag may not be specified when writing.

The problem is that you have a file with IPTC in a non-standard location, and you can not tell ExifTool to only write to the non-standard location because it will insist on putting the IPTC in its proper place (which results in duplicate IPTC, but then at least other applications will be able to read it).

In case it is useful to you, if you "use Image::ExifTool::MWG;" the non-standard IPTC will be ignored (and generate a warning) when reading.

- Phil

[Hayo Baan]

Hi Phil,

Ah, I understand. So I guess I could, in case of IPTC:IPTC2 as groupname, simply use IPTC as groupname instead.

I just tried this in my code and it seems to work well; it updated only one IPTC entry (I do have EditOnly => 1 enabled too, though I don't think that mattered in this case) and it fixed the metadata error as well.

So now I just need to be absolutely certain that there could never ever be an IPTC:IPTC2 group for real so I can change my code to use IPTC in case there is an IPTC:IPTC2 as group.

Thanks,
Hayo

[Phil Harvey]

Hi Hayo,

Ah, right.  If you use EditOnly you will prevent ExifTool from creating the IPTC in the standard location, but I wouldn't suggest this because many utilities won't read IPTC from other locations.

If there are more non-standard IPTC records, there may be IPTC3, IPTC4, etc, but you should always specify only IPTC when writing.  ExifTool will write all of them to keep them consistent.

- Phil

[Hayo Baan]

Ok, so as consistency is my goal here anyway, I can safely change any IPTC:IPTCx group to IPTC in my code.
I know I can't do that for other groups as there may be multiple versions of a tag that should not be the same (ImageWidth and ImageHeight for example, but those are in EXIF)

Thanks for clarifying
Hayo

[Phil Harvey]

Hi Hayo,

I have added this to the IPTC Tags documentation to help document this quirk:

        Note that it is not uncommon for IPTC to be found in non-standard locations
        in JPEG and TIFF-based images.  When reading, the family 1 group name
        differentiates IPTC from various locations (IPTC, IPTC2, IPTC3, etc), but
        when writing only "IPTC" may be specified as the group.  To keep the IPTC
        consistent, ExifTool updates tags in all existing IPTC locations, but will
        create a new IPTC group only in the standard location.

- Phil

[Hayo Baan]

Hi Phil,

Great, then at least more people can benefit from this whole exercise

Many thanks for your conciseness!
Hayo

[Phil Harvey]

This got me thinking that currently it is difficult for the user to identify non-standard IPTC since the family 1 group names are based only on the order of the encountered IPTC ("IPTC" first, then "IPTC2", "IPTC3", etc).  It makes sense to change this so standard IPTC always has a family 1 group name of "IPTC", and non-standard IPTC always has a number added.  Also, standard IPTC should take priority in the case where duplicate tags exist.

I will make these changes in ExifTool 9.66.

- Phil

[Hayo Baan]

Hi Phil,

This got me thinking that currently it is difficult for the user to identify non-standard IPTC since the family 1 group names are based only on the order of the encountered IPTC ("IPTC" first, then "IPTC2", "IPTC3", etc).  It makes sense to change this so standard IPTC always has a family 1 group name of "IPTC", and non-standard IPTC always has a number added.  Also, standard IPTC should take priority in the case where duplicate tags exist.

I will make these changes in ExifTool 9.66.

That really is awesome!

I think I just ran into the ordering problem myself with some of my "bad" files, by the way. In my case, the copyright field used was read from the faulty record (at least I think it was the faulty record; PhotoMechanic showed the value I expected, and I think they ignore the faulty records altogether).