Version: 2.0.0 (using KDE 4.5.5) OS: Linux If there is already an XMP sidecar created by other application, digiKam rewrites it with its own content. Reproducible: Always Steps to Reproduce: Use some other application to create a sidecar XMP file for image.cr2 (e.g. darktable). Open digiKam, make sure "writing to XMP files is allowed", add some tag to image.cr2. Actual Results: XMP sidecar image.xmp gets overwritten, information stored by darktable is lost. Expected Results: digiKam is friendly to existing XMP keys and does not remove them. darktable creates image.cr2.xmp, while digikam (as of now) creates image.xmp. For the test above, either rename the sidecar or create a symlink. BTW, darktable does the same as digiKam (bug).
Created attachment 56398 [details] XMP sidecar after renaming to 0test.xmp and adding tag in digiKam.
Milan, can you still reproduce with a current beta? I tried to reproduce and I think the information was merged into the sidecar.
Marcel, digikam (current git) seems to handle the foreign xmp file correctly - the tags of darktable survives and new ones are added correctly. Another issue: when I re-read metadata from file (blabla.cr2.xmp), they are also synced to IPTC (legacy) and no character conversion from UTF to printable ASCII is carried out. (Not even the buggy conversion as described in # 195508.) E.g. the UTF character "š" gets shown as "Åi" in Metadata tab / IPTC. However, XMP metadata are correct. I propose to use the current conversion through QString::toAscii() to have at least the same behaviour like described in the above mentioned bug 195508.
Gilles, any idea at which level this conversion must be done? When writing IPTC I suppose?
Yes, at IPTC registration. But if i remeber, i already pass UTF8 QString to Exiv2 as QString::toAscii(), which is converted to ASCII. Perhaps it's a problem relevant of Exiv2 when data are recorded to IPTC... Gilles Caulier
(In reply to comment #0) > Version: 2.0.0 (using KDE 4.5.5) > OS: Linux > > If there is already an XMP sidecar created by other application, digiKam > rewrites it with its own content. > > Reproducible: Always > > Steps to Reproduce: > Use some other application to create a sidecar XMP file for image.cr2 (e.g. > darktable). > Open digiKam, make sure "writing to XMP files is allowed", add some tag to > image.cr2. > > > Actual Results: > XMP sidecar image.xmp gets overwritten, information stored by darktable is > lost. > > Expected Results: > digiKam is friendly to existing XMP keys and does not remove them. > > darktable creates image.cr2.xmp, while digikam (as of now) creates > image.xmp. For the test above, either rename the sidecar or create a symlink. > BTW, darktable does the same as digiKam (bug). I've the same issue with Aftershot pro and/or darktable :( xmp sidecar is overwrite by digikam 2.5.0 if geoloc and/or tag is added :( merging will be the top :)
With the sidecar fixes applied for coming 2.6, XMP data should now be merged properly. I would ask Milan to amend the encoding problem which arose here to 195508