"Dave Blandston" <nomail@nomail> wrote:
> This was addressed a few years ago...
>
>
https://news.povray.org/povray.binaries.images/thread/%3C569528cc%241%40news.povray.org%3E/
>
> Interestingly enough, the fellow who brought it up (Kenneth) was doing exactly
> what I'm doing, which is making image_maps fade in and out during animation.

Hi all! I'm still here :-)  I have not posted to the newsgroups in probably
eight months(!) -- real-life and work took over. But I have tried to keep up
with many of the posts and topics since then, and have been working on some
interesting POV-ray stuff too. Sorry that I'm coming late to this discussion.

This 'transmit all' stuff has a strange mix of flaws, even in v3.8.0 beta 1
which I am currently running in Windows.

Although Clipka did fix the situation way back in 2016, with
         v3.7.1-alpha.8431463%2Bav74
(which 'piggy-backs' on v3.7.0),  it is sadly no longer available on the Github
site, and I don't have a copy. Unfortunately, the newer v3.8xx has reverted to
some older code, AFAIK.

BTW, I also use paint.net to make my .png alpha-channel images now, which works
well-- or I use such images made in POV-ray.

I just did more tests in v3.8 -- hopefully thorough-- and this is what I have
found:
1) 'transmit all' completely IGNORES typical 24-bit .jpeg images AND 24-bit
..pngs(!) That's really strange, because at least .jpegs  worked as far back as
v3.7.0. (I just tested it again.)

2) It seems that 'transmit all' works only with 32-bit images now-- for example,
..png saved as 32-bit rather than 24-bit, with or without a 'real' alpha channel.
 In paint.net, it is easy to save (or re-save) 24-bit images there as 32-bit
..png. I don't know if that creates a 'dummy' alpha channel when one does not
exist, but I assume that it does.

3) There is a strange  and interesting work-around to these problems: In my v3.8
scene file -- with #version 3.8 at the top of the file, as it should be-- if I
change that to #version 3.7 (while still running v3.8), transmit all works
CORRECTLY with .jpeg images, 24-bit .pngs (no alpha-channel), and 32-bit .pngs
(no 'real' alpha-channel). But, it introduces visual/color flaws in 32-bit .pngs
that have a 'real'  alpha-channel.

So between the two #version statements, it is possible to fix all of the
problems in 3.8xx... or by changing all images to 32-bit. It's not an ideal
situation, but it's expedient :-)  I have not yet tried using v3.8.0 beta 2 (the
latest), but I assume that its behavior is the same as beta 1.

Post a reply to this message