https://bugs.kde.org/show_bug.cgi?id=305104
--- Comment #18 from Johannes <[hidden email]> --- Reading bug 323210#c4 again: “Dropping the relations table has no side effects, you just lose relations. Locating identical images is not based on the relations table, it's based on file hash and file size“ lead me to look closer into the database and I figured out, that all/most of the images in that dropbox folder had the same Exif.Photo.ImageUniqueID which were also stored in the database in the table ImageHistory in column uuid. These photos were taken by: Exif.Image.Software : N9005XXUBMI7 Exif.Image.Model : SM-N9005 Exif.Image.Make : SAMSUNG -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Bugzilla from pdgfellow@gmail.com
https://bugs.kde.org/show_bug.cgi?id=305104
--- Comment #19 from Johannes <[hidden email]> --- Finally I was able to correct the database. What I did trying to figure it out (using digikam 4.12 on Ubuntu 16.04): I set up a new digikam collection with only the images from dropbox and dumped the sqlite database. Then I removed the ImageUniqueID from the images were it was not unique with exiv2 -M'del Exif.Photo.ImageUniqueID' /home/user/dropbox/images/*.jpg Then I removed the database-file to let digikam create it again and dumped it, too. (Now all images were already shown and no wrong images were assigned as identical.) Then I looked at the diff of the two database dumps. By that I figured out that the table ImageTags is also involved: Images wrongly identified as identical to others have the tagid which has the name "Original Version" in tags table. With this information I were able to edit my original digikam database and now everything works right. Follow these steps to solve the problem: 0. Close digikam and make a bakup of the collection database. Make sure to have sqlite3 or SQLiteManager for Firefox or a similar tool available to check and edit the database. 1. Identifying photos which have identical values in: Exif.Photo.ImageUniqueID This is easily done by SELECT *, COUNT(*) as c FROM ImageHistory GROUP BY uuid HAVING c > 1 ORDER BY c DESC (I also saw only photos affected which have no history entries: SELECT *, COUNT(*) as c FROM ImageHistory GROUP BY uuid HAVING c > 1 AND history IS NULL ORDER BY c DESC ) I removed the entries with unique uuids after copying the imageids to a file for further usage. 2. Remove the ImageUniqueID from the images where it was not unique with exiv2 -M'del Exif.Photo.ImageUniqueID' /home/user/dropbox/images/*.jpg 3. Then DELETE the offending entries in the tables ImageRelations and ImageTags using the imageids from step 1. (Because I edited some images I couldn't simply delete all entries claiming to be an "Original Version", so I looked through them manually, comparing the name or tagid.) For example I used queries like SELECT imageid, name FROM ImageTags LEFT JOIN Images ON Images.id = ImageTags.imageid WHERE name LIKE '20160624%.jpg' AND tagid = 18 to check the database for images of a certain name and the corresponding tagid for "Original Version". Look in the table Tags for tags containing "version" in the name to find out the right tagid: SELECT * FROM Tags WHERE name LIKE'%version%' 4. Close the database and start digikam again. That's it! -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Bugzilla from pdgfellow@gmail.com
https://bugs.kde.org/show_bug.cgi?id=305104
--- Comment #20 from [hidden email] --- If i follow your explaination the dropbox uploader patch file with UUID. Which dropbox tool do you use exactly ? Gilles Caulier -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Bugzilla from pdgfellow@gmail.com
https://bugs.kde.org/show_bug.cgi?id=305104
--- Comment #21 from Johannes <[hidden email]> --- I'm sorry for my writing, English is not my native language. So I don't think that Dropbox is causing that error by adding or changing Exif.Photo.ImageUniqueID . I think some smart phone cameras create these. I just got these photos taken by others with their smart phone via Dropbox. I use the native Dropbox client from https://www.dropbox.com/install for Ubuntu 64bit. It says it has version 9.4.49. I do found other images in my database which I didn't received via Dropbox with not unique Exif.Photo.ImageUniqueID values. They were six characters long so I could select them with: SELECT uuid, name, make, model FROM ImageHistory LEFT JOIN Images ON Images.id = ImageHistory.imageid LEFT JOIN ImageMetadata ON ImageMetadata.imageid = ImageHistory.imageid WHERE uuid LIKE '______' (I don't no how to select entries with an uuid with less then 64 characters.) It turned out that all of these were taken by a Samsung GT-I9300 , Exif.Image.Software I9300XXUGNG3 or Samsung GT-I9400 (Software I9100XWLSD). Can digikam not just ignore the Exif.Photo.ImageUniqueID value? Most images in my collection don't have it. -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Bugzilla from pdgfellow@gmail.com
https://bugs.kde.org/show_bug.cgi?id=305104
--- Comment #22 from [hidden email] --- I think Exif UUID is used to register versionning UUID in Database, if this tag exist in image. To get UUID from metadata : https://quickgit.kde.org/?p=digikam.git&a=blob&f=libs%2Fdmetadata%2Fdmetadata.cpp ... at line 966 The use cases of this method : https://quickgit.kde.org/?p=digikam.git&a=blob&f=libs%2Fdatabase%2Fitem%2Fimagescanner.cpp ... at lines 981 and 1006. Gilles Caulier -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Bugzilla from pdgfellow@gmail.com
https://bugs.kde.org/show_bug.cgi?id=305104
--- Comment #23 from Johannes <[hidden email]> --- Ok, I see. It looks like that the test in https://quickgit.kde.org/?p=digikam.git&a=blob&f=libs%2Fdmetadata%2Fdmetadata.cpp ... at line 966 if (!exifUid.isEmpty() && !exifUid.startsWith(QLatin1String("00000000000000000000"))) is not sufficient, as I have values from Exif.Photo.ImageUniqueID with only 6 characters in the database as ImageHistory.uuid . -- You are receiving this mail because: You are the assignee for the bug. |
Free forum by Nabble | Edit this page |