<div class="gmail_quote">On Fri, Jun 1, 2012 at 12:28 AM, Simon Legrand <span dir="ltr"><<a href="mailto:legrand.simon@gmail.com" target="_blank">legrand.simon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div class="gmail_quote"><div><div>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><br>
On Thu, 31 May 2012 11:58:12 +0200 (CEST), Boudewijn Rempt<br>
<<a href="mailto:boud@valdyas.org" target="_blank">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></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" target="_blank">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></div></blockquote>
<div><br>Wow, that a crazy amout of RAM. How much of that is usually used when editing a texture? Krita tends to trade memory for speed by caching large amounts of data.<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="gmail_quote"><div></div><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><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><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><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></div></blockquote><div><br>I looked through it a bit and it looks similiar to color transformation part of pigment. Documentation isn't really great.<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="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div><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" target="_blank">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>
</div></div></blockquote><div><br><div>
The thing with OpenColorIO is that it basically a second stack that would be
parallel to what we have in pigment. Integration into Krita could be a bit tricky if you want to be able switch between both stacks. I currently we don't have many people how are experts for that (practically only Cyrille). Performance wise it should be ok, at least they have optimizied cpu transformations and can use the gpu.<br>
<br>Currently the only painting application that supports appears to be Mari. Photoshop doesn't have it. So we could have it first :)<br><br></div></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="gmail_quote"><div>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></div></div></blockquote><br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div>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>
</div></div></blockquote></div><br>That's a unexplored territory for us :). So far nobody has been using Krita at this level, so we have only benchmarks for slower machines. At least on my machine the brush size also has a big impact and I wonder how that scales up. We would need a list of all the tool and brushes that you use and then benchmark those probably on your machine to find the bottlenecks.<br>