On 2021-01-29 1:57 PM (-4), William F Pokorny wrote:
> I'm going to blame the couple of you reviving a dormant thread about 
> color to grey conversions for this! Always knock on wood after 
> mentioning a feature... ;-)

*forum Kung-Fu champion takes a bow*

> For those compiling versions of POV-Ray v3.8, be on the look out for 
> issues with the color to grey conversions. Issues which might affect 
> more than .grey, .gray functionality, though that's where I picked up 
> the problem.
> 
> [snip]
> 
> but the gray/grey values reported are wrong (for as right as they get) 
> for recent code versions and compiles.

Holy Chinavia, Batman!

I did further tests, and it appears that .gray/.grey simply returns the 
value of the .green channel.  This is a seriously stinky green bug!

Looks like we'll have to use one of these macros for the time being:

#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

Unfortunately, these won't help with pigment functions.

> FWIW! Expect it very much hit or miss whether - or when - others might 
> see this issue. Be aware of it. I'm unsure of the scope beyond the 
> .grey/.gray feature and using Ubuntu 20.04.1.

I'd mostly ditched .gray for DotGray() anyway, since Christoph revealed 
that the .gray formula was inaccurate in the real world, so I wouldn't 
have run across this bug, at least not without re-rendering one of my 
old scenes in 3.8.  The only situations I can think of in the past 4 
years where I *might* have used .gray would be on gray scale pigments, 
for which, based on my findings, this bug would not manifest.

I'm using openSUSE, but prima facie this doesn't sound like an operating 
system-dependent issue.

Post a reply to this message