POV-Ray : Newsgroups : povray.binaries.images : Going spectral : Re: Going spectral Server Time
8 Jul 2024 07:43:58 EDT (-0400)
  Re: Going spectral  
From: clipka
Date: 5 Aug 2014 02:23:48
Message: <53e07874@news.povray.org>
Am 05.08.2014 06:35, schrieb Cousin Ricky:
> clipka <ano### [at] anonymousorg> wrote:
>> Second image shows the results of a 16-channel spectral rendering, using
>> automatic generation of absorption spectra to match the RGB colours.
>
> What sort of algorithm are you using?

The run-time algorithm is pretty simple:

- If the colour is meant for a light source (or "emission" statement or 
similar), convert to HSV, then look up & interpolate from a precomputed 
table based on H and S for some standard V, and multiply to achieve the 
desired V.

- Otherwise, convert to HSV, then look up & interpolate from a 
precomputed table based on H, S and V. The resulting colour may be a bit 
off (especially since for extreme S and/or V the precomputed table only 
contains the nearest physically realistic colour), which is compensated 
for by transforming the result to RGB, computing the difference to the 
desired colour, feeding that difference into the algorithm intended for 
light sources, and adding the result.


As for creating the lookup tables in the first place, that's a somewhat 
kludgy iterative process, so it's poorly suited for SDL use. The 
essentials are as follows:

1. Pick an initial guess. A grey will do.

2. Compute the mismatch between the guess and the target in some 
arbitrary linear colour space (e.g. XYZ or RGB; I'm currently using the 
latter).

3. Tweak all channels according to how well their nominal contribution 
agrees with the mismatch; I'm using the dot in colour space as a basis 
for this.

4. Tweak the colour to peak as high as the target colour. (E.g. for a 
<1,0.5,0> orange you want some orange-ish channel to reach a value of 
1.0. I'm using a simple uniform scale of all channels for this purpose.)

5. Trim all channels to the range from 0.0 to 1.0.

6. Repeat from Step 2 until happy or bored.

(The actual implementation also accounts for whitepoint issues, which is 
neglected in the description above.)


> What do the spectral curves look like?

Actually I don't even know yet. I've had a few glimpses at the raw data 
of selected precomputed spectra, but I've yet to figure a way to 
actually visualize them.


> Will there be some interface between the channels and the user?

Certainly, in the sense that the user will be able to specify their own 
custom spectral curves.

To avoid various cans of worms I probably won't provide any interface 
for accessing the RGB equivalent of a given spectrum, nor the 
auto-generated spectrum for a given RGB colour.

I guess I'll use a spline- and/or function-based syntax for 
user-specified spectra.


> I'm working on a module for the Object Collection that generates spectra in a
> format that is compatible with Lightsys IV and SpectralRender.  However, it
> takes an HSV approach instead of an RGB approach.  Since the RGB system is an
> artifact of the medium, I did not want to tie down the spectra to that system.
>
> My priority was to generate quasi-realistic spectral curves, and matching
> saturation, lightness, and value to any particular color system was /not/ a
> consideration.  Therefore, using CRGB2HSV() or CRGB2HSL() and passing the
> resulting value to my module will not produce the same results as the rgb (or
> srgb) keyword.  (Indeed, passing a bluish green hue with any decent saturation
> is likely to produce a color outside the sRGB gamut.)  However, to provide a
> convenient and familiar anchor for hue, the hues are matched to the sRGB color
> system.

You shouldn't call it HSV then, as it would cause confusion. Note that 
HSV is strongly tied to the RGB family of colour models.

Also be aware that for the approach you're probably aiming at you should 
avoid the term "hue" altogether, unless you can be sure that the actual 
percieved hue is stable WRT the other parameters of the model. For 
instance, while the percieved hue of a gaussian curve-based spectrum 
will primarily depend on the wavelength of the peak, changes to the 
width of the curve will typically also cause a slight shift in hue. If 
you're going for such an approach, a straigtforward "peak wavelength" 
parameter would certainly be more fitting.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.