This allows perfect representation of E (equal energy spectrum).
It's not important from a perceptual standpoint, but it provides
a simple way for Psychopath to represent E when needed for other
purposes.
This is useful because it's super fast, and chromaticity lookups
are typical for spectral upsampling anyway, so this will likely
enable cutting out a bunch of unecessary intermediate calculations.
The whole point of these formats is to compress down to less
space, so let's not leave actually putting it in the space-saving
form on the client code.
It is identical to the 32-bit format, except with more precision
and range due to using more bits. This format should comfortably
store any color information with precision easily exceeding the
limits of human vision.
This also makes encoding faster. However, it no longer does
rounding to the nearest precision when encoding, and insead does
flooring. This seems like a reasonable tradeoff: if you want more
precision... you should use a format with more precision.
It was a worthwhile experiment, but for it to really work it needs
a really proper luma-chroma separation, which is both slower than
I really want, and requires knowing the colorspace being used.
I might make another go at this based on the TIFF LogLUV color
format, requiring XYZ as input.
Before this it needed SSE 4.1, which is not strictly present on
all x86-64 platforms. This will still compile the faster path if
SSE 4.1 is available, but has an alternate path as well for all
x86-64 platforms.
The biggest one is avoiding a bunch of bit reversals by keeping
numbers in bit-reversed form for as long as we can.
Also reduced the hashing rounds: just 2 rounds seems to be enough
for a reasonable amount of statistical independence on both the
scrambling and shuffling. I tested both independently, keeping
the other with no scrambling/shuffling respectively. This makes
sense because in normal contexts 3 is enough, but in this case
both act as input to yet another hash which is effectively doing
more rounds.
