[cairo] Color space API

[Bill Spitzak]

>> Any other interpretation I think results in unworkable difficulties.
> 
> I do not see difficulties. Say what you want and need and we can discuss that more efficiently.

I can try to explain the versions I DO NOT WANT by using an example color space where this bad implementation would appear desirable:  YUV.

If you took a YUV image and put it directly onto an RGB window, the colors are completely wrong and psychedelic. Therefore it is very tempting to say "you fix this by changing the color space of that window from RGB to YUV".

I want to make absolutely sure that this is NOT what Cairo is going to do. If the Cairo destination surface has colors represented as YUV triplets in it, the on-screen window is going to show exactly the same psychedelic wrong colors and nothing using the cairo color api is going to change this.

This may make it appear that it is now impossible to see YUV data. But that is not true. There are two ways to get it:

1. Put the YUV data into a DIFFERENT cairo surface (the "source"), and set the color space of *that* surface to YUV. Then copy (or composite) that surface to the output surface. Cairo color management will do the conversion then.

2. Use a NON-CAIRO API to create a surface the driver converts from YUV to RGB as it is put on the screen. You can then use the cairo color management api to set the cairo color space of this surface to YUV. The end result is what you "expect" from color management.

This behavior may appear pointlessly stupid for YUV, but it is VITAL that it work this way for more subtle color management to work and for software to produce predictable and repeatable results, and for surfaces to be usable as sources.

It is possible what I am asking for is considered so obvious by the color space designers that they never actually state this?

But I am worried a bit by several mentions that you cannot alter a surface's color space after creation. This would imply that there is concern that this is an expensive or undefined operation. In my version this is a TRIVIAL operation. It would only change a pointer to the color space description. You could call it a hundred times with different color spaces, and as long as you put it back to the original color space this is completely lossless and very fast.

Being able to change the color space of an existing surface is also necessary for any data that is in the wrong color space. This is going to happen because people are going to use libraries that produce cairo surfaces (such as the toy png reader), and those libraries are going to get the color space wrong.

In fact the source+destination color spaces could be part of the cairo_t state, rather than a property of the surfaces. The only reason to make them part of the surfaces is to make the api more convenient for the most common uses.