Am 27.10.2010 16:47, schrieb Mr:

> The closest workaround I found:
> using transmit 0.99 for the background-like entry of the sky sphere I have the
> behaviour I want for transparency with gradient. only problem remaining is when
> user selects no sky spher I let background with transmit 1 do the job, but the
> anti aliasing is white. if I put transmit 0.99 in bacground color, AA is
> perfect, but then color is slightly off.

You should be able to use values even closer to 1.0, which will reduce 
the impact on color.

There is no sane way for a general fix; even a full redesign of 
POV-Ray's internal maths to operate on non-premultiplied values would 
not be a viable solution, as this would in turn cause problems when 
working with emissive media: Non-premultiplied values can't represent 
light to be /added/ to a fully transparent background.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 27.10.2010 16:47, schrieb Mr:
> There is no sane way for a general fix; even a full redesign of
> POV-Ray's internal maths to operate on non-premultiplied values would
> not be a viable solution, as this would in turn cause problems when
> working with emissive media: Non-premultiplied values can't represent
> light to be /added/ to a fully transparent background.

Would an RGB triplet for Alpha solve this, at least for internal working, and as
an extension, use a file format or compositing/post-processing method that
supports this?
i.e. each pixel has:
- source: (R, G, B)
- alpha: (R, G, B)

Examples (I hope I have this correct):
- red filtering glass would be S(1, 0, 0), A(1, 0, 0)
- green transparent emissive media would be S(0, 1, 0), A(1, 1, 1)
- blue surface that lets a little red light through: S(0, 0, 1), A(0.2, 0, 0)

Such a scheme might unify the rgb(), rgbt(), and rgba() methods of specifying
colour.

Post a reply to this message

"MessyBlob" <nomail@nomail> wrote:
> Such a scheme might unify the rgb(), rgbt(), and rgba() methods of specifying
> colour.

Correction: rgba() -> rgbf()
....I've been doing too much CSS3 recently.

Post a reply to this message

Am 20.11.2010 03:40, schrieb MessyBlob:

>> There is no sane way for a general fix; even a full redesign of
>> POV-Ray's internal maths to operate on non-premultiplied values would
>> not be a viable solution, as this would in turn cause problems when
>> working with emissive media: Non-premultiplied values can't represent
>> light to be /added/ to a fully transparent background.
>
> Would an RGB triplet for Alpha solve this, at least for internal working, and as
> an extension, use a file format or compositing/post-processing method that
> supports 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.

Post a reply to this message

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

Am 21.11.2010 01:08, schrieb MessyBlob:

> 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.
...
> 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.

I guess that could work.

The drawback, however, would be...

(1) a lack of file formats to support this complex model, and

(2) a serious increase in image data before file format specific 
handling takes place.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 21.11.2010 01:08, schrieb MessyBlob:
>
> > 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.
> ...
> > 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.
>
> I guess that could work.
>
> The drawback, however, would be...
>
> (1) a lack of file formats to support this complex model

File output is somewhat less complex than the model itself, as it just needs to
be able to cover the "filter" and "object color" portions of this.  ("Object
emission" can be included as an optional portion.)  Since each of these is a
standard RGB image, any sort of layered format works for this.

The first file format that readily springs to mind is PSD (Photoshop's format),
and then using a separate layer for each of "final filter", "final color", and
(if desired) "final emission".  Making it _look_ correct in viewers is
problematic without designing a file format (and viewer) specifically for that,
but I'd think that images output with all of this information are more likely to
be for intermediate usage in a process than for public consumption.

(PSD also has room for a lot of extra metadata about the image that we probably
don't need, so other formats that support either layers or something similar may
be more ideal.)

Post a reply to this message