New color conversion system

[Boudewijn Rempt]

On Thu, 20 Sep 2007, Cyrille Berger wrote:

> While working on tone mapping for Krita, I was dramatically reminded of one of 
> our short coming of our color conversion system. Most (not to say all) tone 
> mapping algorithms work in XYZ float 32bit. But usually HDR pictures are in 
> RGB. So the first step is to convert to XYZ, the problem is that currently, 
> when a convertion involves a non LCMS colorspace, it fallback to converting 
> to/from LAB integer 16bit. Meaning that for a HDR colorspace, we lose a lot 
> of usefull information.

It's always been my intention to have the possibility to short-circuit that 
intermediate step. 

> I see three solutions:
>  * wait for lcms to support float colorspace (we might as well wait forever, 
> from last news, it was a lot of work and Marti Maria don't seem to have much 
> time currently)

Nah, won't work. Unless we start hacking on lcms ourselves. Which is an option, 
too, if it will save us more time than it will cost us.

>  * quick and dirty, do the fallback in LAB32Float
>  * leave to colorspace to define a list of convertion they can make, and have 
> the possibility to link them. For instance, XYZf32 says he can convert to 
> {XYZ16, RGB16f|32f} and RGB32f says he can convert to { RGB8 }
> 
> So if we want XYZf32 to convert to RGB32f, the convertion will be handled by 
> XYZf32 and it wouldn't lose the HDR information. 
> 
> This is a purely theorical case:
> But if we want to do XYZf32 to RGB8, the system will propose XYZf32 to RGB32f 
> to RGB8 .
> The problem with that system is that if XYZ16f offers transformation to RGB8 
> (and it does as they are both lcms colorspace), then we have two options to 
> convert XYZf32 to RGB8, either XYZf32 to RGB32f to RGB8 and XYZf32 to XYZ16 
> to RGB8. Ideally that would give the same results, but I am not so sure.

We'd have to sort the paths by preference. This is conceptually a lot like the
KOffice filter chains, isn't it? Maybe we can re-use some of that code to implement
the color conversion chain preferences.
 
> This solution is more complicated, but it's also more or less how I understand 
> lcms and other color management systems are working.
> 
> So what do you think guys ?

I think color conversion chains are the way to go, although implementing
float for lcms will win us more friends. We'd still need conversion chains, though

However, given the short time to 2.0, couldn't we just implement a single rgb float
to xyz float conversion and use that for tonemapping?

Boudewijn