clipka <ano### [at] anonymousorg> wrote:
> Am 20.11.2010 03:40, schrieb MessyBlob:
>
> >> There is no sane way for a general fix [...]
> >> [...] Non-premultiplied values can't represent
> >> light to be /added/ to a fully transparent background.
> >
> > Would an RGB triplet for Alpha solve this, [...] i.e. each pixel has:
> > - source: (R, G, B)
> > - alpha: (R, G, B)
>
> No - you'd still get the same type of problems at full transparency.

Agreed; I began working through this, and found the problem. Another try then...

To be complete, we'd need RGB triplets for:
- M: Colour to multiply background by (filter coefficients) first,
- P: Colour to add: (a) object colour affected by object alpha, and (b)
emission.

So the process is:
 Background colour         = M1(r,g,b), P1(r,g,b),
 Foreground object colour  = M2(r,g,b), P2(r,g,b),
 Foreground emission       =                       P3(r,g,b),
 Result                    = M4(r,g,b), P4(r,g,b),
   where
     M4 = M1 * M2;

     P4 = P1 * M2  +  P2 * (1 - M2)  +  P3;

N.B. if emissions are to be included in object alpha, then
     P4 = P1 * M2  +  (P3 + P2) * (1 - M2);
Reflections can be placed similarly.

I think that covers it! Some foreground colour definitions:

 M2            P2         P3
(1 , 1 , 1 ), (0, 0, 0), (0, 0, 0) = Default identity: transparent black
(1 , 1 , 1 ), (0, 0, 0), (1, 1, 1) = emissive white
(1 , 1 , 1 ), (0, 0, 0), (1, 0, 0) = emissive red
(1 , 0 , 0 ), (0, 0, 0), (0, 0, 0) = red filter
(.5, .5, .5), (0, 0, 0), (0, 0, 0) = 50% neutral filter
(.5, .5, .5), (1, 0, 1), (0, 0, 0) = Magenta (50% transparency)
(0 , 0 , 0 ), (1, 0, 1), (0, 0, 0) = solid magenta (no transparency)
(0 , 0 , 0 ), (1, 1, 1), (0, 0, 0) = solid white (no transparency)

So P3 is the total of emission, and
M2 and P2 is like surface rgb alpha and rgb pigment.

In a working ray-tracer, each ray would carry M2, P2, and P3 terms, which would
need to be pushed onto a stack at each level of recursion. To resolve screen
pixel values, the M terms are fairly trivial (product of all M terms), but the P
terms (the actual colours) would need to be pushed with each new surface on the
ray path, and then popped off, starting with the background colour, using M and
P terms (see P4= and M4=, above).
The value of P3 is only relevant to resolve the current layer, and can be
discarded (as can P2 and M2) if one has merged from the background thus far by
popping the stack.

To summarise (and add a few more possibilities), I think this would:
- give authentic filters (like the "red filter", above);
- solve the background merging difficulty mentioned by CLipka;
- cover all the rgb(), rgbt(), rgbf(), and rgbft(); and
- improve the capabilities over the current rgb[f][t]() by allowing full
independent RGB specs for object colour, filter colour, and emission colour.

Post a reply to this message