> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Marcus von Appen > Sent: Tuesday, May 27, 2008 2:25 AM > To: [email protected] > 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 [EMAIL PROTECTED]
