Simon Budig wrote:
Sorry, but I don't believe that this destinction would make sense.

From my point of view "transparency/opacity" and "coverage" are two
models to explain what happens when talking about alpha. I do know that
the original Porter Duff paper based its conclusions on the coverage
model, however, the transparency analogy comes closer to what happens
when gimp is building its projection of the image.

The distintion is only important when deciding what to do when color information goes to zero. Coverage says it goes away, transparency says it stays. Also, alpha is the model. Transparency and coverage are the real (as in reality) things. Though I suppose that depends on whether you feel art imitates life, or that life imitates art (and I am not poking fun here, it's an iteresting philosophical debate).

For "proper" coverage handling you'd have to store the information
*what* part of the pixel has been covered. Better leave that to a vector
based implementation. The coverage model also fails to model a flat area
of e.g. 50% opacity (a surface with a small hole in each pixel...).

Yes indeed. Alpha as a measure of coverage is an approximation. The core blending ops derive directly as an extension of this approximation. Since alpha doesn't declare how a pixel is covered, when two pixels overlap you can describe how they overlap in one of 5 ways, listed in a chart on page 838 of "Computer Graphics" (2nd ed, Foley, et. al.). But as I said above, I think the difference is only vital when you have to decide what happens at zero.

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.

I fail to see what would be the win in this situation. All algorithms
would have to be revised and I really doubt that this separation would
make the algorithms simpler. E.g. Blur: It is ok, to blur the opacity
channel, but blurring the coverage channel does not make sense, because
it does not fit in the model of partially covered pixels. What should we
do? And how would we present unexpected results to the user?

It is only a small change to the algorithms (if anyone wants I can work out what I think are reasonable models, do the math and stick 'em on the list, I have already done some of it anyway). And I would think that blur would apply to a partial pixel and ignore opacity (depending on just how you modeled opacity) The impluse to the blur would be smaller, as discussed earlier. Including the alpha is the correct way to blur.

The win in this situation would be greater flexiblity in deciding when
it is appropriate to discard color information, also a more complex
model would allow for more complex results.  AFAIK, this seperation
between coverage and transparency has never been modeled before in a
real application, so I cannot provide any research or data about how
useful it would be.  I can only go with what I have mangaged to work out
myself, and my gut feeling.  My gut feeling tells me this might be useful.

And where would be the win for the added memory requirements, more
complicated algorithms and users looking blankly at the screen and
trying to figure out what is going on?

User's will figure it out. Since no one has ever tried to work with this before, it is hard to say what uses people will come up with. (I mean really, what would anyone use a laser for?) Besides, I am suggesting that if they don't want to work in RGBCT they can always work in RGBA. The added memory requirements give way to more complex results.

That said I could see some use for additional channels in the image.
Normal-Vectors or glossiness are an exciting idea, especially when using
them for generating textures. It also would be cool to have spot-color
channels in the image so e.g. distort plugins would distort the
image+spot color information together and you don't have to apply the
same plugin multiple times in the very same manner on multiple
drawables. It would be nice if these things were possible.

Agreed. I will try to see about incorporating these extra channels into gegl (not necessarlly C and T from above, but the others certainly).


_______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED]

Reply via email to