Am 23.03.2010 17:13, schrieb Thorsten Froehlich:

>> IIRC, POV-Ray 3.5 mishandled alpha transparency against the background
>> in that with antialiased edges and semi-transparent surfaces it blended
>> the surface's color with the background color and then saved the
>> resulting
>> color with an alpha value. This caused object borders to have a
>> pixel-wide
>> halo of the wrong shade, and especially semi-transparent surfaces
>> would have
>> the wrong color.
>>
>> This was fixed in POV-Ray 3.6, where it's calculated correctly (iow. the
>> background color has no effect on the pixel colors when using +UA).
>>
>> Last time I checked (it has been some time, though), the same problem had
>> resurfaced in POV-Ray 3.7 beta. Someone had undone the fix in POV-Ray
>> 3.6.
>>
>> Has this been corrected already?
>
> The fix was that alpha is treated differently depending on the version
> directive as the 3.6 change was unpopular...

I just noticed the following:

(a) With +UA, POV-Ray 3.6 /completely/ suppresses the background except 
in reflections and radiosity-based diffuse illumination.

(b) POV-Ray 3.7 /without/ a #version directive (or with #version >=3.7) 
/always/ takes the background into account, and uses the background's 
transmittance as the basis for alpha channel computation.

(c) POV-Ray 3.7 /with/ a legacy #version directive (e.g. #version 3.6) 
/always/ takes the background into account as well, except that it 
forces the transmittance to 1.0.

The latter variant is totally rubbish, as it cannot be used for anything 
useful at all, and doesn't actually make the thing backward compatible.


As a side note, I think (a) is the most useful, as it allows for the 
background to be used for specifying a color to be seen in reflections 
of the background, while not showing up in the image itself - something 
that cannot easily be accomplished otherwise - so completely 
"retreating" from that behavior seems a bad idea to me. Instead, I 
suggest to make this behavior configurable to the user independently of 
the #version directive, using some additional syntax; and as we're on 
it, we can extend the same syntax to be used with a sky sphere as well, 
so the user can choose whether to have the sky show up only in 
reflections (leaving the background completely transparent), or in the 
background as well (e.g. for generating fully or partially opaque 
clouds). Or use this additional syntax only for the sky_sphere, and make 
the background always invisible in the image itself when +UA is 
specified. (If a user wants to mix some constant background into the 
alpha channel, they can always resort to using a sky sphere with a plain 
constant-color pigment.)

I'm thinking about something along the lines of

background {
   COLOR // only used in reflections or without +UA
}
sky_sphere {
   alpha_substitute { // must be first
     // pigments only used in reflections or without +UA:
     PIGMENT_1
     PIGMENT_2
   }
   // pigments to use always:
   PIGMENT_3
   PIGMENT_4
   ...
}

or:

// to be rendered always:
background { COLOR }
sky_sphere { PIGMENT_LIST }
// to be rendered /additionally/
// "behind" the regular background & sky_sphere
// only in reflections or when +UA is not used:
alpha_substitute {
   background { COLOR }
   sky_sphere { PIGMENT_LIST }
}

Note that if the alpha_substitute contains any transmittance in itself, 
this might be used as an indicator that the user wishes alpha 
transparency even in reflections.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> As a side note, I think (a) is the most useful, as it allows for the 
> background to be used for specifying a color to be seen in reflections 
> of the background, while not showing up in the image itself - something 
> that cannot easily be accomplished otherwise - so completely 
> "retreating" from that behavior seems a bad idea to me.

  Yes. As I already commented in this thread, All versions of POV-Ray which
have supported outputting an alpha-channeled image up to 3.5 (IIRC) had a
simplistic background transparency algorithm which calculated pixel colors
otherwise normally, but added an alpha value proportional to how much
the background was visible in that pixel.

  The problem with this was, of course, that the background color would
affect the color of semi-transparent pixels eg. at antialiased object
edges (where the visible edge of the object is against the background).
This meant that if you eg. had a black bacground, there would be a darkening
of the antialiased edge pixels. When such an image was then viewed eg. with
a web browser against some background color, eg. a white background, the
object would have a visibly darkish border around it. This made the entire
background-transparency feature significantly less useful.

  An even major problem happened with semi-transparent objects, or fully
transparent objects with eg. media inside them: The background color would
affect the color of the entire object, rendering eg. pure media effects
with a transparent background completely unusable (as the shape of the
container object would be visible).

  All in all, this rendered the feature rather useless, or at least a lot
less useful than it could have been. And this is why it was fixed in 3.6
(IIRC; could have been in 3.5, but I don't remember exactly now).

  3.6 did the background transparency properly, making the feature very
useful: Now you could render antialiased objects against a transparent
background, and the resulting image would work perfectly when put eg. on
a web page: The edges would blend nicely against the webpage's background,
without any extraneous coloring. Moreover, media effects against transparent
backgrounds worked like a charm: You could eg. render a flame against a
transparent background, and then use the resulting image on a web page and
it would look superb.

  In fact, when this was first fixed, many many years ago, I actually rendered
an image just as a proof of concept that it indeed worked like a charm:

http://warp.povusers.org/alphatest.html

  As you can see, the fire media blends with the background superbly.

  My guess is that when the result image handling routines were redesigned
in POV-Ray 3.7, this fix was accidentally dropped. This was a mistake which
should be corrected.

> Instead, I 
> suggest to make this behavior configurable to the user independently of 
> the #version directive, using some additional syntax;

  I don't know why anyone would want to use anything else than what 3.6 did,
but even if more options are made available, the 3.6 way should definitely
be the default, as it's the most useful and it's what people expect.

-- 
                                                          - Warp

Post a reply to this message

Am 08.05.2010 07:43, schrieb Warp:

>    I don't know why anyone would want to use anything else than what 3.6 did,
> but even if more options are made available, the 3.6 way should definitely
> be the default, as it's the most useful and it's what people expect.

One could argue that e.g. sky spheres should show up in the background, 
to allow for rendering opaque clouds against an otherwise transparent 
background.

I've also found that 3.6 is /not/ doing it right either (at least with 
regard to PNG), as it premultiplies alpha. Maybe 3.5 had that right, and 
people complained about /that/ change?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 08.05.2010 07:43, schrieb Warp:

> >    I don't know why anyone would want to use anything else than what 3.6 did,
> > but even if more options are made available, the 3.6 way should definitely
> > be the default, as it's the most useful and it's what people expect.

> One could argue that e.g. sky spheres should show up in the background, 
> to allow for rendering opaque clouds against an otherwise transparent 
> background.

  You mean that, with respect to alpha transparency, the sky_sphere would
work the same as if it was an actual sphere primitive with that texture
(naturally without lighting affecting it)?

  I agree that it sounds sensible and could be useful.

  (Nitpicking, but I disagree on the clouds example, though. sky_sphere is
the wrong but unfortunately too much used place to put clouds. Clouds do not
work that way in real life. Clouds work much better on a *plane* which is
parallel to the ground. :) )

> I've also found that 3.6 is /not/ doing it right either (at least with 
> regard to PNG), as it premultiplies alpha. Maybe 3.5 had that right, and 
> people complained about /that/ change?

  I don't really understand the difference. It has never come up as any kind
of problem when I have used POV-Ray 3.6 to render some alpha-channeled images.

  (Is the perceived problem that pre-multiplying means that some color
accuracy can be lost in the process?)

-- 
                                                          - Warp

Post a reply to this message

Am 08.05.2010 10:16, schrieb Warp:
>> I've also found that 3.6 is /not/ doing it right either (at least with
>> regard to PNG), as it premultiplies alpha. Maybe 3.5 had that right, and
>> people complained about /that/ change?
>
>    I don't really understand the difference. It has never come up as any kind
> of problem when I have used POV-Ray 3.6 to render some alpha-channeled images.
>
>    (Is the perceived problem that pre-multiplying means that some color
> accuracy can be lost in the process?)

No, the main problem is that colors simply aren't right.

Compositing images with an alpha channel always works according to the 
formula:

   ResultColor = (R;G;B) * A + Background * (A-1)

The PNG file format specification demands that the file stores the raw 
values ("non-premultiplied alpha"), i.e.:

   (R;G;B;A)

However, POV-Ray - at least at present - internally uses premultiplied 
alpha, i.e. it works with color tuples of the form:

   (R*A; G*A; B*A; 1-A)

For output to PNG files, POV-Ray 3.6 only converts the transparency 
(1-A) to alpha (A), i.e. it writes tuples of the following form to the file:

   (R*A; G*A; B*A; A)
   = (R;G;B;1) * A

Obviously, if you use these values in the above formula, you get:

   ResultColor = (R;G;B) * A^2 + Background * (A-1)

which of course gives a different result color (except for A=0.0 and 
A=1.0). One symptom is that gradients from opacity to transparency, 
while appearing smooth in the preview, will exhibit pretty hard edges in 
the image file.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Obviously, if you use these values in the above formula, you get:

>    ResultColor = (R;G;B) * A^2 + Background * (A-1)

> which of course gives a different result color (except for A=0.0 and 
> A=1.0). One symptom is that gradients from opacity to transparency, 
> while appearing smooth in the preview, will exhibit pretty hard edges in 
> the image file.

  I don't see that happening. Just to test this, I rendered this scene
with POV-Ray 3.6, without +ua and then with +ua:

//----------------------------------------------------------------------
background { rgb 1 }
camera { right x location -z look_at 0 angle 90 }
plane
{ -z, 0
  pigment
  { gradient y color_map
    { [0 rgb 0]
      [.5 rgb y transmit .5]
      [1 rgb y transmit 1]
    }
    scale 2 translate -y
  }
  finish { ambient 1 }
}
//----------------------------------------------------------------------

  I put the two images side-by-side here:

http://warp.povusers.org/images/gradient_test.html

  The image on the left uses no alpha channel, and it's just a gradient
from black to white, going through green. The image on the right uses
alpha channel and goes from opaque black to transparent green.

  There is no visible difference. You can't even tell where the border
between the two images is.

  To corroborate that the image on the right indeed has alpha-transparency,
contrast with this (the only difference being the background color of the
page):

http://warp.povusers.org/images/gradient_test2.html

-- 
                                                          - Warp

Post a reply to this message

Am 08.05.2010 12:38, schrieb Warp:

>    The image on the left uses no alpha channel, and it's just a gradient
> from black to white, going through green. The image on the right uses
> alpha channel and goes from opaque black to transparent green.
>
>    There is no visible difference. You can't even tell where the border
> between the two images is.

(1) Yes, we can - see attched screenshot from IE8. It is not easy to 
distinguish, but it is there (measure in photoshop if you can't see it). 
With a gradient from fully-opaque green to fully-transparency green the 
effect would be more pronounced and thus a bit better visible.

(2) Try again with assumed_gamma=1.0, which does give you the proper 
mixing of colors in POV-Ray, and you /will/ see.

What happened in your test images is that the gamma issues almost (but 
not quite) canceled out the effect of the premultiplied alpha.

Post a reply to this message

Attachments:
Download 'alpha_comparison.png' (63 KB)

Preview of image 'alpha_comparison.png'

clipka <ano### [at] anonymousorg> wrote:
> (1) Yes, we can - see attched screenshot from IE8. It is not easy to 
> distinguish, but it is there (measure in photoshop if you can't see it). 

  There's a really faint dividing vertical line barely visible between the
two images in your screenshot. I can swear it's not visible when I look at
the page with Firefox, and it's impossible to say where the edge between
the two images is. Maybe Firefox handles pngs slightly differently than IE?

  But I suppose that if what you suggest will make the difference disappear
even in IE, it's worth it.

-- 
                                                          - Warp

Post a reply to this message

Am 08.05.2010 16:05, schrieb Warp:

>    There's a really faint dividing vertical line barely visible between the
> two images in your screenshot. I can swear it's not visible when I look at
> the page with Firefox, and it's impossible to say where the edge between
> the two images is. Maybe Firefox handles pngs slightly differently than IE?
>
>    But I suppose that if what you suggest will make the difference disappear
> even in IE, it's worth it.

As I mentioned, with assumed_gamma=1.0 we're no longer talking about 
mere faint lines.

Post a reply to this message

> clipka<ano### [at] anonymousorg>  wrote:
>> As a side note, I think (a) is the most useful, as it allows for the
>> background to be used for specifying a color to be seen in reflections
>> of the background, while not showing up in the image itself - something
>> that cannot easily be accomplished otherwise - so completely
>> "retreating" from that behavior seems a bad idea to me.
>
>    Yes. As I already commented in this thread, All versions of POV-Ray which
> have supported outputting an alpha-channeled image up to 3.5 (IIRC) had a
> simplistic background transparency algorithm which calculated pixel colors
> otherwise normally, but added an alpha value proportional to how much
> the background was visible in that pixel.
>
>    The problem with this was, of course, that the background color would
> affect the color of semi-transparent pixels eg. at antialiased object
> edges (where the visible edge of the object is against the background).
> This meant that if you eg. had a black bacground, there would be a darkening
> of the antialiased edge pixels. When such an image was then viewed eg. with
> a web browser against some background color, eg. a white background, the
> object would have a visibly darkish border around it. This made the entire
> background-transparency feature significantly less useful.
>
>    An even major problem happened with semi-transparent objects, or fully
> transparent objects with eg. media inside them: The background color would
> affect the color of the entire object, rendering eg. pure media effects
> with a transparent background completely unusable (as the shape of the
> container object would be visible).
>
>    All in all, this rendered the feature rather useless, or at least a lot
> less useful than it could have been. And this is why it was fixed in 3.6
> (IIRC; could have been in 3.5, but I don't remember exactly now).
>
>    3.6 did the background transparency properly, making the feature very
> useful: Now you could render antialiased objects against a transparent
> background, and the resulting image would work perfectly when put eg. on
> a web page: The edges would blend nicely against the webpage's background,
> without any extraneous coloring. Moreover, media effects against transparent
> backgrounds worked like a charm: You could eg. render a flame against a
> transparent background, and then use the resulting image on a web page and
> it would look superb.
>
>    In fact, when this was first fixed, many many years ago, I actually rendered
> an image just as a proof of concept that it indeed worked like a charm:
>
> http://warp.povusers.org/alphatest.html
>
>    As you can see, the fire media blends with the background superbly.

That's the way it must work. You have a non-uniform background whose 
colour is not known before you render, and the location and scaling of 
your image is also not known beforehand and can be altered by the user.

>
>    My guess is that when the result image handling routines were redesigned
> in POV-Ray 3.7, this fix was accidentally dropped. This was a mistake which
> should be corrected.
>
>> Instead, I
>> suggest to make this behavior configurable to the user independently of
>> the #version directive, using some additional syntax;
>
>    I don't know why anyone would want to use anything else than what 3.6 did,
> but even if more options are made available, the 3.6 way should definitely
> be the default, as it's the most useful and it's what people expect.
>
In my view, your "should" have to replaced by "must".
If you want to be able to have the background dolour to show thru 
transparency, it must be user selectable, defaulting to off.
The only background that peoples may actualy usualy want to show in 
transparency, is the rainbow.


Alain

Post a reply to this message