rpict: color channel separation

Dear list members:

While getting acquainted with radiance, I stumbled on a phenomenon
that I do not understand.

I keep the following scene description (of a red sphere lonely in vast Euclidean space) in a file called sphere_0.rad

void light SphereLight_0
0 0 3 0.000431188 0 0

SphereLight_0 sphere sphere_0
0 0 4 0 500 0 100

I use oconv and rpict to render the scene and check the output using pvalue.

oconv sphere_0.rad > o.conv
rpict -x 128 -y 128 o.conv | pvalue -o -h -u

The first few lines of output of these commands are

-Y 128 +X 128
     60 95 4.320e-04 9.537e-07 9.537e-07
     62 95 0.000e+00 0.000e+00 0.000e+00
     63 95 4.320e-04 9.537e-07 9.537e-07
     65 95 0.000e+00 0.000e+00 0.000e+00
     67 95 4.320e-04 9.537e-07 9.537e-07
     68 95 0.000e+00 0.000e+00 0.000e+00
     56 94 4.320e-04 9.537e-07 9.537e-07

They demonstrate that am picking up some small power contributions in
the g and b channel which seem suspicious to me. When I use rtrace in an
attempt to reproduce the phenomemon, I find 0 for g and b as I'd expect.

I'd be grateful if somebody could share her/his insight

ps - random observations:

- I have experimented with program options, but even though the defaults
of rtrace and rpict differ slightly, they seem to not be able to explain
rpict's behavior

- A colleague at Fraunhofer ISE checked the pic-file and mentioned to
me that the non-zero contributions are present in the rpict output and
are not created later by pvalue

···

--
Stefan Schwarzer
Fraunhofer-Institut für Physikalische Messtechnik IPM
Optische Fertigungsmesstechnik
Heidenhofstr. 8, 79110 Freiburg, Germany
Telefon: +49-(0)761-8857-366
[email protected]

--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Hello Stefan,

This is simply the round-off error associated with the Radiance RGBE format. Since the picture format uses three mantissas with a common exponent, it is not possible to represent a non-zero value in one channel and a zero value in another channel. Even though the actual byte stored for green and blue may be zero in your calculation, the decoder will interpret this as half a count out of 255 and give a corresponding value.

Since the main purpose of Radiance is lighting calculations for visual simulation, and the eye's color channels have a (more or less) linear response, this is an appropriate/adequate representations for the design application. If you need the original floating point values, and don't mind files than are about 5 times bigger, you can use vwrays with rtrace and output floating point images directly.

I hope this helps.
-Greg

···

From: "Stefan Schwarzer" <[email protected]>
Date: February 18, 2008 2:56:05 AM PST

Dear list members:

While getting acquainted with radiance, I stumbled on a phenomenon
that I do not understand.

I keep the following scene description (of a red sphere lonely in vast Euclidean space) in a file called sphere_0.rad

void light SphereLight_0
0 0 3 0.000431188 0 0

SphereLight_0 sphere sphere_0
0 0 4 0 500 0 100

I use oconv and rpict to render the scene and check the output using pvalue.

oconv sphere_0.rad > o.conv
rpict -x 128 -y 128 o.conv | pvalue -o -h -u

The first few lines of output of these commands are

-Y 128 +X 128
     60 95 4.320e-04 9.537e-07 9.537e-07
     62 95 0.000e+00 0.000e+00 0.000e+00
     63 95 4.320e-04 9.537e-07 9.537e-07
     65 95 0.000e+00 0.000e+00 0.000e+00
     67 95 4.320e-04 9.537e-07 9.537e-07
     68 95 0.000e+00 0.000e+00 0.000e+00
     56 94 4.320e-04 9.537e-07 9.537e-07

They demonstrate that am picking up some small power contributions in
the g and b channel which seem suspicious to me. When I use rtrace in an
attempt to reproduce the phenomemon, I find 0 for g and b as I'd expect.

I'd be grateful if somebody could share her/his insight

ps - random observations:

- I have experimented with program options, but even though the defaults
of rtrace and rpict differ slightly, they seem to not be able to explain
rpict's behavior

- A colleague at Fraunhofer ISE checked the pic-file and mentioned to
me that the non-zero contributions are present in the rpict output and
are not created later by pvalue

--
Stefan Schwarzer