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