Currently just does per-pixel comparison and calculates absolute delta,
failing the comparison if max/mean delta threshold is above specified
values. Useful enough for the case I have right now, might fail in other
case -- but still better than whatever else I was using before :)
Most of the code is in the actual test where I'm comparing and
benchmarking three different implementations (a
naive/straightforward/ground-truth one, the chosen one and a fast though
cache-spilling table-based one) to ensure the behavior is consistent
across all of them and that the performance is within reasonable bounds.
The Corrade::TestSuite benchmarking stuff needs serious improvements,
though.
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().
MeshTools and Shaders dependencies are needed only if either the Shapes
or SceneGraph library is compiled, Primitives are needed only if the
Shapes library is compiled.
I found a way how to hack cmake_dependent_option() beyond just
specifying a list of things AND-ed togeter -- if one uses spaces instead
of `;`, all the contents are passed to a single if() statement and it's
possible to use parentheses, AND, OR and all other stuff.
Now, WindowlessEglApplication is implicitly enabled if targeting
non-desktop ES and magnum-info utility is enabled, because magnum-info
depends on it in that case. In all other cases it is implicitly disabled
with ability to enable it.
WindowlessGlxApplication is now available only when targeting desktop GL
or desktop GLES and is implicitly enabled when magnum-info or any other
GL utility is enabled.
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.