Calculate the RGB-to-XYZ matrix ourselves instead of using a “magic” one from Wikipedia.

Generally we try to derive such values from first principles when possible;
this is some of the oldest code in Movit, which explains why it was forgotten.

Maybe longer-term we should move this out of ColorspaceConversionEffect into a
free function in util.h or something similar, but for now, this will do.
Add an assertion failure that we don't add the same effect instance twice.

Doing this causes hard-to-understand crashes, so just bomb out at once.
It's now 2014 :-P (Happy new year!)
Fix some outdated comments in GammaExpansionEffect.
In the demo application, reset the FPS counter every hundred frames.

Gives much, much better FPS counts for benchmarking.
Implement GammaExpansionEffect using ALU ops instead of texture lookups.

In a standalone benchmark (on a Sandy Bridge laptop), this is pretty much
a no-op performance-wise, but when more ops are put into the mix, it's
a ~20% FPS win, and but in a more real situation with multiple inputs
etc., it's subjectively also a pretty clear win. The reason is probably
that we generally are way overloaded on texture operations.

Note that we had similar code like this before (before we started using
the texture for lookup), but it used pow(), which is markedly slower than our
fourth-degree polynomial approximation.

We should probably do the same for GammaCompressionEffect.
Fix a typo in a comment.
Fix edge errors in the sRGB comment; I had used subs() on the wrong expression.
Add accuracy unit tests for GammaExpansionEffect.

After all the worry about accuracy in the polynomial expansion,
I figured it was time to actually add tests verifying the error
bounds here in a more reasonable way. The limits are set sort-of
randomly, more-or-less to what the new code already handles,
rounded up a bit. (The old texture-based code was _way_ worse than this,
it seems, probably due to texel center issues.)

This also shows that you can probably do 10-bit processing with
Movit without losing way too much accuracy, but that 12-bit is
too much for fp16 to handle.
Comment and README updates about Rec. 2020 in light of the accuracy test results.
Implement GammaCompressionEffect using ALU ops instead of texture lookups.

This is the same as GammaExpansionEffect; however, the numerical issues
are much much bigger, and it took forever to actually get the coefficients
right for proper accuracy.

Added accuracy tests to GammaCompressionEffect to make sure things are
fine; unsurprisingly, just as with GammaExpansionEffect, the old texture
code wasn't all that accurate. The effects were not as bad, though;
it primarily affects 10- and 12-bit processing, and Movit isn't ready
for 12-bit accuracy-wise.

The benchmark wins are huge; in a chain with effectively only a
GammaExpansionEffect and a GammaCompressionEffect, FPS on Sandy Bridge
(HD3000) goes up ~80%. Seemingly sampling that 4096x1 texture was really
expensive.