Performance problem with colorspace conversion in lcms2

[Dmitry Kazakov]

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 at 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 at 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 at kde.org
>> https://mail.kde.org/mailman/listinfo/kimageshop
>>
>
>
> _______________________________________________
> Krita mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
>


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20131009/840a2f6d/attachment.html>