[digikam] [Bug 375483] Wrong history on images taken with Samsung S3 [patch]
https://bugs.kde.org/show_bug.cgi?id=375483
--- Comment #15 from Gernot Hillier <ger...@hillier.de> ---
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= ". 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...
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 375483] Wrong history on images taken with Samsung S3 [patch]
https://bugs.kde.org/show_bug.cgi?id=375483 Gernot Hillier <ger...@hillier.de> changed: What|Removed |Added CC||ger...@hillier.de --- Comment #14 from Gernot Hillier <ger...@hillier.de> --- 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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 354819] Specific pictures not showing up in digikam
https://bugs.kde.org/show_bug.cgi?id=354819 --- Comment #16 from Gernot Hillier <ger...@hillier.de> --- We should probably continue discussion in bug 375483, so that others can find this information, too, right? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 354819] Specific pictures not showing up in digikam
https://bugs.kde.org/show_bug.cgi?id=354819 --- Comment #14 from Gernot Hillier <ger...@hillier.de> --- Ok, I'm one large step ahead: all problematic images are internally tagged as "Original Version" despite I surely never edited those files: sqlite> select * from ImageTags where imageid in (93042); 93042|112 sqlite> select * from Tags where id=112; 112|110|Original Version|0| I can either delete the wrong internal tag: delete from ImageTags where imageid in (select id from Images where name="20170907_102007.jpg"); or enable the "always show original version" setting in digikam. My theory: During initial import from the Samsung smartphone, the files had the non-unique ImageUniqueID in EXIF data which Samsung deliberately uses to confuse people. Due to importing several files with the same unique ID, digikam somehow internally thought they are related and tagged some of them internally as "original version". Now, we could do what we want: manually change/remove EXIF ImageUniqueID field, internally create own uniqueIDs for it, moving the file away and back to digikam folders - this would never remove the internal originalVersion tag again. Is it possible that those pictures received this flag because they -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 354819] Specific pictures not showing up in digikam
https://bugs.kde.org/show_bug.cgi?id=354819 --- Comment #13 from Gernot Hillier <ger...@hillier.de> --- (In reply to Maik Qualmann from comment #11) > Can you provide a test image from this smartphone? > > Maik I already attached it, see attachment 109454. Do you need further images? Unfortunately, this Heisen-bug isn't 100% reproducible, but if it helps I can add more examples to this bug or put them on my website. Thanks for CC'ing https://commits.kde.org/digikam/9a59b9d72b4d7606cf2bdb52be12a91fd22dbf21, but you don't expect this to fix my bug, do you? I always add XMP:Creator to my pictures, so this commit shouldn't change anything for me, if I'm not mistaken. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 354819] Specific pictures not showing up in digikam
https://bugs.kde.org/show_bug.cgi?id=354819 --- Comment #10 from Gernot Hillier <ger...@hillier.de> --- Just to make this clear: touching a problematic file while digikam is running leads to a rescan and the file is found according to debug output (see my last comment), but it still does NOT appear in the UI. I enabled "Rescan file when files are modified" in the metadata settings as suggested in bug 375483. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 354819] Specific pictures not showing up in digikam
https://bugs.kde.org/show_bug.cgi?id=354819 --- Comment #9 from Gernot Hillier <ger...@hillier.de> --- Unfortunately, 5.8.0 pre-release as of today does NOT fix the issue for me. I still have photos which are not shown by digikam. Also, I don't think this is directly connected to bug 375483 any more. Even removing the uuid (exiftool -ImageUniqId= ) doesn't change anything. So far I found no rule when those files are visible in digikam and when not. With 5.7, I even had the same file (identical md5sum) twice under two different names in test directory "aa", one was visible, the other not. When moving them to another folder they both disappeared. So far, it seems this does only affect photos taken by my Samsung smartphone. So there's probably another weirdness in the way Samsung creates JPGs. When touching a visible and an invisible photo while digikam is running, stdout with 5.8 looks nearly identical: invisible file: digikam.general: Detected change, triggering rescan of "/home/gernot/sync/digibilder/to_sort/2017-08-xx Familie Landshut/" digikam.database: Starting scan! digikam.dimg: "/home/gernot/sync/digibilder/to_sort/2017-08-xx Familie Landshut/20170824_094516.jpg" : JPEG file identified digikam.metaengine: DateTime => Exif.Photo.DateTimeOriginal => QDateTime(2017-08-24 09:45:16.000 CEST Qt::TimeSpec(LocalTime)) digikam.metaengine: DateTime (Exif digitalized): Do. Aug. 24 09:45:16 2017 digikam.metaengine: Orientation => Exif.Image.Orientation => 6 digikam.metaengine: "/home/gernot/sync/digibilder/to_sort/2017-08-xx Familie Landshut/20170824_094516.jpg" ==> Read Iptc Keywords: () digikam.metaengine: Loading image history "" digikam.database: Scanning took 3 ms digikam.database: Finishing took 36 ms digikam.dimg: "/home/gernot/sync/digibilder/to_sort/2017-08-xx Familie Landshut/20170824_094516.jpg" : JPEG file identified digikam.metaengine: Orientation => Exif.Image.Orientation => 6 visible file: digikam.general: Detected change, triggering rescan of "/home/gernot/sync/digibilder/to_sort/2017-08-xx Familie Landshut/" digikam.database: Starting scan! digikam.dimg: "/home/gernot/sync/digibilder/to_sort/2017-08-xx Familie Landshut/20170824_091250.JPG" : JPEG file identified digikam.metaengine: DateTime => Exif.Photo.DateTimeOriginal => QDateTime(2017-08-24 09:12:50.000 CEST Qt::TimeSpec(LocalTime)) digikam.metaengine: DateTime (Exif digitalized): Do. Aug. 24 09:12:50 2017 digikam.metaengine: Orientation => Exif.Image.Orientation => 1 digikam.metaengine: "/home/gernot/sync/digibilder/to_sort/2017-08-xx Familie Landshut/20170824_091250.JPG" ==> Read Iptc Keywords: () digikam.metaengine: Loading image history "" digikam.database: Scanning took 6 ms digikam.database: Finishing took 38 ms digikam.dimg: "/home/gernot/sync/digibilder/to_sort/2017-08-xx Familie Landshut/20170824_091250.JPG" : JPEG file identified digikam.dimg: "/home/gernot/sync/digibilder/to_sort/2017-08-xx Familie Landshut/20170824_091250.JPG" : JPEG file identified digikam.metaengine: Orientation => Exif.Image.Orientation => 1 digikam.metaengine: Orientation => Exif.Image.Orientation => 1 The only difference is that "JEPG file identified" and the "Orientation" are printed *three* times for a working file while they are only printed *two* times for a file which is not shown in the UI. Does that somehow ring a bell for you? Any further idea how I could narrow down this issue? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 354819] Specific pictures not showing up in digikam
https://bugs.kde.org/show_bug.cgi?id=354819 --- Comment #7 from Gernot Hillier <ger...@hillier.de> --- Ok, after checking the digikam debug output on stdout, I found that digikam says this when the problematic image is added: digikam.database: Recognized "/home/gernot/sync/digibilder/to_sort/aa/testcase.jpg" as identical to item 94617. So, I'm likely hit by #375483. My smartphone producing those images is a Galaxy S5 and all images have the same ImageUniqueID. As the initial sample picture from Andreas in this report has no ImageUniqueID, my problem is likely distince and I probably shouldn't have added my issue here, sorry. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 354819] Specific pictures not showing up in digikam
https://bugs.kde.org/show_bug.cgi?id=354819 --- Comment #6 from Gernot Hillier <ger...@hillier.de> --- Created attachment 109454 --> https://bugs.kde.org/attachment.cgi?id=109454=edit testcase for picture missing from preview list Test picture, can be displayed with gthumb, dolphin, GIMP, etc. without problems, but digikam 5.7 on OpenSUSE 42.3 refuses to show it in the preview list. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 354819] Specific pictures not showing up in digikam
https://bugs.kde.org/show_bug.cgi?id=354819 Gernot Hillier <ger...@hillier.de> changed: What|Removed |Added CC||ger...@hillier.de --- Comment #5 from Gernot Hillier <ger...@hillier.de> --- I have a similar issue since several digikam releases including 5.7. I'm running it on OpenSUSE 42.3. It seems only pictures taken with my smartphone SM-G900FD are affected. Sometimes, it helps to rename the problematic photos, but with the image attached here as "testcase.jpg", the problem persists, independent of filename. When I copy it in a new directory, this just looks like an empty album in Digikam. When I copy it in an existing album, digikam will show all other photos, but not "testcase.jpg". -- You are receiving this mail because: You are watching all bug changes.
