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)