El sáb, 10-10-2015 a las 02:00 -0300, Gez escribió:
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.
Some further thoughts about this subject: Maybe it is possible to retain wider gamut to a certain extent if the color swatches store color in a device-independent colorspace and they get converted (destructively) to the working RGB/CMYK space for manipulation. I mean, if your colours are defined in, say CIE Lab, and you choose sRGB as your RGB working space, all the compositing math can be done without dealing with color management after colors are converted to sRGB. Now, if you change your mind and change the RGB colorspace of the documents, colors could be remapped from the original device -independent space to your new target space, instead of converting from your previous RGB space to the new one. This could work for linked images too (working with a cached copy of the original image converted to the chosen colorspace) but it would be trickier for embedded images. Of course, both images and swatches should be tagged with its source colorspace to allow conversions.
That can be done with display-referred values without having to recour to out-of-gamut values stored in the RGB channels and its potential complications.
However, I'm not sure if this is compatible with SVG and it's probably a problem with Cairo.
Gez.