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