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