Version: 1.0.0-rc (rev.: 1050601) (using 4.3.2 (KDE 4.3.2), Debian packages) Compiler: cc OS: Linux (i686) release 2.6.31-5.slh.4-sidux-686 I've got an .xcf file here, size about 130 MB. When I hit it in Album View it takes perhaps half a minute to generate the preview image. Meanwhile I'm able to change the selected image in the overview bar, but the image shown does not change as long as the .xcf preview is being generated. Now it would be nice if either the newly selected previews are being shown nevertheless (perhaps abort the rendering process for the .xcf, if necessary) or, even better, just do it faster. The same file opens in 3 seconds in GIMP, so it shouldn't be impossible, I hope :)
Digikam itself has no support for XCF. There is a KImgIO plugin that provides support via QImage, but loading with QImage does not support interruption (nor progress info). So the only fix would be to write our own XCF loader.
Agree. This problem must be fixed in XCF KImgIO loader from KDE core. I move this file at the right place... Gilles Caulier
SVN commit 1172674 by cfeck: Optimize XCF loader (part 1) Optimize assignImageBytes() and assignMaskBytes() * replace setPixel() with direct image data manipulation * use memcpy when possible * move function calls out of loops (except for the GRAYA/INDEXEDA case) CCBUG: 215009 M +44 -19 xcf.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1172674
SVN commit 1172678 by cfeck: Optimize XCF loader (part 2) * only initialize random_table when needed * remove dead/commented add_lut table CCBUG: 215009 M +17 -12 xcf.cpp M +1 -0 xcf.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1172678
SVN commit 1172686 by cfeck: Optimize XCF loader (part 3) Optimize color table assignments for indexed and grayscale images. This also means the palettes are shared between all tiles, resulting in a minor memory saving. CCBUG: 215009 M +12 -4 xcf.cpp M +6 -0 xcf.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1172686
SVN commit 1172712 by cfeck: Optimize XCF loader (part 4) Optimize copyLayerToImage() and mergeLayerToImage() for the common case of RGB(A) data with no mask, simple layer opacity, and "normal" layer blending mode. Using QPainter compositing operations allows us to benefit from optimizations done in the Qt composition code, such as MMX and SSE code paths. It is probably possible to also use QPainter operations for many other layer blending modes. CCBUG: 215009 M +20 -0 xcf.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1172712
Simon, if you still have that monstrous GIMP file, could you test the performance after my commits to trunk? As long as that image does not use advanced layer merging modes, it should load much faster. Thanks in advance.
53 MB file: 10 s with digikam (I tested it by changing the file in GIMP, saving it, and then immediately opening it in digikam) 3 s with GIMP with all layers visible. Invisible layers do not seem to count (a 10 layer image with about 150 MB, 2 of them visible, took around 7 s to load). So yes, seems to have improved around 300 % :)
Thanks for the update, Simon. I guess there is still room for more optimizations, such as avoiding assignImageBytes() by directly decompressing into the image buffers.
Additionally, some XCF files might have embedded thumbnails (the XCF loader refers to them as part of a resolution "hierarchy"). Qt supports scaled loading, so implementing that could result in nice speedups. But I am not sure if GIMP always writes out multiple levels of that hierarchy, so adding code to support them might be wasted.