On 12 September 2016 at 21:13, Guillaume Chatelet via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > 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.
That's very true. The data is all CIE 1931 reference. I haven't seen deployed use of the updated standard... I don't know why.