In addition to alpha (the measure of coverage) you could also include transparency (which is something a measure of how much light passes through, i.e. the actual transparency of glass, as opposed the the coverage of a screen, this is equivilent to insisting on a layer mask to be included for every layer).
It is a little tempting, as it would remove a lot of ambiguity in the overloading of the meaning of the alpha channel. We've (well, GIMP and probably most other transparency-handing packages out there) been equating transparency with alpha for so long now though that I'd hate to have to re-educate users. But it needn't be something that the front-end has to expose.
I think the best way to go here is to re-educate users, without breaking what they expect alpha to be. I think the best way to deal with this is quoted in a email I just sent:
This is why I suggested earlier the seperation between transparency and coverage. Any drawing operation would have to consider whether it is adding transparency or coverage or both at every pixel (a pixel could be partially covered by a transparent effect). This would mean that instead of an alpha channel and a layer mask, we should have a coverage channel and a transparency channel. (giving way to RGBCT colorspaces). In this sort of situation, the full measurement of the pixel includes all five numbers, and any algoritm that affect pixels would have to take into account all five numbers (just as any operation now must account for all four exsisting pixel measurement numbers). Indcidenally, alpha, in the way it as been used would be C*T.
We then explain to the user the benefit of the RGBCT colorspace over the
RGBA colorspace. Since A=C*T it should be easy to write drawing
functions that handle both cases just as easily. I don't think that since it has always been done this way, there should be a reason to keep doing it that way. I don't know if this is really the best approach, but I think it allows for a better representation of real life. And yeah, even if we use coverage and transparently internally, it doesn't mean we have to tell the front end about it (though abstractions have a way of leaking precisely when you don't want them too).
We could also include luminesence, which is a measure of how much light a pixel produces (as opposed to reflectance, which is all we
measure how with rgb).
There are various per-pixel properties I could think of which might be very exciting (surface normal vector, specular reflection index) especially for natural media rendering. Luminescence wouldn't be the
first that'd come to my mind, since I think that any such image elements would by nature be quite isolated and fit very well on their
own 'addition' style layer and save a lot of complexity, but perhaps
it would be nice to paint with fire after all...
Yes, I agree. There is certainly a benefit to keeping the number of numbers used to describe a point in space to a minimum (I sure we could come up with more, with a little effort). And it may be that the distinction between coverage and transparency is better suited to a 3d renderer, where real-life modeling is more important.
-- Dan
