future of hdr colorspaces

[Simon Legrand]

On Thu, May 31, 2012 at 11:43 AM, Cyrille Berger <cberger at cberger.net>wrote:

> Hi,
>
> I think LCMS2 is a better choice. Generally speaking, I would think that
> CTLCS
> is a much more interesting approach, since it is easily allow to create
> new
> color spaces, but lets face it, how often does that happen ? While lcms2
> offers
> support for all the features we need (except "half", but maybe we can
> convince
> Marti to offer the option ?), with better maintainability.
> Personnaly, the future of CTL (or CTL-like) in Krita, rather than being
> the
> base of color spaces, would be to offer scripting features:
>
> For instance, to allow to write your own composite op, and people could
> write suff like:
> void my_compositeop(pixel a, pixel b, output pixel c)
> {
>  c = b / a;
> }
>
> or
> void my_compositeop(pixel a, pixel b, output pixel c)
> {
>  c.red   = a.blue * b.green;
>  c.green = a.red  * b.blue;
>  c.blue  = a.green* b.red;
> }
>
> or whatever else they want. It should be simple, and still offer good
> performance.
>
> On Thu, 31 May 2012 11:58:12 +0200 (CEST), Boudewijn Rempt
> <boud at valdyas.org> wrote:
> > LCMS2:
> >
> > * doesn't support the "half" (f16) format, so we would have to convert
> to
> > full 32 bits float on loading half-based exr files, and convert back on
> > saving,
> > plus we double memory requirements.
>
> How much is it a problem ? I mean I would imagine movie studio to have 100
> of GB of RAM :)
>

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. (64Gb in my current
machine<http://h10010.www1.hp.com/wwpc/us/en/sm/WF06a/12454-12454-296719-307907-4270224-3718645.html?dnr=1>
)
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.


>
> > CTLCS:
> >
> > * Cyrille said he wanted to redo the syntax for the composite ops, which
>
> > should make it easier to write new composite ops. But that's not done,
> > and the set of composite ops is too small
>
> Yes, but there is no real time frame for that one... Technically it would
> still be possible to use the template composite op defined in pigment, by
> simply
> allowing instantiation for a few specific cases (like 4-channels
> float/half).
>
> > * color transformation generally use the fallback mechanism, which means
>
> > that applying a filter removes all the extra precision
> >
> > * but: supports half (f16), so that's good for memory consumption and
> > speed.
> >
> > * I'm not sure, but it feels a bit faster perhaps?
>
> Picture me skeptical on that one :)
>
> > Oh, and studios seem to be using a third color management thingie:
> > OpenColorIO (http://opencolorio.org), but I haven't really looked into
> > that yet.
>
> I had a quick look, sounds equivalent to pigment with a graph-gegl-like
> API.
>
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 cryEngine
cineBox<http://mycryengine.com/index.php?conid=59>package. Mainly
because they're targeting the VFX market and they know the
market makes extensive use of OpenColorIO.


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.

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.

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.

But just to give a rough idea, we're almost never painting in 8bit and
under 4096x4096.

Usually we're looking at images of 8192x8192 at 16bit.

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.

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. :)

And I'm rambling again.


>
> --
> Cyrille Berger
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>



-- 
Simon Legrand
http://slegrand.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120531/877f3a1c/attachment.html>