POV-Ray : Newsgroups : povray.unix : FYI. Watch out for bad color to grey value conversions. : Re: FYI. Watch out for bad color to grey value conversions. Server Time
1 Mar 2024 16:54:34 EST (-0500)
  Re: FYI. Watch out for bad color to grey value conversions.  
From: Le Forgeron
Date: 30 Jan 2021 13:46:41
Message: <6015a991$1@news.povray.org>
Le 30/01/2021 à 04:01, William F Pokorny a écrit :
> Yes, or for those compiling v3.8 at home, change the CASE(GRAY_TOKEN)
> code in source/parser/parser_expressions.cpp to read:
>       *Terms=1;  // TODO. Redundant? Is other than >=1 possible?
>                  // Being explicit is safe for check below.
>       Express[0]=PreciseRGBFTColour(Express).Greyscale();
      i=0;       // i set to 0 at top. Again, being explicit the value
>                  // we want is in Express[0] is safe.
> and re-compile.

I have problem with such changes.

*Terms is in/out , for Express (which is also in/out)

The initial code is only :


Which is bogus because result of Greyscale is stored in .red, but i is
set to .green (to simplify a bit; index 0 is .red, .x as well as .u )

The check at the end of the switch for all "dot" expressions is:

        if (i>=*Terms)
            Error("Bad operands for period operator.");

To be able to use correctly Greyscale, we need at least *Terms to be 3.

So, to keep code simple AND correct, the correction should be:


If the expression has 1 or 2 terms (on entry), it will be reported as
invalid (and that is good).
If the expression has 3 or more terms (on entry), Greyscale is fine, and
result can be provided.

That was my 0.02c !

Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.