I am starting to wonder if we are overthinking the issue of alphas. We are trying to sensibly handle compositing cases with no alpha where two images are the same size. This can never actually be useful. We could consider allowing different sized images, and arbitrary offsets. (There has been a lot of email... Maybe we already have and I just missed it? ) Then we could handle cases where you want to put a rectangular logo image or whatever on top of another image, for example, an RGB copyright notice in the bottom right corner of all your photos. Absent that geometric flexibility, there really isn't any value to channel-flexibility, or the operation of alpha-less compositing. Consequently, I just don't care what the result is, as long as it is comprehensible and similar operations have similar behavior. The more complicated the logic in 'over,' the more likely that some other operator will use slightly different logic which will prove more bewildering than if over fails comprehensibly and simply.
If we are trying to dance on our feet, we seem to be worrying about what happens when the user tells us to dance on our nose. Assuming RGBA in the case of four channels will be accurate for the overwhelming majority of cases where somebody is bother to ask for an over operation. If somebody has some weird requirements on n-channel multispectral images with regard to which channel is the alpha, why not just have the expectation that they need to set the ImageSpec correctly? Then the problem is solved for every operation, instead of having this discussion again for "under" and every other operator. So, personally, I would argue against the alpha_channel parameter as not actually being needed. On Thu, Jun 14, 2012 at 1:07 PM, Larry Gritz <[email protected]> wrote: > 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 _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
