Summary: | Krita & digikam | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | ebm2003rkm |
Component: | File formats | Assignee: | Krita Bugs <krita-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | caulier.gilles, danni.coy, halla, maxim.sheronov |
Priority: | NOR | ||
Version: | 4.3.0 | ||
Target Milestone: | --- | ||
Platform: | Microsoft Windows | ||
OS: | Microsoft Windows | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
ebm2003rkm
2020-06-29 02:49:49 UTC
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 *** |