On Wed, Mar 12, 2003 at 02:23:29PM -0800, Daniel Rogers wrote: > > > > 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. 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. 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). > 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. > > *nod* but I am suggesting that some input validation may have to be > delayed until you are able to traverse a complete graph. > Yes. I think I was saying that color space conversions and precision conversions are delayed until just before you are ready to process the node. Then during input validation you do a certain amount of reasonable color space promotion and precision conversion if the op needs it. Calvin
