On 8/23/2018 8:32 PM, clipka wrote:
> As for normalizing the colours so that all values fall in the range
> 0..1, that's also reasonably simple, because at present, colour
> management in POV-Ray is only very rudimentary anyway: If you use any
> sRGB-related feature (such as the `srgb` keyword for colour literals, or
> the `File_Gamma=sRGB` setting), it is presumed that the colour model is
> sRGB, but otherwise you are still free to decide what primaries you want
> to assign to R, G and B, including imaginary colours (i.e. colours more
> saturated than reality allows), which is what you'll need to get all
> components into the 0..1 range.
> 

What I did was simply record the max values for R, G and B (I think the 
max was only ~1.2 for one of the channels and ~1.1 for another) in one 
pass (loop), then multiply each color by the inverse of the maximums.

Sort of:

     Out_Color = <MyR * 1/MaxR, MyG * 1/MaxG, MyB * 1/MaxB>

The result looks good enough, thought the whites and grays have a slight 
greenish tint.


> It must be noted however that /any/ colour computations in a
> three-channel colour model is inevitably unrealistic; this is true even
> for sRGB. I'm not sure whether e.g. XYZ colour space would fare better
> or worse in this respect. My hunch is that the best compromise might be
> a colour model where the primaries are imaginary but the gamut does not
> fully encompass the entire "spectral horseshoe".
> 
> To /really/ get proper colour computations, you'd need to use spectral
> rendering, i.e. a colour model where you have, say, 16 or maybe even 32
> colour channels, each assigned to a specific frequency band of the
> visible spectrum. And of course instead of an sRGB colour you'd have to
> specify the actual spectrum of your pigments.
> 

Hopefully this will be practical when someone events a single diode that 
can change to any color. (I.e. so we don't need three diodes for every 
pixel.)


Mike

Post a reply to this message