https://bugs.kde.org/show_bug.cgi?id=527759
Bug ID: 527759
Summary: XMP of the primary image ignored, and then
overwritten, in HEIC files that contain a second XMP
item (Apple HDR gain map)
Classification: Applications
Product: digikam
Version First 9.1.0
Reported In:
Platform: macOS (DMG)
OS: macOS
Status: REPORTED
Severity: major
Priority: NOR
Component: Metadata-Xmp
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 197623
--> https://bugs.kde.org/attachment.cgi?id=197623&action=edit
Sample image file edited in Photos, exported, indexed with digiKam
Version: digiKam 9.1.0 (KDE package), macOS 26.6.2 (Apple silicon).
Built-in Exiv2 reader, and the same result with "Use ExifTool backend to read
metadata from files" enabled — which is the workaround that closed bug 494585.
Verified 2026-10-24: with that option on, Maintenance › Sync Metadata and
Database ("From image metadata to database") over a folder of 140 such HEIC
files imported metadata for exactly the 11 whose gain-map XMP item precedes the
primary image's, and nothing at all for the other 129. digiKam's own bundled
ExifTool 13.58 reads all 140 correctly from the command line, so the option
does not appear to change which XMP item is used.
Description: iPhone photos edited in Apple Photos are saved as HEIC with an HDR
gain map: an auxiliary image item (auxl,
urn:com:apple:photo:2020:aux:hdrgainmap) that carries its own XMP metadata item
(HDRGainMapVersion 0.1.0.0, XMP Core 6.0.0). When standard metadata (rating,
colour label, keywords, caption) is added to the primary image with ExifTool,
the file holds two XMP items, each linked by a cdsc reference to a different
image item:
A Photos edit (digiKam shows nothing) A camera original (digiKam is
correct)
pitm = 49 pitm = 49
item 51 rdf+xml 6004 B cdsc -> [49] item 64 rdf+xml 363 B cdsc ->
[63]
= the PRIMARY image = a non-primary image
(gain map)
item 65 rdf+xml 363 B cdsc -> [64] item 66 rdf+xml 6273 B cdsc ->
[49]
= a non-primary image (gain map) = the PRIMARY image
Each item holds exactly one <x:xmpmeta> block; they are separate items, not one
malformed packet with trailing data.
The cdsc reference identifies the right item unambiguously in both cases — the
file already says which XMP item describes the primary image. The only
difference between the two files is the order the items appear in iinf: Apple
writes the gain map's item last in Photos edits and first in camera originals.
digiKam reads the gain map's XMP item instead of the one describing the primary
image, so it shows no rating, colour label, caption or keywords for the photo.
ExifTool (exiftool -a -G3) and Adobe Lightroom Classic 15.6 read the primary
image's XMP correctly.
Steps to reproduce:
Take an HDR photo on an iPhone (13 Pro here); edit it in Apple Photos so it is
rendered with a gain map.
Add metadata to the primary image: exiftool -XMP-xmp:Label=Blue
-XMP-xmp:Rating=3 file.heic
Add the folder to digiKam, then run Maintenance › Sync Metadata and Database
with Sync Direction "From image metadata to database". ("Scan for new items" is
not enough — it refreshes each file's size and timestamp without re-parsing the
metadata.)
Quicker still, without digiKam at all — Exiv2 0.28.9 on such a file reports 1
XMP key, the gain map's HDRGainMapVersion, where ExifTool reports the full set:
exiv2 -q -P X file.heic | wc -l # 1
exiftool -a -s3 -XMPToolkit file.heic # two values: two XMP items
Expected: digiKam shows rating 3 and the Blue label, taken from the XMP item
that is linked by cdsc to the primary item (pitm). Actual: no rating and no
label. HEIC files without a gain map behave correctly.
Also: setting a colour label on such a file in digiKam writes it correctly into
the primary image's XMP (confirmed with ExifTool), but with "Rescan file when
files are modified" enabled, digiKam immediately re-reads the file and the
label disappears from view. So labels and ratings on these files cannot be
shown at all.
Also — data loss (found 2026-10-24, worse than the display problem): the write
is not additive. Because digiKam has read the gain map's XMP item, the record
it writes back to the primary image's XMP item is that empty one plus the
change. Everything else in the primary image's XMP is destroyed. Assigning one
keyword to 16 such files removed, from every one of them:
dc:creator photoshop:Credit
Iptc4xmpCore:CreatorContactInfo (CiEmailWork, CiUrlWork)
dc:rights photoshop:Source photoshop:DateCreated
xmp:Label photoshop:AuthorsPosition xmp:CreateDate,
xmp:ModifyDate, xmp:MetadataDate
Exif (including DateTimeOriginal) is untouched; only the primary image's XMP
item is overwritten. The loss is silent — no warning, and nothing in the log.
It is confined exactly to the files digiKam misreads, which is further evidence
for the diagnosis above: in one folder digiKam wrote to 74 curated files, and
the 67 two-XMP HEICs were all stripped while the 4 JPEGs and the 3 single-XMP
HEICs kept their metadata in full.
Writing was via digiKam's bundled ExifTool 13.58, with "Write metadata to files
with ExifTool" off — HEIC appears to use ExifTool regardless, Exiv2 being
unable to write it.
Scale here: 3,900 of 14,666 HEIC files in one collection have the gain map's
XMP item last and are misread; any metadata set on one of them from digiKam
costs that file its existing XMP. (digiKam's own database holds no tags at all
for 3,869 of them, the small difference being files that never carried
metadata.)
Suggested fix: when a HEIF file has several XMP (mime, application/rdf+xml)
items, read the one whose cdsc reference points to the primary item (pitm) —
which, as shown above, is unambiguous in these files and needs no heuristics.
Exiv2 assigns a single xmpID_ while traversing iinf, so a later mime item
replaces an earlier one and the last one wins; the declared content type is not
consulted. Apple writes the gain map's item last in Photos edits and first in
camera originals, which is exactly why edits are affected and camera originals
are not. Measured here: 48 of 48 "gain map last" files unreadable, 60 of 60
"gain map first" files read correctly.
Not a viable workaround: relabelling the gain map's infe item_type so Exiv2
skips it fixes both the read and the destructive write, but it stops ImageIO
exposing the gain map's metadata, and Core Image's HDR expansion then falls
back to the SDR image (content headroom 3.08 to 1). Tested on 3,900 files and
reverted.
Attachment: a sample file is attached
--
You are receiving this mail because:
You are watching all bug changes.
