I don't know if this situation has ever been discussed in the newsgroups. I've
been meaning to post about it for several years(!); I apologize for its extreme
lateness.

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: As
the transmit all value goes from 0 to 1, the opaque part of the image does
indeed fade out as expected; but the 'masked-off' part of the image-- which
begins by being fully transparent-- actually fades IN, and in an odd way that's
hard to describe. Basically, the normally-invisible 'background' color of the
alpha-channel's mask area fades in with a *complementary* color, and looks like
*filtered* transparency. Very strange. This happens in POV-Ray v3.7 as well as
v3.62.

See the attached image for a visual description. (Normally, the 'invisible' part
of an alpha-channel image has either a white or black color as a default
'background'; I changed that in Photoshop to be more colorful before running the
renders in POV-Ray, in order to show the odd result.)

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

I realize that the idea of fading-out an image that *already* has a mask
attached may seem redundant or unnecessary; but the technique can be really
useful for custom-shaped 'decals' or logos or whatever (with soft-edged masks as
well.) Presently, the only way that I know of to do this fade-out is to prepare
*multiple* PNG images-- each with a slightly different alpha-channel-- and call
them in sequence during the animation. Not very elegant! (There might be a way
of doing this trick by splitting the image into four(?) functions first, in
POV-Ray, then manipulating the 't' function; but offhand, I don't yet know how
that could be done.)

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.
B) POV-Ray's transparency code was written before PNG was invented (?!)
C) There's an unforeseen flaw in how POV-Ray 'sees' an image's alpha-channel
information.

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.
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?

Post a reply to this message

Attachments:
Download 'transmit_all_problem.jpg' (126 KB)

Preview of image 'transmit_all_problem.jpg'

"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

I forgot to mention that my TIFF image experiment showed some additional quirky
behavior in POV-Ray (in addition to the main problem.)  Actually, I never use
TIFF images for this fade-out trick-- in fact, I rarely make TIFF images at all!
But it seemed like an interesting experiment to try...

I used an animation to check it out, with 'transmit all' based on the clock
value. (My TIFF image_map has a soft-edged alpha-channel matte.) The result-- as
'transmit all' goes from 0 to 1-- shows that POV-Ray treats the alpha-channel as
either 'on or off', depending on some threshold value as transmit changes. In
other words, it looks like a (changing-size) hard-edged matte. The other
strangeness is that final full-transparency of the 'opaque' parts of the image
do not occur until transmit reaches 1.0 (or very nearly so), at which point the
opaque-to-transparency shift is quite abrupt. (Actually, the 'final
transparency' seems to depend on the invisible background color of the TIFF
image(!), as evidenced by the black-to-white gradation that I added to the
original image_map.)

Funny thing: I looked up the TIFF file format on Wikipedia-- a long and detailed
technical discussion there-- but it fails to even mention that an alpha-channel
can be used with a TIFF image(!). I had to look elsewhere. I'm guessing that
TIFF encodes alpha-channel information in an entirely different way than a PNG
file.

Post a reply to this message

Attachments:
Download 'tiff_alpha_channel_example.jpg' (516 KB)

Preview of image 'tiff_alpha_channel_example.jpg'

Am 10.01.2016 um 19:02 schrieb Kenneth:

> Funny thing: I looked up the TIFF file format on Wikipedia-- a long and detailed
> technical discussion there-- but it fails to even mention that an alpha-channel
> can be used with a TIFF image(!). I had to look elsewhere. I'm guessing that
> TIFF encodes alpha-channel information in an entirely different way than a PNG
> file.

Did I already mention associated (aka pre-multiplied) vs. unassociated
(aka non-premultiplied) alpha?

As a matter of fact, what you're seeing is the effect of an image using
unassociated alpha being incorrectly interpreted as using associated alpha.

As mentioned earlier, PNG uses unassociated alpha, and so does your TIFF
image. But POV-Ray isn't aware of the fact.

With the PNG image file format, the use of unassociated alpha is
mandatory. With TIFF, either mode may be used.

When I cleaned up alpha handling in POV-Ray, I knew TIFF supported
associated alpha, but wasn't aware it allowed both modes, so I
hard-coded it to associated alpha. I never got around to implementing
auto-detection when I later learned that TIFF even provides a header
field informing of the mode used.

I was well aware however that file formats with transparency support
were sometimes created with the wrong alpha mode (heck, even POV-Ray
itself did that prior to 3.7), so I provide a mechanism for users to
override POV-Ray's defaults, by explicitly specifying "premultiplied
off" or "premultiplied on" after the image file name.

In your case, you'll want to use "premultiplied off".

Post a reply to this message

>
Clipka wrote:
>
> I was well aware however that file formats with transparency support
> were sometimes created with the wrong alpha mode (heck, even POV-Ray
> itself did that prior to 3.7), so I provide a mechanism for users to
> override POV-Ray's defaults, by explicitly specifying "premultiplied
> off" or "premultiplied on" after the image file name.
>
> In your case, you'll want to use "premultiplied off".

Yes indeed, that does eliminate the 'hard-edged matte' quirkiness of my
fading-out TIFF image. Thanks for pointing this out. I'm embarrassed to admit
that I *did* read about the new 'premultiplied' keyword-- then promptly forgot
about it.  :-(  I just gave the docs there a good re-reading!  I actually wasn't
sure *why* it was necessary, until now. What a big difference it makes!

So all that remains is to find a fix for the previously-mentioned 'transmit all'
transparency problem, with its erroneous complementary colors etc.  ;-)

Thanks again for taking the time to explain this complex situation so well.

Post a reply to this message

Am 11.01.2016 um 04:09 schrieb Kenneth:

>> In your case, you'll want to use "premultiplied off".
> 
> Yes indeed, that does eliminate the 'hard-edged matte' quirkiness of my
> fading-out TIFF image. Thanks for pointing this out. I'm embarrassed to admit
> that I *did* read about the new 'premultiplied' keyword-- then promptly forgot
> about it.  :-(  I just gave the docs there a good re-reading!  I actually wasn't
> sure *why* it was necessary, until now. What a big difference it makes!

No reason to be embarrassed: People just forget about stuff if they
don't know what it's good for.

> So all that remains is to find a fix for the previously-mentioned 'transmit all'
> transparency problem, with its erroneous complementary colors etc.  ;-)

Working on it; there's a catch to it though: Currently the injection of
the "transmit all" component happens before compensating for whatever
gamma mode is used in the image. I'll need to wrap my head around the
implications for the formula, or move it someplace else.


> Thanks again for taking the time to explain this complex situation so well.

You're welcome.

By the way, would you mind posting your TIFF test image? The tools I
have at my disposal to quickly create a TIFF with alpha channel all give
me the other alpha mode.

Post a reply to this message

Am 11.01.2016 um 04:09 schrieb Kenneth:

> Yes indeed, that does eliminate the 'hard-edged matte' quirkiness of my
> fading-out TIFF image. Thanks for pointing this out. I'm embarrassed to admit
> that I *did* read about the new 'premultiplied' keyword-- then promptly forgot
> about it.  :-(  I just gave the docs there a good re-reading!  I actually wasn't
> sure *why* it was necessary, until now. What a big difference it makes!
> 
> So all that remains is to find a fix for the previously-mentioned 'transmit all'
> transparency problem, with its erroneous complementary colors etc.  ;-)

The newest `master` branch should fix the interaction between image
alpha channel and "transmit all" (and "filter all" likewise), AND also
implement auto-detection of TIFF alpha mode.

As I'm not really sure whether some existing scenes might be relying on
the old quirk, the new "transmit/filter all" behaviour requires
"#version 3.71".

I'll publish one of those famous(?) semi-official builds once I've
gotten me a fresh batch of round tuits (presumably next weekend).

Post a reply to this message

On 11-1-2016 8:08, clipka wrote:

> I'll publish one of those famous(?) semi-official builds once I've
> gotten me a fresh batch of round tuits (presumably next weekend).
>

I found a few old ones in my drawer. Just needs dusting off. Shall I 
send them to to you? :-)

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> On 11-1-2016 8:08, clipka wrote:
>
> > I'll publish one of those famous(?) semi-official builds once I've
> > gotten me a fresh batch of round tuits (presumably next weekend).
> >
>
> I found a few old ones in my drawer. Just needs dusting off. Shall I
> send them to to you? :-)

Please do so - I can always use a few extra ones :)

Post a reply to this message

On 11-1-2016 13:29, clipka wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> On 11-1-2016 8:08, clipka wrote:
>>
>>> I'll publish one of those famous(?) semi-official builds once I've
>>> gotten me a fresh batch of round tuits (presumably next weekend).
>>>
>>
>> I found a few old ones in my drawer. Just needs dusting off. Shall I
>> send them to to you? :-)
>
> Please do so - I can always use a few extra ones :)
>
>
The homing pigeon is on its way. :-)

-- 
Thomas

Post a reply to this message