colour lib needs reviewers

[Manu via Digitalmars-d]

On 12 September 2016 at 21:13, Guillaume Chatelet via Digitalmars-d
<digitalmars-d at 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.