> > 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. 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. Calvin
