On Monday, 12 September 2016 at 09:09:29 UTC, Manu wrote:
I thought about it, but it added (even more) complexity, and
I'm not really sure it's the MO of a color lib to worry about
the endian-ness of storage.
I could support "_le"/"_be" suffix on the PackedRGB format
string, but
then you have to also specify the word size, ie, is the packed
color
32bit words (eg, 11,11,10) or 16bit words (16f,16f,16f,16f)?
It's only really practically applicable to PackedRGB, so I
wonder why
just one color type should worry about it, but not all the
others...
Consider an unpacked RGB with 16bit elements... that may also
suffer endian problems, but RGB is a runtime type, not a
storage type, which means it doesn't have a pack/unpack
process... so there's no meaningful palace to do it.
Yep I totally understand the rationale - I've been there too :)
I don't think it belong to Color but maybe Buffer(1) could be
templated on endianness? Buffer is indeed the place where you
deal with storage.
If you don't want to add it to the library I think you should add
a paragraph in the documentation explaining why it's not in there
and how people can overcome it (copy + change endianness or use
an adapter?).
Also, it would be nice to have some code snippets in the
documentation.
Last thing, for the white points you didn't specify which CIE
standard observer(2) version you used: CIE 1931 2° Standard
Observer or CIE 1964 10° Standard Observer? IIRC the standard
illuminant are not the same depending on the observer.
1.
http://dtest.thecybershadow.net/artifact/website-04a64e024cf75be39700bebd3a50d26f6c7bd163-7185c8ec7b15c9e785880cab6d512e6f/web/library-prerelease/std/experimental/color/packedrgb/buffer.html
2.
https://en.wikipedia.org/wiki/CIE_1931_color_space#CIE_standard_observer
