While playing with functions came upon this:
 you can create a macro that outputs a function with other #local functions
supporting that function and you call that macro several times for different
outputs.

Like this example:

#macro Gf_waves(r,c,d,V)
  #local g=radians(r);
  #local h=V*<1,1,1>+<.5,0,.5>;
  #local q=<c,1,d>;
  #local PigFa= function {pigment {waves color_map{[0,rgb 0][1,rgb 1]} scale q
        rotate y*r translate h}};
  #local PigF0= function {1-PigFa(x,0,z).hf}
  function(x,z){PigF0(x,0,z)}

#end

Used like this:

#declare Small_Waves=Gf_waves(0,1,1,0)
#declare Mid_Waves=Gf_waves(0,2,2,0)
#declare Big_Waves=Gf_waves(0,9,9,0)

The neat part is that you can used the #local function names in another macros
without conflict.

and you can combine functions like this

#declare Ground=function(x,z){Mat(x,z)*Dirt(x,z)}

I use version 3.7 haven't try it on any of the other versions.

Post a reply to this message

hi,

"Leroy" <whe### [at] gmailcom> wrote:
> While playing with functions came upon this:
> ...
>   #local PigF0= function {1-PigFa(x,0,z).hf}
> ...
> I use version 3.7 haven't try it on any of the other versions.

the macro parses ok on 3.8 beta.2, but WFP's 'povr' chokes on the '.hf'
("Invalid member access").  as it should, perhaps, can't find it in the
documentation.

<https://wiki.povray.org/content/Reference:Vector_Expressions#Dot_Item_Access_for_Vectors>
<https://wiki.povray.org/content/Reference:Color_Expressions#Dot_Item_Access_for_Colors>


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> the macro parses ok on 3.8 beta.2, but WFP's 'povr' chokes on the '.hf'
> ("Invalid member access").  as it should, perhaps, can't find it in the
> documentation.

There was a Loooooooooooooooooooooong discussion of this over here:

http://news.povray.org/povray.advanced-users/message/%3C578a31c0%241%40news.povray.org%3E/#%3C578a31c0%241%40news.povra
y.org%3E

There are also height_field macros in shapes.inc, so maybe there is something
there that will bear fruit.

- BW

Post a reply to this message

On 2/25/23 03:58, jr wrote:
> hi,
> 
> "Leroy" <whe### [at] gmailcom> wrote:
>> While playing with functions came upon this:
>> ...
>>    #local PigF0= function {1-PigFa(x,0,z).hf}
>> ...
>> I use version 3.7 haven't try it on any of the other versions.
> 
> the macro parses ok on 3.8 beta.2, but WFP's 'povr' chokes on the '.hf'
> ("Invalid member access").  as it should, perhaps, can't find it in the
> documentation.
> 
>
<https://wiki.povray.org/content/Reference:Vector_Expressions#Dot_Item_Access_for_Vectors>
>
<https://wiki.povray.org/content/Reference:Color_Expressions#Dot_Item_Access_for_Colors>
> 

Yes. I removed the .hf option in povr at some point. In part because it 
was an undocumented feature.

As best my memory serves...

The larger reason is it was a kind of on the cheap grey scale conversion 
used only for <= 8 bit channel deep color images which creates a 16 bit 
deep value from the red and green color channels(a). We should today 
always be using Greyscale() / .gray where we have color from which we 
want a single grey / luminosity value(b)

Bill P.

--- There is more for those wanting to run this particular rabbit hole...

(a) - The method treats green as the most significant 8 bits and red as 
the least significant 8 bits for 16 bits total - (HF_VAL)s. It is STILL 
in all POV-Ray, including povr, as the (undocumented too, I believe) 
method used when converting image_map '8 bit color image' pixel 
positions to a 16 bit deep, height_field height. It looks to me to 
always have been somewhat of a cheat to get 16 bits of depth in the only 
8 bit channel (or indexed) image days.

So you ask, what happens with height field color images with a bit depth 
of >8 <=16. Well, here we get Greyscale(). This, for example, means 
users playing with bit depths - as they now can in several POV-Ray 
outputs with v3.8+ - will see behavior they cannot easily understand for 
<=8 bits and .gray otherwise when using .hf or the still existing 
image_map Green/Red conversion. Users in prior versions are exposed to 
confusion too, if they are working with 8 and 16 bit color channel depths.

Functions return double float values. The values are clipped/confined to 
a 0-1 range as a ramp wave. This always so in POV-Ray releases. It's 
true by default in povr, but other ranges are allowed as options.

Let's think about what is really going on in Leroy's example. He's 
already converted to grey by using a 0-1 color_map. The expedient thing 
to do is use one of the .r, .g or .b channels directly. What happens 
with .hf is we end up with a least significant byte, 'grey echo' from 
the red channel on top of the most significant high order byte green 
channel's value. In other words, it is not real 16 bit grey resolution 
or even a clean 8.

Further, while Leroy's the code is perfectly valid in creating a pigment 
based function, it would be more efficient here to use the pattern 
mechanism directly.

The code:

#local PigFa= function {pigment {
     waves color_map{[0,rgb 0][1,rgb 1]}
     scale q rotate y*r translate h}};
#local PigF0= function {1-PigFa(x,0,z).hf}

would be more efficient as (I didn't run this...):

#local PatFa= function {pattern { waves
     scale q rotate y*r translate h}}
#local PatF0= function {1-PatFa(x,0,z)}

(b) - The internal .Greyscale() method in POV-Ray proper is close to, 
but not quite, ITU-R 601. It works fairly well when using the older 
assumed_gamma 2.2 internal gamma correction on non-linear textures / 
materials. Better for assumed_gamma 1.0 and the default sRGB output is 
ITU-R 709 (c) and povr has converted to this option as the default color 
to grey scale conversion. The povr fork is configurable with about a 
half dozen color to luminosity options including the old non-standard 
POV-Ray method. Related: V3.8 added image gamma options in the bt709 and 
bt2020 keywords.

An Alert! Related to (b), and my memory is foggy, but some number of 
official v3.8 releases, and over some period of time on github, the 
color to grey scale conversion in certain situations had a significant bug.

(c) - Cousin Ricky created SDL macros for the ITU-R 709 color to 
greyscale conversion some time back. Sorry, I don't have a link handy.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> An Alert! Related to (b), and my memory is foggy, but some number of
> official v3.8 releases, and over some period of time on github, the
> color to grey scale conversion in certain situations had a significant bug.

All I remember is that some folks commented that there was the 255 256 division
issue:
http://news.povray.org/5782990f%40news.povray.org

I found a color conversion equation someone was using (probably for a shader)
that claimed to take into account the differnce in eye response to the different
color wavelengths:
(Y = 0.2126R + 0.7152G + 0.0722B).

POV-Ray color conversion equations:
http://news.povray.org/web.577e98cbff0686005e7df57c0%40news.povray.org

clipka says .hf is mentioned in the isosurface tutorial
http://news.povray.org/57822645%241%40news.povray.org
And so it is, about halfway down, at the bottom of noise and pigment functions

https://wiki.povray.org/content/Documentation:Tutorial_Section_3.2


Here was my take:
http://news.povray.org/web.577ee122ff0686005e7df57c0%40news.povray.org

- BW

Post a reply to this message

On 2/25/23 07:39, William F Pokorny wrote:



> Functions return double float values. The values are clipped/confined to 
> a 0-1 range as a ramp wave. This always so in POV-Ray releases. It's 
> true by default in povr, but other ranges are allowed as options.

On grabbing my first coffee it hit me the above statement is a mess. 
Plus I flipped the red and green significance of the .hf kind of grey 
conversion while writing...

---

Functions return one float value or float vectors. The components of the 
float vectors are doubles too - except for (5d) color vectors, which end 
up as single floats. Functions can return any valid double, but 
downstream consumers may not be able to make use of values outside the 
0-1 range.

I believe the vector component values are clamped to a 0-1 range. 
However, as I write this I'm not 100% sure... Can we get a vector 
component value of say 100.0 function to vector and visa versa?

As used in a height_field or image_map the values would end up with the 
ramp_wave (mod) kind of wrapping, but is that happening in the function 
vector return mechanism or elsewhere...?

The wrapping is happening elsewhere!

If I code up:

#declare Fn00 = function { pigment { rgb <222,333,444> } }
#declare Fn01 = function { Fn00(0,0,0).gray }
#declare Fn02 = function { Fn00(0,0,0).hf }

#debug concat("_pt=<", vstr(3, Fn00(0,0,0), ",", 0, 3), ">\n")
#debug concat("_pt=<", vstr(3,
<Fn00(0,0,0).x,Fn00(0,0,0).y,Fn00(0,0,0).z>, ",", 0, 3), ">\n")

#debug concat("Fn00(0,0,0).grey : ",str(Fn01(0,0,0),0,-1)," \n")
#debug concat("Fn00(0,0,0).hf : ",str(Fn02(0,0,0),0,-1)," \n")

and run it in v3.8 beta 2 I get:

Fn00 : 222.000,333.000,444.000>
Fn00 .x .y .z : 222.000,333.000,444.000>
Fn00(0,0,0).grey : 312.687000
Fn00(0,0,0).hf : 222.433426

Interesting. I learned something new.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> Yes. I removed the .hf option in povr at some point. In part because it
> was an undocumented feature.

Not where it should be: 2.3.3.3.7 Noise and pigment functions

quote:

And two special purpose operators, their supported dot types to access these
operators are:

Note: The .hf operator is experimental and will generate a warning.
1.fn_Pigm( ).gray to get the gray value of the color vector
gray value = Red*29.7% + Green*58.9% + Blue*11.4%
2.fn_Pigm( ).hf to get the height_field value of the color vector
hf value = (Red + Green/255)*0.996093



ingo

Post a reply to this message

On 2/25/23 08:24, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> An Alert! Related to (b), and my memory is foggy, but some number of
>> official v3.8 releases, and over some period of time on github, the
>> color to grey scale conversion in certain situations had a significant bug.
> 
> All I remember is that some folks commented that there was the 255 256 division
> issue:
> http://news.povray.org/5782990f%40news.povray.org
> 
> I found a color conversion equation someone was using (probably for a shader)
> that claimed to take into account the differnce in eye response to the different
> color wavelengths:
> (Y = 0.2126R + 0.7152G + 0.0722B).
> 
> POV-Ray color conversion equations:
> http://news.povray.org/web.577e98cbff0686005e7df57c0%40news.povray.org
> 
> clipka says .hf is mentioned in the isosurface tutorial
> http://news.povray.org/57822645%241%40news.povray.org
> And so it is, about halfway down, at the bottom of noise and pigment functions
> 
> https://wiki.povray.org/content/Documentation:Tutorial_Section_3.2
> 
> 
> Here was my take:
> http://news.povray.org/web.577ee122ff0686005e7df57c0%40news.povray.org
> 
> - BW
> 

Not the issue I was remembering... Can I find it. Ah the updated, paid, 
google search did turn it up!

https://news.povray.org/povray.unix/thread/%3C60144c97%241%40news.povray.org%3E/

Guess I wasn't sure about the bug-ness on initially posting and it ended 
up in p.unix.

Thanks for the references! I need to run, but I'll look them over later.

Bill P.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> There was a Loooooooooooooooooooooong discussion of this over here:

:-)  interesting thread.  thanks.


@WFP

thanks for clarification + input(s); re the red-green thing, confused by "height
field color images", thought they were always just grayscale.


regards, jr.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/25/23 07:39, William F Pokorny wrote:
>

> If I code up:
>
> #declare Fn00 = function { pigment { rgb <222,333,444> } }
> #declare Fn01 = function { Fn00(0,0,0).gray }
> #declare Fn02 = function { Fn00(0,0,0).hf }
>
> #debug concat("_pt=<", vstr(3, Fn00(0,0,0), ",", 0, 3), ">\n")
> #debug concat("_pt=<", vstr(3,
> <Fn00(0,0,0).x,Fn00(0,0,0).y,Fn00(0,0,0).z>, ",", 0, 3), ">\n")
>
> #debug concat("Fn00(0,0,0).grey : ",str(Fn01(0,0,0),0,-1)," \n")
> #debug concat("Fn00(0,0,0).hf : ",str(Fn02(0,0,0),0,-1)," \n")
>
> and run it in v3.8 beta 2 I get:
>
> Fn00 : 222.000,333.000,444.000>
> Fn00 .x .y .z : 222.000,333.000,444.000>
> Fn00(0,0,0).grey : 312.687000
> Fn00(0,0,0).hf : 222.433426
>
> Interesting. I learned something new.
>
> Bill P.

The code works on v3.7 also!

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/25/23 03:58, jr wrote:
> Let's think about what is really going on in Leroy's example. He's
> already converted to grey by using a 0-1 color_map. The expedient thing
> to do is use one of the .r, .g or .b channels directly. What happens
> with .hf is we end up with a least significant byte, 'grey echo' from
> the red channel on top of the most significant high order byte green
> channel's value. In other words, it is not real 16 bit grey resolution
> or even a clean 8.
>
> Further, while Leroy's the code is perfectly valid in creating a pigment
> based function, it would be more efficient here to use the pattern
> mechanism directly.
>
> The code:
>
> #local PigFa= function {pigment {
>      waves color_map{[0,rgb 0][1,rgb 1]}
>      scale q rotate y*r translate h}};
> #local PigF0= function {1-PigFa(x,0,z).hf}
>
> would be more efficient as (I didn't run this...):
>
> #local PatFa= function {pattern { waves
>      scale q rotate y*r translate h}}
> #local PatF0= function {1-PatFa(x,0,z)}
>
True your example is more efficient, But right now I was exploring what
functions can do. I wrote several and just grab one as an example, maybe not the
best. I use the pigment & color_map thinking I could change the color_map to any
of the several I have in stock. It might be interesting!
 I like your point about using the 0-1 color_map I hadn't really thought of it
that way. Just now I notice I didn't need the 1-PigFa(x,0,z).hf I could have
flipped the color_map and used PigFa(x,0,z).hf.
 This is fun!

Post a reply to this message

On 2/25/23 09:59, jr wrote:
> hi,
> 
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> ...
>> There was a Loooooooooooooooooooooong discussion of this over here:
> 
> :-)  interesting thread.  thanks.
> 

Ah, I remember that thread. Also that I gave up on a documentation issue 
therein that was well past any return on investment. :-)

> 
> @WFP
> 
> thanks for clarification + input(s); re the red-green thing, confused by "height
> field color images", thought they were always just grayscale.
> 

:-) My head is always a buzzing mess. Anyone else noticed I'm of late 
often typing 'is' for most any two character word with a leading 'i'. 
:-( A small miracle anyone can make anything of what I write.

---

Anyhow. Color images work as HF input. However, in newer versions of 
POV-Ray I'd recommend never using color inputs directly in a grey scale 
application. Too many ways for it to go astray of intent.

For example, a color image with strong red, green or blue regions will 
create substantially different HFs when encoded as a 16 bit color png vs 
an 8 bit one.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> Anyhow. Color images work as HF input.

But of course.

> However, in newer versions of
> POV-Ray I'd recommend never using color inputs directly in a grey scale
> application. Too many ways for it to go astray of intent.

So, do we just use image_pattern/pigment_pattern and the color to grayscale
conversion is different there?

Or do we "roll our own" color conversion function and daisy-chain that into the
hf?

I suppose the answer is always, "It depends".

How many color to grayscale conversion equations do you currently have in povr?

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

>
> :-) My head is always a buzzing mess. Anyone else noticed I'm of late
> often typing 'is' for most any two character word with a leading 'i'.
> :-( A small miracle anyone can make anything of what I write.

But that's half the fun of deciphering it! :-D  I use my "secret William P.
decoder ring" that came in a box of Cracker Jacks...
>
> Anyhow. Color images work as HF input. However, in newer versions of
> POV-Ray I'd recommend never using color inputs directly in a grey scale
> application. Too many ways for it to go astray of intent.
>
> For example, a color image with strong red, green or blue regions will
> create substantially different HFs when encoded as a 16 bit color png vs
> an 8 bit one.

Ooh, I didn't know that. I need to run (more) tests to see. I did notice an
'oddness' between 8-bits-per-channel vs 16, when running a POV-ray .png render
for HF use, but I didn't know what was causing it.

Post a reply to this message

On 2/25/23 12:52, Bald Eagle wrote:
> So, do we just use image_pattern/pigment_pattern and the color to grayscale
> conversion is different there?
> 

The image_pattern is an unrelated beast meant to work with indexed image 
formats as a way to pick particular entries in a *_map. It's not much 
used these days as far as I know. I used indexed gif files with this 
option maybe 20 years back and I've not played with this feature since. 
Are people using it still?

The pigment_pattern method is a way to be sure you get the inbuilt grey 
scale conversion from a pigments three color channels. The .grey / .gray 
suffixes are another.

> Or do we "roll our own" color conversion function and daisy-chain that into the
> hf?

That is an option. I'd say it's most important to be consistent in the 
color to grey conversion you use. Or, always create and work directly 
with grey image formats.

The thread for that color to grey bug, which existed in the v3.8 
development code for a time, contained a post from Cousin Ricky 
regarding his macros. I'm unsure why two versions on again seeing them 
as either will do I think.

#macro DotGray (Color)
    #local C = color Color;
    (0.2126 * C.red + 0.7152 * C.green + 0.0722 * C.blue) // ITU-R BT.709
#end

---or---

#macro DotGrey (Colour)
    #local C = colour Colour;
    (0.2126 * C.red + 0.7152 * C.green + 0.0722 * C.blue) // ITU-R BT.709
#end

> 
> I suppose the answer is always, "It depends".
> 

:-) It's POV-Ray...

More seriously, if you are working with a color image and want to fix 
the 'as grey' treatment so you don't get surprised, you can use POV-Ray 
itself to do a color to grey image conversion with something like:

povray orthoRenderOfColorImageFile.pov ... \
   +fng16 file_gamma=1.0 +oGreyVersionOfImage.png

You'd then use GreyVersionOfImage.png with a 'gamma 1.0' specification 
when using the file in SDL for an image_map, say. You can, of course, 
create your grey images with POV-Ray too. The height_field feature 
cannot today use more than 16 bits of grey depth.

Take care to keep the grey channel value for HFs within the [0-1] range 
or you'll get ramp value wrapping. Don't use HDRI images, for example.

> How many color to grayscale conversion equations do you currently have in povr?

Let's see... The available color to grey settings in the povr fork.

Note! The configuration setting below does NOT touch the '.hf like' <= 8 
bit color channel to grey red + green height conversion for images. I 
plan to remove that conversion in povr at some point, but it's not done.


The ./configure option is:

GREYREC  Method to use for color to grey value conversion (see 
source/base/configbase.h for details)


// Mangled Doxygen comments below from the header file to try and avoid 
ugly formatting on posting.

@def GREYREC

What ITU-R Recommendation to use when converting color to a grey/gray value.

This setting currently selects one of several sets of constants to use 
during the conversion of RGB values to greyscale values. It relates 
directly to the height field and (ColorV.grey or ColorV.gray) 
functionality within POV-Ray.

The currently supported options are:

111   - The previous long standing POV-Ray method close to Rec 601 and 
most correct at an assumed_gamma of 2.2.

240   - A Society of Motion Picture and Television Engineers (SMPTE) 
proposal 240M rejected as an ITU-R standard. It was aimed to be a 
compromise which worked OK for both SDTVs (Rec.601) and HDTVs Rec.709.

601   - Rec 601. Aimed at SDTVs and most correct at an assumed_gamma of 
2.2 and quite similar to 111.

709   - Rec 709. The default setting for the povr branch. The 
recommendation is aimed at HDTVs with standard dynamic range.  Most 
correct at an assumed_gamma of 1.0 and very near sRGB.  The best general 
choice for v3.8 (povr).

2020  - Rec 2020. UHDTVs with standard dynamic range. The implemented 
form YcCbcCrc at an assumed gamma of 1.0. This version puts an emphasis 
on luminosity and the related color gamut can extend outside an sRGB 
representable space. There is a NOT currently implemented grey 
conversion for YCbCr where the colors pre-corrected to a gamma of 2.4 
prior to calculation. This later form puts the priority on color, but it 
would require more than changes in constants to work in the linear color 
space. Aside: You can effectively play some with this conversion by 
working in an assumed_gamma 2.4 color space.

@note There is too Rec.2100 aimed at HDTVs, UHDTVs with high dynamic 
range of 10-12 bits per channel. No attempt yet made at any support 
here. Not sure what it would entail.

#ifndef GREYREC
     #define GREYREC 709
#endif


Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> :-) My head is always a buzzing mess. Anyone else noticed I'm of late
> often typing 'is' for most any two character word with a leading 'i'.
> :-( A small miracle anyone can make anything of what I write.

fwiw, the most recent post is coherent.  coffee, eh ?! :-)  I saved a copy for
future reference, a lot of details in this grayscale stuff.

have 'povr' related question(s), and started a new thread in unofficial.patches.
 thanks.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> ...  coffee, eh ?!

<https://www.youtube.com/watch?v=TqehRP1sZx8>


enjoy, jr.

Post a reply to this message

On 2/26/23 07:50, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> ...  coffee, eh ?!
> 
> <https://www.youtube.com/watch?v=TqehRP1sZx8>
> 
> enjoy, jr.
> 
:-) Hmm. Many cups - could be contributing to my problem(a)...

Bill P.

(a) - Lying. Replace '(a)' with 's'.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> 709   - Rec 709. The default setting for the povr branch. The
> recommendation is aimed at HDTVs with standard dynamic range.  Most
> correct at an assumed_gamma of 1.0 and very near sRGB.  The best general
> choice for v3.8 (povr).
>

There is something about the REC 709 standard that has confused me for quite
awhile, in a general way. (I'm probably going off-topic here). AFAIU, it is a
standard for video capture and display, so I'm not sure that I understand how it
relates to color -> grayscale conversion within your povr branch (as for
height_field use.)

But my real confusion concerns POV-ray renders made into animations.

In the Wikipedia article, it says:
"Rec. 709 and sRGB share the same primary chromaticities and white point
chromaticity; however, sRGB is explicitly output (display) referred with an
equivalent gamma of 2.2..."

"Rec 709 defines an RGB encoding and a YCBCR encoding, each with either 8 bits
or 10 bits per sample in each color channel. In the 8-bit encoding the R, B, G,
and Y channels have a nominal range of [16..235]...with 128 as the neutral
value. So in limited range RGB reference black is (16, 16, 16) and reference
white is (235, 235, 235)... Values outside the nominal ranges are allowed, but
typically they would be clamped for broadcast or for display."

Is this *the* REC 709 standard? Or is there an 'unlimited' version that
preserves the full 0...255 range? I haven't yet found an unqualified answer.

So as I understand things, when I create a typical color POV-ray image render
(as either .png or .jpg) and with the output encoding as sRGB which I use within
POV-ray, that *by itself* preserves color/brightness values from 0-255 when
decoded. But when it is displayed on a monitor that is set up with the REC 709
standard(?) (vs. sRGB?), the colors/brightness values are restricted to
16...235, with the 'outside' values clamped. (BTW, I do understand some of the
reasons for that.)

Am I correct so far?

But my main confusion concerns this:
For converting POV-ray renders to animation, I use the old but updated
'VirtualDub2 MOD' app. It works well for my purposes-- but gives me a *choice*
between using REC 709 or REC 709-R (the 'restricted' 16...235 range) for the
output encoding. According to how I read the Wikipedia article, the 'plain'
REC709 *is* the restricted version(?). Yet I do see visual differences between
the two schemes, when played back in my various apps: The 'plain' REC 709
animation does not match my POV-ray preview images (increased contrast and/or
different gamma) whereas REC 709-R does. That's a real mystery.

Perhaps this visual difference is totally due to my computer monitor itself; I
don't know.

Post a reply to this message

"Leroy" <whe### [at] gmailcom> wrote:
I found a big difference in using a image pigment in the height_field function
and that pigment in the height_field alone.

that is
 #declare PigM=function{pigment{image_map{ tga "FinalB.tga"}}}
 #declare Dirt =
function(x,z){select(PigM(x,1-z,0).blue,0,0,PigM(x,1-z,0).blue)}
 height_field {function 400,400{ Dirt(x,y) }...
and

 height_field {tga "FinalB.tga"

they don't match! The function has a lower height and seems to be shifted both
in the +z and +x directions



Difference.ppm

Post a reply to this message

Attachments:
Download 'difference.ppm.dat' (507 KB)

"Leroy" <whe### [at] gmailcom> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
> I found a big difference in using a image pigment in the height_field function
> and that pigment in the height_field alone.
>

Lets try attaching that picture again
I also need to state the the function height_field is revered left to right so
the difference can be noticed better

Post a reply to this message

Attachments:
Download 'difference.jpg' (60 KB)

Preview of image 'difference.jpg'

"Leroy" <whe### [at] gmailcom> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
> I found a big difference in using a image pigment in the height_field function
> and that pigment in the height_field alone.
>
> that is
>  #declare PigM=function{pigment{image_map{ tga "FinalB.tga"}}}
>  #declare Dirt =
> function(x,z){select(PigM(x,1-z,0).blue,0,0,PigM(x,1-z,0).blue)}
>  height_field {function 400,400{ Dirt(x,y) }...
> and
>
>  height_field {tga "FinalB.tga"
>
> they don't match! The function has a lower height and seems to be shifted both
> in the +z and +x directions
>

Out of curiosity, I used your code examples but with my own .png image_map (not
..tga), and I see some interesting things:

First, I was surprised that your constructed DIRT function works at all. Z's
instead of y's there? But it does work! Substituting y for z *also* works:
       function(x,y){select(PigM(x,1-y,0).blue,0,0,PigM(x,1-y,0).blue)}

But moving on...
My test image_map includes 3 primary colors, plus a linear white-to-black ramp.
The resulting height_fields have a gradient-y color_map applied, from black to
reddish. (I shouldn't have used black; it makes the results difficult to see.)

I don't see any x or z reversal between the two HF examples. We're both using
the (1-z) trick for the function version, so that should solve it. It does for
me.

But *most* interestingly, the two HF-creation methods show some different
results for the height values. The 'direct' approach uses only the RED color
channel, AND shows the linear white-to-black 'ramp' correctly; the function
approach uses only the BLUE channel...but shows an unexpected gamma-value(?)
bending of the 'ramp' (and some other shapes there too.) I wasn't expecting
that!

Post a reply to this message

Attachments:
Download 'height_field_direct_and_by_functions_kw.jpg' (266 KB)

Preview of image 'height_field_direct_and_by_functions_kw.jpg'

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

> Out of curiosity, I used your code examples but with my own .png image_map (not
> ..tga), and I see some interesting things:
>
> First, I was surprised that your constructed DIRT function works at all. Z's
> instead of y's there? But it does work! Substituting y for z *also* works:
>        function(x,y){select(PigM(x,1-y,0).blue,0,0,PigM(x,1-y,0).blue)}

You can of course put anything you want in those "slots".   It's a function.
When you render an image and you are evaluating a pigment pattern, then you have
the ability to sample the x, y, and z values at the place where the ray-object
intersection takes place.  But there sure isn't a requirement to invoke any
function in that order, or even using those values at all.
Using z instead of y just switches the plane in which that function is
evaluated.

> But moving on...
> My test image_map includes 3 primary colors, plus a linear white-to-black ramp.
> The resulting height_fields have a gradient-y color_map applied, from black to
> reddish. (I shouldn't have used black; it makes the results difficult to see.)
>
> I don't see any x or z reversal between the two HF examples. We're both using
> the (1-z) trick for the function version, so that should solve it. It does for
> me.
>
> But *most* interestingly, the two HF-creation methods show some different
> results for the height values. The 'direct' approach uses only the RED color
> channel, AND shows the linear white-to-black 'ramp' correctly; the function
> approach uses only the BLUE channel...but shows an unexpected gamma-value(?)
> bending of the 'ramp' (and some other shapes there too.) I wasn't expecting
> that!

I'd like to see if the function approach using the red channel gives the same
result as either of these experiments.

Also, you should look into all of the input_gamma for gamma pre-corrected file
formats stuff, to see if that's what's going on.   Maybe if the image file gets
loaded with an input gamma specifying 1.0 or 2.2 (srgb) then they will be the
same.   Just to check that it's the heightfied creation method vs the image
input method that supplies the data to the heighfield.

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > But *most* interestingly, the two HF-creation methods show some different
> > results for the height values. The 'direct' approach uses only the RED color
> > channel, AND shows the linear white-to-black 'ramp' correctly; the function
> > approach uses only the BLUE channel...but shows an unexpected gamma-value(?)
> > bending of the 'ramp' (and some other shapes there too.) I wasn't expecting
> > that!
>
> I'd like to see if the function approach using the red channel gives the same
> result as either of these experiments.

Using Leroy's function and changing his .blue to .red, I still see the
'gamma-curving' ramp in the HF. Same with .green.
>
> Also, you should look into all of the input_gamma for gamma pre-corrected file
> formats stuff, to see if that's what's going on...

An interesting point-- and a good suggestion. By using the newer(?) 'gamma'
value keyword with my .png test image, it eliminates the gamma-curve effect seen
with the function method; the HF ramp is nice and linear now:

#declare PigM =
function{pigment{image_map{png "MY_IMAGE.png" gamma 1.0 }}}

Yet when the image_map is used 'directly' to create the HF (no pre-function
stuff), it works linearly as expected, without any gamma fiddling.

I don't know if this unexpected difference is mentioned in the docs; I haven't
seen anything that expressly mentions it.

-------
By the way, I was a *little* bit mistaken about the 'direct' image-to-HF method
using only the RED channel. With a different color_map and lighting, I see a
*tiny* amount of the GREEN channel used as well, but it looks almost
non-existent. See the attached render.

Post a reply to this message

Attachments:
Download 'test_hf_red_and_green_channels.jpg' (70 KB)

Preview of image 'test_hf_red_and_green_channels.jpg'

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > First, I was surprised that your constructed DIRT function works at all. Z's
> > instead of y's there? But it does work! Substituting y for z *also* works:
> >        function(x,y){select(PigM(x,1-y,0).blue,0,0,PigM(x,1-y,0).blue)}
>
> You can of course put anything you want in those "slots".   It's a function.
> When you render an image and you are evaluating a pigment pattern, then you
> have the ability to sample the x, y, and z values at the place where the
> ray-object intersection takes place.  But there sure isn't a requirement
> to invoke any function in that order, or even using those values at all.
> Using z instead of y just switches the plane in which that function is
> evaluated.
>

But in the case of a function from a (flat) image_map, isn't the 'plane' just
x/y?

My understanding (from the docs) is that a function takes only a 'slice' of a
pattern in the x/y plane, by definition. Granted that most patterns are 3-D and
that even an image_map extends infinitely into z, I thought that the function
would need x and y (not z) as its arguments because of that 'slice'. In other
words, z is usually not used at all (and/or has no real meaning for a flat
image_map.) But since Leroy's function works as-is and uses z... there is
obviously still something fundamental that I'm not grasping about function
arguments and what they mean.

:-[

Post a reply to this message

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

>
> My understanding (from the docs) is that a function takes only a 'slice' of a
> pattern in the x/y plane, by definition...

....for use in a height_field, that is! Sorry if I didn't make that clear.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> >
> > My understanding (from the docs) is that a function takes only a 'slice' of a
> > pattern in the x/y plane, by definition...
>
> ....for use in a height_field, that is! Sorry if I didn't make that clear.

 #declare PigM=function{pigment{image_map{ tga "FinalB.tga"}}}

 #declare Dirt =
function(x,z){select(PigM(x,1-z,0).blue,0,0,PigM(x,1-z,0).blue)}

 height_field {function 400,400{ Dirt(x,y) }...


I think maybe what's going on there is much like passing values into a macro
using macro arguments.

he's passing (x, y) into Dirt () when he invokes it through the hf declaration.
and so Dirt sees 2 values, and assigns them to (x, z) in its definition.

Confusing, and needs checking to verify, but that's my take at 6:30am.  ;)

- BW

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > Also, you should look into all of the input_gamma for gamma pre-corrected file
> > formats stuff, to see if that's what's going on...
>
> An interesting point-- and a good suggestion. By using the newer(?) 'gamma'
> value keyword with my .png test image, it eliminates the gamma-curve
> effect seen with the function method; the HF ramp is nice and linear now:

(actually, the ability to gamma-correct the image goes all the way back to at
least v3.7.0)
>
> #declare PigM =
> function{pigment{image_map{png "MY_IMAGE.png" gamma 1.0 }}}
>
> Yet when the image_map is used 'directly' to create the HF (no pre-function
> stuff), it works linearly as expected, without any gamma fiddling.

I also tested v3.7.0, and the difference is there as well. It's strange that I
never noticed this until now; I've been running image_map functions as
height_fields for years! I guess that having a linear white-to-black ramp in the
image as a tester is something I never used(?). Or I just wasn't paying enough
attention...
>
> I don't know if this unexpected difference is mentioned in the docs; I haven't
> seen anything that expressly mentions it.
>

It IS there; I had to search for it in the 3.8 documentation (the additional
emphasis is mine):

2.3.4.6 GAMMA IN INPUT IMAGES--
"Normally, gamma handling of input image files will work fine without
intervention, but in some cases it may *fail.* To resolve such problems, the
default handling can be overridden using the gamma keyword..."

"When using an image file in a *height_field*, bump_map or image_pattern,
POV-Ray will convert the image data to linear values *if* you explicitly specify
a gamma for that particular file; if you don't, no gamma adjustment will be
performed..."

Since my test image was made at the usual 2.2 (or perhaps sRGB) gamma-- as was
Leroy's presumably-- this makes sense.

Although, it does not really explain the gamma difference between a
function{pigment{...image_map...}} vs. a direct  height_field{...image_map...}

Post a reply to this message

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

> Although, it does not really explain the gamma difference between a
> function{pigment{...image_map...}} vs. a direct  height_field{...image_map...}

Well, I mean this is what I'm saying - without knowing what the data flow is
under-the-hood in source code, we don't know what sorts of logic and switches
are being performed before the data finally gets to where we're directing it.
Or what bugs or omissions are lurking in there.

So, either a scene or three would have to get run through a debugger, or some
sort of clever scene and reference image would have to be used to see exactly
what is happening with any given set of keywords.

So, maybe write a macro that stacks a series of boxes whose height is determined
by a calculated grayscale value based off of a loop counter.  That way you get
your ramp, but it's unsullied by any sort of gamma handling or under-the-hood
interpretation whatsoever.  But probably a standard gradient or colormap/spline
would work.  The key is to have defined _heights_ to use as a reference for any
given .gray value.

Then you could render that as an image using an orthographic camera to get the
same grayscale values for your image (being careful to understand if any gamma
issues apply to saving the render image) and then that could be your reference
image for further experiments.

Then maybe use one of those gamma/srgb conversion macros we worked on a ways
back to manually simulate a given gamma value, and compare that a
function/heightfield using the reference image with an input gamma applied.

It also might be a good idea to poke through the source code and see how
everything works, and post relevant code snippets for reference / help
interpreting.

- BW

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
> > "Leroy" <whe### [at] gmailcom> wrote:
> > I found a big difference in using a image pigment in the height_field function
> > and that pigment in the height_field alone.
> >
> > that is
> >  #declare PigM=function{pigment{image_map{ tga "FinalB.tga"}}}
> >  #declare Dirt =
> > function(x,z){select(PigM(x,1-z,0).blue,0,0,PigM(x,1-z,0).blue)}
> >  height_field {function 400,400{ Dirt(x,y) }...
> > and
> >
> >  height_field {tga "FinalB.tga"
> >
> > they don't match! The function has a lower height and seems to be shifted both
> > in the +z and +x directions
> >
>
> Out of curiosity, I used your code examples but with my own .png image_map (not
> ..tga), and I see some interesting things:
>
> First, I was surprised that your constructed DIRT function works at all. Z's
> instead of y's there? But it does work! Substituting y for z *also* works:
>        function(x,y){select(PigM(x,1-y,0).blue,0,0,PigM(x,1-y,0).blue)}
>
> But moving on...
> My test image_map includes 3 primary colors, plus a linear white-to-black ramp.
> The resulting height_fields have a gradient-y color_map applied, from black to
> reddish. (I shouldn't have used black; it makes the results difficult to see.)
>
> I don't see any x or z reversal between the two HF examples. We're both using
> the (1-z) trick for the function version, so that should solve it. It does for
> me.
>
> But *most* interestingly, the two HF-creation methods show some different
> results for the height values. The 'direct' approach uses only the RED color
> channel, AND shows the linear white-to-black 'ramp' correctly; the function
> approach uses only the BLUE channel...but shows an unexpected gamma-value(?)
> bending of the 'ramp' (and some other shapes there too.) I wasn't expecting
> that!

First, I like your image base documentation!

 function(x,z){select(PigM(x,1-z,0).blue,0,0,PigM(x,1-z,0).blue)} was made to
take care of some funky HF,s made with tga palette images. It seem that the HF
function produce negative value that showed up as spikes.
 function(x,z){PigM(x,1-z,0).hf} works for all of the other image formats I've
tried.( gif | jpeg | pgm | png | ppm | tga )

 Things I think I've learned:

 function(a,b) will work as long as those variables are used in the function.

 function(x,y,z){pigment{...} won't work

 height_field{will take function(x) I guess it sends 3 variables x,y,z float
types that have nothing to do with the x,y,z vectors.

The image_map goes on forever in the +z direction so
  function(x,z){PigM(x,1-z,.5).hf}
 still works, it might do so in the -z direction, I haven't tried it.

I'm still testing image formats. I've done at lease one test of these gif , jpeg
, pgm , png , ppm , tga(256 mapped, 24 bit compressed,24 bit NOT compressed)

I plan to do all the image formats that POV can Make and Read.

Have fun!

Post a reply to this message

On 2/26/23 12:32, Kenneth wrote:
> There is something about the REC 709 standard that has confused me for quite
> awhile, in a general way. (I'm probably going off-topic here). AFAIU, it is a
> standard for video capture and display, so I'm not sure that I understand how it
> relates to color -> grayscale conversion within your povr branch (as for
> height_field use.)

Sure I'm not the one to answer your questions in any definitive way, but...

Firstly, I focused on the color to greyscale / luminosity / height 
conversion while looking at the standards for my supported povr 
conversions. Further, I had a head start in that Christoph had dug some 
into these already the some of the new conversions already existed in 
the code for image input and output, if not the in code greyscale 
conversion itself. He and others had talked about 709 being a better 
color to grey for v3.8 defaults in the newsgroups.

---

That said. I think the difference being talked about in the 709 vs 
'709-R' is likely the fact most LCD based displays cannot reach the 
extremes for darkness and brightness and this is probably what the 
'709-R' you see is about. This I think more true of darkness - lcd 
displays simply fail for dark values because ultimately you need to turn 
off each pixel for true black.

While I am NOT an expert at animation encoding tools, I do not think you 
will see much if any real difference in what gets displayed between 709 
and 709-R. The reality is when when code a black value of 0.0 in a still 
image or animation frame, we mostly do NOT get a 0 pixel value, but 
something brighter.

So... What I suspect is encoding to an animation with '709-R' will 
compress better because fewer overall values are being represented. In 
other words the 'R' is a compression which accepts the typical reality 
of today's displays while pure 709 is optimistic that some few folks 
have displays that can actually do something closer to the extremes.

On the bright side (of displays), I'm less sure 'R' is the reality as I 
think some display can get quite bright (true too cheap ones can be 
dim). Some newer LCD displays at least can occasionally go completely 
dark by region, if not by pixel. There are fancy and pricey displays out 
there too, but most don't have them.

So! All this mostly me guessing - there is probably wiki/web info out 
there, but I didn't read up on anything on answering here.

If someone really knows better - feel free to jump in and correct as 
need be.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/26/23 12:32, Kenneth wrote:
> > There is something about the REC 709 standard that has confused me for quite
> > awhile, in a general way. (I'm probably going off-topic here). AFAIU, it is a
> > standard for video capture and display, so I'm not sure that I understand
> > how it relates to color -> grayscale conversion within your povr branch (as
> > for height_field use.)
>
> Sure I'm not the one to answer your questions in any definitive way, but...
>

Your comments are actually quite helpful and informative, thanks!

I probably should have qualified my earlier statement about seeing different
animation results re: using 'plain' REC 709 vs. 709-R:
It seems to depend on which video app I use to play-back the finished video.
IIRC!

I have not done a definitive series of tests lately. Once I saw that 709-R
'looked' better and matched my POV-ray image render previews within POV-ray, I
stuck with it. This is yet another of those situations where I got side-tracked
from working on a scene, and didn't pursue the problem as far as I would have
liked to.

I could probably spend 23 1/2 hrs per day just doing detailed and pedantic tests
of one kind or another! (Lately, it seems that I am, ha.)
-----

BTW, I am *still* chasing-down that height_field 'mirror reversal' thing when
using functions. Just today, I discovered yet another little interesting
behavioral quirk. I will probably post it in the earlier/recent thread about
"functions to height_fields", as it seems more appropriate there.

Post a reply to this message