Fully-saturated RGB colours, shown on both opaque and transparent 
spheres (the latter using fade_colour with varying fade_distance). Note 
the strong shift towards the primary hues in the first image as 
fade_distance decreases.

Second image shows the results of a 16-channel spectral rendering, using 
automatic generation of absorption spectra to match the RGB colours. 
Note how the shift towards the RGB primaries is somewhat lessened 
especially in the warm yellows and the blue-to-cyan range. The greens 
and purples don't seem to benefit that much; I guess some tweaking of 
the spectrum generation might help there.

Post a reply to this message

Attachments:
Download 'test_coloured_balls_37.png' (459 KB) Download 'test_coloured_balls_spectral.png' (454 KB)

Preview of image 'test_coloured_balls_37.png'

Preview of image 'test_coloured_balls_spectral.png'

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?  What do the spectral curves look like?
Will there be some interface between the channels and the user?

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.

The module is essentially complete, except for some testing.

Post a reply to this message

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

clipka <ano### [at] anonymousorg> wrote:
> 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.

Any suggestions?

As it is, I already have a warning in the proposed documentation that the
arguments do not correspond to RGB color spaces.

> 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.

I vary the saturation by raising the gray level, not by varying the width of the
curve, so that is not an issue.  There is a slight shift in hue due to the
unevenness of the gray curve, but the shift is pretty much imperceptible except
for very low saturation values, where our ability to perceive differences in hue
is pretty fuzzy anyway.  This drift is noted in the proposed documentation.

> If
> you're going for such an approach, a straigtforward "peak wavelength"
> parameter would certainly be more fitting.

Peak wavelength would not be suitable, or even workable.  The purples have two
peaks, and the oranges and reds have a plateau instead of a peak.  (This is
based on real-life spectral curves.)  For the remaining hues, I can just about
guarantee that the hue of the integrated curve will not match that of the peak
wavelength.  Even if I were to match hues to a spectral wavelength (a pointless
effort IMHO), there are no wavelengths corresponding to purples and magentas.

I would love some commentary from Ive on these efforts, if you're following
this.

Post a reply to this message

Am 12.08.2014 17:11, schrieb Cousin Ricky:

>> 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.
>
> I vary the saturation by raising the gray level, not by varying the width of the
> curve, so that is not an issue.  There is a slight shift in hue due to the
> unevenness of the gray curve, but the shift is pretty much imperceptible except
> for very low saturation values, where our ability to perceive differences in hue
> is pretty fuzzy anyway.  This drift is noted in the proposed documentation.

Hmmm... why do you use an uneven gray curve in the first place? (Unless 
that's your official whitepoint, in which case officially there's no 
shift in hue.)

> Peak wavelength would not be suitable, or even workable.  The purples have two
> peaks, and the oranges and reds have a plateau instead of a peak.  (This is
> based on real-life spectral curves.)  For the remaining hues, I can just about
> guarantee that the hue of the integrated curve will not match that of the peak
> wavelength.  Even if I were to match hues to a spectral wavelength (a pointless
> effort IMHO), there are no wavelengths corresponding to purples and magentas.

I was expecting a different approach.

 From what I understand now, you have precomputed spectral curves for 
"pure" colours, and you simply compute a weighted average of one of 
those precomputed colours, the whitepoint and black; so according to my 
knowledge "you /can/ be sure that the actual percieved hue is stable [in 
relation to the whitepoint] WRT the other parameters of the model" 
(emphasis added).

OTOH, you're obviously still imposing some artificial limit on the 
saturation of colours there, as even reflective colours can - at least 
in theory - be arbitrarily narrow-band (albeit at reduced brightness).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Hmmm... why do you use an uneven gray curve in the first place? (Unless
> that's your official whitepoint, in which case officially there's no
> shift in hue.)

Because I'm aiming for approximations of real life curves, and most of the white
samples I've seen have a sharp drop-off in the extreme violet.  But as I noted,
the visual impact is minimal; under default Lightsys IV color system settings,
the white curve yields rgb <0.9985, 1.0017, 0.9848>, or srgb <255, 255, 253> /
255 in 8 bits.

As it turns out, there are a couple of parameters that can be used to even out
the white curve, although I had introduced them for a different reason.

I should point out that, at least for now, I'm only doing reflective curves.
The "whitepoint" is whatever is reflected by an object that reflects all
wavelengths (mostly) equally.

>  From what I understand now, you have precomputed spectral curves for
> "pure" colours, and you simply compute a weighted average of one of
> those precomputed colours, the whitepoint and black; so according to my
> knowledge "you /can/ be sure that the actual percieved hue is stable [in
> relation to the whitepoint] WRT the other parameters of the model"
> (emphasis added).

Exactly, except that the spectral curves themselves are not precomputed.  The
parameters that match them to sRGB hues are precomputed.

> OTOH, you're obviously still imposing some artificial limit on the
> saturation of colours there, as even reflective colours can - at least
> in theory - be arbitrarily narrow-band (albeit at reduced brightness).

I've decided to use the term "brightness" instead of "saturation."  There will
be some minor rewriting of SDL and major rewriting of documentation.

Post a reply to this message

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > OTOH, you're obviously still imposing some artificial limit on the
> > saturation of colours there, as even reflective colours can - at least
> > in theory - be arbitrarily narrow-band (albeit at reduced brightness).
>
> I've decided to use the term "brightness" instead of "saturation."  There will
> be some minor rewriting of SDL and major rewriting of documentation.

Make that "richness."

Post a reply to this message