"epidot" <nomail@nomail> wrote:
> Is there anyway to render a colour that is outside the normal RGB space?
>
> I have a situation where I have some colour data that falls outside the RGB
> gamut. It would be very good to get your input on this

(A) No, it's not possible. POV simply operates in RGB space.

(B) Then again, that's "almost not true": POV's rendering engine actually knows
nothing about color space - it just operates on a 3-band spectral space, which
happens to be typically used as R, G and B respectively. Well, it *almost*
knows nothing about it: There are a few operations that deal with the overall
brightness, which is computed from the three spectral bands, weighting them in
a way custom-tailored to RGB.

(C) IIUC colors outside the gamut can be achieved by "boosting" some of the RGB
components beyond 100% (effectively enlarging the "gamut triangle" in all
directions). AFAIK POV is perfectly fine operating with such high numbers
(though there are a few places where you can deliberately clip colors), and
even writes them to suitable file formats, such as HDR. So yes, you can render
those - you just can't properly display them on a computer screen for obvious
reasons.

Post a reply to this message

clipka wrote:
> "epidot" <nomail@nomail> wrote:
>> Is there anyway to render a colour that is outside the normal RGB space?
>>
>> I have a situation where I have some colour data that falls outside the RGB
>> gamut. It would be very good to get your input on this
> 
> (C) IIUC colors outside the gamut can be achieved by "boosting" some of the RGB
> components beyond 100% (effectively enlarging the "gamut triangle" in all
> directions). AFAIK POV is perfectly fine operating with such high numbers
> (though there are a few places where you can deliberately clip colors), and
> even writes them to suitable file formats, such as HDR. So yes, you can render
> those - you just can't properly display them on a computer screen for obvious
> reasons.
> 

Wrong. Out of gamut values are indicated by one or more RGB components 
with *negative* values. It has nothing to do with HDR. And IIRC POV-Ray 
does clip negative values - but it is a long time since I looked at the 
source - so you might know better.

-Ive

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> Wrong. Out of gamut values are indicated by one or more RGB components
> with *negative* values. It has nothing to do with HDR. And IIRC POV-Ray
> does clip negative values - but it is a long time since I looked at the
> source - so you might know better.

Well, if RGB components can be negative, then obviously we're not talking about
a straightforward 3-band spectrum (or am I missing something here?) as
simulated by POV-Ray.

So there's two things involved here:

(1) A rendering engine, simulating three spectral bands (which, for physical
reasons, cannot have negative intensity), and

(2) the human visual system, partially mixing these spectral bands for a certain
color perception (due to the receptor pigments' spectral response ranges
overlapping).

So I think there cannot be an unsurmountable problem with the render engine -
only with how to present the results to the human eye.

There *is* of course the problem that the render engine's spectral bands are by
convention assumed to be identical to the emission spectrum of the user's
display's phosphors. However, this is not a necessity.

So the right thing to do would be to (A) choose properly defined spectral bands,
(B) make sure color values are coded accordingly, and (C) apply some
transformation to the output to transform the quite arbitrary 3-band image into
a target color space of choice.

If this still yields inferior results, there would still be the possibility to
model a larger number of spectral bands, using macros to define the colors, and
and render the scene in multiple passes, picking three of those bands per pass.
Again, the results would have to be transformed into the desired color space.

Post a reply to this message

clipka wrote:

> Well, if RGB components can be negative, then obviously we're not talking about
> a straightforward 3-band spectrum (or am I missing something here?) as
> simulated by POV-Ray.
> 

POV-Ray might want to use a straightforward 3-band spectrum (e.g. for 
dispersion calculation) but this is not how it works. It would be true 
if you define indeed *all* colors within your pigment statements as 
components from a 3-band spectrum but who does this?
POV simply works with what you feed in. I guess much more common are RGB 
values that are represented by the sRGB color space. But the RGB 
components from sRGB are not meant to be a 3-band spectrum (and I'm not 
talking about gamma here).
The same is true for the Wide-Gamut colorspace, Adobe RGB and what not...

Let me put it this way: what *color* is actually meant by rgb <1,0,0>
- and do not just tell me it's red - I know that ;)

Sorry, I'm really a bit in a hurry right now, but I will remember this
and we might discuss this later...

-Ive

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> POV-Ray might want to use a straightforward 3-band spectrum (e.g. for
> dispersion calculation) but this is not how it works. It would be true
> if you define indeed *all* colors within your pigment statements as
> components from a 3-band spectrum but who does this?

.... which is just what I'm saying: Use it in the right way, and you can do
out-of-RGB-gamut stuff with it.

BTW, color values in POV are typically interpreted by the engine to be linear,
and are therefore not sRGB anyway (which does not only exactly define the
primaries, but also uses some gamma stuff).

Post a reply to this message

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

MessyBlob wrote:
> 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:
> 
[snip...]

This is all true but has nothing to do with the color space gamut.


> The brightness (amplitude) perspective is a bit easier to understand:
> 
[snip...]

Again, true but not related to the color space gamut.

-Ive

Post a reply to this message

clipka wrote:
> Ive <"ive### [at] lilysoftorg"> wrote:
>> POV-Ray might want to use a straightforward 3-band spectrum (e.g. for
>> dispersion calculation) but this is not how it works. It would be true
>> if you define indeed *all* colors within your pigment statements as
>> components from a 3-band spectrum but who does this?
> 
> .... which is just what I'm saying: Use it in the right way, and you can do
> out-of-RGB-gamut stuff with it.
>

...which is not true *if* negative values are clipped - as I sayd.


> BTW, color values in POV are typically interpreted by the engine to be linear,
> and are therefore not sRGB anyway (which does not only exactly define the
> primaries, but also uses some gamma stuff).
> 

No need to tell me trivial things, as I sayd, I was *not* talking about 
gamma, so let's use the the scRGB color space (the sRGB primaries but 
with linear gamma) for that matter.

-Ive

Post a reply to this message

epidot wrote:
> Is there anyway to render a colour that is outside the normal RGB space?
> 
> I have a situation where I have some colour data that falls outside the RGB
> gamut. It would be very good to get your input on this
> 
> 

OK, I finally have just tried it and it does indeed work if you do use 
the OpenEXR output - which is available within the POV-Ray 3.7 beta 
version. In any other case POV-Ray just clips the RGB components and 
does *not* apply any gamut mapping.

-Ive

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> MessyBlob wrote:
> > 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:
> > [snip...]
> This is all true but has nothing to do with the color space gamut.
>
> > The brightness (amplitude) perspective is a bit easier to understand:
> > [snip...]
>
> Again, true but not related to the color space gamut.

Not directly, but you ultimately have to map the RGB range to some other range,
and depending on that mapping, you'll either need to keep the RGB colours so
that they don't extend out of the target gamut, or intelligently map the
out-of-gamut colours.

If the problem is that you have out-of-gamut colours within the RGB
representation, then it can only be because colour element values are out of
range (<0.0 or >1.0), which can be fixed by scaling, shifting, or clipping the
colour values.

I'm not sure how relevant gamut control is to POV-Ray, as standard colour
management software can handle conversions from RGB. I think it's really a
question of 'rendering intent' (a colour management phrase, not a ray tracing
term) after POV-Ray output is generated, in that you can either (a) map the
limits of one device to another (relative colorimetric) so that a full-gamut
image in RGB will extend to the  limits of the target gamut, or (b) you can
equate both gamuts to an absolute scale (absolute colorimetric) so that images
will look the same when arranged (in the real world) next to each other, even
when the image media are different.

If the above is waffle, then maybe we've not understood the problem correctly
:o)

Post a reply to this message