[cairo] [RFC] Color space API (partial proposal)
spitzak at gmail.com
Tue Feb 23 12:12:36 PST 2010
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".
More information about the cairo