[Radiance-general] .pic precision

[Gregory J. Ward]

Hi Richard,

As long as you are not relying on textures that derive from images of 
any kind, there is no inherent limitation in the precision of the 
lighting calculations in Radiance -- everything is carried out in 
double-precision floating point.  However, the accuracy of any Monte 
Carlo calculation is going to depend on a lot of different factors, 
such as number of samples and so on, and if you don't pass the output 
to pfilt to filter the result, you are likely to have samples with 
occassional large discrepancies to their neighboring pixels.

Avoiding these variances requires turning off Monte Carlo sampling as 
much as possible, which probably requires no diffuse interreflection 
and only purely specular (polished) or diffuse surfaces.  I can give 
you hints on how to do this if that is what you are after.

To get out a floating-point image without going into the 32-bit/pixel 
RGBE representation, you can use rtrace instead of rpict, like so:

% vwrays -vf view.vf -x 1024 -y 1024 -ff | rtrace -ff -h [options] 
octree > picture.flt

This will produce a raw floating-point image with 96-bits/pixel (RGB 
floats in scanline order).  The size of the image can be determined by 
running "vwrays -vf view.xf -x 1024 -y 1024 -d" as it won't be 
1024x1024 unless you give it a square view, as vwrays produces square 
pixels by default.

-Greg

> From: Richard Murray <rfmurray at sas.upenn.edu>
> Date: February 24, 2005 2:26:24 PM PST
>
> I'm starting to use Radiance in research on visual perception of 3D 
> shape.  The .pic file format assigns each colour channel one byte, 
> plus a common exponent for all three, resulting in about 1% precision. 
>  When testing peoples' ability to detect faint patterns, 1% isn't 
> precise enough, e.g., humans can detect sine wave patterns at less 
> than 1% contrast, but in the .pic format, a 1% amplitude sine wave 
> would come out more like a square wave.
>
> From a quick look through rpmain.c and rpict.c, it looks like the the 
> floating-point COLOR struct is used throughout the rendering 
> calculations, and that the conversion to COLR is made at the very end, 
> in fwritescan(), when writing the .pic file.  This suggests that I 
> could just replace fwritescan() with a routine that writes the file at 
> a higher precision.
>
> My question is this:  are there other factors in the rendering 
> calculations (rounding, etc.) that limit the precision to around 1% 
> anyway?
>
> Thanks,
>
> Richard