SUMMARY With digikam configured to write metadata to sidecar files only, add caption to jpeg, copy jpeg file but not sidecar (outside digikam). New file has caption. STEPS TO REPRODUCE 1. Configure digikam as follows: Settings->Configure->metadata->Behaviour .Write to metadata ..Image tags ..Captions and title ..Timestamps ..Geolocation info .Reading and writing metadata ..Update file modification ..Rescan when files modified Settings->Configure->metadata->Sidecars .Read from sidecar files .Write to sidecar files .Write to XMP sidecar only .Sidecar file names are compatible with commercial programs 2. Outside digikam, create new jpeg (screen capture) and save to existing album folder 3. Use exiftool to check nothing odd in the jpeg file 4. In digikam change caption (creates sidecar file) 5. Use exiftool to verify jpeg file has not been changed 6. Outside digikam, copy jpeg file - but not xmp file - to new name in same folder 7. digikam finds new image but shows caption same as the original, even though there is no matching sidecar file 8. Use exiftool to verify that no caption has been written to either jpeg file OBSERVED RESULT Digikam shows same caption for new file as old file, even though it doesn't have a sidecar file or embedded caption. EXPECTED RESULT Empty caption. SOFTWARE/OS VERSIONS Windows: 10 ADDITIONAL INFORMATION I'm not sure if this should be higher priority. While I appreciate that it's a contrived situation, it's putting me off making a complete switch to digikam until I understand why this has happened and whether it can happen under other image-importing situation.
This is not a bug, but intentional behavior ... digiKam recognizes the image again during the scan, based on the unique hash in the database. It is therefore the same image, which is why all metadata in the database (including the captions, tags labels, etc.) is also applied to this picture. So has nothing to do with sidecar. If users rename or move pictures externally, digiKam must recognize the picture, otherwise the metadata would be lost. Maik
(In reply to Maik Qualmann from comment #1) > This is not a bug, but intentional behavior ... > digiKam recognizes the image again during the scan, based on the unique hash > in the database. It is therefore the same image, which is why all metadata > in the database (including the captions, tags labels, etc.) is also applied > to this picture. So has nothing to do with sidecar. If users rename or move > pictures externally, digiKam must recognize the picture, otherwise the > metadata would be lost. > > Maik Brilliant! Thank you for that. For a brief moment, I did wonder if something like that was going on but decided it was unlikely. I did have a good nose around looking for something like this to explain it but drew a blank. Thank you again for the explanation and I'm sorry to have taken up your time.
Another note, the digiKam-7.2.0 version is about to be released, as Windows users you should test this version, more than 350 bugs have been closed. Windows support has also been further improved. The version can be downloaded here: https://files.kde.org/digikam/ https://files.kde.org/digikam/digiKam-7.2.0-20210317T200949-Win64.exe Maik