I see your point about not distinguishing between not knowing if there is an
alpha channel (and/or not knowing which one) versus a positive belief that
there is no alpha channel in the file -- alpha-agnosticism and alpha-atheism,
if you will. I would support a different constant to distinguish the two cases.
But I think it's a moot point. Here's why:
The only ambiguous case is a 4-channel image with no identified alpha channel.
If the format reader can't identify an alpha channel, I'm not sure how often it
would be able to conclude with certainty that there is no alpha at all.
(Exercise for the reader: under what circumstances, and for which formats,
could you be SURE that a 4-channel image did not contain an alpha?)
On the other hand, the over() function is being called, I imagine, from an app
like oiiotool, which an actual human being instructed to composite two images.
She wouldn't ask for a composite if she did not have an alpha (and is probably
prepared for weird results if given nonsensical input). If you give me two
4-channel files and say "A over B", the safe assumption is that they are RGBA,
even if we can't positively identify an alpha channel. If the plugin says "no
alpha" and the human says "composite them", the smart bet is to ignore the
reader.
Imagine the case where of RGBA files (let's say, with weird channel names, so
the format reader would be fooled into saying alpha_channel = -2, i.e. there is
none). Do we want "oiiotool A.exr -over B.exr -o comp.exr" to fail (without
much recourse)? Or do we want it to do what is almost certainly what the user
intended?
-- lg
On Jun 13, 2012, at 7:35 AM, Chris Foster wrote:
> Hi guys,
>
> Thanks Larry for fielding Stefan's questions while I've been mostly out
> of contact for the last few days. Good discussion.
>
> As for the API, I like how the details have been fleshed out so far. I
> have one nitpick surrounding the assumed alpha stuff. It seems like the
> value of spec.alpha_channel can mean two distinct things:
>
> 1) The ImageInput knew what the input channels were, and none of them
> represented alpha.
>
> 2) The ImageInput had no idea what the input channels were, and just
> gave up on trying to figure out which was the alpha channel.
>
>
> I would think these two cases have very different desired semantics from
> over(). For case (1), it makes sense to assume complete opacity as
> you've suggested for 3-channel images. For case (2), you can't decide
> what to do; the output is poorly defined and over() should probably
> fail.
>
> Unfortunately it seems like we've mashed both these cases into a single
> indicator spec.alpha_channel. Could we allow spec.alpha_channel to have
> a different negative value (-2 for instance) to indicate confusion as to
> the alpha channel, rather than that it's simply missing? Perhaps
> represented by an enum value for clarity?
>
> ~Chris
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
