Created attachment 103611 [details] Wrong history of Samsung images It seems an old problem is back (see https://bugs.kde.org/show_bug.cgi?id=323210 ), at least very similar. I noticed that a lot of images I downloaded from a Samsung S3 smartphone have a history showing "Derived Images And Identical Images That Are Neither Derived Nor Identical". See attachment! It seems that all these images in the history are edited by digiKam, at least the metadata. If I go to one of these images it also shows this screwed up history. All the false derived or identical images are from the same Samsung S3 as far as I could find out up to now.
Probably like my Samsung S4 the S3 has an always same Exif.Photo.ImageUniqueID for all images. That's really bad. Can you check whether the S3 images has the same ImageUniqueID in the EXIF? Maik
The Exif.Photo.ImageUniqueID only changes here if a new firmware version installed. Maik
A solution : while importing, recompute UUID and patch Exif/XMP tags. Like this database and versioning properties will not be a mess. This will not solve the problem of collection of image not processed by import tool. At least it's better than nothing. Gilles Caulier
We could also put Samsung on a blacklist and ignore Exif.Photo.ImageUniqueID. Xmp.digiKam.ImageUniqueID is read first and would not be affected. Maik
Created attachment 103626 [details] uniqueID.patch Wolfgang can you test this patch? Re-reading the metadata should solve the problem. Maik
Maik to comment #4 : yes, so far, a better solution at all. Why i don't think about it before (:=)))... Gilles Caulier
(In reply to Maik Qualmann from comment #5) > Created attachment 103626 [details] > uniqueID.patch > > Wolfgang can you test this patch? Re-reading the metadata should solve the > problem. > > Maik Maik, Reread Metdata from Image in the Item menu on pics that are already imported does n o t solve the problem. Only if I import the pics again the wrong history is gone, but only with "Use file metadata" un-checked.
Git commit c142f6b5c2a491db75253f75c331bdc2c4d48c0f by Maik Qualmann. Committed on 26/01/2017 at 11:37. Pushed by mqualmann into branch 'master'. blacklist Samsung cameras for Exif.Photo.ImageUniqueID M +2 -1 libs/dmetadata/dmetadata.cpp https://commits.kde.org/digikam/c142f6b5c2a491db75253f75c331bdc2c4d48c0f
Hello, Following a conversation on Digikam-user mailing-list: https://mail.kde.org/pipermail/digikam-users/2017-August/025082.html I made some tests with Digikam 5.7.0 1) With a Fresh account/database: I imported pictures taken with the Samsung cellular, and then updated them (crop/rotation/etc.); everyrhing worked as expected: The pictures remained visible/reachable in the Thumbnail view 2) With my "old" digikam database, which already contains pictures unreachable via Thumbnail view: re-reading metadata from the picture did not solve anything (e.g. The pictures remained visible in Table view, but not in Thumbnail view) 3) With my "old" digikam database, which already contains pictures unreachable via Thumbnail view: Deleting the Samsung pictures and re-importing them made them visible/reachable again via Thumbnail view. It seems that the patch proposed solves the issue for new (or newly imported) files, but does not solve anything for "already imported" files (even by re-reading the metadata). Hope it helps. Best regards,
There is a solution. You must enable the Option "Rescan file when files are modified" in the metadata settings. Then use "touch" to call the relevant files. The disadvantage is that the file date is changed. Maik
Hello, > There is a solution. You must enable the Option "Rescan file when files are > modified" in the metadata settings. Then use "touch" to call the relevant > files. The disadvantage is that the file date is changed. I tried this, but unfortunately, it did not work. Digikam rescans the files, but they still don't appear in the Thumbnail view. Gurvan
Git commit 8be84aebaacfb233daee45533e66b0828f44a39e by Maik Qualmann. Committed on 05/09/2017 at 19:11. Pushed by mqualmann into branch 'master'. generate for Samsung a new random unique ID FIXED-IN: 5.8.0 M +2 -1 NEWS M +12 -2 libs/dmetadata/dmetadata.cpp https://commits.kde.org/digikam/8be84aebaacfb233daee45533e66b0828f44a39e
Note: now re-read the metadata from the images to fix history. Maik
I was also hit by this nice interpretation of a "unique id" by Samsung. But for me, re-scanning metadata for old samsung photos already known to Digikam does NOT heal all internal database inconsistencies with Digikam 5.8. I found that such images were falsely internally tagged as "originalVersion" by Digikam which hides them from the album preview (unless you enable "always show original images" in Settings > Image Editor > Versioning). See bug 354819 for further details of my journey. By the way, during my travel inside digikam4.db, I also noticed that the ImageHistory table also still knows the old, problematic uniqueId for my Samsung photos. Not sure if this could also harm someday.
I fixed it manually now in the files as well as in the Digikam database "digikam4.db": 0. Shutdown digikam, backup digikam4.db and photos. 1. Scan all pictures using "exiftool -ImageUniqueId" and find duplicates. A small number of duplicates can come from edited pictures, so only filter out those with many occurences. I used a lot of Samsung phones over the years, so I ended up with this list: "NULL NULL ", "LL ", "OAEL01", "S08Q0LEGC01", "SCEE07", "T13LLIA00PM T13LLIL04SB " 2. Find all problematic images in digikam4.db: select name from Images where id in ( select imageid from ImageHistory where uuid in ("NULL NULL ", "LL ",...) ); Compare this list to files with problematic IDs from step 1. 3. Now I started digikam, and deleted IDs from all those files using "exiftool -ImageUniqueId= <file>". This forces re-read of files in digikam. With digikam >= 5.7, a simple touch shuold be enough, too. Shutdown digikam again. 4. Identify tagid for Digikam's internal tag "Original Version": select id from Tags where name="Original Version"; For me, this was "112". 5. Find all entries for tag "112" in ImageTags for problematic images: select * from ImageTags where tagid=112 and imageid in ( select imageid from ImageHistory where uuid in ("NULL NULL ", "LL ", ...) ) ; Store this result. 6. Verify if some of those images were edited (get file names as in 2., search for name_v?.jpg). If yes, the originals should keep tag "112". 7. Delete all entries with tag="112" and problematic imageid in ImageTags which are not found in 6. (For me, step 6 only returned a small number of files, so I just deleted tag "112" for all Samsung images and added it later again for those who shall have it. 8. Delete all entries in ImageHistory with problematic uuids. Sorry for not sharing a full script here, but I had no time to make a polished version which is sufficiently fool-proof... But if you have some experience using SQL and shell scripts, the above description will hopefully be helpful...