"Kenneth" <kdw### [at] gmailcom> wrote:

> When animating in POV-Ray, I sometimes like to 'fade out' an image_map pigment
> over time, using 'transmit all' (and 'clock', for example.) This works perfectly
> well for JPEG, BMP (Windows-specific) and 'basic' PNG images-- i.e., images that
> do not have a built-in alpha channel.
>
> Like this:
>
> pigment{
>  image_map{jpeg "my_image.jpg" once interpolate 2 transmit all *some value*}
>        }
>
> But if the image has been pre-made with an alpha-channel mask (a PNG file for
> example, made in Photoshop),'transmit all' produces some unexpected results:

Looks odd indeed, but doesn't surprise me in the least.

I hope to have a closer look at this during the weekend.

> I tried an alpha-channel TIFF image, too; same behavior. I even tried a POV-made
> alpha-channel PNG image; same behavior.

OpenEXR might also be worth trying; as it is using "associated" (aka
"premultiplied") alpha, as opposed to the "unassociated" (aka non-premultiplied)
alpha used in PNG, the behaviour might be different there.

> I realize that the idea of fading-out an image that *already* has a mask
> attached may seem redundant or unnecessary;

Not at all.

> I have my own guesses as to why this doesn't work:
> A) 'Transmit all' was never designed to do work with an alpha channel.

Indeed, it absolutely wasn't.

> B) POV-Ray's transparency code was written before PNG was invented (?!)

Again, absolutely. It's one of the reasons behind (A).

> C) There's an unforeseen flaw in how POV-Ray 'sees' an image's alpha-channel
> information.

As a matter of fact POV-Ray's PNG alpha handling used to be wrong, but that was
on image output. I had given the entire alpha handling a thorough overhaul
during the 3.7 beta phase to make sure we're doing everything strictly according
to the specs.

BUT I guess I didn't address potential interference between 'transmit all' and
an image's inherent alpha channel.


> From the visual behavior of the results, it seems that POV's transparency code
> is (naturally) trying to alter not just the 'opaque' part of the image_map, but
> also the areas where there is already 'full transparency'-- as if all the
> underlying PNG image 'information' is of the same type, to be treated equally.

It has to be all of the same type, because in between the special cases "opaque
coloured" and "fully transparent" we have a continuum of the general case
"coloured, with X% transparency".

I expect the problem to be somehow related to alpha premultiplication: In a PNG
image, the data is stored with full colour information, even for the transparent
portions. In POV-Ray however, we need to multiply the colour information with
the opacity, because we'll add the resulting colour to the light transmitted
from the background. But if the opacity turns out to be negative (because we're
probably just adding the 'transmit all' value to the image's inherent
transparency, giving us a transparency of >1) we'll actually be /subtracting/
colour from the background.


> My own (naive) suggestion for a fix would be to 'clamp' any full-transparency
> values, encountered in the image's alpha-channel or during the fade, to a fixed
> 'base' value. Would that make sense?

No, the proper handling would be to /multiply/ the image's inherent opacity with
the 'transmit all'-governed opacity. This way even semi-transparent portions of
an image (such as at the border between the transparent and opaque portions of
the image) will fade properly.

Post a reply to this message