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.
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.
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).
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.
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.
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).
I just downloaded your samples - a couple of questions to sate my curiosity…
The original NEF file contains both the exif:imageDescription and exif:userComment tags. I take it these are coming from the Image Comment menu item on the camera? My D850 only writes the exif:userComment tag.
I notice that the dc:description tag in the XMP file contains the value from that/those tag(s)? This is something I didn’t think of for my keywording/etc app but it looks like more cameras are now putting more metadata in the EXIF. Something, too my mind, that both DxO and other DAM apps are going to have to take account of. This also means that, if apps don’t allow writing to RAW files, we are going to find more and more synchronisation errors when moving files from one DAM to another.
The XMP file was apparently authored through ExifTool 12.39, which is the very latest version, what did you use to create the XMP file - an app that wraps it or the command line?
The lr:hierarchicalSubject tag contains a non-hierarchical, or at least, single level keyword…
Excellent questions. I’m likely tied up today on other things, so probably won’t be able to answer until tomorrow. In the meantime, you may find this topic in the IMatch Help system relevant/interesting: IMatch Help System
Also of interest: IMatch Help System You’re certainly not a beginner, but this link discusses how IMatch handles metadata internally.
By way of background, I use IMatch as my DAM; IMatch in turn uses ExifTool to manage metadata. IMatch creates an XMP sidecar for files, as described in IMatch Help System (again, this link is just to explain how IMatch processes metadata). Internally, they use the ExifTool .args files to copy/translate tags from one group/tag to another group/tag. These .args files are part of the full ExifTool installation. One example from exiftool Application Documentation is
exiftool -@ iptc2xmp.args -iptc:all= a.jpg
Translate IPTC information to XMP with appropriate tag name conversions, and delete the original IPTC information from an image. This example uses iptc2xmp.args, which is a file included with the ExifTool distribution that contains the required arguments to convert IPTC information to XMP format. Also included with the distribution are xmp2iptc.args (which performs the inverse conversion) and a few more .args files for other conversions between EXIF, IPTC and XMP.
IMatch uses the full set of ExifTool .args files.
This is interesting. My Z6 includes an option for storing user comment in the image file, but I don’t use it. So in this case, the information in the dc:description tag in the .XMP file was created via IMatch/ExifTool (using those .arg files) when I used IMatch to add the description tag XMP::dc\description\Description\0. But I don’t find exif:imageDescription in the NEF file, using Notepad++.
Yes, as noted above I was using IMatch/ExifTool (12.30) to create the XMP file.
I’m not sure what happened here. PL5 does create superfluous top-level keywords (‘National Park’) in the output JPG file, which I’ve reported as a bug; a fix is ‘in a development stage’ PL5 Adds Legacy (i.e., obsolete) IPTC Metadata - #16 by jch2103. However, I don’t know how this got copied to the NEF. I’ll need to monitor things to see if it happens again or if it was due to user error on my part.
I did set up a new copy of the unedited NEF, added basic metadata (caption, hierarchical keywords) and processed it with PL5. No issues with the NEF. The output JPG demonstrated the bug (extraneous 'National Park). So the issue with the original NEF that I had posted may have been a one-off.
The ‘photoshop’, etc., tags are a result of the ExifTool .args files. I didn’t use PS or LR or any other Adobe product on this files.