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

Reply via email to