[Bug 305104] New: Digikam does not show some jpg images in files

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 305104] Digikam does not show some jpg images in files

bugzilla_noreply
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.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 305104] Digikam does not show some jpg images in files

bugzilla_noreply
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.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 305104] Digikam does not show some jpg images in files

bugzilla_noreply
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.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 305104] Digikam does not show some jpg images in files

bugzilla_noreply
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.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 305104] Digikam does not show some jpg images in files

bugzilla_noreply
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.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 305104] Digikam does not show some jpg images in files

bugzilla_noreply
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.
12