New color conversion system

[Cyrille Berger]

Hello,

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.

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

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 ?
-- 
Cyrille Berger