Colorspace promotion is a sticky issue. There doesn't seem to be any
good, simple solution. I will assume that you have read the "color
faq." by charles poynton. It is an excellent intro to the topic:
http://www.poynton.com/Poynton-color.html
Also, "Computer Graphics: Principles and Practice" by Foley has a good
discussion of the topic (these two references are my primary sources).
First the easy stuff
Now the hard stuff:
Normally when you consider datatype promotion, you want to convert, such
that the "lower" form is a subset of the "higher" from. For the vast
majority of cases this just isn't true for colorspaces. Differently
calibrated RBG spaces (say from a digital camera to an LCD monitor) will
most likly contain colors the other calibrated space can't represent.
Even in a grayscale to rgb transformation, the grayscale may represent
an brighter white or dark black than is in the rgb gamut. For a clear
and precise discussion of what a gamut is see "Computer Graphics:
principles and practice" and the color faq. The short answer is that a
gamut is a volume in CIE XYZ colorspace that contains all the colors in
a partiular representation.
The only space that contains all the colors that the human eye can
represent is CIE XYZ and its derivitives (L*uv, xyY, etc). XYZ, however
is a slow space to work in (it requires complicated transformations to
get to a monitor's colorspace, so it is hard to view in real time), and
besides most (perhaps all?) operators produce different results,
depending on what colorspace you are in. Color conversions themselves
are complicated by the "rendering intent" which gives a hint to the
algorithm about what to do to out of gamut colors (based on how the
color information is going to be used).
There is, usually, a pretty good compromise colorspace. Pre-press
people want to work in CMYK, while movie people would probably prefer a
film-calibrated RBG colorspace, while web people would prefer sRGB. As
you can see, though, it depends sharply on what context you are working in.
I think there are three solutions to this problem. I will present them
in increasing order of complexity.
1. Don't worry about it. I.e. insist that the user insert the proper
color conversion operator himself. This would make sure that the user
understands what was going on and give him an opportunity to tune the
conversion before begining to operate.
2. Allow the user to define a prefered "working space" and just accept
the loss of information. There must be some way to ensure that a user
can still make a proof (in this context, a proof is usually an image
with ugly flashing green hi-lights where color information is about to
be lost). You might also want to let the user define a default
rendering intent.
3. Create a general "ColorspaceTransformationStrategy" object. This
object would allow someone to precisly define what transformations are
made for each colorspace. We could then write different objects that
are specialized for different purposes (pre-press, movies, web, photo, etc).
I belive that 3 contains both 2 and 1 as a solution, but with much
greater flexibility. As such 3 is the method I prefer in the long run,
but 2 or 1 may be better for now.
--
Dan
