Cannot update or delete some metadata fields

[BanjoTom]

When I import some JPG images, I find that there are existing entries in some metadata fields that I view with the Default layout.  In particular, I note that these TWO fields

   {File.MD.XMP::photoshop\TransmissionReference\TransmissionReference\0}

         AND

   {File.MD.XMP::photoshop\Instructions\Instructions\0}

often contain some data -- not helpful information, but just an alphanumeric series -- when a file has been imported.  That would be OK, but in such cases I cannot delete the unhelpful data.  That is, I can try, by changing or deleting the information in those fields, but then when I save the image, IMatch notes in the metadata panel that it is "UPDATING," and after a short time, the useless alphanumeric information reappears.

I tried using a metadata template to delete such unhelpful information from the "TransmissionReference" and "Instructions" fields, but that didn't work either.  So far the only way I can delete such useless content is by opening the image in another application, such as Photoshop or Nikon's ViewNX2, then deleting the un-helpful metadata, and re-saving the file. 

Why does this happen?  Is it just an unexplainable part of what Mario calls the "Metadata Mess?"  And/or, is there a way to get these changes or deletions to work within IMatch?   

[sinus]

When I import some JPG images, I find that there are existing entries in some metadata fields that I view with the Default layout.  In particular, I note that these TWO fields

   {File.MD.XMP::photoshop\TransmissionReference\TransmissionReference\0}

What about Metadata-Panel:

Default - and there the field

Job_Id

This is related to the Transmission and you should be able to edit this field.
Can you try this, please?

[Mario]

Both of these XMP fields have counterparts in legacy IPTC metadata. Do you allow IMatch to map between XMP and legacy IPTC on write-back? If not, the XMP data will not stick, because it will be replaced by the IPTC data in the file on re-import.

I've made a quick test with a file which has the -IPTC:OriginalTransmissionReference and -IPTC:SpecialInstructions tags filled.
On import, IMatch maps these into the corresponding XMP tags. Correct.
When I update the XMP tags or 'empty' them, the XMP data is written and then the XMP data is mapped back to IPTC. Which also removes the tags from IPTC. The data does not "come back".

Please check if you use the default settings for write-back in IMatch (Allow to map XMP into IPTC).
Maybe attach a sample image (or send it to me) which exhibits this behavior. I can then check it out here.

[BanjoTom]

In Metadata 2 configuration, I had been using default settings for all file types.

Mario, is the setting you were referring to based on the line for JPG files labeled "Allow create IPTC/EXIF/GPS"?   

I went into the Metadata 2 preference settings for JPG files, and changed the line "Allow create IPTC/EXIF/GPS" from "NO" to "YES", and now the problem seems solved for JPG files.   

[Mario]

This setting is off by default because creating legacy IPTC data for new files is not recommended by the MWG. IMatch always updates existing legacy IPTC data in files when detected (which should be the case for your files)  but does not create new data.

1. Your test seems to indicate that your file has only a partial / incomplete legacy IPTC record.
2. IMatch fails to detect the partial record.
3. IMatch hence does not synchronize XMP back into IPTC on write-back, leaving the partial IPTC data untouched.
4. This causes the 'roll-back' of XMP data on re-import because some XMP data is replaced by legacy IPTC data read from the file.

Don't forget to hange the setting back to the default setting.

Reason for this problem:

When IMatch writes back XMP data, it needs to determine if the target file has legacy IPTC data which needs to be synchronized. There are over 200 legacy IPTC tags or so. IMatch tests about 5 or 6 legacy IPTC tags (e.g. the mandatory IPTC version number tag). If none of these tags is found in the file, it assumes that the file has no IPTC data. Testing for all IPTC data tags every time a file is written would be way too slow.

Your file seems to have no IPTC data in any of the tested tags, and thus IMatch does not perform the XMP -> IPTC synchronization on write-back. This is normally a good thing because it saves time. In your case it is wrong, because the partial existing legacy IPTC data is not overwritten.

I would need to see a file (attach or send via email) so I can see if

a) I need to test other tags as well
b) The IPTC record in your file is invalid/broken and thus no change to IMatch is required.

[BanjoTom]

OK, and thanks, Mario.  Here (attached) is another JPG file, which does contain data in the "Job-ID" and "Instructions" metadata fields.  With the default settings for JPG, I cannot update these fields successfully -- on write-back, the same data reappears. 



[attachment deleted by admin]

[Ferdinand]

You may need to zip the file, as the forum software seems to strip metadata out of uploaded image files.

[Mario]

You may need to zip the file, as the forum software seems to strip metadata out of uploaded image files.

When you use "Save link as" for the link shown under the image, the original file is downloaded. Usually.

[Mario]

OK, and thanks, Mario.  Here (attached) is another JPG file, which does contain data in the "Job-ID" and "Instructions" metadata fields.  With the default settings for JPG, I cannot update these fields successfully -- on write-back, the same data reappears.

The image file contains an invalid/incomplete IPTC record.
It has only two IPTC fields: OriginalTransMissionReference and SpecialInstructions.
None of the tags specified as mandatory in the IPTC standard are included. For IMatch, this file has no IPTC information.

Solution

Fix the incomplete IPTC data in the file.

A)
1. Add the legacy IPTC tag ApplicationRecordVersion (not the XMP tag, mind) to a Metadata Panel layout.
2. Select the files with the problem.
3. Set the ApplicationRecordVersion to 4
4. Write-back

This adds the mandatory version number to the file and when IMatch reloads the file it detects that it has IPTC info.

B) Select the files and run the ExifTool CommandProcessor with these arguments:

-overwrite_original
-iptc:applicationrecordversion=4
{Files}


This does the same.

Note: Always try with a test file first!

[BanjoTom]

Thanks, Mario!  I used Method A, and after saving the file with {File.MD.IPTC::ApplicationRecord\0\ApplicationRecordVersion\0} set to "4" it was then possible to successfully remove the "Transmission Reference" and "Instructions" fields and resave (write back pending metadata) to the file, leaving those fields blank -- as I hoped. 

Now that my default core metadata panel includes the IPTC "ApplicationRecordVersion" field, I should be able to easily fix any files that contain these sorts of un-helpful data in the IPTC "Transmission Reference" and "Instructions" fields. 

But -- although this solves my problem, I'm left with one final question: why is 4 the right value to use in the IPTC ApplicationRecordVersion field?  What does it mean, in IPTC terms, to set up a file as ApplicationRecordVersion 4?  I'm simply curious about the meaning of this particular needed value in that field . . .   

[Mario]

But -- although this solves my problem, I'm left with one final question: why is 4 the right value to use in the IPTC ApplicationRecordVersion field?  What does it mean, in IPTC terms, to set up a file as ApplicationRecordVersion 4?  I'm simply curious about the meaning of this particular needed value in that field . . .

4 was the last version of the old legacy IPTC standard. It was good for a few years, and then the IPTC abandoned their old schema and moved everything into Adobe's XMP metadata. 4 is also the version ExifTool writes when you add legacy IPTC data to a file.