To be more consistent with GLSL naming. Also, the original naming was
quite misleading, as normalize() is used in GLSL for something
completely different.
If building with deprecated APIs, the Functions.h header includes the
new Packing.h header and the {de,}normalize() functions are defined as
deprecated aliases to the new functions. This will be removed at some
point in the future.
The test is running pretty slow on debug builds, though (sorry). I see
no way how to make it faster while still exposing the issues with
std::accumulate().
Building blocks for supporting other colorspaces such as L*a*b. I was
not happy with matrices from Wikipedia because they don't round-trip
perfectly so I have slightly different / more precise versions that do
round-trip.
At first I designed a hugely disrupting change that basically deprecated
everything related to 8-bit linear RGB colors, but then I took a step
back and reconsidered 8-bit linear RGB as a valid use case.
The documentation of Color classes, typedefs and literals was clarified
to mention that these classes should always represent linear RGB and
that 8-bit colors are commonly treated as *not* linear and one should be
aware of it.
There is now a new Color3::fromSrgb() and Color3::toSrgb() that converts
from sRGB representation to a linear RGB usable for calculations and
then back. For four-component colors, there is now
Color4::fromSrgbAlpha() and Color4::toSrgbAlpha(). Similarly to what
OpenGL sRGB behavior is regarding to alpha, the alpha channel is kept
linear, that's why I'm also calling it sRGB + alpha instead of sRGBA.
Besides that, there are four new literals _srgb, _srgba, _srgbf and
_srgbaf that have different semantics to support the sRGB workflow. The
8-bit versions are equivalent to _rgb and _rgba, though they don't
return Color3 but a non-color Vector3 to hint that the result is not a
linear RGB color. Main purpose of these is documentation. The float
versions apply an inverse sRGB curve to the input, returning a linear
RGB color.
For consistency with naming scheme for other color spaces (upcoming
Srgb, Xyz, Lab etc.). The old uppercase names are now marked as
deprecated and will be removed in some future release.
No need for them to be classes, less indentation, less keywords and
boilerplate, more space for documentation, better `using` usage. Also
revised and fixed various issues in the documentation.
The compiler does that for us. Probably a brain fart from 2010. On the
other hand, the ConfigurationValue specializations need to be there,
because the type is used explicitly as template parameter.