On Jun 8, 2012, at 2:28 PM, Daniel Wexler wrote:
> I would expose a ROI in the public call. If this were my code, I'd require
> the images to be the same size and NOT specify an ROI, but instead, the
> typical solution is to define an ImageReference class, which derives from the
> base Image class, defining a ROI, but only *referencing* the image data. But,
> I'm not familiar enough with the OIIO image classes to know how this would
> affect things. It generally means a more fundamental change to the way
> everything works that probably won't work if it isn't already supported. So,
> if that's not possible here, I'd pass an ROI.
The resolutions and offsets shouldn't be required to match -- it's a common
case to want to combine images that do not exactly overlap in image space.
I'm on the fence about whether to expose ROI in the public call, or if it
should default to the full area of the result image. Either way is ok with me
at this point. In my earlier email, I just punted by adding the parameter, but
making it optional with the default being something that means "use the
result's full area".
Oh, you know what, I got it wrong. I think what I meant was:
// The public version!
bool over (Result, A, B, roi, threads)
{
/* check for channel compatibility here */
// Initialized Result -> use as allocated; Uninitialized Result -> size it
to the union
if (Result is uninitialized) {
ImageSpec newspec = A.spec();
newspec.{x,y,z,width,height,depth} = union of A's and B's pixel regions
Result.reset ("over", newspec); // Resize it
}
// Specified ROI -> use it; Unspecified ROI -> compute over the whole of
Result's pixels
if (roi is unbounded)
roi = ROI(Result);
// do it!
bool parallel_image (over_1, Result, A, B, roi, -1);
}
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
