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

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



> -----Original Message-----
> From: owner-pygame-users@xxxxxxxx [mailto:owner-pygame-users@xxxxxxxx] On
> Behalf Of Marcus von Appen
> Sent: Tuesday, May 27, 2008 2:25 AM
> To: pygame-users@xxxxxxxx
> Subject: [pygame] New pygame.Color class now in SVN
> 
> 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

Well, as far as the rgb to cmyk conversion status goes, it looks like the
patents have either expired or the rights holders haven't sued anybody for a
while, since there's a plethora of open source projects adding CMYK support
these days, as illustrated in this article:
http://rants.scribus.net/2008/01/12/when-a-million-does-not-equal-a-million/

If you were looking for a safe to use algorithm, best place to look would
probably be imagemagick since it's open source, well known, and has been
doing rgb to cmyk for a while. If anybody was going to get sued, they'd
probably be first on the list:
http://www.imagemagick.org/script/index.php

Interestingly, with US patent law it can actually be a good idea not to
research if you're infringing on any patents, as knowing that you're
infringing can be grounds for treble damages. (Not a lawyer, this is not
legal advice, yada yada).

---------
John Krukoff
helot@xxxxxxxxxxx