When I import images that have existing XMP sidecar files Digikam reads those files and uses the metadata in them. But it creates its own UUID for the database although there already is one supplied in the XMP sidecar, as <rdf:Description ... ... digiKam:ImageUniqueID="QXbwXF%yQEqRFBbG+GkfyA" ... > This is important if you reimport files again so they are uniquely identifiable even from an external script. The UUID is the only *safe* way of uniquely identifying an image after the import (after all, it might have been renamed, moved, etc). I suppose the UUID really is just a unique random string of any length (right?). Duplicate UUIDs, if present, should be handled just like duplicate files, by prompting the user to replace the file or create a new UUID when first reading the image file's metadata. But in reality this should never happen - it is just important that Digikam doesn't crash with a duplicate UUID. Reproducible: Always
Hi, can anything be done about this? This makes the import process of iphoto2xmp (see github -> jensb/iphoto2xmp) much harder and I don't really see why Digikam would need to regenerate a unique ID here. Thank you!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
As far as I can see there has been no change and the issue still exists.
This bug report is invalid for digiKam. The UUID that digiKam generates has nothing to do with the random unique image ID. The UUID that digiKam generates comes from parts of the file data itself. The image UUID is not even unique for many cameras (Samsung e.g.) and cannot be used to recognize the file. Maik
But in this case, Digikam created the XMP sidecar, and thus the "ImageUniqueID" inside this file. Where is the content-based checksum UUID which you mentioned stored? Not in the XMP sidecar? If not, why not?
The UUID (hash) used by digiKam is in the database, as is the image ID. What is the purpose of this information in the metadata? Other programs use other methods to create a UUID from the file. The UUID also doesn't help us to recognize files more easily. We have to calculate a new one anyway when importing, because the file may have been modified externally in the meantime. The image UUID in the metadata is a random UUID to make it more unique the current database UUID (hash) is also appended. This UUID is only used to resolve an image processing history. Maik
You answered your own question about the purpose of the UUID in the metadata :-) My intention is to make this a (more) stable interface to make images uniquely identifiably *also across Digikam installations*. I have a mobile Digikam setup on my laptop (Macbook, just a few GB) which I use to tag images when on the road or on vacation. I want to be able to easily sync these to my home Digikam setup (Linux, 300GB of images) and avoid re-importing duplicates, which would be a lot easier if at least Digikam itself would use just one single UUID. If the database UUID is content-based (and not random), as you seem to indicate, then it should not change if the file didn't change. Can we just use this one in the metadata too?
How can you write a UUID in the metadata, since the UUID of the file changes again after the metadata is written? Maik
If the uuid is only generated from the file *metadata*, just exclude the tag with the (previous) UUID when generating a new one. This requires generating the UUID not from the raw file text but from a parsed / cleaned / sorted copy - but you are probably doing this anyway since otherwise the UUID would be very brittle and sensible to the tiniest changes in XML spacing, quotation and tag order. Ruby-like pesudocode: data = XML.parse("my_image.jpg.xmp").delete_by_xpath("//digiKam:ImageUniqueID"); // parse into structure, remove previous UUID uuid = my_uuid_generator(data.to_string); // data.to_string should output a stable formatting (need not be XML) data["digikam:ImageUniqueID"] = uuid; // generate new UUID and insert into data structure File.write("my_image.jpg.xmp", data.to_xml); // generate new XML structure
Maik, What's about the last Jens proposal here ? Gilles
Maik, did you see the Jens proposal in this thread ?