There are two ways of looking at this 'out of gamut' question: wavelengths, and
brightness (amplitudes). It's possible to have wavelengths that don't exist in
POV-Ray, and amplitudes that are too bright for integer (8-bit or 16-bit)
output from POV-Ray.


First, the frequency perspective:

There's a difference between real life light and the RGB representation. If you
have a real-world monochromatic colour that has a single spectral peak
somewhere between the wavelengths of green and red, then we'd see (perceive) it
as 'orange' or 'yellow'.

In RGB, we represent this colour in terms of the spectral responses that
redd-ish, green-ish, and blue-ish receptors would give, provided the receptors
had a reasonably wide frequency response (like those in the eye), so it would
be 'red + green' (a response in red, and a response in green).

As it stands, POV-Ray light acts like all light consists only of three
monochoromatic peaks: R, G, and B, centred on frequencies of red, green, and
blue. It's sufficient for most purposes, but effects like diffraction,
refraction, dispersion, diffusion, scattering, quantum interference, and true
transmission (with different alpha values at different wavelengths) can only be
done realistically in the frequency domain, with all ray calculations using
amplitude information for all frequencies (in the relevant range).

It's possible to write a rendering engine that carries frequency-domain values
for each ray, but it would take a huge re-write for POV-Ray to work this way,
and the benefits would be minimal and the penalites high. Even then, it's only
a part of the way towards simulating how light really really propagates... but
like I said, RGB is sufficient for most purposes.


The brightness (amplitude) perspective is a bit easier to understand:

I think POV-Ray clips on output, unless you're using HDR or floating-point file
format. I tend to use a line like
  #declare Exposure = 1.0;
and then use Exposure to scale the colour of lights and ambient objects.

This allows you to set the exposure of the scene, just like one would use
'exposure compensation' on a digital camera. This can help ensure all levels
are <1.0. For example, if a scene renders twice as bright as you want it to be,
then set Exposure to 0.5. With 16-bit PNG output, this should be suitable for
most visual output.

If you're using the output for data, rather than visual images, then that's
another matter.

Post a reply to this message