"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