From douglas at paradise.net.nz Mon Jun 1 02:23:18 2009 From: douglas at paradise.net.nz (Douglas Bagnall) Date: Mon, 01 Jun 2009 12:23:18 +1200 Subject: [Image-SIG] remove an image background using PIL In-Reply-To: <368a5cd50905311027u190f74f6s9eb077b9c684848e@mail.gmail.com> References: <368a5cd50905281343w7da41753u9e18a137963e5d1b@mail.gmail.com> <368a5cd50905311027u190f74f6s9eb077b9c684848e@mail.gmail.com> Message-ID: <4A231F76.3010906@paradise.net.nz> Peter Yen wrote: >> Thanks for your quick response. The background is unknown at the time of >> processing. Actually I don't need a very accurate methodology to remove all >> background, removing partially is good enough. I once wrote a (GPL'd) C module that fairly reliably extracts the background of a photograph of a drawing on paper. It is essentially the same as PIL's floodfill but it follows shallow gradients. The public git browser[1] seems to be broken right now, but if this sounds like what you need download a tarball[2], and look for the expand_region function in the img-c directory. [1] https://savannah.nongnu.org/git/?group=tetuhi [2] http://sourceforge.net/project/showfiles.php?group_id=217385 Douglas From fbuchinger at gmail.com Tue Jun 2 13:58:38 2009 From: fbuchinger at gmail.com (Franz Buchinger) Date: Tue, 2 Jun 2009 13:58:38 +0200 Subject: [Image-SIG] Lanczos interpolation In-Reply-To: <368a5cd50905120535y56292766n7565ddacfe818c16@mail.gmail.com> References: <2fede7f50905100345n58232bc2va0f00ea0c876c425@mail.gmail.com> <368a5cd50905120535y56292766n7565ddacfe818c16@mail.gmail.com> Message-ID: A good old trick is to work with intermediate images: resize the image using the Bilinear method and produce an intermediate image that is about 25% larger than the final image. Then you can downscale the intermediate image using Lanczos. This should give a much better performance than working just with Lanczos, especially for large downscaling ratios (e.g. 10 Megapixel JPEG -> 1024x768) . Image quality shouldn't be affected too much by this method. Franz 2009/5/12 Fredrik Lundh > On Sun, May 10, 2009 at 12:45 PM, David Yan wrote: > > I want to resize an image Lanczos interpolation but I haven't found any > > python module that can do so. Also, I'm not knowledgeable enough to > write > > one myself. What's the best way I can do this? I use PIL currently but > the > > resampling filters don't suit my needs (antialias is too slow, bilinear > and > > bicubic produce aliasing when downsampling). > > ANTIALIAS is a Lanczos interpolation written in C, so it's not > entirely obvious to me how you expect a Python version to be faster... > > > _______________________________________________ > Image-SIG maillist - Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fbuchinger at gmail.com Tue Jun 2 14:12:34 2009 From: fbuchinger at gmail.com (Franz Buchinger) Date: Tue, 2 Jun 2009 14:12:34 +0200 Subject: [Image-SIG] Reading title EXIF data In-Reply-To: <6a8d94bd0905221119n682a2868t96f640aec5addea7@mail.gmail.com> References: <6a8d94bd0905221119n682a2868t96f640aec5addea7@mail.gmail.com> Message-ID: PIL is an excellent image processing library, but unfortunatly not a tool of choice when you want to deal with EXIF data seriously. It only extracts a subset of the EXIF-Data contained in an image, for a more complete library you may want to check pyexiv2 (python wrapper for exiv2). And beware, EXIF (as well as other metadata standards like IPTC) is full of "dead tags" that are only written by some exotic image processing applications or camera models. In your special case ("finding a title for a photo"), I'd resort to IPTC:Caption - this is where Photoshop/Lightroom/Google Picasa and many other image processing apps store "title" information. Franz 2009/5/22 Luke Hutscal > Hello, all. > > > I am currently working on a Django application that stores photos as users > upload them. > > > One of the cooler features that we'd like to add is automatic EXIF reading > - so instead of users having to go through and update their photo's > information again after uploading them, the EXIF data on the uploaded photos > can get automatically read into certain fields - title, caption, and so on. > > > I have been using the Image._getexif() method to retrieve the EXIF data for > the photos that are being uploaded - but it seems that the "title" attribute > is missing. Here's an example of what _getexif() returns: > > > http://liftslice3.com/getexif.txt > > However, when I run ExifTool(http://www.sno.phy.queensu.ca/~phil/exiftool/) > on the image with the -d flag, this is what is output: > > http://liftslice3.com/exiftool.txt > > As you can see, there's definitely a title attribute present on the image > in question. I took a look at the EXIF tags list at > http://www.element-it.com/StandardImageTags.ASPX, and noticed that the > ImageTitle EXIF tag isn't present in PIL's ExifTags.py - is there a reason > for this? I tried adding a key for 0x0320 with the value "ImageTitle" to the > TAGS dict, but PIL still doesn't seem to be reading the ImageTitle attribute > out of my images. > > Is there something I've missed that is keeping PIL from reading the title > attribute? > > Thanks, > > Luke > > > _______________________________________________ > Image-SIG maillist - Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From geert at nznl.com Tue Jun 2 21:13:50 2009 From: geert at nznl.com (Geert Dekkers) Date: Tue, 2 Jun 2009 21:13:50 +0200 Subject: [Image-SIG] Python Core Graphics Question (resent) Message-ID: Hi all (I just resent this message as I couldn't it find it on the digest even after days - again, I apologise for any cross-posting) Below is a piece of code that I found over in the quartz-dev list. I've been using this function unchanged in a batch processor, and it appears to leak memory quite substantially. So much so that my test machine (1Gb memory) , a mac mini, and my production xserve (2 Gb memory) both crashed using it. My dev machine, an imac (4Gb memory) slowed, but stayed up. I think I have the problem down to "croppedimg = srcimg.createWithImageInRect(cliprect)". If used with an image of suffient size, it quickly sucks up all available memory. Has anyone experienced similar problems using this method? Its Obj-C name is "CGContextCreateWithImageInRect". And I should think that one would only see something bad happening in some sort of batch processing. Incidentally, my workaround was to lower the size of the source image. But the process is still quite unstable. It brought down my xserve after processing 7000 of the 7600 odd items. I've pasted the original post below. And sorry for any cross - posting. Cheers, Geert ---------------------------------------------------------------------------------------------- Geert Dekkers Web Studio | 2e Keucheniusstraat 8HS 1051VR Amsterdam | +31(0)627224301 | http://nznl.net ---------------------------------------------------------------------------------------------- >> Thanks for you detailed reply Glen - much appreciated. >> You helped me to solve what i was trying to do by using >> CGImageCreateWithImageinRect as suggested. >> >> For anyone else interested here is some simple python code for >> making cropped thumbnails of any proportion and not loosing the >> aspect ratio of the original image. >> ...and its damn fast! >> >> ----------- #!/usr/bin/python >> >> from __future__ import division import CoreGraphics >> >> def resizeimage(srcimage,targetimage, tw, th): >> >> srcimg = >> CoreGraphics >> .CGImageImport >> (CoreGraphics.CGDataProviderCreateWithFilename(srcimage)) >> >> sw = srcimg.getWidth() >> sh = srcimg.getHeight() >> >> aspect = tw/th >> >> widthfactor = tw/sw >> heightfactor = th/sh >> >> if widthfactor < heightfactor: >> #src height stays the same >> #src width gets cropped >> cropwidth = sh * aspect >> x1 = ((sw-cropwidth)/2) >> y1 = 0 >> x2 = sw-((sw-cropwidth)) >> y2 = sh >> else: >> #src height gets cropped >> #src width stays the same >> cropheight = sw / aspect >> x1 = 0 >> y1 = ((sh-cropheight)/2) >> x2 = sw >> y2 = sh-((sh-cropheight)) >> >> cliprect = CoreGraphics.CGRectMake(x1, y1, x2, y2) >> croppedimg = srcimg.createWithImageInRect(cliprect) >> >> cs = CoreGraphics.CGColorSpaceCreateDeviceRGB() >> c = CoreGraphics.CGBitmapContextCreateWithColor(tw, th, cs, >> (0,0,0,0)) >> >> c.setInterpolationQuality(CoreGraphics.kCGInterpolationLow) >> newRect = CoreGraphics.CGRectMake(0, 0, tw, th) >> c.drawImage(newRect, croppedimg) >> c.writeToFile(targetimage, CoreGraphics.kCGImageFormatJPEG) >> >> resizeimage("/users/adam/Desktop/bootlogo4pa8.jpg", "/users/adam/ >> Desktop/aaaaa.jpg" , 80,80) >> >> >> >> >> >> >> >>> On Aug 12, 2008, at 3:41 AM, Glenn Cole wrote: >>> >>> Hi, Adam -- >>> >>> I'm no expert, but until others more knowledgeable respond, here's >>> my understanding. >>> >>> First, I suspect the fact that you're using Python won't matter at >>> all here. (It does in other circumstances, but I don't think so >>> here.) >>> >>> It sounds like you're looking for more support from Quartz for >>> your task than what's really there. In the end, I think it's going >>> to be more a choice of algorithm on your part. >>> >>> For example, given different aspect ratios, the new image could >>> either: >>> >>> 1. ignore the difference (i.e., the current behaviour) >>> 2. show the entire original image within the new target, >>> respecting the aspect ratio >>> 3. clip the original image to match the new aspect ratio >>> >>> For #2, you could shrink the target rect to match the aspect ratio >>> of the original image. >>> >>> For #3 (your goal), you could clip the original image to match the >>> target aspect ratio. However, page 250 of the outstanding >>> Programming With Quartz notes a few downsides to this, and >>> suggests using CGImageCreateWithImageInRect instead (first >>> available in Tiger) to define a "subimage" of the original image. >>> Again, though, you would need to determine yourself that the >>> subimage should ignore 100 pixels from the left and right sides of >>> the original image. >>> >>> At least, that's my take on things. We'll see what others say >>> (though they've tended to ignore Python questions in the past). >>> >>> Incidentally, the subject line says "Core Image resize question." >>> The code below has no reference to Core Image, and I'm pretty sure >>> that Core Image need not be involved in this task at all. (Perhaps >>> you mentioned Core Image because of the existence of its CICrop >>> filter, but I think that's not the best direction for the task at >>> hand.) >>> >>> --Glenn >>> >>> >>> On Aug 11, 2008, at 5:33 AM, Adam Jones wrote: >>> >>> Hi there i am wondering if someone can help me with this. Below is >>> the code i am using to resize and save a jpeg image. >>> >>> It works mint as but it obviously scales the image with no respect >>> for the aspect ratio. >>> >>> i want to be able to take an image and scale it proportionaly to a >>> square thumbnail. so for example a 800x600 image scaled to 80x80 >>> would need to loose 100pixels off the left and 100 pixels on the >>> right before scaling. >>> >>> Does any one know how to crop using python quartz or can i draw >>> the rec with the image off the canvas to achieve the same? >>> >>> Thanks Adam >>> >>> >>> ----------- #!/usr/bin/python >>> >>> import CoreGraphics >>> >>> def resizeimage(srcimage,targetimage, w, h): >>> >>> origImage = CoreGraphics .CGImageImport >>> (CoreGraphics.CGDataProviderCreateWithFilename(srcimage)) >>> >>> origwidth = origImage.getWidth() # not used yet but will be once i >>> work out how to crop >>> origheight = origImage.getHeight() # not used yet but will be once >>> i work out how to crop >>> >>> cs = CoreGraphics.CGColorSpaceCreateDeviceRGB() >>> c = CoreGraphics.CGBitmapContextCreateWithColor(w, h, cs, (0,0,0,0)) >>> >>> c.setInterpolationQuality(CoreGraphics.kCGInterpolationLow) >>> newRect = CoreGraphics.CGRectMake(0, 0, w, h) >>> c.drawImage(newRect, origImage) >>> c.writeToFile(targetimage, CoreGraphics.kCGImageFormatJPEG) >>> >>> >>> resizeimage(uploadedfile, "/svr/data/images/listings/%s/ >>> %s_160x90.jpg" % (str(listing_id), newimagename), 160,90) >>> >>> ------------- >>> >>> >>> _______________________________________________ Do not post admin >>> requests to the list. They will be ignored. Quartz-dev mailing >>> list (email at hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartz-dev/email at hidden >>> >>> This email sent to email at hidden >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From halbert at halwitz.org Wed Jun 3 00:28:23 2009 From: halbert at halwitz.org (Dan Halbert) Date: Tue, 2 Jun 2009 18:28:23 -0400 (EDT) Subject: [Image-SIG] =?utf-8?q?im=2Eshow=28=29_using_eog_doesn=27t_work_se?= =?utf-8?q?cond_time?= Message-ID: <1243981703.60930922@192.168.1.202> I'm using PIL 1.1.6 on Ubuntu jaunty, and noticed a problem with invoking im.show() more than once without closing the image viewing window. On this system, im.show() uses "eog" to view the images. If you do something like: >>>im.show() # don't close the eog window >>>im.show() then the second im.show() causes an error. The actual images don't matter: they could be the same or different. The two im.show() calls invoke Image._showxv() twice, which effectively does this: os.system("(eog /tmp/tmp123; rm -f /tmp/tmp123)&") os.system("(eog /tmp/tmp456; rm -f /tmp/tmp456)&") However, eog is very clever and tries to reuse its first instance. So the second instantiation of eog exits immediately after notifying the first to display /tmp/tmp456. But then the file disappears out from under it. The _showxv() code shows a similar problem already came up on OS X, and a "sleep 20" was inserted before the "rm". For eog, another, perhaps more elegant solution is to invoke eog as "eog -n", which always starts a new instance instead of reusing an existing one. Regards, Dan From fredrik at pythonware.com Wed Jun 3 00:38:56 2009 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 3 Jun 2009 00:38:56 +0200 Subject: [Image-SIG] Python Core Graphics Question (resent) In-Reply-To: References: Message-ID: <368a5cd50906021538x1deca389u7dce3502dcc26092@mail.gmail.com> On Tue, Jun 2, 2009 at 9:13 PM, Geert Dekkers wrote: > (I just resent this message as I couldn't it find it on the digest even > after days - again, I apologise for any cross-posting) It's in the image-sig archive, at least: http://mail.python.org/pipermail/image-sig/2009-May/005709.html From fredrik at pythonware.com Wed Jun 3 00:40:59 2009 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 3 Jun 2009 00:40:59 +0200 Subject: [Image-SIG] im.show() using eog doesn't work second time In-Reply-To: <1243981703.60930922@192.168.1.202> References: <1243981703.60930922@192.168.1.202> Message-ID: <368a5cd50906021540v704270a8o337709d65091f44a@mail.gmail.com> On Wed, Jun 3, 2009 at 12:28 AM, Dan Halbert wrote: > I'm using PIL 1.1.6 on Ubuntu jaunty, and noticed a problem with invoking im.show() more than once without closing the image viewing window. On this system, im.show() uses "eog" to view the images. If you do something like: > >>>>im.show() ?# don't close the eog window >>>>im.show() > > then the second im.show() causes an error. The actual images don't matter: they could be the same or different. > > The two im.show() calls invoke Image._showxv() twice, which effectively does this: > > ? os.system("(eog /tmp/tmp123; rm -f /tmp/tmp123)&") > ? os.system("(eog /tmp/tmp456; rm -f /tmp/tmp456)&") > > However, eog is very clever and tries to reuse its first instance. So the second instantiation of eog exits immediately after notifying the first to display /tmp/tmp456. But then the file disappears out from under it. > > The _showxv() code shows a similar problem already came up on OS X, and a "sleep 20" was inserted before the "rm". For eog, another, perhaps more elegant solution is to invoke eog as "eog -n", which always starts a new instance instead of reusing an existing one. The standard 1.1.6 distribution doesn't know about eog, so this is probably an Ubuntu-specific fix. Have you reported the problem to Ubuntu? From halbert at halwitz.org Wed Jun 3 02:22:07 2009 From: halbert at halwitz.org (Dan Halbert) Date: Tue, 02 Jun 2009 20:22:07 -0400 Subject: [Image-SIG] im.show() using eog doesn't work second time In-Reply-To: <368a5cd50906021540v704270a8o337709d65091f44a@mail.gmail.com> References: <1243981703.60930922@192.168.1.202> <368a5cd50906021540v704270a8o337709d65091f44a@mail.gmail.com> Message-ID: <4A25C22F.7050309@halwitz.org> Fredrik Lundh wrote: > On Wed, Jun 3, 2009 at 12:28 AM, Dan Halbert wrote: > >> I'm using PIL 1.1.6 on Ubuntu jaunty, and noticed a problem with invoking im.show() more than once without closing the image viewing window. On this system, im.show() uses "eog" to view the images. [...] >> > The standard 1.1.6 distribution doesn't know about eog, so this is > probably an Ubuntu-specific fix. Have you reported the problem to > Ubuntu? > > > Thanks - I should have looked more carefully at the original source. For the record, using eog was introduced as a fix for Debian bug #321658, with a corresponding Ubuntu bug #67755. #321658 is too old to reopen, so I reported this as the new Ubuntu bug #382987. --Dan From douglas at paradise.net.nz Wed Jun 3 03:57:52 2009 From: douglas at paradise.net.nz (Douglas Bagnall) Date: Wed, 03 Jun 2009 13:57:52 +1200 Subject: [Image-SIG] Lanczos interpolation In-Reply-To: References: <2fede7f50905100345n58232bc2va0f00ea0c876c425@mail.gmail.com> <368a5cd50905120535y56292766n7565ddacfe818c16@mail.gmail.com> Message-ID: <4A25D8A0.8030002@paradise.net.nz> If you want the downsampling algorithm used by the Gimp and (I think) Photoshop, try: def stretch(im, size, filter=Image.NEAREST): im.load() im = im._new(im.im.stretch(size, filter)) return im In 2005 I found it to be a few times quicker than ANTIALIAS resizing, and the results were better from what I was doing. (From http://mail.python.org/pipermail/image-sig/2005-May/003310.html) Douglas From geert at nznl.com Wed Jun 3 07:51:37 2009 From: geert at nznl.com (Geert Dekkers) Date: Wed, 3 Jun 2009 07:51:37 +0200 Subject: [Image-SIG] Reading title EXIF data In-Reply-To: References: Message-ID: <657A3236-3585-4298-82D5-5B397DA0D472@nznl.com> Hi all I have a django asset management tool that uses the exiftool command line to extract metadata which does get the title, and a host of other tags. Exiftool is great because it's complete and really well maintained. The downside is of course that it's perl. I use the command line interface through subprocess, works really well. Geert On Jun 3, 2009, at 12:35 AM, image-sig-request at python.org wrote: > Send Image-SIG mailing list submissions to > image-sig at python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/image-sig > or, via email, send a message with subject or body 'help' to > image-sig-request at python.org > > You can reach the person managing the list at > image-sig-owner at python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Image-SIG digest..." > Today's Topics: > > 1. Re: Lanczos interpolation (Franz Buchinger) > 2. Re: Reading title EXIF data (Franz Buchinger) > 3. Python Core Graphics Question (resent) (Geert Dekkers) > > From: Franz Buchinger > Date: June 2, 2009 1:58:38 PM GMT+02:00 > To: image-sig at python.org > Subject: Re: [Image-SIG] Lanczos interpolation > > > A good old trick is to work with intermediate images: resize the > image using the Bilinear method and produce an intermediate image > that is about 25% larger than the final image. > Then you can downscale the intermediate image using Lanczos. > > This should give a much better performance than working just with > Lanczos, especially for large downscaling ratios (e.g. 10 Megapixel > JPEG -> 1024x768) . > Image quality shouldn't be affected too much by this method. > > > Franz > > 2009/5/12 Fredrik Lundh > On Sun, May 10, 2009 at 12:45 PM, David Yan > wrote: > > I want to resize an image Lanczos interpolation but I haven't > found any > > python module that can do so. Also, I'm not knowledgeable enough > to write > > one myself. What's the best way I can do this? I use PIL > currently but the > > resampling filters don't suit my needs (antialias is too slow, > bilinear and > > bicubic produce aliasing when downsampling). > > ANTIALIAS is a Lanczos interpolation written in C, so it's not > entirely obvious to me how you expect a Python version to be faster... > > > _______________________________________________ > Image-SIG maillist - Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig > > > > > From: Franz Buchinger > Date: June 2, 2009 2:12:34 PM GMT+02:00 > To: image-sig at python.org > Subject: Re: [Image-SIG] Reading title EXIF data > > > PIL is an excellent image processing library, but unfortunatly not a > tool of choice when you want to deal with EXIF data seriously. > > It only extracts a subset of the EXIF-Data contained in an image, > for a more complete library you may want to check pyexiv2 (python > wrapper for exiv2). > > And beware, EXIF (as well as other metadata standards like IPTC) is > full of "dead tags" that are only written by some exotic image > processing applications or camera models. > > In your special case ("finding a title for a photo"), I'd resort to > IPTC:Caption - this is where Photoshop/Lightroom/Google Picasa and > many other image processing apps store "title" information. > > Franz > > 2009/5/22 Luke Hutscal > Hello, all. > > I am currently working on a Django application that stores photos as > users upload them. > > One of the cooler features that we'd like to add is automatic EXIF > reading - so instead of users having to go through and update their > photo's information again after uploading them, the EXIF data on the > uploaded photos can get automatically read into certain fields - > title, caption, and so on. > > I have been using the Image._getexif() method to retrieve the EXIF > data for the photos that are being uploaded - but it seems that the > "title" attribute is missing. Here's an example of what _getexif() > returns: > > http://liftslice3.com/getexif.txt > > However, when I run ExifTool(http://www.sno.phy.queensu.ca/~phil/exiftool/ > ) on the image with the -d flag, this is what is output: > > http://liftslice3.com/exiftool.txt > > As you can see, there's definitely a title attribute present on the > image in question. I took a look at the EXIF tags list at http://www.element-it.com/StandardImageTags.ASPX > , and noticed that the ImageTitle EXIF tag isn't present in PIL's > ExifTags.py - is there a reason for this? I tried adding a key for > 0x0320 with the value "ImageTitle" to the TAGS dict, but PIL still > doesn't seem to be reading the ImageTitle attribute out of my images. > > Is there something I've missed that is keeping PIL from reading the > title attribute? > > Thanks, > > Luke > > > _______________________________________________ > Image-SIG maillist - Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig > > > > > > From: Geert Dekkers > Date: June 2, 2009 9:13:50 PM GMT+02:00 > To: image-sig at python.org > Cc: pythonmac-sig at python.org > Subject: [Image-SIG] Python Core Graphics Question (resent) > > > Hi all > (I just resent this message as I couldn't it find it on the digest > even after days - again, I apologise for any cross-posting) > Below is a piece of code that I found over in the quartz-dev list. > I've been using this function unchanged in a batch processor, and it > appears to leak memory quite substantially. So much so that my test > machine (1Gb memory) , a mac mini, and my production xserve (2 Gb > memory) both crashed using it. My dev machine, an imac (4Gb memory) > slowed, but stayed up. > I think I have the problem down to "croppedimg = > srcimg.createWithImageInRect(cliprect)". If used with an image of > suffient size, it quickly sucks up all available memory. > Has anyone experienced similar problems using this method? Its Obj-C > name is "CGContextCreateWithImageInRect". And I should think that > one would only see something bad happening in some sort of batch > processing. > Incidentally, my workaround was to lower the size of the source > image. But the process is still quite unstable. It brought down my > xserve after processing 7000 of the 7600 odd items. > I've pasted the original post below. And sorry for any cross - > posting. > Cheers, Geert > ---------------------------------------------------------------------------------------------- > Geert Dekkers Web Studio | 2e Keucheniusstraat 8HS 1051VR Amsterdam > | +31(0)627224301 | http://nznl.net > ---------------------------------------------------------------------------------------------- > > >>> Thanks for you detailed reply Glen - much appreciated. >>> You helped me to solve what i was trying to do by using >>> CGImageCreateWithImageinRect as suggested. >>> >>> For anyone else interested here is some simple python code for >>> making cropped thumbnails of any proportion and not loosing the >>> aspect ratio of the original image. >>> ...and its damn fast! >>> >>> ----------- #!/usr/bin/python >>> >>> from __future__ import division import CoreGraphics >>> >>> def resizeimage(srcimage,targetimage, tw, th): >>> >>> srcimg = >>> CoreGraphics >>> .CGImageImport >>> (CoreGraphics.CGDataProviderCreateWithFilename(srcimage)) >>> >>> sw = srcimg.getWidth() >>> sh = srcimg.getHeight() >>> >>> aspect = tw/th >>> >>> widthfactor = tw/sw >>> heightfactor = th/sh >>> >>> if widthfactor < heightfactor: >>> #src height stays the same >>> #src width gets cropped >>> cropwidth = sh * aspect >>> x1 = ((sw-cropwidth)/2) >>> y1 = 0 >>> x2 = sw-((sw-cropwidth)) >>> y2 = sh >>> else: >>> #src height gets cropped >>> #src width stays the same >>> cropheight = sw / aspect >>> x1 = 0 >>> y1 = ((sh-cropheight)/2) >>> x2 = sw >>> y2 = sh-((sh-cropheight)) >>> >>> cliprect = CoreGraphics.CGRectMake(x1, y1, x2, y2) >>> croppedimg = srcimg.createWithImageInRect(cliprect) >>> >>> cs = CoreGraphics.CGColorSpaceCreateDeviceRGB() >>> c = CoreGraphics.CGBitmapContextCreateWithColor(tw, th, cs, >>> (0,0,0,0)) >>> >>> c.setInterpolationQuality(CoreGraphics.kCGInterpolationLow) >>> newRect = CoreGraphics.CGRectMake(0, 0, tw, th) >>> c.drawImage(newRect, croppedimg) >>> c.writeToFile(targetimage, CoreGraphics.kCGImageFormatJPEG) >>> >>> resizeimage("/users/adam/Desktop/bootlogo4pa8.jpg", "/users/adam/ >>> Desktop/aaaaa.jpg" , 80,80) >>> >>> >>> >>> >>> >>> >>> >>>> On Aug 12, 2008, at 3:41 AM, Glenn Cole wrote: >>>> >>>> Hi, Adam -- >>>> >>>> I'm no expert, but until others more knowledgeable respond, >>>> here's my understanding. >>>> >>>> First, I suspect the fact that you're using Python won't matter >>>> at all here. (It does in other circumstances, but I don't think >>>> so here.) >>>> >>>> It sounds like you're looking for more support from Quartz for >>>> your task than what's really there. In the end, I think it's >>>> going to be more a choice of algorithm on your part. >>>> >>>> For example, given different aspect ratios, the new image could >>>> either: >>>> >>>> 1. ignore the difference (i.e., the current behaviour) >>>> 2. show the entire original image within the new target, >>>> respecting the aspect ratio >>>> 3. clip the original image to match the new aspect ratio >>>> >>>> For #2, you could shrink the target rect to match the aspect >>>> ratio of the original image. >>>> >>>> For #3 (your goal), you could clip the original image to match >>>> the target aspect ratio. However, page 250 of the outstanding >>>> Programming With Quartz notes a few downsides to this, and >>>> suggests using CGImageCreateWithImageInRect instead (first >>>> available in Tiger) to define a "subimage" of the original image. >>>> Again, though, you would need to determine yourself that the >>>> subimage should ignore 100 pixels from the left and right sides >>>> of the original image. >>>> >>>> At least, that's my take on things. We'll see what others say >>>> (though they've tended to ignore Python questions in the past). >>>> >>>> Incidentally, the subject line says "Core Image resize question." >>>> The code below has no reference to Core Image, and I'm pretty >>>> sure that Core Image need not be involved in this task at all. >>>> (Perhaps you mentioned Core Image because of the existence of its >>>> CICrop filter, but I think that's not the best direction for the >>>> task at hand.) >>>> >>>> --Glenn >>>> >>>> >>>> On Aug 11, 2008, at 5:33 AM, Adam Jones wrote: >>>> >>>> Hi there i am wondering if someone can help me with this. Below >>>> is the code i am using to resize and save a jpeg image. >>>> >>>> It works mint as but it obviously scales the image with no >>>> respect for the aspect ratio. >>>> >>>> i want to be able to take an image and scale it proportionaly to >>>> a square thumbnail. so for example a 800x600 image scaled to >>>> 80x80 would need to loose 100pixels off the left and 100 pixels >>>> on the right before scaling. >>>> >>>> Does any one know how to crop using python quartz or can i draw >>>> the rec with the image off the canvas to achieve the same? >>>> >>>> Thanks Adam >>>> >>>> >>>> ----------- #!/usr/bin/python >>>> >>>> import CoreGraphics >>>> >>>> def resizeimage(srcimage,targetimage, w, h): >>>> >>>> origImage = CoreGraphics .CGImageImport >>>> (CoreGraphics.CGDataProviderCreateWithFilename(srcimage)) >>>> >>>> origwidth = origImage.getWidth() # not used yet but will be once >>>> i work out how to crop >>>> origheight = origImage.getHeight() # not used yet but will be >>>> once i work out how to crop >>>> >>>> cs = CoreGraphics.CGColorSpaceCreateDeviceRGB() >>>> c = CoreGraphics.CGBitmapContextCreateWithColor(w, h, cs, >>>> (0,0,0,0)) >>>> >>>> c.setInterpolationQuality(CoreGraphics.kCGInterpolationLow) >>>> newRect = CoreGraphics.CGRectMake(0, 0, w, h) >>>> c.drawImage(newRect, origImage) >>>> c.writeToFile(targetimage, CoreGraphics.kCGImageFormatJPEG) >>>> >>>> >>>> resizeimage(uploadedfile, "/svr/data/images/listings/%s/ >>>> %s_160x90.jpg" % (str(listing_id), newimagename), 160,90) >>>> >>>> ------------- >>>> >>>> >>>> _______________________________________________ Do not post admin >>>> requests to the list. They will be ignored. Quartz-dev mailing >>>> list (email at hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartz-dev/email at hidden >>>> >>>> This email sent to email at hidden >>> > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at gordallott.com Wed Jun 3 18:04:14 2009 From: mail at gordallott.com (Gordon Allott) Date: Wed, 03 Jun 2009 17:04:14 +0100 Subject: [Image-SIG] Bug in PIL regaring streaming png files, Patch fixed Message-ID: <1244045054.9406.6.camel@zazu> Hi, It appears there is no place to report bugs regarding PIL or even contact the developers so it seems that here is the best place to report this kind of thing. There is a bug when you stream png files into PIL.ImageFile.Parser() any kind of image operation you try and perform on the file will fail with Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 961, in histogram self.load() File "/usr/lib/python2.6/dist-packages/PIL/ImageFile.py", line 189, in load s = read(self.decodermaxblock) File "/usr/lib/python2.6/dist-packages/PIL/PngImagePlugin.py", line 365, in load_read return self.fp.read(bytes) File "/usr/lib/python2.6/dist-packages/PIL/ImageFile.py", line 300, in read data = self.data[pos:pos+bytes] TypeError: 'NoneType' object is unsubscriptable More info can be found on the bug report i published to launchpad.net (without any proper bug reporting mechanism, this was the next best thing) including a patch to fix the bug for now. https://bugs.edge.launchpad.net/ubuntu/+source/python-imaging/+bug/383228 -- Gordon Allott -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From fredrik at pythonware.com Thu Jun 4 08:37:46 2009 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 4 Jun 2009 08:37:46 +0200 Subject: [Image-SIG] Bug in PIL regaring streaming png files, Patch fixed In-Reply-To: <1244045054.9406.6.camel@zazu> References: <1244045054.9406.6.camel@zazu> Message-ID: <368a5cd50906032337y58f58dfic0efa67f2b307410@mail.gmail.com> On Wed, Jun 3, 2009 at 6:04 PM, Gordon Allott wrote: > Hi, > > It appears there is no place to report bugs regarding PIL or even > contact the developers so it seems that here is the best place to report > this kind of thing. > > There is a bug when you stream png files into PIL.ImageFile.Parser() any > kind of image operation you try and perform on the file will fail This is (hopefully) fixed in 1.1.7; see: http://hg.effbot.org/pil-2009-raclette/changeset/fe4688f15fed/ From fredrik at pythonware.com Mon Jun 8 22:52:42 2009 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 8 Jun 2009 22:52:42 +0200 Subject: [Image-SIG] 1.1.7 final status (was Re: Will 1.1.7 be true-division safe ?) Message-ID: <368a5cd50906081352n3d0ffbdfx9fea7fe528ed657d@mail.gmail.com> On Sun, May 31, 2009 at 3:32 PM, Fredrik Lundh wrote: > But I think I'll have to leave this as is in 1.1.7 (which should go RC > later today or tomorrow) Just FYI, the RC was pulled due to two last-second bug reports, and a set of rather interesting patches that I wasn't aware of. The bugs have been fixed, but I'll need a few more days to evaluate the patches. From yallabalagan at gmail.com Sun Jun 14 19:59:45 2009 From: yallabalagan at gmail.com (yalla balagan) Date: Sun, 14 Jun 2009 20:59:45 +0300 Subject: [Image-SIG] Writing diacritic marks (nikud) using PIL text draw Message-ID: Writing simple text on an image using PIL is easy: draw = ImageDraw.Draw(img) draw.text((10, y), text2, font=font, fill=forecolor ) however, when I try to write Hebrew punctuation marks (called "nikud" or ?????), the characters does not overlap as it should. I guess this question is relevant also to Arabic and other similar languages. On supporting environment, these two words take up the same space/width (the below example depend on your system, hence the image): ????? ??? However when drawing the text with PIL i'd get ? ? ? ? ? since the library probably doesn't obey kerning(?) rules. Is that all possible without writing manually character positioning? image url: http://tinypic.com/r/jglhc5/5 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nikud.png Type: image/png Size: 1049 bytes Desc: not available URL: From hdg at cox.net Sun Jun 14 19:00:06 2009 From: hdg at cox.net (H David Goering) Date: Sun, 14 Jun 2009 12:00:06 -0500 Subject: [Image-SIG] Unable to build PIL with TrueType support Message-ID: Re: Freetype2-dev_2.1.3-22_darwin-i386 Imaging 1.1.5 Python 2.6.2 Mac OS X 10.4.11 Mac Mini Intel Core Duo Hello, I am unable to build PIL with Freetype2 support. The transcript follows. I have attempted to follow the instructions in README and setup.py, but some requirements are unclear to me: Instruction #3. The Python installation is a fresh framework build, but no filenames including "python-devel" exist. What does "probably" mean? What does "or similar" mean? Instruction #4: I do not seem to have a Python extensions directory. What would be a "suitable directory"? Instruction #5: What does "in-place" mean? How can I tell if Freetype is properly installed? setup.py documentation: what would be "well-known library location" for Freetype2? What would a directory that is an appropriate value for FREETYPE_ROOT contain? Any suggestions and advice are welcome. Excepting this issue of TrueType font support I've found PIL painless to use, well documented, and effective. Thanks, David Goering ----------------- Build transcript: ----------------- Last login: Sun Jun 14 10:56:11 on ttyp2 Welcome to Darwin! ip68-103-43-176:~ hdg$ cd Desktop/Imaging-1.1.5 ip68-103-43-176:~/Desktop/Imaging-1.1.5 hdg$ python setup.py build_ext -i running build_ext --- using frameworks at /System/Library/Frameworks building '_imaging' extension creating build creating build/temp.macosx-10.3-i386-2.6 creating build/temp.macosx-10.3-i386-2.6/libImaging gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c _imaging.c -o build/temp.macosx-10.3-i386-2.6/_imaging.o _imaging.c:2765: warning: initialization from incompatible pointer type _imaging.c:2767: warning: 'intargfunc' is deprecated _imaging.c:2767: warning: initialization from incompatible pointer type _imaging.c:2768: warning: 'intargfunc' is deprecated _imaging.c:2768: warning: initialization from incompatible pointer type _imaging.c:2769: warning: 'intintargfunc' is deprecated _imaging.c:2769: warning: initialization from incompatible pointer type _imaging.c:2770: warning: initialization from incompatible pointer type _imaging.c:2771: warning: initialization from incompatible pointer type gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c decode.c -o build/temp.macosx-10.3-i386-2.6/decode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c encode.c -o build/temp.macosx-10.3-i386-2.6/encode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c map.c - o build/temp.macosx-10.3-i386-2.6/map.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c display.c -o build/temp.macosx-10.3-i386-2.6/display.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c outline.c -o build/temp.macosx-10.3-i386-2.6/outline.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c path.c - o build/temp.macosx-10.3-i386-2.6/path.o path.c:535: warning: initialization from incompatible pointer type path.c:537: warning: 'intargfunc' is deprecated path.c:537: warning: initialization from incompatible pointer type path.c:538: warning: 'intargfunc' is deprecated path.c:538: warning: initialization from incompatible pointer type path.c:539: warning: 'intintargfunc' is deprecated path.c:539: warning: initialization from incompatible pointer type path.c:540: warning: initialization from incompatible pointer type path.c:541: warning: initialization from incompatible pointer type gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Access.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ Access.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Antialias.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ Antialias.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Bands.c -o build/temp.macosx-10.3-i386-2.6/libImaging/Bands.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/BitDecode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ BitDecode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Blend.c -o build/temp.macosx-10.3-i386-2.6/libImaging/Blend.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Chops.c -o build/temp.macosx-10.3-i386-2.6/libImaging/Chops.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Convert.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ Convert.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/ConvertYCbCr.c -o build/temp.macosx-10.3-i386-2.6/ libImaging/ConvertYCbCr.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Copy.c -o build/temp.macosx-10.3-i386-2.6/libImaging/Copy.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Crc32.c -o build/temp.macosx-10.3-i386-2.6/libImaging/Crc32.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Crop.c -o build/temp.macosx-10.3-i386-2.6/libImaging/Crop.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Dib.c -o build/temp.macosx-10.3-i386-2.6/libImaging/Dib.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Draw.c -o build/temp.macosx-10.3-i386-2.6/libImaging/Draw.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Effects.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ Effects.o libImaging/Effects.c:210: warning: 'perlin_init' defined but not used gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/EpsEncode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ EpsEncode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/File.c -o build/temp.macosx-10.3-i386-2.6/libImaging/File.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Fill.c -o build/temp.macosx-10.3-i386-2.6/libImaging/Fill.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Filter.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ Filter.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/FliDecode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ FliDecode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Geometry.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ Geometry.o libImaging/Geometry.c:236: warning: 'quadratic_transform' defined but not used gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/GetBBox.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ GetBBox.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/GifDecode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ GifDecode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/GifEncode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ GifEncode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/HexDecode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ HexDecode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Histo.c -o build/temp.macosx-10.3-i386-2.6/libImaging/Histo.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/JpegDecode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ JpegDecode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/JpegEncode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ JpegEncode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/LzwDecode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ LzwDecode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Matrix.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ Matrix.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/ModeFilter.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ ModeFilter.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/MspDecode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ MspDecode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Negative.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ Negative.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Offset.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ Offset.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Pack.c -o build/temp.macosx-10.3-i386-2.6/libImaging/Pack.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/PackDecode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ PackDecode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Palette.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ Palette.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Paste.c -o build/temp.macosx-10.3-i386-2.6/libImaging/Paste.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Quant.c -o build/temp.macosx-10.3-i386-2.6/libImaging/Quant.o libImaging/Quant.c:311: warning: 'test_sorted' defined but not used gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/QuantHash.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ QuantHash.o libImaging/QuantHash.c:136: warning: '_hashtable_test' defined but not used gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/QuantHeap.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ QuantHeap.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/PcdDecode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ PcdDecode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/PcxDecode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ PcxDecode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/PcxEncode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ PcxEncode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Point.c -o build/temp.macosx-10.3-i386-2.6/libImaging/Point.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/RankFilter.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ RankFilter.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/RawDecode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ RawDecode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/RawEncode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ RawEncode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Storage.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ Storage.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/SunRleDecode.c -o build/temp.macosx-10.3-i386-2.6/ libImaging/SunRleDecode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/TgaRleDecode.c -o build/temp.macosx-10.3-i386-2.6/ libImaging/TgaRleDecode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/Unpack.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ Unpack.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/UnpackYCC.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ UnpackYCC.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/XbmDecode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ XbmDecode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/XbmEncode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ XbmEncode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/ZipDecode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ ZipDecode.o gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBZ -I/System/Library/Frameworks/ Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/ Headers -IlibImaging -I/sw/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include -I/usr/include -I/Library/ Frameworks/Python.framework/Versions/2.6/include/python2.6 -c libImaging/ZipEncode.c -o build/temp.macosx-10.3-i386-2.6/libImaging/ ZipEncode.o gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386-2.6/ _imaging.o build/temp.macosx-10.3-i386-2.6/decode.o build/ temp.macosx-10.3-i386-2.6/encode.o build/temp.macosx-10.3-i386-2.6/ map.o build/temp.macosx-10.3-i386-2.6/display.o build/ temp.macosx-10.3-i386-2.6/outline.o build/temp.macosx-10.3-i386-2.6/ path.o build/temp.macosx-10.3-i386-2.6/libImaging/Access.o build/ temp.macosx-10.3-i386-2.6/libImaging/Antialias.o build/ temp.macosx-10.3-i386-2.6/libImaging/Bands.o build/temp.macosx-10.3- i386-2.6/libImaging/BitDecode.o build/temp.macosx-10.3-i386-2.6/ libImaging/Blend.o build/temp.macosx-10.3-i386-2.6/libImaging/Chops.o build/temp.macosx-10.3-i386-2.6/libImaging/Convert.o build/ temp.macosx-10.3-i386-2.6/libImaging/ConvertYCbCr.o build/ temp.macosx-10.3-i386-2.6/libImaging/Copy.o build/temp.macosx-10.3- i386-2.6/libImaging/Crc32.o build/temp.macosx-10.3-i386-2.6/ libImaging/Crop.o build/temp.macosx-10.3-i386-2.6/libImaging/Dib.o build/temp.macosx-10.3-i386-2.6/libImaging/Draw.o build/ temp.macosx-10.3-i386-2.6/libImaging/Effects.o build/temp.macosx-10.3- i386-2.6/libImaging/EpsEncode.o build/temp.macosx-10.3-i386-2.6/ libImaging/File.o build/temp.macosx-10.3-i386-2.6/libImaging/Fill.o build/temp.macosx-10.3-i386-2.6/libImaging/Filter.o build/ temp.macosx-10.3-i386-2.6/libImaging/FliDecode.o build/ temp.macosx-10.3-i386-2.6/libImaging/Geometry.o build/ temp.macosx-10.3-i386-2.6/libImaging/GetBBox.o build/temp.macosx-10.3- i386-2.6/libImaging/GifDecode.o build/temp.macosx-10.3-i386-2.6/ libImaging/GifEncode.o build/temp.macosx-10.3-i386-2.6/libImaging/ HexDecode.o build/temp.macosx-10.3-i386-2.6/libImaging/Histo.o build/ temp.macosx-10.3-i386-2.6/libImaging/JpegDecode.o build/ temp.macosx-10.3-i386-2.6/libImaging/JpegEncode.o build/ temp.macosx-10.3-i386-2.6/libImaging/LzwDecode.o build/ temp.macosx-10.3-i386-2.6/libImaging/Matrix.o build/temp.macosx-10.3- i386-2.6/libImaging/ModeFilter.o build/temp.macosx-10.3-i386-2.6/ libImaging/MspDecode.o build/temp.macosx-10.3-i386-2.6/libImaging/ Negative.o build/temp.macosx-10.3-i386-2.6/libImaging/Offset.o build/ temp.macosx-10.3-i386-2.6/libImaging/Pack.o build/temp.macosx-10.3- i386-2.6/libImaging/PackDecode.o build/temp.macosx-10.3-i386-2.6/ libImaging/Palette.o build/temp.macosx-10.3-i386-2.6/libImaging/ Paste.o build/temp.macosx-10.3-i386-2.6/libImaging/Quant.o build/ temp.macosx-10.3-i386-2.6/libImaging/QuantHash.o build/ temp.macosx-10.3-i386-2.6/libImaging/QuantHeap.o build/ temp.macosx-10.3-i386-2.6/libImaging/PcdDecode.o build/ temp.macosx-10.3-i386-2.6/libImaging/PcxDecode.o build/ temp.macosx-10.3-i386-2.6/libImaging/PcxEncode.o build/ temp.macosx-10.3-i386-2.6/libImaging/Point.o build/temp.macosx-10.3- i386-2.6/libImaging/RankFilter.o build/temp.macosx-10.3-i386-2.6/ libImaging/RawDecode.o build/temp.macosx-10.3-i386-2.6/libImaging/ RawEncode.o build/temp.macosx-10.3-i386-2.6/libImaging/Storage.o build/temp.macosx-10.3-i386-2.6/libImaging/SunRleDecode.o build/ temp.macosx-10.3-i386-2.6/libImaging/TgaRleDecode.o build/ temp.macosx-10.3-i386-2.6/libImaging/Unpack.o build/temp.macosx-10.3- i386-2.6/libImaging/UnpackYCC.o build/temp.macosx-10.3-i386-2.6/ libImaging/XbmDecode.o build/temp.macosx-10.3-i386-2.6/libImaging/ XbmEncode.o build/temp.macosx-10.3-i386-2.6/libImaging/ZipDecode.o build/temp.macosx-10.3-i386-2.6/libImaging/ZipEncode.o -L/sw/lib -L/ Library/Frameworks/Python.framework/Versions/2.6/lib -L/usr/local/lib -L/usr/lib -lz -o PIL/_imaging.so building '_imagingtk' extension creating build/temp.macosx-10.3-i386-2.6/Tk gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/System/Library/Frameworks/Tcl.framework/ Headers -I/System/Library/Frameworks/Tk.framework/Headers - IlibImaging -I/sw/include -I/Library/Frameworks/Python.framework/ Versions/2.6/include -I/usr/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include/python2.6 -c _imagingtk.c -o build/temp.macosx-10.3-i386-2.6/_imagingtk.o -framework Tcl - framework Tk In file included from /System/Library/Frameworks/Tk.framework/Headers/ tk.h:96, from _imagingtk.c:20: /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: warning: function declaration isn't a prototype i686-apple-darwin8-gcc-4.0.1: -framework: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: Tcl: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: -framework: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: Tk: linker input file unused because linking not done gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/System/Library/Frameworks/Tcl.framework/ Headers -I/System/Library/Frameworks/Tk.framework/Headers - IlibImaging -I/sw/include -I/Library/Frameworks/Python.framework/ Versions/2.6/include -I/usr/include -I/Library/Frameworks/ Python.framework/Versions/2.6/include/python2.6 -c Tk/tkImaging.c -o build/temp.macosx-10.3-i386-2.6/Tk/tkImaging.o -framework Tcl - framework Tk In file included from /System/Library/Frameworks/Tk.framework/Headers/ tk.h:96, from Tk/tkImaging.c:51: /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: function declaration isn't a prototype /System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: warning: function declaration isn't a prototype i686-apple-darwin8-gcc-4.0.1: -framework: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: Tcl: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: -framework: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: Tk: linker input file unused because linking not done gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386-2.6/ _imagingtk.o build/temp.macosx-10.3-i386-2.6/Tk/tkImaging.o -L/sw/lib -L/Library/Frameworks/Python.framework/Versions/2.6/lib -L/usr/local/ lib -L/usr/lib -o PIL/_imagingtk.so -framework Tcl -framework Tk -------------------------------------------------------------------- PIL 1.1.5 BUILD SUMMARY -------------------------------------------------------------------- version 1.1.5 platform darwin 2.6.2 (r262:71600, Jun 13 2009, 22:49:22) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] -------------------------------------------------------------------- --- TKINTER support ok *** JPEG support not available --- ZLIB (PNG/ZIP) support ok *** FREETYPE2 support not available -------------------------------------------------------------------- To add a missing option, make sure you have the required library, and set the corresponding ROOT variable in the setup.py script. To check the build, run the selftest.py script. ip68-103-43-176:~/Desktop/Imaging-1.1.5 hdg$ From Scott.Daniels at Acm.Org Mon Jun 15 23:06:58 2009 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Mon, 15 Jun 2009 14:06:58 -0700 Subject: [Image-SIG] roop found an interesting flaw in PIL's ImageEnhance.py Message-ID: roop wrote: > I was browsing ImageEnhace.py, and found something that I thought was > odd in class Contrast: > > class Contrast(_Enhance): > "Adjust image contrast" > def __init__(self, image): > self.image = image > mean = reduce(lambda a,b: a+b, image.convert("L").histogram())/ > 256.0 > self.degenerate = Image.new("L", image.size, mean).convert > (image.mode) > > Isn't reduce(lambda a,b: a+b, image.convert("L").histogram()) the same > as (image.size[0] * image.size[1]) - just count the number of pixels > in the image? (Afaik, the histogram is a list of 256 elements where > the ith element gives the number of pixels with i as the pixel value > (0 <= i < 256)). Is this actually fishy or have I got it all muddled > up? > > Thanks, > roop Good catch [I'll send a copy to the imaging sig]. If you replace class Contrast like this: class Contrast(ImageEnhance._Enhance): "Adjust image contrast" def __init__(self, image): self.image = image w, h = image.size mean = sum(n * c for n, c in enumerate( image.convert("L").histogram()) ) / float(w * h) self.degenerate = Image.new("L", image.size, mean).convert(image.mode) You should get a working Contrast class. There _is_ another possibility: class Contrast(ImageEnhance._Enhance): "Adjust image contrast" def __init__(self, image): self.image = image clone = image.copy() clone.thumbnail((1, 1)) self.degenerate = clone.resize(image.size) The former goes to a grey point, while the latter goes to the picture's color center. I'm not quite sure which one is more properly called "contrast," as I can see wanting either one. --Scott David Daniels Scott.Daniels at Acm.Org From jaraco at jaraco.com Tue Jun 16 04:44:29 2009 From: jaraco at jaraco.com (Jason R. Coombs) Date: Mon, 15 Jun 2009 22:44:29 -0400 Subject: [Image-SIG] First cut at porting PIL to py3k Message-ID: <8B473FAE8A08C34C9F5666FD4B0A87B69970D01BBC@hornigold.jaraco.com> On Mon, Dec 29, 2008 at 2:26 PM, Guilherme Polo wrote: > Hi there, > > So.. I ported PIL 1.1.6 to py3k today and I believe someone else > around here might be interested on it. It is very likely to exist > problems caused by the transition to bytes in py3k that I didn't fix > yet, but all the tests pass. I also didn't fix display.c (since it is > all Windows dependent) neither Sane/. > I've cloned Guilherme's repository and made a couple of fixes that enable PIL to compile and install on Windows. I'm unsure how to compile in JPEG and PNG and font support, so I wasn't able to save any images, but this patch works to create Image instances in Python 3.1rc2 on Windows. This is a patch against the repo at git://gpolo.ath.cx:4242/pil-py3k.git . Regards, Jason diff --git a/PIL/Image.py b/PIL/Image.py index 7c3cf7f..68d90e9 100644 --- a/PIL/Image.py +++ b/PIL/Image.py @@ -94,7 +94,15 @@ def isImageType(t): def isDirectory(f): return isStringType(f) and os.path.isdir(f) -from operator import isNumberType, isSequenceType +from numbers import Number + +def isNumberType(t): + return isinstance(t, Number) + +from collections import Sequence + +def isSequenceType(t): + return isinstance(t, Sequence) # # Debug level diff --git a/display.c b/display.c index 415e03c..f21ce7f 100644 --- a/display.c +++ b/display.c @@ -200,7 +200,7 @@ _tostring(ImagingDisplayObject* display, PyObject* args) if (!PyArg_ParseTuple(args, ":tostring")) return NULL; - return PyString_FromStringAndSize( + return PyUnicode_FromStringAndSize( display->dib->bits, display->dib->ysize * display->dib->linesize ); } @@ -330,7 +330,7 @@ PyImaging_GrabScreenWin32(PyObject* self, PyObject* args) /* step 3: extract bits from bitmap */ - buffer = PyString_FromStringAndSize(NULL, height * ((width*3 + 3) & -4)); + buffer = PyUnicode_FromStringAndSize(NULL, height * ((width*3 + 3) & -4)); if (!buffer) return NULL; @@ -339,7 +339,7 @@ PyImaging_GrabScreenWin32(PyObject* self, PyObject* args) core.bcHeight = height; core.bcPlanes = 1; core.bcBitCount = 24; - if (!GetDIBits(screen_copy, bitmap, 0, height, PyString_AS_STRING(buffer), + if (!GetDIBits(screen_copy, bitmap, 0, height, PyUnicode_AS_UNICODE(buffer), (BITMAPINFO*) &core, DIB_RGB_COLORS)) goto error; @@ -370,11 +370,11 @@ static BOOL CALLBACK list_windows_callback(HWND hwnd, LPARAM lParam) /* get window title */ title_size = GetWindowTextLength(hwnd); if (title_size > 0) { - title = PyString_FromStringAndSize(NULL, title_size); + title = PyUnicode_FromStringAndSize(NULL, title_size); if (title) - GetWindowText(hwnd, PyString_AS_STRING(title), title_size+1); + GetWindowText(hwnd, PyUnicode_AS_UNICODE(title), title_size+1); } else - title = PyString_FromString(""); + title = PyUnicode_FromString(""); if (!title) return 0; @@ -528,7 +528,7 @@ PyImaging_GrabClipboardWin32(PyObject* self, PyObject* args) size = wcslen(data) * 2; #endif - result = PyString_FromStringAndSize(data, size); + result = PyUnicode_FromStringAndSize(data, size); GlobalUnlock(handle); diff --git a/map.c b/map.c index d8249d5..97dc708 100644 --- a/map.c +++ b/map.c @@ -381,10 +381,10 @@ PyImaging_MapBuffer(PyObject* self, PyObject* args) /* setup file pointers */ if (ystep > 0) for (y = 0; y < ysize; y++) - im->image[y] = ptr + offset + y * stride; + im->image[y] = (char*)ptr + offset + y * stride; else for (y = 0; y < ysize; y++) - im->image[ysize-y-1] = ptr + offset + y * stride; + im->image[ysize-y-1] = (char*)ptr + offset + y * stride; im->destroy = mapping_destroy_buffer; -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6998 bytes Desc: not available URL: From wrybread at gmail.com Tue Jun 16 02:17:21 2009 From: wrybread at gmail.com (Alec Bennett) Date: Tue, 16 Jun 2009 02:17:21 +0200 Subject: [Image-SIG] How to open "raw" images using PIL? Message-ID: I have some "raw" images shot from a Canon DSLR that I'd like to manipulate using the PIL. I know I can convert them using another program, but if possible I'd like to do so directly using PIL. Is this possible with the PIL? Currently I get something like: f = "IMG_0025.CR2" im = Image.open(f) Traceback (most recent call last): File "C:/test.py", line 7, in ? im = Image.open(f, mode = "r") File "C:\Python24\lib\site-packages\PIL\Image.py", line 1916, in open raise IOError("cannot identify image file") IOError: cannot identify image file -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik at pythonware.com Tue Jun 16 17:46:12 2009 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 16 Jun 2009 17:46:12 +0200 Subject: [Image-SIG] How to open "raw" images using PIL? In-Reply-To: References: Message-ID: <368a5cd50906160846g244ba43et3ff1a4dc38d31a8a@mail.gmail.com> On Tue, Jun 16, 2009 at 2:17 AM, Alec Bennett wrote: > I have some "raw" images shot from a Canon DSLR that I'd like to manipulate > using the PIL. I know I can convert them using another program, but if > possible I'd like to do so directly using PIL. > > Is this possible with the PIL? > > Currently I get something like: > > f = "IMG_0025.CR2" > im = Image.open(f) > > Traceback (most recent call last): > ? File "C:/test.py", line 7, in ? > ??? im = Image.open(f, mode = "r") > ? File "C:\Python24\lib\site-packages\PIL\Image.py", line 1916, in open > ??? raise IOError("cannot identify image file") > IOError: cannot identify image file "raw" files (or rather, camera-specific formats) is a big topic, and there's no standard support in current versions of PIL. I suspect you have to use external converters for most major cameras (but contributions are welcome). From fredrik at pythonware.com Tue Jun 16 20:54:49 2009 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 16 Jun 2009 20:54:49 +0200 Subject: [Image-SIG] roop found an interesting flaw in PIL's ImageEnhance.py In-Reply-To: References: Message-ID: <368a5cd50906161154m7bd0acedkc76a709093672267@mail.gmail.com> On Mon, Jun 15, 2009 at 11:06 PM, Scott David Daniels wrote: > roop wrote: >> I was browsing ImageEnhace.py, and found something that I thought was >> odd in class Contrast: >> >> class Contrast(_Enhance): >> ? ? "Adjust image contrast" >> ? ? def __init__(self, image): >> ? ? ? ? self.image = image >> ? ? ? ? mean = reduce(lambda a,b: a+b, image.convert("L").histogram())/ >> 256.0 >> ? ? ? ? self.degenerate = Image.new("L", image.size, mean).convert >> (image.mode) >> >> Isn't reduce(lambda a,b: a+b, image.convert("L").histogram()) the same >> as (image.size[0] * image.size[1]) - just count the number of pixels >> in the image? (Afaik, the histogram is a list of 256 elements where >> the ith element gives the number of pixels with i as the pixel value >> (0 <= i < 256)). Is this actually fishy or have I got it all muddled >> up? >> >> Thanks, >> roop > > Good catch [I'll send a copy to the imaging sig]. ?If you replace class > Contrast like this: And the award for finding the oldest bug in PIL goes to... (that code was last touched in 1996). I've checked in a last-second fix for 1.1.7 (to be frozen any day soon now, promise). Thanks /F From spe.stani.be at gmail.com Wed Jun 17 15:07:16 2009 From: spe.stani.be at gmail.com (Stani) Date: Wed, 17 Jun 2009 15:07:16 +0200 Subject: [Image-SIG] suggestion: xdg-open for invoking the imageviewer on linux Message-ID: <2078a7ad0906170607hab58771t11f07a3c25d6ff75@mail.gmail.com> On Tue, Jun 16, 2009 at 8:54 PM, Fredrik Lundh wrote: > On Mon, Jun 15, 2009 at 11:06 PM, Scott David > I've checked in a last-second fix for 1.1.7 (to be frozen any day soon > now, promise). Hi Fredrik, In case the freezer is not started yet, you might consider using xdg-open in ImageShow: http://portland.freedesktop.org/xdg-utils-1.0/xdg-open.html xdg-open ? opens a file or URL in the user's preferred application It is the equivalent of open on OSX and will work on most modern distributions (ubuntu, opensuse, fedora, debian, ...) as it is part of the freedesktop specification. You could keep the existing code as a fallback. Best regards, Stani -- Phatch Photo Batch Processor - http://photobatch.stani.be SPE Python IDE - http://pythonide.stani.be From szymon at mwg.pl Fri Jun 19 11:48:49 2009 From: szymon at mwg.pl (Szymon Kosok) Date: Fri, 19 Jun 2009 02:48:49 -0700 (PDT) Subject: [Image-SIG] Semi-transparent - gray "border" Message-ID: <24108447.post@talk.nabble.com> Hello, I had problem a quite some time ago - resolved here, on mailing list. An avatar system worked well until then... I don't know why, I haven't changed anything in code... haven't upgraded PIL... all semi-transparent elements have gray "border", just like that: http://i44.tinypic.com/2s9x351.png And here is correct version: http://i41.tinypic.com/2h4wb9x.png And here is code: def sklejanie(wartstwy, plec, skora): import os, Image, ImageChops from settings import MEDIA_ROOT, MEDIA_URL lalka = Image.open(MEDIA_ROOT + "img/ciala/%s%s.png" % (plec, skora)) alfa = lalka.split()[-1] for p in wartstwy: czesc = Image.open(p.element.binaria.path) lalka.paste(czesc, (p.x, p.y), czesc) czesc = ImageChops.offset(czesc, p.x, p.y) alfa = ImageChops.lighter(alfa, czesc.split()[-1]) lalka.putalpha(alfa) return lalka As I've said... it worked for a long time. What can be wrong? Best regards, Szymon -- View this message in context: http://www.nabble.com/Semi-transparent---gray-%22border%22-tp24108447p24108447.html Sent from the Python - image-sig mailing list archive at Nabble.com. From Carl.Petterson at tobii.com Mon Jun 22 15:06:41 2009 From: Carl.Petterson at tobii.com (Carl Petterson) Date: Mon, 22 Jun 2009 15:06:41 +0200 Subject: [Image-SIG] Skewing when converting with ImageQt Message-ID: <0129ED0DAC15A3428D2FF95D3C54E0E6016F5BF2C1@semailsrv01> Hi! I'm using PIL to load .pgm images into an application. They are to be displayed as QPixmaps in a Qt app, so I'm using the ImageQt class to convert my PIL images to QImages, and later QPixmaps. However, for some - but not all - pictures, the resulting image is skewed. It looks fine if I do Image.show() on it before conversion, and if I load it via Qt directly it's also fine. I have posted a sample comparison between IrfanView and my application here http://www.dumpt.com/img/viewer.php?file=hp8r22jhcffr0xowduok.jpg. Any ideas what might be causing this? Best regards Carl Pettersson -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik at pythonware.com Mon Jun 22 16:32:45 2009 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 22 Jun 2009 16:32:45 +0200 Subject: [Image-SIG] Skewing when converting with ImageQt In-Reply-To: <0129ED0DAC15A3428D2FF95D3C54E0E6016F5BF2C1@semailsrv01> References: <0129ED0DAC15A3428D2FF95D3C54E0E6016F5BF2C1@semailsrv01> Message-ID: <368a5cd50906220732r19af03a6s33f67b3a9e7ca358@mail.gmail.com> On Mon, Jun 22, 2009 at 3:06 PM, Carl Petterson wrote: > Hi! > > I?m using PIL to load .pgm images into an application. They are to be > displayed as QPixmaps in a Qt app, so I?m using the ImageQt class to convert > my PIL images to QImages, and later QPixmaps. However, for some - but not > all - pictures, the resulting image is skewed. It looks fine if I do > Image.show() on it before conversion, and if I load it via Qt directly it?s > also fine. Looks like PIL doesn't do line alignment correctly for mode L and P images (at least). Hmm. Can you check if it works correctly if the width is a multiple of 4? What happens if you explicitly convert the image to RGB before passing it to the wrapper? (Are you using the ImageQt file from http://svn.effbot.org/public/stuff/sandbox/pil/ImageQt.py or some other version, btw? I doubt the one in 1.1.7 works any better than that one, though, but it's good to know what code you've been using). From ben at ekran.org Mon Jun 22 18:52:13 2009 From: ben at ekran.org (B. Bogart) Date: Mon, 22 Jun 2009 09:52:13 -0700 Subject: [Image-SIG] Workarounds for MemoryErrors Message-ID: <4A3FB6BD.50508@ekran.org> Hello all, I want to create a very large RGBA image (96000x72000 pixels). I have 4GB of RAM. Is there an easy way of getting around this error by having PIL only allocate one section of the image at a time? If PIL does not have any internal trick to work with large images then I'll have to make 4+ smaller images one at a time, but then I'm not sure how I could combine them without needing to allocate a memory chunk for the whole image. Otherwise I suppose I'll have to try with some other language, perhaps C/SDL, though a quick calculation seems to show that such a large RGBA image is just unworkable. Is there some way of using disk space rather than memory? Does not matter if it is slow, just that it is possible! Any advice? Thanks, B. From kevin at cazabon.com Mon Jun 22 21:27:51 2009 From: kevin at cazabon.com (Kevin Cazabon) Date: Mon, 22 Jun 2009 15:27:51 -0400 Subject: [Image-SIG] Workarounds for MemoryErrors In-Reply-To: <4A3FB6BD.50508@ekran.org> References: <4A3FB6BD.50508@ekran.org> Message-ID: <915E63E0-7813-443C-A22A-E993E1A5DD60@cazabon.com> Quite a number of years back I processed a 1.5GB image on a machine with 256MB of RAM (the rest virtual memory - 48x96" poster at 304 pixels/inch). It took days, but it worked. The software actually was pretty inefficient too, so I was probably using well over 2GB of memory space at a time. I think your image is about 19GB (at 24bits/pixel)... not that different of a ratio than what I did. Have you tried it? Besides ensuring you have lots of VM available, it might just work as-is. Memory is cheap these days too... probably cheaper than the hours of programming a work-around. Kevin On 22 Jun 2009, at 12:52, B. Bogart wrote: > Hello all, > > I want to create a very large RGBA image (96000x72000 pixels). > > I have 4GB of RAM. > > Is there an easy way of getting around this error by having PIL only > allocate one section of the image at a time? > > If PIL does not have any internal trick to work with large images then > I'll have to make 4+ smaller images one at a time, but then I'm not > sure > how I could combine them without needing to allocate a memory chunk > for > the whole image. > > Otherwise I suppose I'll have to try with some other language, perhaps > C/SDL, though a quick calculation seems to show that such a large RGBA > image is just unworkable. Is there some way of using disk space rather > than memory? Does not matter if it is slow, just that it is possible! > > Any advice? > > Thanks, > B. > _______________________________________________ > Image-SIG maillist - Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig From cannon.el at gmail.com Mon Jun 22 19:36:59 2009 From: cannon.el at gmail.com (Laura & Edward Cannon) Date: Mon, 22 Jun 2009 10:36:59 -0700 Subject: [Image-SIG] Workarounds for MemoryErrors In-Reply-To: <4A3FB6BD.50508@ekran.org> References: <4A3FB6BD.50508@ekran.org> Message-ID: Off the top of my head I would divide the image into horizontal bands and only work on one part at a time, writing the rest to disk. At the final join I would write a custom file writter that wrote to some very simple file format such as .tga or .bmp and could handle just appending the new pixel data. On Mon, Jun 22, 2009 at 9:52 AM, B. Bogart wrote: > Hello all, > > I want to create a very large RGBA image (96000x72000 pixels). > > I have 4GB of RAM. > > Is there an easy way of getting around this error by having PIL only > allocate one section of the image at a time? > > If PIL does not have any internal trick to work with large images then > I'll have to make 4+ smaller images one at a time, but then I'm not sure > how I could combine them without needing to allocate a memory chunk for > the whole image. > > Otherwise I suppose I'll have to try with some other language, perhaps > C/SDL, though a quick calculation seems to show that such a large RGBA > image is just unworkable. Is there some way of using disk space rather > than memory? Does not matter if it is slow, just that it is possible! > > Any advice? > > Thanks, > B. > _______________________________________________ > Image-SIG maillist ?- ?Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig > From Carl.Petterson at tobii.com Tue Jun 23 09:53:03 2009 From: Carl.Petterson at tobii.com (Carl Petterson) Date: Tue, 23 Jun 2009 09:53:03 +0200 Subject: [Image-SIG] Skewing when converting with ImageQt In-Reply-To: <368a5cd50906220732r19af03a6s33f67b3a9e7ca358@mail.gmail.com> References: <0129ED0DAC15A3428D2FF95D3C54E0E6016F5BF2C1@semailsrv01> <368a5cd50906220732r19af03a6s33f67b3a9e7ca358@mail.gmail.com> Message-ID: <0129ED0DAC15A3428D2FF95D3C54E0E6016F5BF484@semailsrv01> > -----Original Message----- > From: fredrik.lundh at gmail.com [mailto:fredrik.lundh at gmail.com] On > Behalf Of Fredrik Lundh > Sent: den 22 juni 2009 16:33 > > Looks like PIL doesn't do line alignment correctly for mode L and P > images (at least). Hmm. > > Can you check if it works correctly if the width is a multiple of 4? > > What happens if you explicitly convert the image to RGB before passing > it to the wrapper? > > (Are you using the ImageQt file from > http://svn.effbot.org/public/stuff/sandbox/pil/ImageQt.py or some > other version, btw? I doubt the one in 1.1.7 works any better than > that one, though, but it's good to know what code you've been using). > > Thank you for your quick reply. Seems you are right about that, all the skewed images have width%4 != 0. Converting to RGB (with img2=img.convert('RGB')) crashes python when creating the wrapper. No exception or anything, "Python has stopped working, Windows is checking for a solution". I was using PIL 1.1.6, but just downloaded and tried with PIL 1.1.7b1. Same result however. Best regards Carl Pettersson From gregor at kopka.net Tue Jun 23 09:34:27 2009 From: gregor at kopka.net (Gregor Kopka) Date: Tue, 23 Jun 2009 09:34:27 +0200 Subject: [Image-SIG] Workarounds for MemoryErrors In-Reply-To: <4A3FB6BD.50508@ekran.org> References: <4A3FB6BD.50508@ekran.org> Message-ID: <4A408583.5030301@kopka.net> Hello, to process a ~ 25GB (uncompressed image data) you are afaik out of luck with PIL. Only chance would be to use a fairly recent 64 bit OS with 64 bit python binaries (some custom patches /might/ be needed though) and give it a hefty amount of swapspace (at least eight times main memory) to fit the image into virtual memory, but then you would wait for the disk for hours (at best) or - depending on the operations you want to perform - way longer. The question of how to open the resulting image also arises... Since you didn't give any details on what you need as output format, or the operations you want to perform on the image while in memory (or whereever it might be at that point) it's hard to give any better clues. Regards, Gregor B. Bogart schrieb: > Hello all, > > I want to create a very large RGBA image (96000x72000 pixels). > > I have 4GB of RAM. > > Is there an easy way of getting around this error by having PIL only > allocate one section of the image at a time? > > If PIL does not have any internal trick to work with large images then > I'll have to make 4+ smaller images one at a time, but then I'm not sure > how I could combine them without needing to allocate a memory chunk for > the whole image. > > Otherwise I suppose I'll have to try with some other language, perhaps > C/SDL, though a quick calculation seems to show that such a large RGBA > image is just unworkable. Is there some way of using disk space rather > than memory? Does not matter if it is slow, just that it is possible! > > Any advice? > > Thanks, > B. > _______________________________________________ > Image-SIG maillist - Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gregor.vcf Type: text/x-vcard Size: 314 bytes Desc: not available URL: From spe.stani.be at gmail.com Tue Jun 23 15:26:01 2009 From: spe.stani.be at gmail.com (Stani) Date: Tue, 23 Jun 2009 15:26:01 +0200 Subject: [Image-SIG] Workarounds for MemoryErrors In-Reply-To: <2078a7ad0906221055k1059065aq14b37c3485864e33@mail.gmail.com> References: <4A3FB6BD.50508@ekran.org> <2078a7ad0906221055k1059065aq14b37c3485864e33@mail.gmail.com> Message-ID: <2078a7ad0906230626s51725a35m1a8c553b2d47c217@mail.gmail.com> As an emergency solution I think VIPS has support for large images. It has python bindings, but they are not so nice and well documented as PIL. On Mon, Jun 22, 2009 at 6:52 PM, B. Bogart wrote: > Hello all, > > I want to create a very large RGBA image (96000x72000 pixels). > > I have 4GB of RAM. > > Is there an easy way of getting around this error by having PIL only > allocate one section of the image at a time? > > If PIL does not have any internal trick to work with large images then > I'll have to make 4+ smaller images one at a time, but then I'm not sure > how I could combine them without needing to allocate a memory chunk for > the whole image. > > Otherwise I suppose I'll have to try with some other language, perhaps > C/SDL, though a quick calculation seems to show that such a large RGBA > image is just unworkable. Is there some way of using disk space rather > than memory? Does not matter if it is slow, just that it is possible! > > Any advice? > > Thanks, > B. > _______________________________________________ > Image-SIG maillist ?- ?Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig > -- Phatch Photo Batch Processor - http://photobatch.stani.be SPE Python IDE - http://pythonide.stani.be From ben at ekran.org Wed Jun 24 01:50:28 2009 From: ben at ekran.org (B. Bogart) Date: Tue, 23 Jun 2009 16:50:28 -0700 Subject: [Image-SIG] Workarounds for MemoryErrors In-Reply-To: <915E63E0-7813-443C-A22A-E993E1A5DD60@cazabon.com> References: <4A3FB6BD.50508@ekran.org> <915E63E0-7813-443C-A22A-E993E1A5DD60@cazabon.com> Message-ID: <4A416A44.4080904@ekran.org> Thanks Kevin, I have tried the code, the Image.new() function just bails due to MemoryError. I've now enabled some extra swap, giving me about 20GB of free swap+mem. Still python bails on Image.new(). Looking at memory usage it seems python does not even try to allocate, just bails before any memory is used. Does PIL have some intelligence to bail when some pre-test shows there is not enough available memory? If so is there a way to override it? I just tried allocating a 32000x32000 RGBA image, which leaves this: total used free shared buffers cached Mem: 4065824 4037288 28536 0 3376 6960 -/+ buffers/cache: 4026952 38872 Swap: 15623164 112048 15511116 So very little swap is actually being used, and I'm guessing not by PIL. creating an image much larger than 32000x32000 bails due to memoryerror. Seems the memory usage check does not include swap. Any ideas? Thanks, B. Kevin Cazabon wrote: > Quite a number of years back I processed a 1.5GB image on a machine with > 256MB of RAM (the rest virtual memory - 48x96" poster at 304 > pixels/inch). It took days, but it worked. The software actually was > pretty inefficient too, so I was probably using well over 2GB of memory > space at a time. > > I think your image is about 19GB (at 24bits/pixel)... not that different > of a ratio than what I did. Have you tried it? Besides ensuring you > have lots of VM available, it might just work as-is. Memory is cheap > these days too... probably cheaper than the hours of programming a > work-around. > > Kevin > > On 22 Jun 2009, at 12:52, B. Bogart wrote: > >> Hello all, >> >> I want to create a very large RGBA image (96000x72000 pixels). >> >> I have 4GB of RAM. >> >> Is there an easy way of getting around this error by having PIL only >> allocate one section of the image at a time? >> >> If PIL does not have any internal trick to work with large images then >> I'll have to make 4+ smaller images one at a time, but then I'm not sure >> how I could combine them without needing to allocate a memory chunk for >> the whole image. >> >> Otherwise I suppose I'll have to try with some other language, perhaps >> C/SDL, though a quick calculation seems to show that such a large RGBA >> image is just unworkable. Is there some way of using disk space rather >> than memory? Does not matter if it is slow, just that it is possible! >> >> Any advice? >> >> Thanks, >> B. >> _______________________________________________ >> Image-SIG maillist - Image-SIG at python.org >> http://mail.python.org/mailman/listinfo/image-sig > > From janssen at parc.com Wed Jun 24 03:35:40 2009 From: janssen at parc.com (Bill Janssen) Date: Tue, 23 Jun 2009 18:35:40 PDT Subject: [Image-SIG] JPEG 2000? Message-ID: <979.1245807340@parc.com> My bottleneck right now is JPEG 2000. I'm getting lots of LOC images in this format, and need to manipulate them with PIL. Bill From gregor at kopka.net Wed Jun 24 10:06:19 2009 From: gregor at kopka.net (Gregor Kopka) Date: Wed, 24 Jun 2009 10:06:19 +0200 Subject: [Image-SIG] Workarounds for MemoryErrors In-Reply-To: <4A416A44.4080904@ekran.org> References: <4A3FB6BD.50508@ekran.org> <915E63E0-7813-443C-A22A-E993E1A5DD60@cazabon.com> <4A416A44.4080904@ekran.org> Message-ID: <4A41DE7B.5070901@kopka.net> Hi, could it be that it bails the moment you step with the image size over the maximum value of a signed word (32768) ? Regards, Gregor B. Bogart schrieb: > Thanks Kevin, > > I have tried the code, the Image.new() function just bails due to > MemoryError. > > I've now enabled some extra swap, giving me about 20GB of free swap+mem. > > Still python bails on Image.new(). Looking at memory usage it seems > python does not even try to allocate, just bails before any memory is used. > > Does PIL have some intelligence to bail when some pre-test shows there > is not enough available memory? If so is there a way to override it? > > I just tried allocating a 32000x32000 RGBA image, which leaves this: > > total used free shared buffers cached > Mem: 4065824 4037288 28536 0 3376 6960 > -/+ buffers/cache: 4026952 38872 > Swap: 15623164 112048 15511116 > > So very little swap is actually being used, and I'm guessing not by PIL. > > creating an image much larger than 32000x32000 bails due to memoryerror. > > Seems the memory usage check does not include swap. > > Any ideas? > > Thanks, > B. > > Kevin Cazabon wrote: > >> Quite a number of years back I processed a 1.5GB image on a machine with >> 256MB of RAM (the rest virtual memory - 48x96" poster at 304 >> pixels/inch). It took days, but it worked. The software actually was >> pretty inefficient too, so I was probably using well over 2GB of memory >> space at a time. >> >> I think your image is about 19GB (at 24bits/pixel)... not that different >> of a ratio than what I did. Have you tried it? Besides ensuring you >> have lots of VM available, it might just work as-is. Memory is cheap >> these days too... probably cheaper than the hours of programming a >> work-around. >> >> Kevin >> >> On 22 Jun 2009, at 12:52, B. Bogart wrote: >> >> >>> Hello all, >>> >>> I want to create a very large RGBA image (96000x72000 pixels). >>> >>> I have 4GB of RAM. >>> >>> Is there an easy way of getting around this error by having PIL only >>> allocate one section of the image at a time? >>> >>> If PIL does not have any internal trick to work with large images then >>> I'll have to make 4+ smaller images one at a time, but then I'm not sure >>> how I could combine them without needing to allocate a memory chunk for >>> the whole image. >>> >>> Otherwise I suppose I'll have to try with some other language, perhaps >>> C/SDL, though a quick calculation seems to show that such a large RGBA >>> image is just unworkable. Is there some way of using disk space rather >>> than memory? Does not matter if it is slow, just that it is possible! >>> >>> Any advice? >>> >>> Thanks, >>> B. >>> _______________________________________________ >>> 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 HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gregor.vcf Type: text/x-vcard Size: 314 bytes Desc: not available URL: From fredrik at pythonware.com Wed Jun 24 15:51:09 2009 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 24 Jun 2009 15:51:09 +0200 Subject: [Image-SIG] Workarounds for MemoryErrors In-Reply-To: <4A41DE7B.5070901@kopka.net> References: <4A3FB6BD.50508@ekran.org> <915E63E0-7813-443C-A22A-E993E1A5DD60@cazabon.com> <4A416A44.4080904@ekran.org> <4A41DE7B.5070901@kopka.net> Message-ID: <368a5cd50906240651w60938fffv46af440e59eaffca@mail.gmail.com> On Wed, Jun 24, 2009 at 10:06 AM, Gregor Kopka wrote: > could it be that it bails the moment you step with the image size over the > maximum value of a signed word (32768) ? The size is stored as C ints, so that shouldn't happen (unless you compile on a machine that thinks int is 16 bits). The following works just fine on my 64-bit machine: >>> a = Image.new("L", (100000000, 1)) >>> b = Image.new("L", (1, 100000000)) so if you get a MemoryError, the reason is simply that the OS doesn't want to allocate that much memory for your process, either because it doesn't have it, or because a process-level or other resource limitation. But PIL simply isn't made for processing humongous images in a single block; I suggest doing some preprocessing to split them up in tiles or strips, or, if you're reading from an uncompressed format, manipulating the "size" and "tile" attributes directly after open; see e.g. http://mail.python.org/pipermail/image-sig/2005-September/003525.html (if the input is TIFF, the tile attribute may contain a bunch of tiles; in that case, you can simply process one tile at a time by keeping just one in the list, and adjusting the size/extent to match that tile). For output, you're pretty much on your own, even if you can probably reuse code from e.g. the PPM module, or any other codec that writes uncompressed files. From ben at ekran.org Wed Jun 24 20:14:07 2009 From: ben at ekran.org (B. Bogart) Date: Wed, 24 Jun 2009 11:14:07 -0700 Subject: [Image-SIG] Workarounds for MemoryErrors In-Reply-To: <4A408583.5030301@kopka.net> References: <4A3FB6BD.50508@ekran.org> <4A408583.5030301@kopka.net> Message-ID: <4A426CEF.7020601@ekran.org> Thanks all for your help. The code generates a large image from many small ones. So I'll just scale each image individually before collaging them. .b. Gregor Kopka wrote: > Hello, > > to process a ~ 25GB (uncompressed image data) you are afaik out of luck > with PIL. > Only chance would be to use a fairly recent 64 bit OS with 64 bit python > binaries (some custom patches /might/ be needed though) and give it a > hefty amount of swapspace (at least eight times main memory) to fit the > image into virtual memory, but then you would wait for the disk for > hours (at best) or - depending on the operations you want to perform - > way longer. > > The question of how to open the resulting image also arises... > > Since you didn't give any details on what you need as output format, or > the operations you want to perform on the image while in memory (or > whereever it might be at that point) it's hard to give any better clues. > > Regards, > > Gregor > > B. Bogart schrieb: >> Hello all, >> >> I want to create a very large RGBA image (96000x72000 pixels). >> >> I have 4GB of RAM. >> >> Is there an easy way of getting around this error by having PIL only >> allocate one section of the image at a time? >> >> If PIL does not have any internal trick to work with large images then >> I'll have to make 4+ smaller images one at a time, but then I'm not sure >> how I could combine them without needing to allocate a memory chunk for >> the whole image. >> >> Otherwise I suppose I'll have to try with some other language, perhaps >> C/SDL, though a quick calculation seems to show that such a large RGBA >> image is just unworkable. Is there some way of using disk space rather >> than memory? Does not matter if it is slow, just that it is possible! >> >> Any advice? >> >> Thanks, >> B. >> _______________________________________________ >> Image-SIG maillist - Image-SIG at python.org >> http://mail.python.org/mailman/listinfo/image-sig >> >> From oc-spam66 at laposte.net Fri Jun 26 23:04:21 2009 From: oc-spam66 at laposte.net (oc-spam66) Date: Fri, 26 Jun 2009 23:04:21 +0200 (CEST) Subject: [Image-SIG] Transform a "Tk PhotoImage" to a "PIL Image" Message-ID: <31589406.82065.1246050261562.JavaMail.www@wwinf8403> Hello, is there a way to transform a "Tk PhotoImage" to a "PIL Image" ? In other words, how to do the reverse of this : Tk_PhotoImage = ImageTk.PhotoImage(image=PIL_Image, master=root) Cr?ez votre adresse ?lectronique prenom.nom at laposte.net 1 Go d'espace de stockage, anti-spam et anti-virus int?gr?s. From larryhaja at gmail.com Sat Jun 27 02:26:26 2009 From: larryhaja at gmail.com (Larry Hajali) Date: Fri, 26 Jun 2009 17:26:26 -0700 Subject: [Image-SIG] Not clear about distributing header files Message-ID: <8ba30f850906261726p1bc09850nd8b76b773ca2054c@mail.gmail.com> Hi, I've tried to find an answer for this by googling your mailing list and just googling in general. This has probably been asked before but I can't seem to find a concisive answer to it. Currently, I have PIL 1.1.6 installed with the additional SANE module on Slackware. When it came time to compile swftools it complained that it couldn't find Imaging.h. This header file along with ImPlatform.h comes with PIL, which are needed to compile swftools. It seems to be looking for the header files in /usr/inlclude/python$PYTHON_VERSION. But when installing PIL to the system I do not see a way the setup.py scripts include any of the header files. My question is, what (if any) header files should be included so other packages can compile against the PIL library? As far as I can see, Archlinux and Fedora include all header files from the libImage folder, whereas Gentoo includes Imaging.h and ImPlatform.h (specifically for sketch), and finally Ubuntu/Debian include Imaging.h, ImPlatform.h, and ImDib.h (taken from the rules file in the debian subfolder included with PIL). As far as I can see, most, if not all, *.c files inluded with PIL use Imaging.h. Thank you, Larry -------------- next part -------------- An HTML attachment was scrubbed... URL: