PL5 Adds Legacy (i.e., obsolete) IPTC Metadata

,

The original International Press Telecommunications Council (IPTC) metadata for digital photos was IIM, aka Legacy IPTC. IIM has been superseded by IPTC’s XMP-based metadata standards.

PL4 copied metadata from RAW images to output images (e.g., JPG) essentially intact. PL5 has added new metadata editing capabilities. Unfortunately, this implementation has created some metadata issues.

Specifically, PL5, unlike PL4, is adding Legacy IPTC metadata tags to output images. This can create inconsistencies in metadata and possible corruption of user metadata. The Metadata Working Group guidelines detail how to deal with Legacy IPTC metadata. However, if Legacy IPTC metadata does not exist in the RAW image, it should not be created in output images!

This behavior is a bug that is likely to create problems for users and possibly lead to loss of metadata.

2 Likes

I agree, this should be fixed as soon as possible.

Please provide a few examples (tag names, output file format) so that we can check if the same thing happens on Mac.

Here are several attachments:

  • List of Legacy IPTC tags produced by PL5 in a JPG output file. The original NEF did not contain any Legacy IPTC tags.
  • Dump via ExifTool of metadata from JPG file produced by PL5
  • Dump via ExifTool of metadata from same file after deleting Legacy IPTC tags

Let me know if you need more information.
Legacy JPG PL5 output.txt (500 Bytes)
ExifTool Dump of tags from PL5 JPG output file.txt (24.5 KB)
ExifTool Dump of tags from PL5 JPG output file wo Legacy IPTC tags.txt (25.0 KB)

Also, here are the ‘before’ and ‘after’ JPG images (DxO-1 is after I removed the Legacy IPTC tags). (I zipped both images to prevent the forum software from changing the images.)
2021-10-16 13-32-26 NIKON Z 6_DxO.zip (10.6 MB)
2021-10-16 13-32-26 NIKON Z 6_DxO-1.zip (10.6 MB)

As far as my experiences go, I’ve never found PhotoLab to add “invented” metadata to output files.
What I see in your “Legacy…” file is data that has been added manually, be it inside or outside of PhotoLab. If that data came along with an .xmp sidecar file, PhotoLab will read that data when PL sees that image/sidecar file for the first time.

PhotoLab adds metadata to exported files, unless you uncheck the respective options in the export dialog. As for IIM or XMP notations, I find that all the apps I tested with (LrC, C1, PM) were able to read metadata that came from PL, except (of course) for data in fields that were not filled or present in PL or the other apps.

I assume that professional asset management systems and applications will be able to handle metadata in “legacy” notation for a long time: Cutting that support would mean to loose all MD of “old” files in the blink of an eye. As for IIM vs. .XMP notation in new files, I suppose that both notations will coexist for a longish time too.

All in all, I’d not consider the current behaviour as faulty.

platypus, although we don’t have the NEF+Sidecar source, your conclusions seem to be a bit hasty.

You might try to process “2021-10-16 13-32-26 NIKON Z 6_DxO-1.jpg” (no IPTC-IIM) and find that DxO adds IPTC-IIM data if “IPTC” is checked in the export dialog, and suppresses other data (e.g. LocationShown) if “IPTC” is unchecked in the export dialog.

John: It would be cleaner to use the (any) original NEF + XMP sidecar for the demonstration and to state your export settings.

Have not checked that…but if it is as you write, a bug seems to be in how PL reacts to the checkbox(es)…

Not only. I’m afraid the problem is much bigger.

I’ve attached the XMP file from the original NEF. It contains metadata I added in IMatch. It does not contain any Legacy IPTC data. The problem I originally described is that PL5 has copied the metadata from the NEF/XMP file (good) but also added Legacy IPTC tags to the output PJG file (not good).

I’ve also attached a zipped copy of a JPG output file for which I unchecked ‘IPTC’ for the export. (I had just upgraded to PL 5.1 if this matters.) This omits the Legacy IPTC tags, but also leaves out important metadata such as Creator, Copyright and several tags describing location.
2021-10-16 13-32-26 NIKON Z 6.xmp (8.1 KB)
2021-10-16 13-32-26 NIKON Z 6_DxO No IPTC 2.zip (11.3 MB)

As I’ve mentioned on these boards several time in the past, metadata is a mess. Life would be easier for all of us if manufacturers and others would adopt and stick with a defined standard set of metadata tags. One useful step would be migrating from proprietary tags to using XMP metadata standards in their images. Unfortunately, I don’t see much movement in this direction…

That’s what I also found (see my posting 2021-12-06).

JFTR: I was also among the posters who warned about the complexity of DAM functionality and advised against its implementation as long as there are still many long standing user requests regarding the image processing functions.

3 Likes

When you look at other DAM’s you see the range they cover which will be the range PL users will be asking for. It will be a never ending cycle of demands as its become now I suspect at the cost of the core program.

Hello!

@jch2103 the issue is claimed as fixed but to have a clear test of it I need your raw+xmp. Could you, please, provide them for me via upload.dxo.com?

Thank you
Regards,
Svetlana G.

Thank you for checking back.

Better yet, I’ll kill two birds with one stone. Here’s a link to a raw and output image with .dop and .xmp sidecars: Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.
I set this up for @artmax for a time zone issue.

The ExifTool dump for the output JPG suggests that DxO has indeed cleaned up most of the Legacy IPTC tags, but that IPTC Application Record tags for By-line and Copyright Notice are still being created in the output image (but not present in the NEF).

Thank you!

Testing the issue.

Update: I confirm, the issue has been fixed, here is the output after the fix DSC_2725_DxO.zip (6.5 MB)

The fix will be delivered with the next release.

Regards,
Svetlana G.

Regards,
Svetlana G.

Excellent! Thanks, Svetlana.

John

1 Like