colour lib needs reviewers
Guillaume Chatelet via Digitalmars-d
digitalmars-d at puremagic.com
Mon Sep 12 04:13:57 PDT 2016
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
More information about the Digitalmars-d
mailing list