> compensate for that. Green LED might be a good example, because, despite 
> being
> monochrome, it might attract weak responses from red or blue, in which 
> case,
> you change the response profiles, rather than mess about with negative 
> numbers.
> (?)

Sure, for that you can use the CIE 1931 XYZ standard observer responses, 
X,Y,Z are guaranteed to be positive for all visible colours (but the 
downside is you also get some XYZ combinations that are not visible).  But 
usually when creating images you are using some other space, like sRGB (for 
web), adobeRGB (from digital cameras), the NTSC standard (for TV work) etc. 
These don't cover the whole CIE gamut so negative values must be used if you 
want to describe and preserve some colours (eg the green LED).

For example if I take a photo on my camera it will produce an image using 
the adobeRGB colour space.  If I convert that to sRGB (to display on a web 
page) or to some other space (eg to submit to a printer, or for use on a 
certain display system) it is possible that some resulting RGB values might 
be negative.  It's not wrong or an error, it's just what is needed to 
represent those colours.  What you do with negative values is up to you, but 
if you really only need positive values (eg to display on a monitor) then 
just clipping them to zero is almost the worst thing to do.

Going back to what POV does, the best thing POV could do is just to preserve 
the negative-ness of colour components and produce an output file (if using 
a suitable format) that reflects this.  That way if the POV output file is 
converted to some other colour space further down the workflow line, the 
results will be as accurate as possible.  For immediate display on a monitor 
or print, maybe an option to clip negative values to zero, or to use a more 
sophisticted algorithm that preserves hue could be included.

Post a reply to this message