[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Performance problem with colorspace conversion in lcms2
From:       Lukast dev <lukast.dev () gmail ! com>
Date:       2013-10-01 20:15:30
Message-ID: CAKdU0rNXPpWD_niHAOCQNGSmoh+Tdm2JAPPX52ERCBY+hfCo+A () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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:
http://paste.kde.org/p19eeee78/

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?

[1] valgrind log
https://www.dropbox.com/s/wvazoys09p0ujtb/callgrind-convert-to.tgz

Lukas

[Attachment #5 (text/html)]

<div dir="ltr">Hi all,<div><br></div><div>I&#39;m working on Gmic as you know and I \
hit performance bottleneck</div><div>when converting Krita layers to gmic layers and \
back and making the whole </div><div>experience for Krita artists quite slow.</div> \
<div><br></div><div>What I&#39;m doing -- converting Krita colorspace uchar 8-bit \
rgba  to float 32-bit rgba.</div><div>I found out that the bottleneck is actually in \
lcms2<br></div><div><br></div><div>There is benchmark where is roundtrip conversion \
rgb8-float-rgb8<br> </div><div>You can run it \
at<br></div><div><div>&quot;build/calligra/krita/plugins/extensions/gmic/tests/KisGmicBenchmark \
testConversion&quot;</div></div><div><br></div><div>Source: \
calligra/krita/plugins/extensions/gmic/tests/kis_gmic_benchmark.cpp::testConversion()<br>
 </div><div><br></div><div><div>From the valgrind log [1] we can see that the \
bottleneck (98% of time) is \
in</div></div><div><br></div><div>KoColorSpace::convertTo</div><div>and there in \
</div><div>cmsDoTransform </div><div> <br></div><div>and there it looks like it is \
using a lot of math pow, exp per pixel which is of course slow. </div><div>For \
3840x2400 image it takes 6,5 second to convert from rgba8 to rgba32 float on my \
laptop.</div><div> <br></div><div>I wrote this hack to convert Krita pixels from \
rgba8-&gt;rgba32 float:<br></div><div><div><a \
href="http://paste.kde.org/p19eeee78/">http://paste.kde.org/p19eeee78/</a><br></div></div><div><br></div><div>It \
takes 120 ms to convert Krita layer to gmic with this hack way, so it&#39;s 60-times \
faster.<br> </div><div><br></div><div>Of course it ignores all rendering intends and \
profile, but I wonder if there is some way to tell</div><div>lcms2 to do it stupidly \
and simply and avoid stuff like: pow, exp1 per pixel and cmsEvalToneCurveFloat?</div> \
<div><br></div><div><div>[1] valgrind log <a \
href="https://www.dropbox.com/s/wvazoys09p0ujtb/callgrind-convert-to.tgz">https://www. \
dropbox.com/s/wvazoys09p0ujtb/callgrind-convert-to.tgz</a></div></div><div><br></div><div>
 Lukas</div></div>



_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


[prev in list] [next in list] [prev in thread] [next in thread]