future of hdr colorspaces

Cyrille Berger cberger at cberger.net
Thu May 31 10:43:41 UTC 2012


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

-- 
Cyrille Berger


More information about the kimageshop mailing list