POV-Ray : Newsgroups : povray.beta-test : A step back in alpha transparency (+ua) blending? : Re: A step back in alpha transparency (+ua) blending? Server Time
28 Jul 2024 16:16:31 EDT (-0400)
  Re: A step back in alpha transparency (+ua) blending?  
From: Ian McAulay
Date: 20 Mar 2009 12:40:00
Message: <web.49c3c68b9a0ca7fa4eaf1cbf0@news.povray.org>
(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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.