Calvin Williamson wrote:
You really want to be able to mix things like precisions and
color spaces together in a library like this and not have to do
it by hand though. The library should be able to convert
when it can for things like this.
Yes. I wholeheartedly agree that it is good for the library to do as
much of this work as possible. But I think there are practial concerns
as well and more importantly I think it's important to discuss the
alteratives, even if don't agree with them.
On the other hand, if you put a node with some unknown kind of data
as output (say not image data) into an image data input, you do have
to complain about that somewhere. But I think the earlier the better.
Since ops have to specify the kinds of data they send to output
and the kinds of data they expect as inputs (ie image data, scalar
data, channel data, string data) you could do it as soon as the
ops are hooked up. But I think its reasonable to convert color
models between image data (Gray to RGB), and channel spaces
between channel data (eg U8 to FLOAT).
Yeah, the channel data conversions are simple. The reason I am
expressing concern is that almost any color coversion over a
sufficiently large sample of distinct pixels will involve a loss of
color information and any loss of information is A Bad Thing (TM).
number 2 is still feasable 'cause it means that if you ever have a
problem with colorspace mis-matching, you convert everything to your
working space and now you have a match. It's the simplest solution
(and, I believe the one shake uses).
Is "working space" different from a "connection space" (like CIE_XYZ)
here? So that if every color space specifies a toXYZ and fromXYZ then
you would be able to get from your space to the one needed by the op with
at worst a toXYZ and fromXYZ.
Yes. By working space I mean a prefered color space. THis is why it
should be settable by the user. If the user is going to have to accept
a loss of information from automatic color conversion, it would be nice
if the user could decide what colorspace things should prefer to move
to. This will minimize the impact of color space conversions. For
example, since a pre-press person is going to go to cmyk eventually, if
you are going to convert to a color space, you would prefer to convert
to CMYK 'cause that way you don't have to convert again on output (for a
second possible loss of information). A web person, however would
prefer sRGB, since sRGB is where a typical web image ends it's life.
(The strategy here is to minimize the number of color conversions in a
given processing graph).
--
Dan
