[Image-SIG] Problem with JPEG and CMYK color space
kevin at cazabon.com
kevin at cazabon.com
Sun Apr 16 14:25:53 CEST 2006
I've attached a patched JpegImagePlugin.py file (sorry for the 14.5kb
attachment to a mailing list). It should fix the inversion problem both
upon load and upon save of CMYK JPEG files.
Modifications can be found starting on the following lines:
line 35: add ImageChops to the import list, for inverting images
line 273: comment out previous patch for Adobe Photoshop 2.5 CMYK files...
I sure hope nobody uses 2.5 anymore, and this patch breaks newer versions.
line 288: invert CMYK images after load
line 416: invert CMYK images before save
I'm sure there are more elegant an efficient ways of fixing this problem,
but this works. I hope it helps you, as I've had the same issues myself.
Fredrik - if you're ok with the crude methods of fixing this problem, can
you include it in future builds? Thanks.
Kevin.
----- Original Message -----
From: <kevin at cazabon.com>
To: <kevin at cazabon.com>; "Cesare Leonardi" <ced at bernispa.com>;
<image-sig at python.org>
Sent: Saturday, April 15, 2006 2:01 PM
Subject: Re: [Image-SIG] Problem with JPEG and CMYK color space
> In the JPEGImagePlugin.py module, there's a hack to handle Photoshop 2.5
> CMYK JPEG images (around line 273)... that's causing half the problem upon
> loading JPEG's. By commenting that out, you get a proper image, although
> it's still inverted.
>
> I can't seem to find the right place to re-invert the image upon load, but
> I'll see what I can find. Anyone with suggestions would be welcome.
> There's probably a better way to do this though, so the data is read
> correctly in the first place (in CMYK, 0,0,0,0 = white, 255,255,255,255 =
> full black... this is probably the problem).
>
> Kevin.
> ----- Original Message -----
> From: <kevin at cazabon.com>
> To: "Cesare Leonardi" <ced at bernispa.com>; <image-sig at python.org>
> Sent: Saturday, April 15, 2006 1:32 PM
> Subject: Re: [Image-SIG] Problem with JPEG and CMYK color space
>
>
>> Actually, the problem is that PIL also has problems reading CMYK JPEG
>> files
>> apparently. I just proved that by loading your CMYK test files and doing
>> a
>> "show", then loading a CMYK TIFF file and doing a show (note that to use
>> show, it converts to RGB with the internal conversion, so the colors
>> won't
>> be perfect). The TIFF loaded fine, the JPEG didn't.
>>
>> The patch I've submitted fixes the problem with saving incorrectly, but
>> doesn't fix the reading issue (yet). So, as long as your source CMYK
>> image
>> doesn't come from a JPEG file it's ok (with my invert patch).
>>
>> I'll see if I can spend some time looking at that this weekend.
>>
>> Kevin.
>> ----- Original Message -----
>> From: "Cesare Leonardi" <ced at bernispa.com>
>> To: <image-sig at python.org>
>> Sent: Friday, April 14, 2006 9:38 AM
>> Subject: Re: [Image-SIG] Problem with JPEG and CMYK color space
>>
>>
>>> kevin at cazabon.com ha scritto:
>>>> When saving a CMYK file to JPG, PIL seems to invert the colors. I've
>>>> submitted a patch to Fredrik already for this, and it should be in the
>>>> next major build.
>>>>
>>>> Adding a simple invert to the image before saving will help.
>>>
>>> Thanks all for your responses.
>>>
>>> Kevin, i've made some tests following what you've suggested and here is
>>> the results.
>>> To obtain the color inversion i've used the function invert() in
>>> ImageChops module. I've added the code and the new sample images in this
>>> page (see "part 2"):
>>> http://www.bernispa.com/pil/index.html
>>>
>>> As you can see your suggestion works partially.
>>> Images 02 and 03 (that was particular in "part 1") are the only that
>>> after the inversion looks ok.
>>> All the other images looks less dark, but the color are always different
>>> than the original.
>>> The particular thing to note is that the images produced by the
>>> inversion looks the same as Image.show(). Seems that show() already do
>>> the inversion.
>>>
>>> There is another thing that i have noted only now: the images saved by
>>> PIL are often less big than the original. Sometimes much less. For
>>> example:
>>> test01: 1435 KB test01-dst: 198 KB test01-dst-invert: 198 KB
>>> test04: 1237 KB test01-dst: 405 KB test01-dst-invert: 405 KB
>>> test08: 1647 KB test01-dst: 777 KB test01-dst-invert: 776 KB
>>> test09: 1715 KB test01-dst: 665 KB test01-dst-invert: 665 KB
>>> test10: 2032 KB test01-dst: 659 KB test01-dst-invert: 659 KB
>>> I can think that PIL optimize the compression, but that difference are
>>> really big. Isn't it suspicious? I expect that saving an image in a new
>>> file without modifications produces a file very similar to the original,
>>> isn't it?
>>> The original images was not produced by me so the author can have used
>>> low compression. I cannot make tests since i haven't a program that can
>>> save in CMYK (Gimp seems not able).
>>>
>>> Regards.
>>>
>>> Cesare.
>>> _______________________________________________
>>> Image-SIG maillist - Image-SIG at python.org
>>> http://mail.python.org/mailman/listinfo/image-sig
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Image-SIG maillist - Image-SIG at python.org
>> http://mail.python.org/mailman/listinfo/image-sig
>>
>>
>>
>
>
>
>
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: JpegImagePlugin.py
Url: http://mail.python.org/pipermail/image-sig/attachments/20060416/62df61be/attachment.pot
More information about the Image-SIG
mailing list