Calvin Williamson wrote:
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.
1 and 2 dont really work for what I am talking about. True, in the
node based realm, there are some color convert ops (ToRgb, ToGray, etc)
and some precision convert ops (ToFloat, ToU8, toU16, etc) and the
user can insert these in the tree where they please if they
know they want those conversions. (like I want to go to
float precision for a few operations, then back to 16bit)
But also you need to detect when inputs dont have the right
color space/precision an op expects and do a conversion if you need
to automatically. You want to be able to hook up any kind
op that produces an image output to any op that takes an image input,
and not have it complain. It cant complain on hook up, really cause
the color model/space at a node in the graph is not determined
until the color space/model information is propagated from the
leaves towards the root, and your leaves may not be there
yet cause you havent hooked them up. So if an op is going
to be passed a Gray image input during its operation,
but it can only process an Rgb one, someone has to detect this
and insert the ToRgb node on the fly. Now finding the appropriate
convert op is part of this as well, that could be color management
based for example.
You're assuming this has to be done automatically. It could still be an
error try to compute on two different color spaces, it is just that you
won't be able to detect the error untill you tranverse the graph. This
is analagous to a linker error when compiling a program. Sure each file
(node) compiles fine, but the system fail when you try to put it all
together. This attitude is what I meant as a solution in number 1.
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).
Anyway, I am trying to develop the mechanism where the op
will specify what types of inputs it expects and then how
the system checks those inputs before it starts calling
process on the op. It would be nice if the mechanism could also
check other kinds of data inputs as well (scalars, channels).
So its really more than just color conversion from that
point of view. Its also input validation.
*nod* but I am suggesting that some input validation may have to be
delayed until you are able to traverse a complete graph.
--
Dan
