| Summary: | "Image cannot be loaded" – some images not rendered correctly | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Tim Heymans <tim.heymans> |
| Component: | Preview-Image | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 726494679, caulier.gilles, metzpinguin |
| Priority: | NOR | ||
| Version: | 8.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed In: | 8.2.0 | |
| Attachments: |
screenshot
example image - image rendering correctly example image - image not rendering correctly the 'good' file with the original file name the 'bad' file with the original file name Debug View logs. .jpg files that can't be previewed .jpg files that can't be previewed Screenshot of digikim page |
||
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 |
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