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