|
![](/i/fill.gif) |
Am 05.08.2014 06:35, schrieb Cousin Ricky:
> clipka <ano### [at] anonymous org> 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
|
![](/i/fill.gif) |