On 1/31/21 12:44 AM, William F Pokorny wrote:
> On 1/30/21 1:46 PM, Le_Forgeron wrote:
...
>> 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 !
>>

Finally got some sleep & starting my first cup. I woke up this morning 
thinking if .blue (i=pBLUE) works with all the expressions passed, .grey 
using (i=pBlue=2) must too. I'm going to change to something essentially 
your version in:

  i=pBLUE;
  Express[i]=PreciseRGBFTColour(Express).Greyscale();

The test cases I've created (only 16) are clean with the code above. The 
check can only fail if there was a reason for *this=1 - and then we'd 
know what it is.

Thanks again for the review!

Bill P.

P.S. In my first response I started to ramble about what I saw in the 
Greyscale() coding options, but deleted it. My writing tends to reflect 
the storm in my head - and in my povr branch I'm eventually deleting all 
the code changes related to the start of support for spectral rendering. 
For completeness, I'll mention it.

In colour.h, if you search for NUM_COLOUR_CHANNELS, you'll see there is 
an implementation of Greyscale() - not the one currently compiled - 
which supports a 'channels' number of color channels. I had the thought 
this might have been why *Terms was hard coded to 1, but if so .blue 
need modification too and don't have it. (As would the .grey 
functionality in fncode.cpp ... and expect much more)

Post a reply to this message