Bug 215009

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.

I tested latest version of the XCF plugin under Windows using a 250GiB XCF image (4 levels) compared with GIMP 2.10.38: the image was opened by the plugin in 3 second. GIMP took the same amount of time.
You need to attach an image that shows the problem.

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!