On Jun 11, 2012, at 4:59 PM, Stefan Stavrev wrote:
> I handled all possible cases for the channels of the two input images. Not
> sure how to check the result image though.
I bet we can supply you with some test cases.
>
> Just to remind you of the function:
> bool ImageBufAlgo::over (ImageBuf &R, const ImageBuf &A, const ImageBuf &B,
> ROI roi, int threads) {...}
>
> R is either initialized by the caller or not.
>
> 1. If R is initialized already by the caller, I see two options if the number
> of channels differ:
>
> Option 1.1: If input images A and B have number of non-alpha channels X, then
> fail if the number of non-alpha channels for R is different than X.
>
> Option 1.2: If input images A and B have number of non-alpha channels X, then
> DON'T fail if the number of non-alpha channels for R is different than X.
> Modify the number of channels for R and move on.
>
> I vote for Option 1.1 since the programmer already made a decision for the
> number of channels by initializing R, so if we modify it, it leads to
> unexpected behaviour.
Agreed.
> 2. What about the case where R is initialized, it has same number of
> non-alpha channels as the input images but it does not have an alpha channel?
> Should I add one or fail? I vote for fail for the same reason as above.
Agreed.
> 3. If R is not initialized, then we can give ourselves the freedom to modify
> it as we wish I guess? Modify not just the origin and dimensions, but also
> number of channels.
Yes. So the general rule is:
* If A and B are not compatible (same number of non-alpha channels, and
matching alpha designations if they are specified for both), fail.
* If R is uninitialized, initialize it to the "obvious" size, channels, and
alpha designation based on the input images.
* If R is initialized, fail if its number of channels and alpha designation
does not match what A and B imply. BUT... it's ok for R to have a different
resolution; it just means that you only do the math for the pixels in R (assume
that any of A's or B's pixels are 0 if outside their respective bounds).
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
