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