Created attachment 119142 [details] Corrupted thumbnail on miniature view SUMMARY Some pictures show a corrupted thumbnail. Maybe one every 100 or less. They all look like a video thumbnail with TV static noise in it, although they all are a bit different from each other. See attached picture as a sample. These pictures can be correctly opened in digikam and other picture viewers, and all the metadata seem to be correct, there are no signs of corruption anywhere. Re-reading the metadata from file to recreate the thumbnail does nothing. Adding and removing a tag from the metadata seems to work in some cases, but not others, to restore the original thumbnail. I am in a high-latency network, so I am suspecting that these files were edited at some point and due to the high-latency there was some kind of problem and the thumbnail could not be generated correctly. But that wouldn't explain why re-reading the metadata does not restore it. I repeatedly get this error on the console, but I don't know if it has anything to do with it, it appears regardless of the image: Cannot open workspace color profile "/tmp/.mount_digikasDTsw0/usr/share/digikam/profiles/srgb-d65.icm" I am using digikam-6.1.0-git-20190325T162715.appimage in Ubuntu 18.04 with Gnome.
I already seen this kind of dysfunction, rarely but... Typically, a JPEG image is not well recognized as JPEG, and thumbnailer try other renderer : raw decoder, and ffmpeg. This last one is the result of your corrupted image. Look the film-gram on the left and right side. Running digiKam from a console and forcing to render all thumbs from scrach can be interesting. Gilles Caulier
Can the thumbnail renderer be changed in the settings?
No you cannot, the thumbnail generator workflow is hard-coded... Gilles Caulier
Created attachment 123067 [details] Another example (This issue was quite prominent on a few pictures I scanned yesterday)
This happens when Exiv2 can not extract a thumbnail and the image loader fails. In the last attempt, the video thumbnailer is still being tried. These images must be broken, unreadable or similar. Maik
I don't think it's the images' fault. Sometimes, changing some metadata and forcing digikam to rebuild the thumbnails corrects it. Also, it does not happen for the same pictures in two different computers (or even the exact same picture in two different folders produce different results). Moreover, I believe this is not an issue that happened before digikam 6.1. I suspect it might have to do with the system being too busy to generate the thumbnail (because it's doing other stuff), so it times out and a corrupted thumbnail is displayed instead.
No, even if digiKam is busy the behavior can not arise. I have special images that cause the behavior for testing purposes. The video thumbnailer is the last attempt, he would also create a thumbnail with JPG, with filmstrip. I think that your images can not be read temporarily and are even broken in the disk cache. Normally I can not reproduce this behavior, not even on my relatively slow router NAS (FritzBox with a large USB stick). Maik
I just tried that same picture album in another computer, with the same digikam version (digikam-6.4.0-git-20191005T120037-x86-64.appimage) and none of the images showed this issue. So it's most likely not related to the pictures themselves. Since the computer where I most experience this issue accesses the albums via internet, through a VPN (but keeping the database local), could it be related to the connection speed and/or latency? The internet connection is 100/100mbps, with a latency around 40ms.
I can reproduce the problem very confidently on a Windows7 computer in my company. Namely when a new collection is added or you start with an empty DB and the thumbnails are created on the first scan. Later with F5 the problem does not occur anymore. There are no error messages, but loading the thumbnail via DImg must generate a NULL image. Maik
Git commit 20dbf8abadbeac5cc093e8283f0e105c9d763be5 by Maik Qualmann. Committed on 14/10/2019 at 19:35. Pushed by mqualmann into branch 'master'. try revert a older commit M +4 -4 core/libs/threadimageio/engine/managedloadsavethread.cpp https://invent.kde.org/kde/digikam/commit/20dbf8abadbeac5cc093e8283f0e105c9d763be5
@Gilles, would be nice if you could create a new windows package. My MXE is too old, I have to create again. Maik
Hum, i recreate the Windows bundles yesterday. I will run the script this evening. I'm not in my office for 4 days. Gilles
Windows 6.4.0 pre-release installers are just published at usual place: https://files.kde.org/digikam/ Gilles Caulier
Problem is still to reproduce. Maik
Git commit b3f3c26b5ebfadd804e097162f9e4fedbbaa2388 by Maik Qualmann. Committed on 17/10/2019 at 06:12. Pushed by mqualmann into branch 'master'. add test debug M +1 -0 core/libs/dimg/dimg_fileio.cpp https://invent.kde.org/kde/digikam/commit/b3f3c26b5ebfadd804e097162f9e4fedbbaa2388
Git commit 3397546f18a0f15bf8dfecb049f6032e4bcb73d1 by Maik Qualmann. Committed on 17/10/2019 at 20:24. Pushed by mqualmann into branch 'master'. do not try video thumbnail from image type M +2 -3 core/libs/threadimageio/thumb/thumbnailcreator_engine.cpp https://invent.kde.org/kde/digikam/commit/3397546f18a0f15bf8dfecb049f6032e4bcb73d1
Git commit 27f663c1155498c03c174ce93d7c94e69d77489a by Maik Qualmann. Committed on 19/10/2019 at 16:28. Pushed by mqualmann into branch 'master'. review loading tasks Related: bug 399923 M +42 -37 core/libs/threadimageio/fileio/loadsavetask.cpp M +49 -46 core/libs/threadimageio/preview/previewtask.cpp M +1 -1 core/libs/threadimageio/thumb/thumbnailcreator_engine.cpp M +41 -40 core/libs/threadimageio/thumb/thumbnailtask.cpp https://invent.kde.org/kde/digikam/commit/27f663c1155498c03c174ce93d7c94e69d77489a