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

List:       kde-kimageshop
Subject:    Re: Performance problem with colorspace conversion in lcms2
From:       Lukast dev <lukast.dev () gmail ! com>
Date:       2013-10-10 8:15:44
Message-ID: CAKdU0rODXkSPxu+BZ3fZ2iXeMJPtkmWy9=zb8mHBGEc0bpZjHg () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Hi Dmitry,

I fixed the performance problem in this commit [1]

Basically I inspired myself by sahil's code in filters where he scales to
float colorspace.
In that case lcms2 is not needed. But I wonder if it is possible to use
lcms2 just to scale
to different color-depth without using expensive curve fitting etc.

I will check KoStreamedMath though. But the performance is really good now,
see the commit message
with numbers

[1]
http://quickgit.kde.org/?p=calligra.git&a=commit&h=932980c140d2519d5569783154e283ef197f15f9

Lukas


2013/10/9 Dmitry Kazakov <dimula73@gmail.com>

> Hi, Lukas!
>
> I just wanted to tell you that the KoStreamedMath class internally has
> methods for converting a bunch of rgba8 pixels into rgbaf32. This is used
> inside SSE/AVX1 code to do the trick. So theoretically, you can reuse these
> methods as well.
>
> And I'm agree with Boud, that for usual RGB images you needn't do a color
> conversion using lcms and can scale and pass the image to the gmic directly.
>
>
>
> On Wed, Oct 2, 2013 at 5:03 PM, Lukast dev <lukast.dev@gmail.com> wrote:
>
>> Linear format is not needed for gmic.
>>
>> Do you have suggestions how to implement it correctly for all possible
>> colorspace formats
>> that we currently support?
>>
>> And where does this plain scaling belongs to? Pigment?
>>
>> Lukas
>>
>>
>> 2013/10/2 Boudewijn Rempt <boud@valdyas.org>
>>
>>> 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:
>>> > 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?
>>>
>>> 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
>>> > https://www.dropbox.com/s/wvazoys09p0ujtb/callgrind-convert-to.tgz
>>> >
>>> > Lukas
>>> --
>>> Boudewijn Rempt
>>> http://www.valdyas.org, http://www.krita.org,
>>> http://www.boudewijnrempt.nl
>>>
>>> _______________________________________________
>>> Krita mailing list
>>> kimageshop@kde.org
>>> https://mail.kde.org/mailman/listinfo/kimageshop
>>>
>>
>>
>> _______________________________________________
>> Krita mailing list
>> kimageshop@kde.org
>> https://mail.kde.org/mailman/listinfo/kimageshop
>>
>>
>
>
> --
> Dmitry Kazakov
>
> _______________________________________________
> Krita mailing list
> kimageshop@kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
>

[Attachment #5 (text/html)]

<div dir="ltr">Hi Dmitry, <div><br></div><div>I fixed the performance problem in this \
commit [1]</div><div><br></div><div>Basically I inspired myself by sahil&#39;s code \
in filters where he scales to float colorspace.</div> <div>In that case lcms2 is not \
needed. But I wonder if it is possible to use lcms2 just to scale</div><div>to \
different color-depth without using expensive curve fitting \
etc.</div><div><br></div><div>I will check KoStreamedMath though. But the performance \
is really good now, see the commit message</div> <div>with \
numbers</div><div><br></div><div>[1] <a \
href="http://quickgit.kde.org/?p=calligra.git&amp;a=commit&amp;h=932980c140d2519d55697 \
83154e283ef197f15f9">http://quickgit.kde.org/?p=calligra.git&amp;a=commit&amp;h=932980c140d2519d5569783154e283ef197f15f9</a></div>
 <div><br></div><div>Lukas</div></div><div class="gmail_extra"><br><br><div \
class="gmail_quote">2013/10/9 Dmitry Kazakov <span dir="ltr">&lt;<a \
href="mailto:dimula73@gmail.com" \
target="_blank">dimula73@gmail.com</a>&gt;</span><br> <blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
dir="ltr"><div><div>Hi, Lukas!<br><br></div>I just wanted to tell you that the \
KoStreamedMath class internally has methods for converting a bunch of rgba8 pixels \
into rgbaf32. This is used inside SSE/AVX1 code to do the trick. So theoretically, \
you can reuse these methods as well.<br>

<br></div>And I&#39;m agree with Boud, that for usual RGB images you needn&#39;t do a \
color conversion using lcms and can scale and pass the image to the gmic \
directly.<br><br></div><div class="gmail_extra"><div><div class="h5"> <br><br><div \
class="gmail_quote"> On Wed, Oct 2, 2013 at 5:03 PM, Lukast dev <span \
dir="ltr">&lt;<a href="mailto:lukast.dev@gmail.com" \
target="_blank">lukast.dev@gmail.com</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">

<div dir="ltr">Linear format is not needed for gmic.<div><br></div><div>Do you have \
suggestions how to implement it correctly for all possible colorspace \
formats</div><div>that we currently support?</div><div><br></div><div>


And where does this plain scaling belongs to? \
Pigment?</div><div><br></div><div>Lukas</div></div><div><div><div \
class="gmail_extra"><br><br><div class="gmail_quote">2013/10/2 Boudewijn Rempt <span \
dir="ltr">&lt;<a href="mailto:boud@valdyas.org" \
target="_blank">boud@valdyas.org</a>&gt;</span><br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div><div>On Tuesday 01 October 2013 Oct 22:15:30 Lukast dev \
wrote:<br> &gt; Hi all,<br>
&gt;<br>
&gt; I&#39;m working on Gmic as you know and I hit performance bottleneck<br>
&gt; when converting Krita layers to gmic layers and back and making the whole<br>
&gt; experience for Krita artists quite slow.<br>
&gt;<br>
&gt; What I&#39;m doing -- converting Krita colorspace uchar 8-bit rgba  to float<br>
&gt; 32-bit rgba.<br>
&gt; I found out that the bottleneck is actually in lcms2<br>
&gt;<br>
&gt; There is benchmark where is roundtrip conversion rgb8-float-rgb8<br>
&gt; You can run it at<br>
&gt; &quot;build/calligra/krita/plugins/extensions/gmic/tests/KisGmicBenchmark<br>
&gt; testConversion&quot;<br>
&gt;<br>
&gt; Source:<br>
&gt; calligra/krita/plugins/extensions/gmic/tests/kis_gmic_benchmark.cpp::testConversion()<br>
 &gt;<br>
&gt; From the valgrind log [1] we can see that the bottleneck (98% of time) is in<br>
&gt;<br>
&gt; KoColorSpace::convertTo<br>
&gt; and there in<br>
&gt; cmsDoTransform<br>
&gt;<br>
&gt; and there it looks like it is using a lot of math pow, exp per pixel which<br>
&gt; is of course slow.<br>
&gt; For 3840x2400 image it takes 6,5 second to convert from rgba8 to rgba32<br>
&gt; float on my laptop.<br>
&gt;<br>
&gt; I wrote this hack to convert Krita pixels from rgba8-&gt;rgba32 float:<br>
&gt; <a href="http://paste.kde.org/p19eeee78/" \
target="_blank">http://paste.kde.org/p19eeee78/</a><br> &gt;<br>
&gt; It takes 120 ms to convert Krita layer to gmic with this hack way, so \
it&#39;s<br> &gt; 60-times faster.<br>
&gt;<br>
&gt; Of course it ignores all rendering intends and profile, but I wonder if<br>
&gt; there is some way to tell<br>
&gt; lcms2 to do it stupidly and simply and avoid stuff like: pow, exp1 per<br>
&gt; pixel and cmsEvalToneCurveFloat?<br>
<br>
</div></div>I don&#39;t think so -- it&#39;s exactly what LCMS is doing. But I think \
that for G&#39;Mic, a plain scaling of rgb u8 to rgb f32 is actually better than \
going through lcms and actually converting the colorspace.<br>



<br>
That is -- unless G&#39;Mic needs the f32 data in linear format? If that&#39;s \
needed, you really need to use the proper profiles and let lcms do the \
conversion.<br> <div><div><br>
&gt;<br>
&gt; [1] valgrind log<br>
&gt; <a href="https://www.dropbox.com/s/wvazoys09p0ujtb/callgrind-convert-to.tgz" \
target="_blank">https://www.dropbox.com/s/wvazoys09p0ujtb/callgrind-convert-to.tgz</a><br>
 &gt;<br>
&gt; Lukas<br>
</div></div><span><font color="#888888">--<br>
Boudewijn Rempt<br>
<a href="http://www.valdyas.org" target="_blank">http://www.valdyas.org</a>, <a \
href="http://www.krita.org" target="_blank">http://www.krita.org</a>, <a \
href="http://www.boudewijnrempt.nl" \
target="_blank">http://www.boudewijnrempt.nl</a><br>



<br>
_______________________________________________<br>
Krita mailing list<br>
<a href="mailto:kimageshop@kde.org" target="_blank">kimageshop@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kimageshop" \
target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br> \
</font></span></blockquote></div><br></div> \
</div></div><br>_______________________________________________<br> Krita mailing \
list<br> <a href="mailto:kimageshop@kde.org" \
target="_blank">kimageshop@kde.org</a><br> <a \
href="https://mail.kde.org/mailman/listinfo/kimageshop" \
target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br> \
<br></blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font \
color="#888888">-- <br>Dmitry Kazakov </font></span></div>
<br>_______________________________________________<br>
Krita mailing list<br>
<a href="mailto:kimageshop@kde.org">kimageshop@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kimageshop" \
target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br> \
<br></blockquote></div><br></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] 

Configure | About | News | Add a list | Sponsored by KoreLogic