[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



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
>