https://bugs.kde.org/show_bug.cgi?id=468830
--- Comment #11 from Darek Kay <m...@darekkay.com> ---
I have encountered the same issue (digiKam deletes all metadata) and the core
issue is the same (XMP segment is big), BUT the use case is slightly different
and I feel like this is a problem with digiKam itself. I have attached 3 files:
- A minimal jpg file
- A "small" XMP sidecar file
- A "big" XMP sidecar with 240Kb of data (minimal example of a file coming
from Lightroom)
To reproduce the problem:
- Save XMP sidecar files as "468830-small.xmp" and "468830-big.xmp"
- Duplicate the jpg file into "468830-small.jpg" and "468830-big.jpg" to
match both sidecar files.
- Open both images in digiKam.
- Change the rating (or any other metadata) for both files.
- Synchronize/save the metadata.
What you will notice is that the "small" JPG file is fine (the metadata is
stored), while the "big" JPG file is broken (metadata lost).
The interesting part is that the field that causes the problem
("crs:Table_...") is never actually stored within JPG by digiKam. This is fine,
as the field does not make much sense in a JPG file, but despite not being
saved it causes the metadata loss. My guess is that DigiKam passes all XMP data
- including the sidecar file - to the backend, even if some data won't be
stored in the JPG file.
If you think it's worth handling my use case separately from the initial bug, I
can open a new ticket.
--
You are receiving this mail because:
You are watching all bug changes.
