On Thu, Sep 21, 2000 at 02:51:28PM -0700, Kevin Turner 
<[EMAIL PROTECTED]> wrote:
> > While this might be interesting from a technical perspectibve, since
> > both compositors must result in the same image, 
> 
> In Gary's defense, I am not yet convinced this is true.

Premultiplied alpha is a _representation_ of a colour (including
alpha). Just like you can represent colour using 8 or 16 bits per channel,
or RGB and CMYK. Some representations are equivalent, most aren't.
premultiplied alpha is equivalent to RGBA, _except_ that it's spatial
resolution is lower.

So, if both types of compositing result in different images then they are
simply two different algorithms to do compositing. both ways can work with
both representations, it just happens to be that the current compositing
modes do not include them (just as there are no effect layers). I fail to see
what the internal representation has to do with that.

Now, if somebody came and claimed that fkat RGBA compositing modes make
no sense for premultiplied RGBA comp. modes and vice versa, he'd have a
point, but...

> core, but in my preliminary investigation I found no clean way for the
> blend tool to do premultiplied compositing.

Since you can always convert between the two representations, it
"just" has to convert flat RGBA to premultiplied RGBA. RGBA is all you
need. IF your algorithm works better in premultiplied RGBA, then just
convert. Usually you can reformulate the algorithm to work in RGBA,
preserving the resolution.

(The only exception I can see is layer/channel compositing, but as I
mentioned, if there are two different common ways to compose layers then
you can do both using both representations, and gimp could easily support
both at the same time).

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       [EMAIL PROTECTED] |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Reply via email to