HSB and HLS were developed to specify numerical Hue, Saturation and
Brightness (or Hue, Lightness and Saturation) in an age when users had
to specify colors numerically. The usual formulations of HSB and HLS
are
flawed with respect to the properties of color vision. Now that users can
choose colors visually, or choose colors related to other media (such as
PANTONE), or use perceptually-based systems like L*u*v* and L*a*b*,
HSB and
HLS should be abandoned.
Here are some of problems of HSB and HLS. In color selection where
“lightness” runs from zero to 100, a lightness of 50 should appear to be
half as bright as a lightness of 100. But the usual formulations of HSB and
HLS make no reference to the linearity or nonlinearity of the underlying
RGB, and make no reference to the lightness perception of human vision.
The usual formulation of HSB and HLS compute so-called “lightness” or
“brightness” as (R+G+B)/3.
This computation conflicts badly with the
properties of color vision, as it computes yellow to be about six times
more intense than blue with the same “lightness” value (say L=50).
HSB and HSL are not useful for image computation because of the
discontinuity of hue at 360°. You cannot perform arithmetic mixtures of
colors expressed in polar coordinates.
Nearly all formulations of HSB and HLS involve different computations
around 60° segments of the hue circle. These calculations introduce
visible discontinuities in color space.
Although the claim is made that HSB and HLS are “device independent”,
the ubiquitous formulations are based on RGB components whose chromaticities
and white point are unspecified.
Consequently, HSB and HLS
are useless for conveyance of accurate color information.
If you really need to specify hue and saturation by numerical values,
rather than HSB and HSL you should use polar coordinate version of u*
and v*: h*uv for hue angle and c*uv for chroma.
Gladiatore, chi pensi che dice ste belle cosette??
