Performance problem with colorspace conversion in lcms2

Boudewijn Rempt boud at
Wed Oct 2 09:26:43 UTC 2013

On Tuesday 01 October 2013 Oct 22:15:30 Lukast dev wrote:
> Hi all,
> I'm working on Gmic as you know and I hit performance bottleneck
> when converting Krita layers to gmic layers and back and making the whole
> experience for Krita artists quite slow.
> What I'm doing -- converting Krita colorspace uchar 8-bit rgba  to float
> 32-bit rgba.
> I found out that the bottleneck is actually in lcms2
> There is benchmark where is roundtrip conversion rgb8-float-rgb8
> You can run it at
> "build/calligra/krita/plugins/extensions/gmic/tests/KisGmicBenchmark
> testConversion"
> Source:
> calligra/krita/plugins/extensions/gmic/tests/kis_gmic_benchmark.cpp::testConversion()
> From the valgrind log [1] we can see that the bottleneck (98% of time) is in
> KoColorSpace::convertTo
> and there in
> cmsDoTransform
> and there it looks like it is using a lot of math pow, exp per pixel which
> is of course slow.
> For 3840x2400 image it takes 6,5 second to convert from rgba8 to rgba32
> float on my laptop.
> I wrote this hack to convert Krita pixels from rgba8->rgba32 float:
> It takes 120 ms to convert Krita layer to gmic with this hack way, so it's
> 60-times faster.
> Of course it ignores all rendering intends and profile, but I wonder if
> there is some way to tell
> lcms2 to do it stupidly and simply and avoid stuff like: pow, exp1 per
> pixel and cmsEvalToneCurveFloat?

I don't think so -- it's exactly what LCMS is doing. But I think that for G'Mic, a plain scaling of rgb u8 to rgb f32 is actually better than going through lcms and actually converting the colorspace.

That is -- unless G'Mic needs the f32 data in linear format? If that's needed, you really need to use the proper profiles and let lcms do the conversion.

> [1] valgrind log
> Lukas
Boudewijn Rempt,,

More information about the kimageshop mailing list