SUMMARY Several images don't load as expected. In the main view there is no thumbnail but just a green icon (see screenshot). When double clicking the image, a larger preview isn't loaded either. SPECIFICS This is all the more surprising since often I have "doubles" in my library, one the normal image, the second one a copy with a large chunk of text in the XMP metadata ('title' field). This goes well most of the time... But in a number of cases the bug appears and the image containing the metadata is not readable. NOTE: I checked in other DAM software and the problem really lies with Digikam. XnViewer for example can read the supposedly 'defective' file perfectly! Don't know what to think of this... SOFTWARE/OS VERSIONS Windows 10 64 bit ADDITIONAL INFORMATION
Created attachment 158696 [details] screenshot
Created attachment 158697 [details] example image - image rendering correctly
Created attachment 158698 [details] example image - image not rendering correctly
What's DebugView report as debug trace from digiKam when you want to display the problematic images ? See more details about to capture debug traces under Windows here : https://www.digikam.org/contribute/ Gilles Caulier
Your sample images can be shown properly under Linux. Ther is no huge title metadata in your problematic JPEG sample, just a number. Did you use XMP side car ? Gilles Caulier
You may have confused something, the image "image 1 - rendered correctly.jpg" contains the large description text. But both images are displayed without problems on my 3 Windows test systems (Windows 10 in VM, Windows7 and Windows10 on real machines). So we absolutely need the DebugView Log. Maik
@Tim Heymans we needs a debugview trace to help you, as Maik said in previous comment. See here for details : https://www.digikam.org/contribute/
Created attachment 159230 [details] the 'good' file with the original file name
Created attachment 159231 [details] the 'bad' file with the original file name
Hello, sorry to keep you all waiting. I'm trying to get DebugView working just now. We'll see how far I get. In the meantime I uploaded the two example files with their original file names - in case that might have something to do with it. File names are rather long, I admit. Not sure if that could cause trouble.
Created attachment 159232 [details] Debug View logs.
The files cannot be found, I see characters in the path that I assume are not allowed. I'm testing it tonight. Maik
Both sample files have no problems under Windows10 due to the file names. But I see a question mark "?" in your path, this is definitely a forbidden character under Windows. I can't create such a directory with Windows Explorer either. Maik
Hello Maik, there is no question mark in the file path, it is a "‽" symbol. It's a combination of a question mark and an exclamation mark; it has a fancy name, but I forgot what it is. Important: this character is perfectly accepted in Windows in folders and file names (so I use it as a workaround whenever I need a question mark). Cheers, Tim
'?' is forbided. https://stackoverflow.com/questions/1976007/what-characters-are-forbidden-in-windows-and-linux-directory-names
Gilles, like I said, it is NOT a question mark. Please read carefully and mark the difference between "?" and "‽". 🙂
I also repeat that XnViewer – another DAM – has no issues reading the same files, with the same metadata and the same file paths.
Ok, a test here under Windows in a VM shows everything with this character "‽": Exiv2 cannot process this and produces a file not found error. ExifTool can handle this character, so we have metadata in the view. Our JPEG loader can handle the character and will display an image with such a path with no problem. The fact that some images are still not displayed is because you sometimes exceed the maximum file path of 255 characters (I counted 278 characters for a path). I don't think we can do a workaround for the API that libjpeg uses. Maik
Note : Windows use UTF16 instead UF8 under Linux. Exiv2 can handle UTF16 with dedicated native API when cmake flag is turned on (activated with Windows build): https://invent.kde.org/graphics/digikam/-/blob/master/project/bundles/3rdparty/ext_exiv2/CMakeLists.txt#L41 But, remember that digiKam is cross compiled with MinGW. So I don't know the state of the Windows API corresponding in the cross-compiler... Gilles
@Tim, are you using SQLite or MySQL? I haven't checked, it's possible that the character isn't supported by the 3 bytes UTF-8 in MySQL. See Bug 469310 Maik
Hello Maik, I'm using SQLite since my library isn't that big.
So basically, the problem is that my file paths are too big, is that it? 🙄
we suspect that... yes. I already experienced this kind of problem on my Windows computer in my office with path largest than 220 characters. It's not 100% reproducible al the time, but it's a good idea to reduce path size, at least to experiment. Gilles Caulier
Bad news, Unicode support is broken in Exiv2-0.28. I can confirm it under Windows with file names that still worked under Exiv2-0.27.x. We don't notice it immediately, because from digiKam-8.0.0 onwards we read the metadata with ExifTool if there are problems in Exiv2. See bug report: https://github.com/Exiv2/exiv2/issues/2637 Maik
Git commit 37c680073ffa9ac53e056c71dd8fbc0b7178c455 by Gilles Caulier. Committed on 06/06/2023 at 08:37. Pushed by cgilles into branch 'master'. under Windows, we needs to use 0.27-maintenance branch for the moment. Related: bug 470566 M +2 -2 project/bundles/3rdparty/ext_exiv2/CMakeLists.txt https://invent.kde.org/graphics/digikam/-/commit/37c680073ffa9ac53e056c71dd8fbc0b7178c455
Created attachment 161373 [details] .jpg files that can't be previewed I have some .jpg files that I can't preview and open either, and changing the filename doesn't help!
Created attachment 161374 [details] .jpg files that can't be previewed
Created attachment 161375 [details] Screenshot of digikim page
@Tim, This problem still reproducible with the new digiKam 8.2.0 pre-release Windows installer available at usual place: https://files.kde.org/digikam/ This new bundle is based on last Qt framework 5.15.11 and KDE framework 5.110. Thanks in advance Gilles Caulier
(In reply to caulier.gilles from comment #29) > @Tim, > > This problem still reproducible with the new digiKam 8.2.0 pre-release > Windows > installer available at usual place: > > https://files.kde.org/digikam/ > > This new bundle is based on last Qt framework 5.15.11 and KDE framework > 5.110. > > Thanks in advance > > Gilles Caulier Hi Gilles, I updated to the new version and it seems the issue has been resolved! 🙂 Thanks a bunch to you and the whole team! ♥ Cheers, Tim