Bug 504135 - Fail to create sidecar file (Exiv2) for certain XMP block in metadata
Summary: Fail to create sidecar file (Exiv2) for certain XMP block in metadata
Status: RESOLVED UPSTREAM
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Sidecar (other bugs)
Version First Reported In: 8.7.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-05-13 07:02 UTC by wsyxbcl
Modified: 2025-06-25 06:20 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 8.7.0
Sentry Crash Report:


Attachments
A image to reproduce (2.05 MB, image/jpeg)
2025-05-13 07:02 UTC, wsyxbcl
Details
The "original" Ere 0004.JPG (2.05 MB, image/jpeg)
2025-05-15 11:40 UTC, wsyxbcl
Details
XMP metadata output by xmp_toolkit SDK (the rust binding) (3.74 KB, text/plain)
2025-05-15 14:46 UTC, wsyxbcl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description wsyxbcl 2025-05-13 07:02:05 UTC
Created attachment 181236 [details]
A image to reproduce

Here’s the step-by-step process to reproduce it:

1.Import the image into digiKam.
2. Use Album → Read Metadata from Files. At this point, the tag list (in this case Species/Blank) appears correctly, and the XMP tab in the metadata sidebar displays the expected content.
3. In Settings → Configure digiKam → Metadata → Sidecars, I’ve enabled Write to sidecar files with the option Write to item and XMP sidecar. Based on this setting, I expect that writing metadata will update or create a sidecar file with the correct information.
4. Now, run Album → Write Metadata to Files. After this, the XMP data seen in step 2 disappears, and the output "empty" sidecar file contains only the XML header: <?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
5. The image file’s metadata remains unchanged, so if I delete the generated sidecar and redo step 2, the metadata appears again in digiKam.
Comment 1 wsyxbcl 2025-05-13 07:48:29 UTC
I'm using exiv2 as the backend, with debugging log:

digikam.metaengine: Loading metadata with "Exiv2" backend from "/home/wsyxbcl/Pictures/test_empty_xmp/Ere 0004.JPG"
digikam.metaengine: Rating value to write is out of range!
digikam.general: Writing tags
digikam.general: -------------------------- New Keywords ("Human")
digikam.metaengine: "/home/wsyxbcl/Pictures/test_empty_xmp/Ere 0004.JPG"  ==> New Iptc Keywords:  ("Human")
digikam.metaengine: MetaEngine::metadataWritingMode 2
digikam.metaengine: Will write Metadata to file "/home/wsyxbcl/Pictures/test_empty_xmp/Ere 0004.JPG"
digikam.metaengine: wroteComment:  true
digikam.metaengine: wroteEXIF:  true
digikam.metaengine: wroteIPTC:  true
digikam.metaengine: wroteXMP:  true
digikam.metaengine: File time stamp restored
digikam.metaengine: Metadata for file "Ere 0004.JPG" written to file.
digikam.metaengine: Will write XMP sidecar for file "Ere 0004.JPG"
digikam.metaengine: wroteComment:  false
digikam.metaengine: wroteEXIF:  true
digikam.metaengine: wroteIPTC:  true
digikam.metaengine: wroteXMP:  true
digikam.metaengine: Exiv2 ( 3 ) :  XMP Toolkit error 102: Composite nodes can't have values

digikam.metaengine: Exiv2 ( 3 ) :  Failed to encode XMP metadata.

digikam.metaengine: File time stamp restored
digikam.metaengine: Metadata for file "Ere 0004.JPG" written to XMP sidecar.
Comment 2 Maik Qualmann 2025-05-13 11:04:47 UTC
I can reproduce the XMP toolkit error with this image. Interestingly, the XMP in the image was created by Exiv2 and now can't be written to a sidecar. Great.

I haven't found the exact error in the XML yet, but as a test, I added the ExifTool writing for sidecars as well. This works without any problems. We'll probably fix it this way. Exiv2 isn't error-tolerant due to the XMP toolkit.

Maik
Comment 3 Maik Qualmann 2025-05-13 11:16:42 UTC
We had this problem a long time ago, perhaps as a reference Bug 181853.

Maik
Comment 4 wsyxbcl 2025-05-15 11:31:27 UTC
Thanks, Maik, for reproducing the issue.

First, I’d like to apologize. After running some additional tests, I realized the image I initially provided (Ere 0004.JPG) is unfortunately very misleading.

Here’s what actually happened:

    1. The user started with the original image — let's call it Ere 0004_original.JPG.

    2. They then used the Adobe XMP Toolkit (specifically the Rust SDK) to generate an XMP sidecar file for that image.

    3. So when importing the image into digiKam, the software read the metadata from step 2 and overwrote the original metadata, resulting in the current version: Ere 0004.JPG.

I re-tested using the original image (Ere 0004_original.JPG), and everything worked as expected.

Digging further into the issue, I inspected the XMP file generated by the Adobe XMP Toolkit and identified the problematic lines as:

<exif:DeviceSettingDescription rdf:parseType="Resource">
   <exif:Columns>0</exif:Columns>
   <exif:Rows>0</exif:Rows>
</exif:DeviceSettingDescription>
Comment 5 wsyxbcl 2025-05-15 11:40:00 UTC
Created attachment 181325 [details]
The "original" Ere 0004.JPG
Comment 6 wsyxbcl 2025-05-15 12:22:31 UTC
This is not technically a digiKam issue, so I’ll mark it as resolved.
Comment 7 wsyxbcl 2025-05-15 14:46:13 UTC
Created attachment 181336 [details]
XMP metadata output by xmp_toolkit SDK (the rust binding)
Comment 8 caulier.gilles 2025-06-25 06:20:01 UTC
wsyxbcl@gmail.com

As it's an UPSTREAM bug for Exiv2, did you open a file in Exiv2 bugzilla ?

https://github.com/Exiv2/exiv2/issues

Gilles Caulier