(repost)
Ray Pasco wrote:
> I'm using the im.convert() from RGB to CMYK and am getting very strange
> results.
> First, the K value is stuck at zero no matter what the RGB values are.
PIL doesn't do gray component removal and undercolor removal, since they're
both device dependent. for some background, see:
http://mail.python.org/pipermail/image-sig/2002-July/001908.html
for device-aware conversions, you need device profiles and color management
software, such as:
http://www.cazabon.com/pyCMS/
> Next, the C, M and Y values are integers and not in the value range 0.0 -
> 1.0. I have no idea
> what they mean. They seem to bear no relationship at all to the proper CMYK
> values.
there's no absolute connection between a color model and the value ranges
you use to represent a color component in that model. PIL uses 32-bit
CMYK, where each channel is stored in an 8-bit integer (0-255). if you
want another range, multiply or divide as necessary (to get 0.0 to 1.0, just
divide the PIL value by 255.0).
> I coded an RGB to CMY to CMYK algorithm derived from the formulas
> found at http://www.easyrgb.com/math.php?MATH=M2#text2 , which
> seem to be correct.
the CMY(K) <=> RGB conversions on those page looks pretty similar to
the PIL versions.
> Is im.convert ('CMYK') broken?
no.
> Is there any particular reason why conversions to HSV and/or HSL don't exist ?
for individual pixels, use the colorsys module in the standard Python library
(but make sure to scale the values on the way in and out).
for entire images, there's no good way to represent HSV/HSL/HSI/HSB etc
in a 3*8-bit image memory (you usually want more resolution, especially for
the H component).
</F>
_______________________________________________
Image-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/image-sig
