[cairo] [RFC] Color space API (partial proposal)

[Bill Spitzak]

Kai-Uwe Behrmann wrote:

> on the colour space sizes some arrangement has to be defined for out of 
> gamut colours through the rendering intents. For this there are more 
> options possible than four rendering intents.

Okay it does sound like there are more options. I don't think we should 
add more apis for these and that the proposed "rendering intent" api 
should be removed.

One think I remember from one of the cms libraries I used (Truecolor?) 
is that they just stuck "rendering intent" into the color space 
structure. When converting from A to B it used the value from B and 
ignore the one in A. This puts all the variables for color correction 
into a single "cairo_color_space_t" structure.

> If a surface is used to blend into an existing document the image colour 
> space is the input colour space to be converted to the documents 
> blending colour space. For gradients I found the term interpolating 
> colour space very nice.
> Imaging the blending colour space as the central space to convert into 
> on input and convert from on output seems the most plausible to me.

This sounds exactly like I though it would work. However it does 
disagree with quite a few statements in these letters. I will try to 
call this "blending space" from now on.

>> 5. The "destination" space of a pixel buffer surface or a gradient 
>> also becomes the "source" space when that is used to render onto 
>> another surface. (ie despite the fact that it would be trivial to 
>> implement, making these spaces different is purposely discouraged by 
>> the api).
> 
> Yes. "discouraged" meaning not impossible but some more work.

I very much recommend that changing the color space of a surface, if 
allowed at all, should leave the numbers in the channel buffers 
unchanged (though it can add zero-filled channels or truncate them if 
the new color space has a different number of channels). I have 
certainly proven to myself from working on Nuke that this sort of 
operation is a requirement. Conversions between spaces can still be done 
by Cairo by copying from one surface to another.

>> 6. A correct Cairo backend can be implemented that will IMMEDIATELY 
>> (ie before the call to set the color or image returns) convert the 
>> color or image to destination space and throw away irretrievably the 
>> "source" space.
> 
> Yes, e.g. the Xlib backend.

I certainly agree that this is how it MUST be done, but I have to point 
out that this directly conflicts with most/all of the claims of color 
management making it possible to replicate a given printer's output. 
Even if you assume mixing the numbers in the printer's space is the same 
as printing those quantities of ink (which is demonstratively false), it 
is certainly not true in a different color space such as the display device.

> For monitors the control is typical provided by the operating system or 
> its conventions.

Yes this is what I meant by "fixed". The device space MUST be the form 
that the buffer is communicated to the system. This may be raw hardware 
(ie blending is in device space) or it may pass through a further color 
correction step, in which case blending space is the input space to this 
further correction. The only way changing the blending space could 
change the display is if this further step also took the blending space 
color space as input.

 > The print colour space is often set in the app by the
> user or to be detected by the local print system.

In this case it sounds like the application is expected to discover the 
printer's space and send that to Cairo as the blending space. I am 
guessing (or I HOPE!) that this is the default result if no attempt is 
made by the application to set the blending space.

> The output space is for many backends the same as the blending space on 
> that surface. PNG should not alter and just embedd as should PDF.
> Xlib should implicitely convert from whatever blending space to the 
> device space.

This sounds trememdously inefficient and forces programs to discover the 
device space and set it as the blending space and forces backends to 
reliably detect the identity.

I would greatly prefer a "it acts like the blending space is the device 
space unless there is hardware or operating system support to make the 
further conversion from an arbitrary color space efficient".