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

<br>
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.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> [1] valgrind log<br>
> <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>
><br>
> Lukas<br>
</div></div><span class="HOEnZb"><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">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>