<br><div class="gmail_quote">On Thu, May 31, 2012 at 11:43 AM, Cyrille Berger <span dir="ltr"><<a href="mailto:cberger@cberger.net" target="_blank">cberger@cberger.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I think LCMS2 is a better choice. Generally speaking, I would think that<br>
CTLCS<br>
is a much more interesting approach, since it is easily allow to create<br>
new<br>
color spaces, but lets face it, how often does that happen ? While lcms2<br>
offers<br>
support for all the features we need (except "half", but maybe we can<br>
convince<br>
Marti to offer the option ?), with better maintainability.<br>
Personnaly, the future of CTL (or CTL-like) in Krita, rather than being<br>
the<br>
base of color spaces, would be to offer scripting features:<br>
<br>
For instance, to allow to write your own composite op, and people could<br>
write suff like:<br>
void my_compositeop(pixel a, pixel b, output pixel c)<br>
{<br>
  c = b / a;<br>
}<br>
<br>
or<br>
void my_compositeop(pixel a, pixel b, output pixel c)<br>
{<br>
  c.red   = a.blue * b.green;<br>
  c.green = a.red  * b.blue;<br>
  c.blue  = a.green* b.red;<br>
}<br>
<br>
or whatever else they want. It should be simple, and still offer good<br>
performance.<br>
<div class="im"><br>
On Thu, 31 May 2012 11:58:12 +0200 (CEST), Boudewijn Rempt<br>
<<a href="mailto:boud@valdyas.org">boud@valdyas.org</a>> wrote:<br>
> LCMS2:<br>
><br>
> * doesn't support the "half" (f16) format, so we would have to convert<br>
to<br>
> full 32 bits float on loading half-based exr files, and convert back on<br>
> saving,<br>
> plus we double memory requirements.<br>
<br>
</div>How much is it a problem ? I mean I would imagine movie studio to have 100<br>
of GB of RAM :)<br></blockquote><div> </div><div>Lol. Yes, we do have plenty or ram. However we're dealing with such high resolution textures most of the time that even our massive amount of ram needs to be saved and used wisely. (<a href="http://h10010.www1.hp.com/wwpc/us/en/sm/WF06a/12454-12454-296719-307907-4270224-3718645.html?dnr=1">64Gb in my current machine</a>)<br>
ILM and NVIDIA more or less pioneered 16bit half for memory reasons and it's become standard for us in almost all case except extreme displacement maps which sometimes require 32bit grayscale. <br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class="im"><br>
> CTLCS:<br>
><br>
> * Cyrille said he wanted to redo the syntax for the composite ops, which<br>
<br>
> should make it easier to write new composite ops. But that's not done,<br>
> and the set of composite ops is too small<br>
<br>
</div>Yes, but there is no real time frame for that one... Technically it would<br>
still be possible to use the template composite op defined in pigment, by<br>
simply<br>
allowing instantiation for a few specific cases (like 4-channels<br>
float/half).<br>
<div class="im"><br>
> * color transformation generally use the fallback mechanism, which means<br>
<br>
> that applying a filter removes all the extra precision<br>
><br>
> * but: supports half (f16), so that's good for memory consumption and<br>
> speed.<br>
><br>
> * I'm not sure, but it feels a bit faster perhaps?<br>
<br>
</div>Picture me skeptical on that one :)<br>
<div class="im"><br>
> Oh, and studios seem to be using a third color management thingie:<br>
> OpenColorIO (<a href="http://opencolorio.org" target="_blank">http://opencolorio.org</a>), but I haven't really looked into<br>
> that yet.<br>
<br>
</div>I had a quick look, sounds equivalent to pigment with a graph-gegl-like<br>
API.<br></blockquote><div>Implementing OpenColorIO can only be good for us as it is becoming more and more standard. In fact even game engines are starting to make use of it, crytek is supporting it in their upcoming <a href="http://mycryengine.com/index.php?conid=59">cryEngine cineBox</a> package. Mainly because they're targeting the VFX market and they know the market makes extensive use of OpenColorIO.<br>
<br><br>That said. This discussion should be all about performance. I've no idea what effect OpenColorIO would have on both the performance and initial stability, and neither do I really know how much work it would involve to implement. <br>
<br>What Krita offers now is very promising so if you thin it is possible to stick with what's currently available and refine it then I would prioritise that.<br><br>I'm in the process of making templates of our most commonly used image formats and bit depth, which I will send to Boudewijn tomorrow.<br>
<br>But just to give a rough idea, we're almost never painting in 8bit and under 4096x4096. <br><br>Usually we're looking at images of 8192x8192 at 16bit.<br><br>Trying it at home with the latest and greatest everything (kubuntu 12.04 and krita 2.4 straight out of apt) the performance is actually very good. Definitely usable without much trouble. I have tried all the filters brush ect yet, but it seems great to me.<br>
<br>The tarball I'm using at work is not cutting it as easily at those resolution but that's simply because it's a 32bit build. Boudewijn said he was working on a 64bit build for us so I'm impatiently waiting for it to start benchmarking against the photoshop box that sits next to me. :)<br>
<br>And I'm rambling again. <br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Cyrille Berger<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
kimageshop 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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Simon Legrand<br><a href="http://slegrand.blogspot.com/">http://slegrand.blogspot.com/</a><br>