hi,

"Dave Blandston" <nomail@nomail> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > ...
> > What you should have done from the beginning is _upgrade to version 3.8_.
>
> ... will have to wait until I build up the motivation.

see if that (rich) list of "new" can help build "the motivation" :-)

<https://wiki.povray.org/content/Documentation:Tutorial_Section_1#Changes_and_New_Features_Summary>


regards, jr.

Post a reply to this message

"Dave Blandston" <nomail@nomail> wrote:

> Oh shoot I decided to give it a try but since I bought a new computer a few
> years ago I haven't set it up to compile stuff so it'll be a little bit more of
> a job that will have to wait until I build up the motivation.

No excuses, slacker.  Get crackin'   :P

https://github.com/POV-Ray/povray/releases/tag/v3.8.0-beta.2


https://github.com/POV-Ray/povray/releases/download/v3.8.0-beta.2/povwin-v3.8.0-beta.2-setup.exe

How motivating it THAT?    :D

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> No excuses, slacker.  Get crackin'   :P
>
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-beta.2
>
>
>
https://github.com/POV-Ray/povray/releases/download/v3.8.0-beta.2/povwin-v3.8.0-beta.2-setup.exe
>
> How motivating it THAT?    :D



Hey cool I thought we all had to compile the source code ourselves. So version
3.8 will be lots of fun to learn about. And sure enough, it handles "transmit
all" with .png transparency differently than version 3.7 but still not how I
think would be most useful. In the sample image attached (made with version
3.8), there are multiple layers of .png images - some with transparent areas and
some without. The transparent areas affect the layers beneath them and in my
opinion, this is not a desirable effect. I'm not complaining, just pointing it
out in case it's an oversight. I also discovered another problem that I'll have
to experiment with to try to figure out what might be going on if anyone is
interested.

Thanks for helping me get caught up to the new version guys!

Post a reply to this message

Attachments:
Download 'untitled.jpg' (123 KB)

Preview of image 'untitled.jpg'

On 30.12.2022 00:01, Dave Blandston wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
>> color mapped images are image with a palette, not true/direct color.
>>
>> For example, gif is always palette mapped, whereas jpeg is not.
>> Png is variable: it could have a palette or not.
>> ("indexed": there is a palette; grayscale & truecolor: no palette)
>>
>> This has nothing to do with transparency channel;
>> Gif can have it, png too, but I have never seen jpeg with it.
>>
>> Alain suggested to not use "transmit all" for that picture, but to have
>> the transparency directly from the picture. (without any modifier)
>>
>> You would edit first the transparency in your favorite editor and voilà.
> 
> 
> 
> Using a paint program to adjust the transparency is what I'm currently doing to
> achieve the result that I want but it's not a perfect solution because of the
> number of images involved. I'm using the "transmit all" feature to animate some
> elements of a website mockup animation that fade in and fade out, such as
> buttons and pop-ups and such. Images that don't require different levels of
> transparency work great and I can use "transmit all," and only one copy of the
> image needs to be made. But images that require part of the image to be fully
> transparent exhibit the problem in the image posted above, so I can't use
> "transmit all" and I have to make many copies of the image with the varying
> levels of transparency which is very tedious. That's why I was curious if there
> was a better way so I just thought I'd ask. I should have a sample animation
> ready to post soon that will make this more clear. It's a fun project.
> 

You can use a pigment function to get control over the transmit value:



#version 3.7;

global_settings {assumed_gamma 2.2}

camera {
    orthographic
    location <0, 0, -1>
    right image_width / image_height * x
    direction <0, 0, 1>
    look_at <0, 0, 0>
} //camera

#include "colors.inc"

background {Orange}

#local ImagePigment    = pigment {image_map {png "ABBA.png" gamma 2.2 map_type 0 once
} }
#local ImageResolution = max_extent (ImagePigment);

#local ImageFunction   = function {pigment { ImagePigment} }

#local FADE_STRENGTH = 0.5;

#local FR = function {ImageFunction(x,y,z).red}
#local FG = function {ImageFunction(x,y,z).green }
#local FB = function {ImageFunction(x,y,z).blue }
#local FT = function {1 - (1 - FADE_STRENGTH) * (1-ImageFunction(x,y,z).transmit) }

#local FadePigment = pigment { average pigment_map
{
    [function{FR(x,y,z)} color_map{[0 rgb 0][1 rgbft 4*<1,0,0,0,0>]}]
    [function{FG(x,y,z)} color_map{[0 rgb 0][1 rgbft 4*<0,1,0,0,0>]}]
    [function{FB(x,y,z)} color_map{[0 rgb 0][1 rgbft 4*<0,0,1,0,0>]}]
    [function{FT(x,y,z)} color_map{[0 rgb 0][1 rgbft 4*<0,0,0,0,1>]}]
}

}


object {
    box {<0, 0, 0> <1, 1, .01>}
    texture {pigment {FadePigment} finish {emission .9} scale <1, 1.0000001, 1>}
    translate <-.5, -.5, 0>
    scale <1, ImageResolution.y / ImageResolution.x, 1>
} //object

Post a reply to this message

"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

Christian Froeschlin <chr### [at] chrfrde> wrote:
>
> You can use a pigment function to get control over the transmit value:
>
[snip]
> #local FR = function {ImageFunction(x,y,z).red}
> #local FG = function {ImageFunction(x,y,z).green }
> #local FB = function {ImageFunction(x,y,z).blue }
> #local FT = function {1 - (1 - FADE_STRENGTH) * (1-ImageFunction(x,y,z).transmit) }
>
> #local FadePigment = pigment { average pigment_map
> {
>     [function{FR(x,y,z)} color_map{[0 rgb 0][1 rgbft 4*<1,0,0,0,0>]}]
>     [function{FG(x,y,z)} color_map{[0 rgb 0][1 rgbft 4*<0,1,0,0,0>]}]
>     [function{FB(x,y,z)} color_map{[0 rgb 0][1 rgbft 4*<0,0,1,0,0>]}]
>     [function{FT(x,y,z)} color_map{[0 rgb 0][1 rgbft 4*<0,0,0,0,1>]}]
> }
....

Yes indeed, that does also work-- at least in v3.8.0 beta 1, and with ALL of the
various kinds of 24-bit and 32-bit images! Good news.

I set my own functions up a bit differently, but the results are the same:

#declare TEMP_IMG =
pigment{
   image_map{
        jpeg "MY_IMAGE.jpg" // or .png
        once
        interpolate 2
        // no 'transmit all' here
            }
}

#declare IMG_FUNCTION =
function{pigment{TEMP_IMG}}

#declare FINAL_IMG =
pigment{
     average
     pigment_map{
[1 function{IMG_FUNCTION(x,y,z).red} color_map {[0,rgb 0][1,rgb <1,0,0>]}
[1 function{IMG_FUNCTION(x,y,z).green} color_map {[0,rgb 0][1,rgb <0,1,0>]}]
[1 function{IMG_FUNCTION(x,y,z).blue} color_map {[0,rgb 0][1,rgb <0,0,1>]}]
[1 function{IMG_FUNCTION(x,y,z).transmit}
               color_map {[0, transmit 0][1,transmit 4]}]
                }
       }

Then, to vary the transparency, I adjust the 'transmit' channel's FIRST
color-map value between 0 and 4. Like,
             color_map {[0, transmit 4*clock][1,transmit 4]}


[ I personally prefer the rgb colors to be 'weights' of 1 instead of 4-- except
for 'transmit'-- then later use finish{ambient 4 emission 0 diffuse 0}  In the
past, I have noticed a slight change in color contrast(?) when I give the
function's color_maps a large value like 4. But that may have been a quirk in
how I used the final pigment, so I can't say yes or no absolutely. In other
words, does a value larger than 1.0 cause any 'clipping' in the functions?]

Post a reply to this message

On 09.01.2023 23:38, Kenneth wrote:


> In other words, does a value larger than 1.0 cause any 'clipping' in the functions?]

I wouldn't expect any issues here as the color values are just some temporary numbers
that the average pattern will divide by 4 again (in this case). Basically I aimed to
make
the pigment a drop-in replacement with same color values as the original image map.

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> On 09.01.2023 23:38, Kenneth wrote:
>
>
> > In other words, does a value larger than 1.0 cause any 'clipping' in
> > the functions?
>
> I wouldn't expect any issues here as the color values are just some
> temporary numbers that the average pattern will divide by 4 again (in
> this case).

You are right about that. I just did a test with *extreme* values for the three
rgb color functions -- like <60,0,0> (!) , and of course compensated my
finish{ambient...} value-- and I don't see any visual difference at all when
compared to using <1,0,0>.

Thanks for putting my erroneous 'clipping' thought to rest, once and for all.


> Basically I aimed to make the pigment a drop-in replacement with same
> color values as the original image map.

Yes, that makes sense. No fiddling with the finish{...} values are required.

Post a reply to this message

Converting to PNG files works well for me.

I use this a lot as a template overlay object.

Post a reply to this message