Hi There is something that I try to understand every once in a while with
povray:
I am trying to have a sky sphere with gradient but still with an alpha layer
fully transparent in the end image. How do you do that?

I try using two rgbt colors, both with a transmit value of 1 as entries to the
colormap.

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?

Post a reply to this message

Le 26/10/2010 23:38, Mr nous fit lire :
> Hi There is something that I try to understand every once in a while with
> povray:
> I am trying to have a sky sphere with gradient but still with an alpha layer
> fully transparent in the end image. How do you do that?
> 
> I try using two rgbt colors, both with a transmit value of 1 as entries to the
> colormap.
> 
> 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?
> 
> 
> 
Could we have a minimal demo scene ? please.

Post a reply to this message

"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?

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 26/10/2010 23:38, Mr nous fit lire :
> > Hi There is something that I try to understand every once in a while with
> > povray:
> > I am trying to have a sky sphere with gradient but still with an alpha layer
> > fully transparent in the end image. How do you do that?
> >
> > I try using two rgbt colors, both with a transmit value of 1 as entries to the
> > colormap.
> >
> > 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?
> >
> >
> >
> Could we have a minimal demo scene ? please.

Here it is:



#declare shader_Material = finish {
 brilliance 1.8
 phong 0.5
 phong_size 25.2
 diffuse 0.8 0
 ambient 1
 emission 0
 conserve_energy
}

#declare camLocation  = <7.481132, -6.507640, 5.343665>;
#declare camLookAt = <63.559295, 0.619768, 46.691945>;
camera {
 location  <0, 0, 0>
 look_at  <0, 0, -1>
 right <-1.77777777778, 0, 0>
 up <0, 1, 0>
 angle  49.134343
 rotate  <63.559295, 0.619768, 46.691945>
 translate <7.481132, -6.507640, 5.343665>
}
light_source {
 < 0,0,0 >
 color rgb<2, 2, 2>
 fade_distance 5.999997
 fade_power 2
 matrix <-0.290865, 0.955171, -0.055189,  -0.771101, -0.199883, 0.604525,
0.566393, 0.218391, 0.794672,  4.076245, 1.005454, 5.903862>
}
mesh2 {
 vertex_vectors {
  8,
  <1.000000, 1.000000, -1.000000>,
  <1.000000, -1.000000, -1.000000>,
  <-1.000000, -1.000000, -1.000000>,
  <-1.000000, 1.000000, -1.000000>,
  <1.000000, 0.999999, 1.000000>,
  <0.999999, -1.000001, 1.000000>,
  <-1.000000, -1.000000, 1.000000>,
  <-1.000000, 1.000000, 1.000000>
  }
 normal_vectors {
  6,
  <1.000000, -0.000000, 0.000000>,
  <0.000000, -0.000000, 1.000000>,
  <0.000000, 0.000000, -1.000000>,
  <-0.000000, -1.000000, -0.000000>,
  <-1.000000, 0.000000, -0.000000>,
  <0.000000, 1.000000, 0.000000>
  }
 texture_list {
  1
  texture {
    pigment {rgbft<0.8, 0.8, 0.8, 0, 0>}finish {shader_Material}
    pigment {rgbft<0.8, 0.8, 0.8, 0, 0>}finish {shader_Material}
  }
 }
 face_indices {
  12,
  <0,1,2>, 0,0,0,
  <0,2,3>, 0,0,0,
  <4,7,6>, 0,0,0,
  <4,6,5>, 0,0,0,
  <0,4,5>, 0,0,0,
  <0,5,1>, 0,0,0,
  <1,5,6>, 0,0,0,
  <1,6,2>, 0,0,0,
  <2,6,7>, 0,0,0,
  <2,7,3>, 0,0,0,
  <4,0,3>, 0,0,0,
  <4,3,7>, 0,0,0
  }
 normal_indices {
  12,
  <2,2,2>,
  <2,2,2>,
  <1,1,1>,
  <1,1,1>,
  <0,0,0>,
  <0,0,0>,
  <3,3,3>,
  <3,3,3>,
  <4,4,4>,
  <4,4,4>,
  <5,5,5>,
  <5,5,5>
  }
 interior { ior 1.000000
 caustics 0.1
 }
 matrix <1.000000, 0.000000, 0.000000,  0.000000, 1.000000, 0.000000,  0.000000,
0.000000, 1.000000,  0.000000, 0.000000, 0.000000>
}
sky_sphere {
 pigment {
  gradient y
  color_map {
   [0.0 rgbt<0.33, 0, 0.528, 1>]
   [1.0 rgbt<0.481, 0.774, 0.645, 1>]
  }
 }
}
global_settings {
 max_trace_level 7
 ambient_light rgb<0, 0, 0>
}

Post a reply to this message

Le 26/10/2010 23:49, Mr a écrit :
> "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?
> 
> 

You are specifying a transmit of 1, which means that the ray must goes
straight through the sky_sphere, without interacting with the colour.
Hence it get to the background... whose default is black unless you
specify another.

I'm afraid we are entering the big discussion in image format: does a
transparent pixel have a colour (or: is the rgb part of an alpha-enabled
image format pre-multiplied or not in regard to alpha (and gamma, it's
far more fun with gamma in the equation)).

The problem is that different format have different answers.
(and they might be all valid, up to their tenants)

Maybe you want to replace rgbt with rgbf (it give a colored background
with some transparency with +UA (and using a format which support alpha,
such as png)) ?

Or keep rgbt, but reduces t to 0.5 ?

I do not get what you are trying to achieve with such transmitting
sky_sphere.

-- 
Real software engineers work from 9 to 5, because that is<br/>
the way the job is described in the formal spec.  Working<br/>
late would feel like using an undocumented external procedure.

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Le 26/10/2010 23:49, Mr a écrit :
> > "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?
> >
> >
>
> You are specifying a transmit of 1, which means that the ray must goes
> straight through the sky_sphere, without interacting with the colour.
> Hence it get to the background... whose default is black unless you
> specify another.
>
> I'm afraid we are entering the big discussion in image format: does a
> transparent pixel have a colour (or: is the rgb part of an alpha-enabled
> image format pre-multiplied or not in regard to alpha (and gamma, it's
> far more fun with gamma in the equation)).
>
> The problem is that different format have different answers.
> (and they might be all valid, up to their tenants)
>
> Maybe you want to replace rgbt with rgbf (it give a colored background
> with some transparency with +UA (and using a format which support alpha,
> such as png)) ?
>
> Or keep rgbt, but reduces t to 0.5 ?
>
> I do not get what you are trying to achieve with such transmitting
> sky_sphere.
>
> --
> Real software engineers work from 9 to 5, because that is<br/>
> the way the job is described in the formal spec.  Working<br/>
> late would feel like using an undocumented external procedure.

I'm working with PNG and I want my Blender exporter to give me the proper alpha
to allow compositing, and other things just like the internal renderer outputs:
it allows a gradient for color of the background sky (blend sky option) but the
alpha is  still cutting the whole sky as *fully* tranparent. So in Pov an alpha
of 0.5 will not solve the problem as I'll have only partial transparency.

And the first solution you suggest, won't work either, should I use Filter for
the background, I get no transparency at all. Maybe that's what is broken? So I
assume you meant transmit, and transmit 0 for BG as well as both sky sphere
color map entries gets me no transparency, transmit 1 for both color entries
of skysphere gives me only the flat color taken from background keyword, and
using transmit 1 for only one of the sky sphere colormap entries, namely the one
that is similar to the "background" to let background actually do it and sky
sphere only do the second color: then I get a gradient in the transparency
values.

Any other solution?

Post a reply to this message

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

Post a reply to this message

Attachments:
Download 'skysphere.png' (9 KB)

Preview of image 'skysphere.png'

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