On digikam 7.0.0-rc, is not possible to see the thumbnail and also the image from Krita 2.3.0 (.kra), but if the same file is saved with Krita 2.2.9, everything its ok. STEPS TO REPRODUCE 1. Add some file saved with Krita 2.3.0 on digikam 2. No thumbnail and image visualization 3. Add the same file as before but saved with Krita 2.2.9 4. Everything should be ok with it OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: Windows 10 2004 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
The file format hasn't changed, though since 4.2.8 or 4.2.9 we use quazip instead of karchive to save .kra files. But in any case, when checking a large number .kra files, it didn't make much difference which version of Krita a file was created with; sometimes kimageformats could load the file, sometimes it couldn't. I suspect that Digikam uses frameworks-kimageformats to open the files, just like gwenview does.
Hi Boudewijn, yes, digiKam can use KImageFormat Qt::Image plugins to load/preview/thumbnails of extra file formats. It's the case of KRA and ORA images. See the older report about this topic: https://bugs.kde.org/show_bug.cgi?id=301543 The Q is: How KImageFormat work with .KRA files ? Did it use a dedicated loader shared with Calligra & co ? As i can seen, there is no KRA loader code in KImageFormat... Best Gilles Caulier
See also bug 423547.
There is a kra loader in kimageformats: https://invent.kde.org/frameworks/kimageformats/-/blob/master/src/imageformats/kra.cpp (and an ora loader). The way it works is, it takes the mergedimage.png file from the zip file (a kra file is a zip file).
*** Bug 423547 has been marked as a duplicate of this bug. ***
Note that we changed our zip library from kzip to quazip, which is likely the reason for the problem. kzip cannot handle 64 bit zip files.
*** Bug 301543 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 362999 ***