"Question #1: Would you like the public "over" function to always operate over full image size, or should it expose the "region of interest" arguments? If the latter, do you like the "xbegin,xend,ybegin,..." approach, or for the sake of reducing the arguments passed around is it better to create a "ROI" structure that holds these?"
On second thought, we can't use a Crop function when working with regions, because sometimes we want to apply an operation to an image region without cropping the image. Therefore, we must specify a region of interest, the only question is how. Having 6 related arguments separate is kinda messy, I would rather have them all in one structure that will be passed to the function. Most of the time we work with full images, so whatever way we specify the image region, there must be a default value for working on full image, in other words make it an optional argument. Summary: I vote for some structure, as Larry suggests, that would hold all these 6 arguments. It will have default value NULL, that is, it will be an optional parameter for Over. "Question #2: Should ImageBufAlgo functions such as over resize the destination image (for example, to the union of the extents of the inputs), or is it the caller's responsibility to already have initialized the size, channels, and data format of the destination image, and the IBA function merely fills in the pixel values for whatever range of pixels it already contains?" We want to do A over B. We have two cases basically: 1. One of the images is smaller than the other. 2. A and B have the same size. The Over function should handle both, I think it should not fail for different sizes. The next question is, what is the result for each case? 1. The output image will have the bigger size of both input images. It is like overlaying a smaller image on a canvas, and we want to keep the whole canvas. 2. Obviously the output image will have same size as input images. Larry, about "caller's responsibility to already have initialized the size", this is basically a crop operation. Just that the crop is done ahead of time. I think the caller should not do such thing, if we need it, we can apply a crop operation later. So, we handle the two cases above, and then we can do a crop if we want, as a separate function. An interesting question that comes up is, what do we do if we have two input images with different sizes, and the region of interest is not fully in the intersection of both images? Should we fail or should we operate on the valid region part that is in both images? I think we should handle this case and not fail. As long as the region of interest is inside the bigger image we should be fine. Hmm, and what do we do if the image region or part of it is outside even of the bigger image? Stefan
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
