Re: [pygame] New pygame.Color class now in SVN

["René Dudfield" <renesd@xxxxxxxxx>]

ah, I just noticed you've added tests for color :)  cool.

On Tue, May 27, 2008 at 8:33 PM, René Dudfield <renesd@xxxxxxxxx> wrote:
> yes, very nice work :)
>
> btw, Nicholas has been working on unittests for the color stuff.
>
> It's interesting that Color is kind of similar to Rect.  In that they
> are both vectors of length 4.
>
> cu,
>
>
> On Tue, May 27, 2008 at 6:25 PM, Marcus von Appen <mva@xxxxxxxxxxxx> wrote:
>> Hi,
>>
>> on the mini sprint of the last weekend we decided to put the new Color
>> class into the main tree. It is now available in rev. 1251 of the SVN
>> tree and will make its way into 1.8.1.
>>
>> So what are its benefits? Extensibility and features of course. The
>> Color class replaces the previously used 4-value color tuples throughout
>> the whole pygame framework. To maintain backwards compatibility, any
>> function, object and method taking a color argument now can take either
>> the old-style tuple or a Color.
>>
>> For creation of a Color, you can define each RGBA part separately, use
>> the predefined color names or an integer value, which _must_ represent
>> all four parts (otherwise you'll wonder, why the alpha has a value, but
>> the red not :-).
>>
>>    c = pygame.Color (10, 20, 30, 40)
>>    c = pygame.Color ("red")
>>    c = pygame.Color (0xCCAA90FF)
>>
>> Colors also support several arithmetic operations, namely addition,
>> subtraction, multiplication, division, modulo operations and inversion
>> (those are currently not implemented as inplace operations, though).
>>
>> You can normalize colors, receiving a tuple with a value range between 0
>> and 1, correct their gamma values or use different color space
>> representations, such as HLSA, HSVA and YUV. You also convert them to an
>> integer, long, float, hexadecimal and octal representation.
>>
>> The color space representations are implemented as attributes using
>> a tuple and let you retrieve or assign the respective representation.
>>
>>     y, u, v = color.yuv
>>     ...
>>     color.yuv = (y, u, v)
>>
>> As well as the normalized representation, the different color space
>> representations are within the range between 0 and 1.
>>
>> On updating, please remove the color.py file from your existing pygame
>> installation in case you are installing over it without prior removal of
>> the package.
>>
>> Rene mentioned that a CMYK representation would be nice. I am unsure
>> about the legal state of the RGB(A) to CMYK conversion though. Back in
>> the 90s, EFI (I think) sued several companies and product developers,
>> who supported RGB to CMYK conversion routines. Does someone know, if
>> they still hold those weird rights, or is it safe to add such
>> routines nowadays?
>>
>> Regards
>> Marcus
>>
>