On Jun 8, 2012, at 11:44 AM, Stefan Stavrev wrote:
> 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.
OK, sounds good to me. I'm thinking something along the lines of:
class ROI {
public:
ROI (); // default constructor somehow means "unbounded"
ROI (int xbegin, int xend, int ybegin, int yend, int zbegin, int
zend); // explicit bounds
ROI (const ImageBuf &ib); // bounds taken from ib's pixel window
ROI (const ImageBuf &A, const ImageBuf &B); // bounds that are
the union of the two IB's pixel windows
int xbegin() const { return m_xbegin; }
...
int width() const { return m_xend - m_xbegin; }
...
private:
int m_xbegin, m_xend, ...;
}
> "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.
3. Regardless of size, they do not overlap perfectly. (Remember offsets and
whatnot.)
Wherever one image does not have defined pixels, you should treat it like all
channels are zero (i.e. black and transparent).
The output image should be the union of the two inputs. Maybe something like
this:
bool over (const ImageBuf &dst, const ImageBuf &A, const ImageBuf &B,
ROI roi = ROI())
{
if (roi is unbounded)
roi = ROI(A,B); // If not set to something other than
default, assume the union of the inputs
...do "over" using roi as the domain...
}
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org