The change in behavior of the alpha transparency (+ua) feature in pov3.7
was made quite long time ago, but I didn't notice it until now.

  I must protest.

  Taking into account the background color when calculating transparent
pixels was how POV-Ray worked long time ago, and this was changed to the
pov3.6 behavior for a good reason. If I'm not mistaken, I was the one who
suggested the change in the first place. (I don't remember now when the
change was done. Possibly to some version of POV-Ray 3.5.)

  The suggestion came because some people were (IMO correctly) complaining
that they could not create transparent PNGs with POV-Ray which would blend
smoothly with the background, as the 'background' color was interfering
with the color of the semi-transparent pixels.

  Here's a demo:

  I rendered a white object against a transparent background using
antialiasing with POV-Ray 3.6. Then I opened the resulting image in
the gimp, added a layer below the opened image and colored that layer
red. This is a highly-zoomed view of a portion of that image:

http://warp.povusers.org/snaps/pov36-blending.png

  The white object nicely blends with the added red background.

  Then I did the exact same thing with POV-Ray 3.7 beta, and this is
the result:

http://warp.povusers.org/snaps/pov37-blending.png

  Now the shape doesn't blend nicely with the background. It has a darkened
contour because of the original black 'background' in the original scene.

  This is exactly how POV-Ray used to work in the past and is precisely
the reason why it was changed to how POV-Ray 3.6 works. Usually when you
render an alpha-channeled image, you want the semi-transparent pixels to
blend with whatever will be below them, without any extraneous colors.

  I strongly suggest either changing the behavior back to how POV-Ray 3.6
does it, or at least make this behavior optional (with the default behavior
being that of POV-Ray 3.6, which is what people usually want). If not, this
will, once again, greatly diminish the usability of POV-Ray to create
alpha-channeled images.

  If the idea in POV-Ray 3.7 is that you can specify a transparency value
for the background instead of it being an on/off switch like in 3.6 (not
a bad idea, IMO), make it so that this transparency value is taken into
account in those semi-transparent pixels. In other words, when blending
pixels with the background, take the background color into account weighted
by this transparency value (that is, if the transparency is set to 0.75,
only take the background color into account with a weight of 0.25; if the
transparency is set to 1, the weight would be 0, ie. the background color
is not taken into account at all).
  IMO that would be a more logical way of doing it. That's how it would
work if the background was a transparent plane with that color behind
everything else (if a transmission value of 1 has been specified for
that plane, its color doesn't matter).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   The change in behavior of the alpha transparency (+ua) feature in pov3.7
> was made quite long time ago, but I didn't notice it until now.
> 
>   I must protest.

It isn't complete.

	Thorsten

Post a reply to this message

Warp schrieb:

>   The change in behavior of the alpha transparency (+ua) feature in pov3.7
> was made quite long time ago, but I didn't notice it until now.
> 
>   I must protest.
> 
>   Taking into account the background color when calculating transparent
> pixels was how POV-Ray worked long time ago, and this was changed to the
> pov3.6 behavior for a good reason. If I'm not mistaken, I was the one who
> suggested the change in the first place. (I don't remember now when the
> change was done. Possibly to some version of POV-Ray 3.5.)
> 
> [...]

The current (3.6) behaviour was designed by Nathan - there was some 
discussion about this some time ago (don't remember where) about how 
exactly this background compensation should work.  If for example there 
is a specular highlight on a completely transparent surface you might 
want this highlight to be visible or not - the 3.6 code tried to address 
this but you can of course question if this is 'correct'.

Anyway what you describe how 3.7 handles transparency is of course not 
how you would usually like it.

-- Christoph

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> The current (3.6) behaviour was designed by Nathan - there was some 
> discussion about this some time ago (don't remember where) about how 
> exactly this background compensation should work.  If for example there 
> is a specular highlight on a completely transparent surface you might 
> want this highlight to be visible or not - the 3.6 code tried to address 
> this but you can of course question if this is 'correct'.

  Well, the highlight does make the surface less transparent regardless
of what is in the background, so I don't really see the ambiguity.

  But I understand that doing it "correctly" is not always necessarily
trivial. For example, one question is that if in an antialiased pixel
20% of the rays hit the object, 30% hit another differently-colored
object and 50% the background, what should be the color of that pixel?
The transparency is trivial (50% transparent), but what about the color?

  (I assume POV-Ray 3.6 makes the pixel 40% of the first object's shaded
color and 60% of the second's?)

-- 
                                                          - Warp

Post a reply to this message

(This is my first time posting here. I'm not involved in development of POV-Ray
at all, but fairly experienced user.)

I'm just getting to grips with 3.7 beta to take advantage of the multi-core
capabilities. The reason for posting is that the new alpha handling turns out
to be a complete showstopper for the primary use I make of POV-Ray.

I use POV mainly for producing photomontage overlays to be layered on top of
photographs. The 3.6 behaviour guaranteed that the rendering would blend
correctly with the background photograph and that small detail that tendered to
sub-pixel dimensions would be correctly represented by partly transparent
pixels.

The 3.7 behaviour as currently implemented means that the edge pixels to the
overlaid object are tinted with the background colour used in the POV run
(whereas with 3.6, the background colour was immaterial).

I can think of two work-arounds; both are imperfect and cumbersome:

1 - Render with the target photograph as a background.

This will get the edge pixels the right colour, but as the background now forms
an object in the scene, the alpha information is lost and it is necessary to do
a second run without a background in order to obtain an alpha channel to use as
a mask for the first run.

This approach also assumes that the photograph is itself not going to be
changed, which, in practice, is often not the case. For example, I might be
placing a building in a landscape, but doing so might require the removal of
some trees form the photo in Photoshop. I don't know which trees to remove
until I overlay the rendering on the photo. If I remove a tree behind the
building, replacing it with sky, then the edge pixels of the rendered building
are the wrong colour rather than being always automatically right in 3.6.

Even ignoring the above problem, the edge pixels will still be slightly wrong.
Imagine a white flagpole rendered in POV and superimposed on a background of
trees. In 3.6, the edge pixels would be affected by the lighting model but not
by the background colour during rendering. Their partial occupancy by object
would be handled by the alpha channel. In 3.7, if we render against the photo
as described above, the edge pixels will be slightly green from the tree
colour. If we now superimpose that rendering on the photo, those pixels will be
blended with the photo by the alpha channel and will result in background +
overlay WHICH ALREADY HAS SOME GREEN IN IT. The result will be a halo of
incorrect colour around the object. This will look particularly awful on
renderings of lattice structures.

2 - Fix the problem by post-processing.

If the render is done against black, it is possible to calculate from the pixel
colour and the alpha value what colour the pixel should be without the effect
of the background.

A long while ago, I used to have to do this with another renderer that I used.
It can be done, by writing either a stand-alone program or a Photoshop filter
(I did the latter, but the filter I wrote isn't going to work with current
versions of Photoshop).

It's cumbersome and with POV 3.6 is entirely unnecessary.

Conclusion:

For any application of POV where an overlay with a transparent background is
required (this includes Warp's example of a PNG for a website) the behaviour
currently in 3.7 is a disaster - there will be a halo of background colour
around the image which can only be removed with considerable difficulty. In
3.6, it just worked.

At the very least a switch is required to allow 3.6 behaviour to be maintained.

Post a reply to this message

Maybe this change history entry from the POV beta page might give you helpful
clues:

---snip---

Alpha Changes
  -------------

  Some changes have been made to the way alpha is handled when +UA is activated.
  Firstly, in previous versions, specifying a background with the background
  keyword would by default supply a background with transmit set to 1.0 (i.e.
  fully transparent provided that +ua is being used). This is no longer the
case.

  While the default background is transparent, any background specified in a
  scene file (unless 3.6 or earlier compatibility is being used) will now be
  opaque unless transmit is explicitly given. (In other words, use rgbft<>
  rather than rgb<> in the background statement if you want the old behaviour).

  Secondly, the way that objects are blended with the background has changed.
  Previously the color of the background was not taken into account when
  calculating effects of transmission through translucent objects when +ua is
  in effect (i.e. where the background could otherwise have been seen through
  the object). Now, however, the background color is taken into account, even
  if it is not otherwise visible. (In other words, blending is performed in the
  same way regardless of the presence of background transparency).

  Note that this change is not affected by the #version directive, so it may
  change the appearance of scenes written for version 3.6 and earlier. We will
  monitor feedback on this from beta testers to evaluate the impact of this.

---snip---

So, if I interpret these statements correctly, explicitly specifying the
background color as "rgbt 1" might do the trick.

Did you already try adding a "#version 3.6" statement to your scene file?

Post a reply to this message

clipka <nomail@nomail> wrote:
>   Secondly, the way that objects are blended with the background has changed.
>   Previously the color of the background was not taken into account when
>   calculating effects of transmission through translucent objects when +ua is
>   in effect (i.e. where the background could otherwise have been seen through
>   the object). Now, however, the background color is taken into account, even
>   if it is not otherwise visible. (In other words, blending is performed in the
>   same way regardless of the presence of background transparency).

  As I wrote in my original post, I still very strongly protest against
this decision.

  This is how POV-Ray 3.1 (and maybe 3.5, I don't remember) worked, and
it was flawed. It made rendering images with a transparent background
mostly useless.

  It was specifically changed for 3.5 or 3.6 (I don't remember which) to
fix this flaw. You *don't* want the background color to be taken into
account when rendering against a completely transparent background. This
makes it useful to render with transparent background because now the
resulting image can be used to blend it with something else in third-party
programs (such as image editors or web browsers).

  Now in 3.7 this has been reverted to the old, flawed behavior, and now
we once again have undesired background color blended in with the
semi-transparent pixels, ruining the image and making it mostly useless.

  3.6 worked correctly (and not only with antialiasing but also with
semi-transparent objects and media). The reverted behavior in 3.7 is
flawed and has made the results useless once again.

  I can't understand why this was reverted. Maybe the reason for the 3.6
behavior has been forgotten?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I can't understand why this was reverted. Maybe the reason for the 3.6
> behavior has been forgotten?

Maybe you should have read the whole post because as usual you 
miss-construct the facts to cause an argument over a non-issue.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Warp wrote:
> >   I can't understand why this was reverted. Maybe the reason for the 3.6
> > behavior has been forgotten?

> Maybe you should have read the whole post because as usual you 
> miss-construct the facts to cause an argument over a non-issue.

  I apologize, but I don't really understand what you are referring to.
Could you please be a bit more specific?

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   I can't understand why this was reverted. Maybe the reason for the 3.6
> behavior has been forgotten?

If it really doesn't work even with "transmit" set on the background, then I'd
expect so. After all, the PNG spec explicitly states:

"The color values stored for a pixel are not affected by the alpha value
assigned to the pixel. This rule is sometimes called "unassociated" or
"non-premultiplied" alpha. (Another common technique is to store sample values
premultiplied by the alpha fraction; in effect, such an image is already
composited against a black background. PNG does not use premultiplied alpha.)"

So even with a black background, mixing that in would be the wrong way to do it.

There may be a rationale behind the new 3.7 behavior: In a non-anti-aliased
shot, apps that don't support alpha would display the original background.
However, this rationale breaks down as soon as anti-aliasing comes into play,
or semi-transparent objects. And it violates the specs.

So wherever the background is mixed in, alpha must be set to fully opaque there.
That's a clear one for PNG.

Which hints at another problem with the new 3.7 behavior: It seems that this is
dealt with in the backend; but a look at the PNG spec indicates that it is in
fact a file-format dependent issue, and should therefore be handled in the
frontend.

Post a reply to this message