On 9/19/20 10:52 AM, jr wrote:
...
>> In tracetask.cpp, at about line 764, insert code so things look like:
>>
>> double cf = confidenceFactor[neighborSamples-1];
>> PreciseRGBTColour sqrtvar = Sqrt(variance);
>>
>> if (variance.red()<0)
>>       throw POV_EXCEPTION_STRING("kaboom");
>>
>> PreciseRGBTColour confidenceDelta = sqrtvar * cf;
> 
> sure, will find time in the next few days.  (will I need line above and below
> for context or is it "self-evident"?  :-))

The lines above and below the test and throw are provided for context.

> a specific "white/black and white/colour" test scene or are you referring to
> Ton's code modified?

Ton's code modified for color and not. What you were running on both 
machines.

> 
>> ...
> 

Thanks. It's less a priority 4 hours later :-), but I would like to see 
the results.

--------
Both implementations have the same basic problem. The occasional square 
root of negative values (Domain errors). Both would kinda / sorta work 
regardless. Due compiler versions, flag settings or maybe machine types 
- seems, on the domain errors, you might not break on the color channel 
threshold and instead only break on hitting the max samples check.

To fix those of you compiling at home can change the code in 
tracetask.cpp to look like:

if (samples >= minSamples)
{
     if (samples >= maxSamples)
         break;

     PreciseRGBTColour variance =
         (neighborSumSqr - Sqr(neighborSum)/neighborSamples)
         / (neighborSamples-1); // Sometimes very slightly neg
     variance = PreciseRGBTColour(           // Fix
                 max(0.0,variance.red()),    // Fix
                 max(0.0,variance.green()),  // Fix
                 max(0.0,variance.blue()),   // Fix
                 max(0.0,variance.transm())  // Fix
             );                              // Fix
     double cf = confidenceFactor[neighborSamples-1];
     PreciseRGBTColour sqrtvar = Sqrt(variance);
     PreciseRGBTColour confidenceDelta = sqrtvar * cf;
     if (confidenceDelta.red() +
         confidenceDelta.green() +
         confidenceDelta.blue() +
         confidenceDelta.transm() <= threshold)
         break;
}

Ton, The reason you need smaller thresholds in v3.8 for equivalent 
result in uberpov is the uberpov threshold test was:

if ((confidenceDelta.red()    <= threshold) &&
     (confidenceDelta.green()  <= threshold) &&
     (confidenceDelta.blue()   <= threshold) &&
     (confidenceDelta.transm() <= threshold))
     break;

With the fix in povr I can get pretty good white on black, or white on
Acajou results in roughly 16 seconds and 18 seconds, respectively. 
Similar quality white on black results took me nearly 20 minutes without 
the fix above.

The command lines I used were:

povr2 +d +p +q9 +am3 +a0.05 +ac0.9 +ss123456 +r6 +w600 +h600 ...
povr2 +d +p +q9 +am3 +a0.025 +ac0.9 +ss123456 +r6 +w600 +h600 ...

The color threshold does need to be smaller for similar method3 result 
and, on thinking about it, this makes sense. The absolute color 
difference white to the background is reduced. I'll post an image of the 
two results to povary.binaries.

Aside: There are comments in the code related to allowing a min sampling 
of other than 1, which I think could be helpful, but I don't immediately 
see how to implement it.

---------
So, all good right? Nope... We have an underlying problem at which I've 
yet too look. We have a color template class with a Sqrt method that 
doesn't handle negative color values. POV-Ray allows negative color 
values. Do we update it to return negative square roots --> (sqrt(abs()) 
and flip result neg on neg inputs? What might changing this method mean 
to the code base as whole? I don't know.

Suppose we might want a maxZero color vector method too - if that a 
common need.

Bill P.

Post a reply to this message