I just noticed that not all .jpg images are shown in photo files although the total number of images shown although the count in the tree view is correct. The images had the suffix .JPG (Upper case) and when I manually renamed two of them to .jpg (lower case) their thumbnails appeared. I tried a batch rename of all of them to .jpg but they still did not appear. I have moved the images to other files and they do not appear. I have done re-scans and the images thumbnails do not appear. I have checked permissions and they are the same as other (viewable) images GwenView shows the images correctly.
This is a binary compatibility issue with digiKam KIO slave on your system : It's typically a packaging problem with dependencies... Update digiKam to last 2.8.0 and try again... Gilles Caulier
I have the same issue with Version 2.8.0. I use the MYSQL database, in which alle the images are listed for the folder in which I have the problem (with jpg and JPG extensions which corresponds to the file name extension) . Also they are all present in the folder (as I see in a terminal), but the files with JPG don't show up in the Album preview for this folder In other folders, where I have images with upper case JPG ending, the images show up, so I don't know what's different in this specific folder. I Use: digikam/quantal uptodate 4:2.8.0-0ubuntu1 digikam-data/quantal uptodate 4:2.8.0-0ubuntu1 libkface-data/quantal uptodate 1.0~digikam2.8.0-0ubuntu1 libkface1/quantal uptodate 1.0~digikam2.8.0-0ubuntu1 libkgeomap-data/quantal uptodate 1.0~digikam2.8.0-0ubuntu1 libkgeomap1/quantal uptodate 1.0~digikam2.8.0-0ubuntu1 libkvkontakte1/quantal uptodate 1.0~digikam2.8.0-0ubuntu1 libmediawiki1/quantal uptodate 1.0~digikam2.8.0-0ubuntu1
Did you edit them with the digikam image editor, hiding the original?
(In reply to comment #3) > Did you edit them with the digikam image editor, hiding the original? I guess you are refering to the non-destructive image manipulation. I didn't edit the picture. I did some further test, an in a new image folder it is no problem to have jpg/JPG files. I guess there is something mixed up in the Database, also I could not find differences in the images / imageinformation tables in the pictures showing up or not showing up. However, when I moved all images from the folder to another place (on a terminal), and then back, the missing images reappeared. In the "image" Table they have a new id Still, I have the problem that I don't know if images in other folders are not shown our found by refreshing.
I'm having the same problem with some JPG images not showing up in Digikam. The images in question used to show up, because they have tags that I added using Digikam. digiKam Version 2.5.0 Using KDE Development Platform 4.8.5 (4.8.5) Ubuntu 12.04.1 LTS Unity 5.18
If I check: Settings → Configure digiKam → Editing Images → Always show original images, the missing images appear. The Image HIstory bar shows a mess of Derived Images and Identical Images that are neither derived nor identical.
Is there a pattern how to reproduce this situation? Do you remember how you saw this first?
Unfortunately, I don't know when or how the problem started. I just noticed the images were missing in Thumbnails view, but I'm sure the problem went unnoticed for awhile.
To all in this file : This problem still exists with digiKam 3.5.0 ? Gilles Caulier
Have not see the problem lately and I have been working with local and network files so I think the bug has been killed. Thank You Mac On 13-12-04 09:30 AM, Gilles Caulier wrote: > https://bugs.kde.org/show_bug.cgi?id=305104 > > --- Comment #9 from Gilles Caulier <caulier.gilles@gmail.com> --- > To all in this file : > > This problem still exists with digiKam 3.5.0 ? > > Gilles Caulier >
The problem still exists with: Qt: 4.8.6 KDE Development Platform: 4.14.9 digiKam: 4.6.0 by checking: Settings → Configure digiKam → Editing Images → Always show original images, the missing images appear, as previously described.
I have the problem too. Interestigly, the "Table" view mode is not affected, only thumbnails and preview. The "versioning" sidebar also show some pictures with tons of "identical images" that are not identical _at all_. Like an Aquarium image from Akademy 2015 daytrip is identical to a camp file from Randa.
Encountered this problem in digikam Version 3.5.0 with KDE 4.13.3 on Ubuntu 14.04.05 LTS. Status of this bug is resolved as FIXED in Version 4.0.0 but Juraj #c11said on 2015-07-13 15:53:34 UTC that the problem still exists with digiKam: 4.6.0. Any news about that?
How do I fix the "mess of Derived Images and Identical Images that are neither derived nor identical"? Is this possible to do within digikam? Or do I have to use a command line tool to remove the non identical images? And how do I do that? Thank you very much!
I did the following, awhile back, on linux. Not sure what may have changed in the interim, and I can't speak for non-linux platforms, so YMMV. FIRST, BACK UP YOUR DATABASE! Make sure digikam is not running. Go into digikam4.db using sqliteman and drop and re-created the imagerelations table. Re-start digikam. I don't remember if there's a tool that you have to run manually, or if it runs automatically, but it should recreate correct image relations. May take awhile depending on the size of your albums. I hope this helps. Please post your results for others.
Given I just **deleted** the database and started from scratch and still have the issue, I would argue that the bug isn't fixed, it never was and it still fully there as of Digikam 5.1
I forgot to say in my comment 13 that I encountered that problem in only one album which is a folder synced with the Dropbox client after editing an image. It looks like bug 323210 is a duplicate of this one, maybe someone with the permission can set this and maybe also edit the summary of this bug to something like “Digikam does not show some jpg images because assigned wrong identical/derived images”. What I tried to fix the problem: I deleted the wrong data sets (I had 21 entries for one subject with different objects, type 1 and the same objects also for another subject - 42 wrong entries in total) and later cleared the table ImageRelations - also with no success. The images still have the wrong identical images assigned. The cleared table is still empty. So these information has to be stored elsewhere - but where? I couldn't find a corresponding XMP entry in these images with neither exiv2 nor exiftool. Tools -> Maintenance -> Sync Metadata and Database -> Sync direction: From database to image metadata seems to be useful, but in the settings no checkbox looks like the right one.
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
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!
If i follow your explaination the dropbox uploader patch file with UUID. Which dropbox tool do you use exactly ? Gilles Caulier
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.
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
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 .