El vie, 09-10-2015 a las 18:42 +0200, Tobias Ellinghaus escribió:
but floats also allow to transform colors to a smaller gamut without clipping them since the values can be bigger than 1.0. Of course, all color math has to be checked if it would still work with values bigger than "full power" and there are cases where it will fail.
Let me see if I got this straight (probably the simplified explanation left some things out), but you seem to be considering the values beyond 0,1 for the colorspace math. In a display-referred model (ICC is) colors beyond the 0,1 range are undefined, unless you have something like lcms' (and GEGL's) unbounded RGB. Encoding out-of-gamut values outside the 0,1 range could be fine for storage and conversions, but it might be very problematic for editing, specially for arithmetic RGB operations like multiplication since you can end up with negative RGB values and shifted channels.
It seems safer to stick with the good-old "destructive" colorspace transforms (i.e. wider gamut is mapped to smaller gamuts and the out-of -gamut values are lost). Otherwise even simple RGB compositing could fall apart.
Artists should choose their desired colorspace as one of the first decisions, then deal with that choice (For instance: if you chose wide gamut and you're targetting for the web, you'll likely lose gamut. You should know that).
Apart from that, higher bit depth and floats could allow high dynamic range scene-referred imaging (where RGB data goes from 0 to infinity and values beyond 1 aren't used for encoding out of gamut colors but light intensity). Using those values for storing out-of-gamut color would be probably incompatible. It's probably way out of the scope of SVG and a vector drawing program to think about HDR, but the trend in digital imaging seems to be going towards linear RGB compositing and HDR anyway.
Gez.