On Jun 14, 2012, at 12:25 PM, Jonathan Gibbs wrote:
> That's what I meant. I'd be annoyed if the CMYK over didn't work,
Really? Over means A+B*(1-A.alpha). Is that operation meaningful for CMYK
(even if you knew K was K, and didn't mistake it for alpha)? I don't know, but
I'm suspicious. Does compositing math work sensibly for subtractive color
systems?
> but I'd probably be more often annoyed if the un-tagged RGBA image didn't
> work. The latter is far more likely.
Yeah, that's my thought, too.
> However, it feels icky because in the latter case, I can fix the problem by
> tagging the image. In the former case my image is properly tagged and there
> is nothing I can do as a user to make the software work.
>
> I do think this is more elegantly solved by letting the readers indicate
> either "I know there is no alpha channel" or "I don't know what these
> channels mean - feel free to guess".
OK, how about this compromise (I'm just throwing it out for discussion, not
even sure if I like it yet):
We could change the over() to look like
bool IBA::over (IB &Result, const IB &A, const IB &B, int
alpha_channel=-1, int threads=-1)
* If 0 < = alpha_channel < nchannels, use that as the alpha channel
(regardless of what the ImageSpecs imply).
* If alpha_channel == -1, try to deduce the alpha channel from the ImageSpec,
and assume it's channel 3 in the case of a 4-channel image with no alpha
channel tagged.
* If alpha_channel == -2, try to deduce the alpha channel from the ImageSpec,
but if none is tagged, assume there is NO alpha channel (fail).
* In all cases, 3-channel images with no identified alpha channels are assumed
to be "opaque" (implicitly alpha=1).
In all cases, fail if A and B do not have the same number of non-alpha
channels, or if they have both have alpha channels marked but they do not match.
Program logic could use this set of rules to say "composite my spectral images
with alpha in channel 7", or "fail if there is no identified alpha", or "assume
channel 3 (of 4) is alpha if not told otherwise." (I recommend the last as the
default for oiiotool, at the very least.)
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
