I will start with the Over operation as we agreed. This is the most basic signature, just to start from something. As you read along, you will see me modifying it as I provide arguments why I do so.
bool Over (const ImageBuf &src1, const ImageBuf &src2, ImageBuf &dst, float alpha) 1. Chris already asked this before, should we have just two source images or more? At this point, there are two functions in oiiotool.cpp for each image processing operation. One function handles input from command line, pops/pushes images on stack, etc. and then calls the second function, which is the actual image processing operation. The first function is named "action_ip_name" and the second just "ip_name". My point is, we have a separate function that prepares the arguments for the actual image processing function. We could modify it to check if there are enough images on stack, pop them and place them in an array, and then pass the array to our image processing function. Opinion: I vote for more source images for Over. New signature: bool Over (const ImageBuf* srcs, ImageBuf &dst, float* alphas) 2. Should we apply this operation only on one channel? There are two options. Option1: Over is applied only on one specified channel, bool Over (const ImageBuf* srcs, ImageBuf &dst, float* alphas, int channel) Option2: Over is applied on one or more channels at once, bool Over (const ImageBuf* srcs, ImageBuf &dst, float* alphas, int* channels) Opinion: I vote for Option1, since Option2 can get messy as I explain below. What do we do if we have input images with different number of channels? How many channels will the output image have? We have two options: Option1: Over will make sure at start that all input images have the same number of channels. Otherwise it will fail and return false. Option2: Over will allow input images with different number of channels. The output image will have as many channels as the size of the argument channels, that is, it will only contain the modified channels. Opinion: I vote for Option1, since Option2 is messy. 3. The function should work on a specified region rather than on the whole image. There are two options. Option1: The function could have parameters int xbegin, int xend, int ybegin, int yend, int zbegin, int zend. Option2: As Chris suggested, we could have a crop function. Opinion: I vote for Option2, because we get a much nicer interface than Option1 which adds additional 6 arguments to the signature. Potential problem: Option1 is used in many other ImageBufAlgo functions so far, so Option2 might break some design rules. 4. Use more threads if available. I agree with Chris on this one. Even though the operation is dead simple and it won't benefit much from multithreading, we should consider more threads anyway because we don't lose anything and we can use the signature as a model for other functions later. Opinion: We should include an upper bound parameter for maximum number of threads to use: Over (const ImageBuf* srcs, ImageBuf &dst, float* alphas, int channel, int threads) Final result: Over (const ImageBuf* srcs, ImageBuf &dst, float* alphas, int channel, int threads) Looking forward to hear your comments, whether to add new parameters or improve what we already have. Stefan
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
