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'