> 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