SUMMARY IPTC title ("Object Name") is not getting truncated at 64 characters when there is an xmp file containing a long title. STEPS TO REPRODUCE 1. Add a new jpeg photo (`myimage.jpeg`) to digikam, and go to "Captions" -> "Description". 2. Enter a "Title" that is longer than 64 characters (e.g., "digiKam is an advanced open-source digital photo management application that runs on Linux, Windows, and MacOS") and click "Apply". 3.1. Use exiftool to check the image: `exiftool -G1 myimage.jpeg`. 3.2. As expected, the "[IPTC] Object Name" is truncated as 64 characters ("digiKam is an advanced open-source digital photo management appl"). 4.1. Now add a raw file with the same name to the same directory (e.g., `myimage.nef`). It doesn't matter what the raw image is. It is just used to generate a sidecar xmp file that contains a long title. 4.2. In digikam, click the raw file and add a "Title" that is longer than 64 characters ("digiKam is an advanced open-source digital photo management application that runs on Linux, Windows, and MacOS") and click "Apply". 4.3. Now we have a xmp file with the same name (e.g., `myimage.xmp`). (We can remove the raw image at this point.) 5. Go back to the jpeg file, and click "Information". Select any of the template (e.g., "To remove") and click "Apply". 6. Run the same exiftool command again: `exiftool -G1 myimage.jpeg`. OBSERVED RESULT The object name is not truncated. ``` [IPTC] Object Name : digiKam is an advanced open-source digital photo management application that runs on Linux, Windows, and MacOS ``` EXPECTED RESULT The object name should be truncated as before (in step 3.2). ``` [IPTC] Object Name : digiKam is an advanced open-source digital photo management appl ``` SOFTWARE/OS VERSIONS digikam: 6.4.0 macOS: 10.15.5 ADDITIONAL INFORMATION Notice that when you edit the "Title" again and click "Apply", the IPTC Object Name got truncated again. I discovered this bug when I was working with both raw and jpeg file and assigning the same title to both of them. For a long time I thought it was normal for the IPTC title to be longer than 64 characters, until I removed the raw file and discovered that the title got truncated (http://digikam.1695700.n4.nabble.com/digiKam-users-Embedded-IPTC-title-in-JPEG-suddenly-started-to-get-truncated-at-64-characters-td4712640.html). I think it is very confusing for the users to get this inconsistent behavior (being able to have a title that is longer than 64 characters, but got truncated with seemingly no reason later when they remove the raw file).
This problem is quite specific and there are some conditions that must come together. You are using a "compatible" sidecar name. The XMP file would not be considered for sidecars with an image extension. In the upcoming digiKam-7.0.0, the "compatible" sidecar will also be deleted if the RAW image is deleted. You have to understand that with XMP sidecars the IPTC metadata is interpreted and merged with the XMP sidecars. We couldn't merge the IPTC object name. Or check for this special key during the merge and cut to a length of 64 characters. Maik
Maik, Look the code from this method: https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/metadataengine/dmetadata/dmetadata_comments.cpp#L449 This can be a source of problem as now IPTC support UTF8 encoding in digiKam, and this method force to drop non printable characters whn this tag is written. Typically, i think that IPTC charset tag must be checked to see if we drop non printable elements. Something done like here: https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/metadataengine/engine/metaengine_p.cpp#L947 Gilles
Gilles, In this case, the IPTC field is set to over 64 characters using the merge function with the sidecar if the XMP field is longer. https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/metadataengine/engine/metaengine_p.cpp#L895 Maik
https://bugs.kde.org/show_bug.cgi?id=426938 --- Comment #4 from caulier.gilles@gmail.com --- Hi, digiKam 7.2.0-beta2 pre-release PKG installer now support BigSur and is compiled with last stable Qt 5.15.2. https://files.kde.org/digikam/ Problem still reproducible with this version. Thanks and happy Christmas in advance Best Regards Gilles Caulier
@hesyifei digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier
Following comment #1 from Maik, you have now a Metadata settings for the compatible sidecar name to prevent this problem. I close this file now. Gilles Caulier