Le_Forgeron <lef### [at] freefr> wrote:
> Le 27/10/2010 15:50, Mr a écrit :
> > And the first solution you suggest, won't work either, should I use Filter for
> > the background, I get no transparency at all.
>
> With filter at 1 on the sky_sphere and NO background, with beta 39, I
> got the attached pictures.
>
> sky_sphere {
>  pigment {
>   gradient y
>   color_map {
>    [0.0 rgbf<0.33, 0, 0.528, 1>]
>    [1.0 rgbf<0.481, 0.774, 0.645, 1>]
>   }
>  }
> }
> global_settings {
>  max_trace_level 7
>  ambient_light rgb<0, 0, 0>
> }
>
>  //  background { rgbt <1,1,1,0.5>}
>
>
> --
> A good Manager will take you
> through the forest, no mater what.
> A Leader will take time to climb on a
> Tree and say 'This is the wrong forest'.

I had the same.
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.

Post a reply to this message

If someone wants to try with the exporter for latest blender 2.5, here it is:

https://projects.blender.org/tracker/index.php?func=detail&aid=22717&group_id=153&atid=468

Post a reply to this message

Am 26.10.2010 23:49, schrieb Mr:
> "Mr"<nomail@nomail>  wrote:
>> If I do that,  only the last entry of color map of my gradient will be used as
>> if the the first entry had never existed. so it seems like the transparency is
>> baked into the color for each entry. could there be an option to make it so that
>> if the first entry has transmit 1 its color is still retained and all
>> transparencies
>> only applied in the alpha layer?
>
> Actually it's not the color of the last entry, it happened to be the color of my
> background too. If I remove the background, I get a completely black skysphere!
> So what is happening, Are spy sphere totally ignoring the separation between
> colors and alpha?

If you're using OpenEXR, there is nothing that can be done about this, 
except for violating the file format specifications. OpenEXR uses what 
is called "premultiplied alpha", i.e. if you take the RGB components by 
themselves, you get the same result as if you'd compose the transparent 
image against a black background. So with 100% transparency you'll 
always get pitch black, no matter what. (This /does/ have some benefits 
of its own.)

With the PNG file format, the story is rather different: PNG is 
specified to use "non-premultiplied alpha", i.e. if you take the RGB 
components by themselves, you get the same result as if you had no 
transparency in the first place. So theoretically, what you're asking 
for should be possible.

However, for internal computations POV-Ray uses "premultiplied 
alpha"-like format as well. With the most recent betas, it /does/ 
"un-premultiply" the values when writing PNG files - but when the 
transparency is 100%, this approach breaks down: Regardless of the 
original color, the premultiplied value will be <0,0,0>, so there's no 
way to tell what the original color might have been. In the absence of 
better information, POV-Ray will resort to guessing that the color may 
have been pitch black.


 From this root cause it is pretty easy to derive a workaround: Just 
never use 100% transparency. If you use e.g. 99.9% and PNG output, you 
should be fine.

That is, provided you use the newest beta. Earlier versions of POV-Ray 
weren't even aware of the premultiplied vs. non-premultiplied alpha 
issue, and erroneously wrote premultiplied alpha data for all file 
formats, even where contrary to specification. (Worse yet, they presumed 
all input files to use /non/-premultiplied alpha, i.e. POV-Ray wasn't 
even self-consistent about it.)

Post a reply to this message

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