Job Identifier tag in the Metadata panel

[cos49]

Lightroom 10.1

Can anyone comfirm that Lr doesn't use the XMP tag IPTC:JobId for the value in the Metadata panel.

I've used exiftool to write some values to that tag and then did Metadata->Read metadata from file and the value is not updated.  I've also done Metadata->Save metadata to file thinking it would write the current value to XMP data.  It doesn't.  It still has the value I wrote with exiftool.

This process works for writing Caption data to the XMP Description tag, but doesn't seem to work for Job Identifier. From the IPTC.org web site this tag is part of the IPTC Core so I'm somewhat surprised Lr doesn't use it.

[cos49]

I found the tag it is using - TransmissionReference

[cos49]

This only seems to work for raw files.  It is written to .psd, .tif, jpg under the photoshop namespace, but is not seen by Lr for those file types.

[johnrellis]

Short answer: LR does indeed read its Metadata > IPTC > Job Identifier from either the IPTC:OriginalTransmissionReference or XMP:TransmissionReference of non-raws (e.g. JPEGs). But if you use Exiftool to test this, you have to be very careful to delete all XMP metadata from the non-raw after setting IPTC:OriginalTransmissionReference or to delete IPTCDigest.

Long answer: You're in the depths of legacy metadata madness.  I spent 45 minutes disentangling it all.

While Exiftool supports a tag IPTC:JobId (tag ID 184), I can't find any reference to that in the current IPTC documentation, which says that the field "Job Id" can be stored in IPTC-IIM field OriginalTransmissionReference (tag ID 103) or in XMP photoshop:TransmissionReference:

You can access these via Exiftool using IPTC:OriginalTransmissionReference or XMP:TransmissionReference.  I don't know where Exiftool got IPTC:JobId (tag ID 184).

LR follows the Metadata Working Group's Guidelines for Handling Image Metadata (which despite the name "Guidelines" is in fact a specification).  The spec defines a method that allows apps to keep the IPTC-IIM versions of fields (e.g. IPTC:OriginalTransmissionReference) in sync with the XMP versions (e.g. XMP:TransmissionReference) when non-conforming apps (e.g. Exiftool) modify one or the other.  

I did the following steps:

1. In LR, set Job Identifier to "xyz" for a JPEG.

2. In LR, do Metadata > Save Metadata To File.

3. Do "exiftool -a -G test.jpg | grep xyz" to confirm that LR has written both fields with "xyz".

4. Do "exiftool -xmp:transmissionreference= test.jpg" to delete the XMP version of the field.

5. In LR, do Metadata > Read Metadata From File.

My reading of the spec is that the IPTCDigest hasn't changed after step 4, so LR should read IPTC:OriginalTransmissionReference and display "xyz".  But in fact LR displays blank. I think this is a bug.

However, if after step 4 you do "exiftool -iptcdigest=- test.jpg", or in step 4 you do "exiftool -xmp= a.jpg" (deleting all XMP metadata), then in step 5, LR will read IPTC:OriginalTransmissionReference into Metadata > IPTC > Job Identifier.

[Use the blue reply button under the first post to ensure replies sort properly.]

[cos49]

What I had written into a .jpg file was TransmissionReference, but Lr would not read that when doing Metadata->Read Metadata from File.  If I write that into OriginalTransmissionReference and then do the Read Metadata from File it is read.

So, it seems for non-raw files Lr is ignoring TransmissionReference even if there is no OriginalTransmissionReference.  Is the take-away to just write it to OriginalTransmissionReference?

What triggered this whole descending into the depths of legacy metadata madness was importing metadata with Lr/Transporter and using filename as the matching field.  This was older data and more than one file could have a filename of _DSCXXX_<sequence> which would import the same data into more than one file.  So, using File::Find, Data::UUID and Image::ExifTool I could generate a value to put in Job Identifier that Lr/Transporter could match on.

In hindsight the better workflow would have been to use the Search+Replace plugin to copy the Lr image UUID to Job Identifier, then use the ListView plugin to generate an Excel file, and use that to attach additional data to import and Lr/Transporter would have a unique value to match on.

[johnrellis]

"What I had written into a .jpg file was TransmissionReference, but Lr would not read that when doing Metadata->Read Metadata from File. "

In my tests just now, LR reads from XMP:TransmissionReference:

One thing to be careful about: If you had previously done Metadata > Save Metatadata to that file, LR would have written an IPTCDigest field, which LR subsequently uses to determine whether to read from IPTC:OriginalTransmissionReference or XMP:TransmissionReference. As mentioned before, I'm not completely sure that LR's use of IPTCDigest is bug free.  So the safest thing to do is to use Exiftool to write new values into both fields or to delete one of the fields and IPTCDigest.

Or use a non-IPTC field, such as EXIF:UserComment.

[Use the blue reply button under the first post to ensure replies sort properly.]

[cos49]

I had been doing a Save metadata thinking the image file would be consistent with what I was seeing in Lr before writing anything new to the file so that when I did a Read Metadata I wouldn't get any surprises.

I think that and not being aware of the IPTCDigest explains some of the inconsistencies I was seeing.

Thanks for your input.