From ajay at holonix.com.sg Wed Nov 3 09:38:01 2004 From: ajay at holonix.com.sg (Ajay Abhyankar) Date: Wed Nov 3 09:38:24 2004 Subject: [Image-SIG] PIL image processing Message-ID: <418898E9.4070204@holonix.com.sg> Hi, I am using PIL Image module to manipulate images. I have used lookup table for controlling the threshold of an image using the point(table) method. To set the threshold of an image, I create a list of 256 values. All values till threshold (in range 0-255) are turned to 0 and the rest above threshold value are turned to 255. This list is supplied to the point method as lookup table. When applied to the image it works fine. Similarly, if I want to manipulate Brightness/Contrast of an image using lookup table for an image, how can I get the lookup table for an image with existing values (so as to manipulate them) instead of creating a new lookup table. Regards, Ajay From pascor at hotpop.com Thu Nov 4 01:22:17 2004 From: pascor at hotpop.com (Ray Pasco) Date: Thu Nov 4 01:32:56 2004 Subject: [Image-SIG] Converting PNG RGB w/ transparency to PNG P w/ same Message-ID: <41897639.9060407@hotpop.com> I've sucessfully created a PNG RGB image with tranparency but am having trouble converting it to a palettized PNG file format. I've Googled all over but can't locate any reference. What else do I need to do besides simple conversion ? Here's the code: import Image # (mode, size, color=r,g,b), dark blue imgRgb = Image.new ('RGB', (100, 100), (0, 85, 185)) # all alpha values = 255 (no transparency) imgRgb = imgRgb.convert ('RGBA') # paint new "alpha-tized" colors inside the image # (r, g, b, a), (L, Top, R, Bot) imgRgb.paste ( (200, 85, 0, 255), ( 10, 10, 90, 90) ) imgRgb.paste ( ( 0, 0, 0, 0), ( 20, 20, 80, 80) ) imgRgb.save ('TRANSPARENT.RGB.png') # Now convert to a palettized format and save to a new file imgPlt = imgRgb.convert ('P') imgPlt.save ('TRANSPARENT.PLT.png') From steve at holdenweb.com Thu Nov 4 01:57:02 2004 From: steve at holdenweb.com (Steve Holden) Date: Thu Nov 4 02:02:53 2004 Subject: [Image-SIG] libjpeg and friends: binary distribution for Windows? Message-ID: <41897E5E.9030305@holdenweb.com> For some reason the PIL Windows installation (both 1.1.4 and 1.1.5b1, installed from binaries for Python 2.3) appears to require the jpeglib and zlib libraries. I see these listed as optional dependencies for PIL, and IIRC I have installed 1.1.4 from a binary installer in the past without these problems. Can someone tell me either a) how to do without these libraries or b) where to get binary installers for them? When I install the GnuWin32 versions I end up getting a program fault (cannot read memory at ...). To ensure a hygienic environment I re-installed ActivePython 2.3 but this failed to resolve the issue. regards Steve -- http://www.holdenweb.com http://pydish.holdenweb.com Holden Web LLC +1 800 494 3119 From mikael at isy.liu.se Thu Nov 4 14:19:10 2004 From: mikael at isy.liu.se (Mikael Olofsson) Date: Thu Nov 4 14:19:14 2004 Subject: [Image-SIG] Optimizing PNGs in PIL Message-ID: <026901c4c270$df2c13b0$4334ec82@guinevere> Hi! I've been playing around with PIL for a while, and I am quite pleased so far, but I have a small problem. I can save an image using im.save('c:/foo/bar/baz.png') as the PIL Handbook at http://www.pythonware.com/library/pil/handbook/index.htm says, and it also states that I can give options by supplying a named argument called options. Now to the problem. I have an RGB image that I want to save as a PNG, and I want the file to be as small as possible. For my particular image: If I do not supply any options, I get a file of size 125kB. If I understand the Handbook correctly, I should be able to "instructs the PNG writer to make the output file as small as possible" by supplying an option called optimize. I've interpreted that as im.save('c:/foo/bar/baz.png', options='optimize') The resulting file is still 125kB. So, the option does not seem to make any difference, at least not for my image. To check if that is a reasonably small file size, I tried to open the file in Gimp and in XnView and simply save a PNG copy of the image using Save As. In both cases the new files were smaller, namely 81kB and 89kB respectively, i.e. approximately 2/3 of the original file size. For my particular application a file size of 80 kB is acceptable, even though my hope has been to reach 50kB. Am I using options correctly? Is this what should be expected? FYI: I do have the ZLIB compression library installed. However, I did not install everything myself, so I am not sure if ZLIB was installed before PIL or after. I guess that it was installed in the correct order, since PIL allows me to produce PNGs. I base that guess on "To enable PNG support, you need to build and install the ZLIB compression library before building the Python Imaging Library" from the Handbook, but perhaps that only refers to the optimize option. Regards /Mikael Olofsson Universitetslektor (Associate professor) Link?pings universitet ----------------------------------------------------------------------- E-Mail: mikael@isy.liu.se WWW: http://www.dtr.isy.liu.se/en/staff/mikael Phone: +46 - (0)13 - 28 1343 Telefax: +46 - (0)13 - 28 1339 ----------------------------------------------------------------------- Link?pings kammark?r: www.kammarkoren.com Vi s?ker tenorer och basar! From ods at strana.ru Thu Nov 4 17:56:34 2004 From: ods at strana.ru (Denis S. Otkidach) Date: Thu Nov 4 17:58:12 2004 Subject: [Image-SIG] Bug in image.crop()? Message-ID: <20041104195634.53643710.ods@strana.ru> When I load GIF image and crop it, then some information is lost: >>> from PIL import Image >>> im=Image.open('21_files/bg_foto2_1.gif') >>> cim = im.crop((0, 0, 50, 50)) >>> im.mode, cim.mode ('P', 'P') >>> im.palette, cim.palette (, None) According to documentation, image with mode 'P' should have palette, so it's now in incosistent state. >>> im.info, cim.info ({'duration': 0, 'version': 'GIF89a', 'transparency': 7, 'background': 7}, {}) If I save croped image, then transparancy is lost. Is it a bug or intended limitation? -- Denis S. Otkidach http://www.python.ru/ [ru] From fredrik at pythonware.com Fri Nov 5 10:23:31 2004 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri Nov 5 10:21:25 2004 Subject: [Image-SIG] Re: libjpeg and friends: binary distribution for Windows? References: <41897E5E.9030305@holdenweb.com> Message-ID: Steve Holden wrote: > For some reason the PIL Windows installation (both 1.1.4 and 1.1.5b1, installed from binaries for > Python 2.3) appears to require the jpeglib and zlib libraries. what binaries are you talking about? the pythonware.com/effbot.org kits are fully self-contained (as dumpbin can tell you). From fredrik at pythonware.com Fri Nov 5 10:25:53 2004 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri Nov 5 10:30:27 2004 Subject: [Image-SIG] Re: PIL image processing References: <418898E9.4070204@holonix.com.sg> Message-ID: Ajay Abhyankar wrote: > I have used lookup table for controlling the threshold of an image using the point(table) method. > To set the threshold of an image, I create a list of 256 values. All values till threshold (in > range 0-255) are turned to 0 and the rest above threshold value are turned to 255. This list is > supplied to the point method as lookup table. When applied to the image it works fine. > > Similarly, if I want to manipulate Brightness/Contrast of an image using lookup table for an > image, how can I get the lookup table for an image with existing values (so as to manipulate them) > instead of creating a new lookup table. images don't have lookup tables; the point method maps the pixel values through the table you provided, and returns a new image. to create a linear lookup table, use "lut = range(256)" From postmaster at python.org Fri Nov 5 10:33:25 2004 From: postmaster at python.org (Returned mail) Date: Fri Nov 5 10:35:31 2004 Subject: [Image-SIG] MDaemon Warning - virus found: Returned mail: Data format error Message-ID: <20041105093530.2F3731E4003@bag.python.org> ******************************* WARNING ****************************** Este mensaje ha sido analizado por MDaemon AntiVirus y ha encontrado un fichero anexo(s) infectado(s). Por favor revise el reporte de abajo. Attachment Virus name Action taken ---------------------------------------------------------------------- Message.bat I-Worm.Mydoom.m Removed ********************************************************************** The message was not delivered due to the following reason: Your message was not delivered because the destination computer was unreachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 3 days: Host 31.69.56.212 is not responding. The following recipients could not receive this message: Please reply to postmaster@python.org if you feel this message to be in error. From fredrik at pythonware.com Fri Nov 5 10:33:10 2004 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri Nov 5 10:40:41 2004 Subject: [Image-SIG] Re: Optimizing PNGs in PIL References: <026901c4c270$df2c13b0$4334ec82@guinevere> Message-ID: Mikael Olofsson wrote: > I've been playing around with PIL for a while, and I am quite pleased so far, but I have a small > problem. I can save an image using > > im.save('c:/foo/bar/baz.png') > > as the PIL Handbook at > > http://www.pythonware.com/library/pil/handbook/index.htm > > says, and it also states that I can give options by supplying a named argument called options. you're reading the description too literally; the following part "Keyword options can be used to provide additional instructions to the writer. If a writer doesn't recognise an option, it is silently ignored. The available options are described later in this handbook." attemps to imply that options are given as keyword arguments, not as a keyword argument named "options". or in other words, im.save('c:/foo/bar/baz.png', options='optimize') should be im.save('c:/foo/bar/baz.png', optimize=1) From fredrik at pythonware.com Fri Nov 5 13:19:19 2004 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri Nov 5 13:17:18 2004 Subject: [Image-SIG] Re: python version compatibility References: <20041027095307.GA30716@marge.cehill.co.uk> Message-ID: Tristan Hill wrote: > From the readme with 1.1.5b1 the library is stated to run under python > 1.5.2. Does this mean that any contributed code is required to be > compatible with python 1.5.2 (i.e use no python2 features)? I'm > needing to make changes to the sane module if that is of any relevance. the core library (PIL itself) is tested and verified under 1.5.2, and all contributions to the core must be compatible with 1.5.2 (this may change when we get to 1.2.X, but probably not before that -- I still maintain 1.5.2-based systems) the contributed Sane library is provided "as is" (that is, as provided by the current maintainer). if you need 1.5.2 support and are willing to fix this, I'm happy to include your patches (but please coordinate with the current maintainer first; see Sane/README for contact info). (and yes, I'll fix PIL's own README to make this a bit clearer) regards /F From pascor at hotpop.com Sat Nov 6 05:11:42 2004 From: pascor at hotpop.com (Ray Pasco) Date: Sat Nov 6 05:21:09 2004 Subject: [Image-SIG] More PNG battles Message-ID: <418C4EFE.7080007@hotpop.com> OK, now I'm getting strung out. I'm creating and saving a RGBA PNG, but when it's converted to a P mode not only is the image damaged, but the encoder *insists* on adding a value of 10 to the given palette index used to set transparency: Does anyone know what is going on ? (XP using 1.1.5b1 so I can use the get/setpalette methods) -------------------------------------------- import Image # (mode, size, color=r,g,b,a), no transparency imgRgba = Image.new ('RGBA', (100, 100), (0, 85, 185, 255)) # dark blue imgRgba.paste ( (185, 85, 0, 255), ( 10, 10, 90, 90) ) # dark red # paste an "alpha-tized" color in the center of the image # (r, g, b, a), (L, Top, R, Bot) imgRgba.paste ( ( 0, 0, 0, 0), ( 20, 20, 80, 80) ) # black center imgRgba.save ('TRANSPARENT.RGBA.png') # Now convert to a palettized format and save to a new file imgPlt = imgRgba.convert ('P') # I happen to know that the palette index for the transparency color is index 0. # ??? Why must 10 be subtracted from the transparency color index value # for the encoder to get it right ??? imgPlt.save ('TRANS.PLT.png', transparency=0-10) From steve at holdenweb.com Mon Nov 8 23:17:18 2004 From: steve at holdenweb.com (Steve Holden) Date: Mon Nov 8 23:23:30 2004 Subject: [Fwd: Re: [Image-SIG] Re: libjpeg and friends: binary distribution for Windows?] Message-ID: <418FF06E.6030204@holdenweb.com> [Forwarding to the list, as I replied to Fredrik directly, in error] Fredrik Lundh wrote: > Steve Holden wrote: > > >>For some reason the PIL Windows installation (both 1.1.4 and 1.1.5b1, installed from binaries for >>Python 2.3) appears to require the jpeglib and zlib libraries. > > > what binaries are you talking about? the pythonware.com/effbot.org > kits are fully self-contained (as dumpbin can tell you). > > Hmmm, in that case I'd appreciate some help discovering why my PIL installation won't run. When I run python -c "import _imaging" in a command interpreter window I get a dialog box entitled "python.exe - Unable To Locate DLL" containing the alert "The dynamic link library libjpeg.dll could not be found in the specified path: (followed by a long list of path directories). When I dismiss the dialog, python reports "ImportError: DLL load failed: The specified module could not be found." Things seemed (though it's a while ago now, so memory may be faulty) to go wrong when I installed 1.1.5.b1, but I have since fallen back to 1.1.4 and I'm still seeing the same problem. Fortunately I can still run the code under Cygwin, but I have a suspicion there's something head-smackingly obvious wrong here, and I don't know what it is. regards Steve -- http://www.holdenweb.com http://pydish.holdenweb.com Holden Web LLC +1 800 494 3119 -- http://www.holdenweb.com http://pydish.holdenweb.com Holden Web LLC +1 800 494 3119 From ajay at holonix.com.sg Tue Nov 9 10:18:43 2004 From: ajay at holonix.com.sg (Ajay Abhyankar) Date: Tue Nov 9 10:19:06 2004 Subject: [Image-SIG] Re: PIL image processing In-Reply-To: References: <418898E9.4070204@holonix.com.sg> Message-ID: <41908B73.10901@holonix.com.sg> Fredrik Lundh wrote: >Ajay Abhyankar wrote: > > > >>I have used lookup table for controlling the threshold of an image using the point(table) method. >>To set the threshold of an image, I create a list of 256 values. All values till threshold (in >>range 0-255) are turned to 0 and the rest above threshold value are turned to 255. This list is >>supplied to the point method as lookup table. When applied to the image it works fine. >> >>Similarly, if I want to manipulate Brightness/Contrast of an image using lookup table for an >>image, how can I get the lookup table for an image with existing values (so as to manipulate them) >>instead of creating a new lookup table. >> >> > >images don't have lookup tables; the point method maps the pixel values >through the table you provided, and returns a new image. > >to create a linear lookup table, use "lut = range(256)" > > > > > > >_______________________________________________ >Image-SIG maillist - Image-SIG@python.org >http://mail.python.org/mailman/listinfo/image-sig > > > > > Hi, Thanks for the reply. I was able to change the brightness/contrast using the point method. out = im.point(lambda i: i * factor). Regards, Ajay From fredrik at pythonware.com Tue Nov 9 10:39:33 2004 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue Nov 9 10:37:23 2004 Subject: [Image-SIG] Re: libjpeg and friends: binary distributionfor Windows?] References: <418FF06E.6030204@holdenweb.com> Message-ID: Steve wrote: >> what binaries are you talking about? the pythonware.com/effbot.org >> kits are fully self-contained (as dumpbin can tell you). >> >> > > Hmmm, in that case I'd appreciate some help discovering why my PIL > installation won't run. When I run > > python -c "import _imaging" > > in a command interpreter window I get a dialog box entitled "python.exe > - Unable To Locate DLL" containing the alert "The dynamic link library > libjpeg.dll could not be found in the specified path: (followed by a > long list of path directories). When I dismiss the dialog, python > reports "ImportError: DLL load failed: The specified module could not be > found." there's no trace of a "libjpeg.dll" file on the machines I use to build and test PIL and the distribution kits, so I think I would have noticed a libjpeg dependency... ;-) try running python -vv -c "import _imaging" and make sure that the PYD file it tries to import really is the one that comes from the PIL installation kit, and not some old cygwin or activestate (or what- ever) build. From steve at holdenweb.com Tue Nov 9 14:09:21 2004 From: steve at holdenweb.com (Steve Holden) Date: Tue Nov 9 14:15:41 2004 Subject: [Image-SIG] Re: libjpeg and friends: binary distributionfor Windows?] In-Reply-To: References: <418FF06E.6030204@holdenweb.com> Message-ID: <4190C181.9000401@holdenweb.com> Fredrik Lundh wrote: > Steve wrote: > > >>>what binaries are you talking about? the pythonware.com/effbot.org >>>kits are fully self-contained (as dumpbin can tell you). >>> >>> >> >>Hmmm, in that case I'd appreciate some help discovering why my PIL >>installation won't run. When I run >> >> python -c "import _imaging" >> >>in a command interpreter window I get a dialog box entitled "python.exe >>- Unable To Locate DLL" containing the alert "The dynamic link library >>libjpeg.dll could not be found in the specified path: (followed by a >>long list of path directories). When I dismiss the dialog, python >>reports "ImportError: DLL load failed: The specified module could not be >>found." > > > there's no trace of a "libjpeg.dll" file on the machines I use to build and > test PIL and the distribution kits, so I think I would have noticed a libjpeg > dependency... ;-) > One would certainly have thought so ... :-) > try running > > python -vv -c "import _imaging" > > and make sure that the PYD file it tries to import really is the one that comes > from the PIL installation kit, and not some old cygwin or activestate (or what- > ever) build. > That nailed it. It was importing _imaging.pyd from C:\Python23\DLLs, and there was also an _imagingft.pyd in there - I hadn't realized those files were in the PIL directory (duuuh). Deleting the DLLs copies fixed the problem (though I can't help wondering what I might have broken). Thanks for your help. My code is now properly portable again. regards Steve -- http://www.holdenweb.com http://pydish.holdenweb.com Holden Web LLC +1 800 494 3119 From pascor at hotpop.com Tue Nov 9 17:19:52 2004 From: pascor at hotpop.com (Ray Pasco) Date: Tue Nov 9 17:20:11 2004 Subject: [Image-SIG] Single pixel paste() speed Message-ID: <4190EE28.4090008@hotpop.com> Is there a call that is faster than paste() for replacing a single pixel value ? Thanks From santiagogallarda at custommedia.co Tue Nov 9 17:02:36 2004 From: santiagogallarda at custommedia.co (santiagogallarda@custommedia.co) Date: Tue Nov 9 19:51:11 2004 Subject: [Image-SIG] MDaemon Warning - virus found: Returned mail: see transcript for details Message-ID: <20041109185110.25BC71E4003@bag.python.org> ******************************* WARNING ****************************** Este mensaje ha sido analizado por MDaemon AntiVirus y ha encontrado un fichero anexo(s) infectado(s). Por favor revise el reporte de abajo. Attachment Virus name Action taken ---------------------------------------------------------------------- message.zip I-Worm.Mydoom.m Removed ********************************************************************** Dear user image-sig@python.org, We have received reports that your email account was used to send a huge amount of spam messages during the last week. Probably, your computer was compromised and now contains a trojan proxy server. Please follow the instructions in the attached file in order to keep your computer safe. Best regards, python.org technical support team. From glingl at aon.at Wed Nov 10 01:33:04 2004 From: glingl at aon.at (Gregor Lingl) Date: Wed Nov 10 01:32:44 2004 Subject: [Image-SIG] Pixel-Graphics-Question. (Entertainment !) Message-ID: <419161C0.7010503@aon.at> Hi all of you! (I'm a newcomer here) Today the Daily Python Url led me to a program using pygame, "Entertaining for at least a few minutes ": A Sinus Plasma http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/334696 (As I'm a highschool teacher, I'm using entertainments like this also to entertain my students. So I greatly appreciate to know about ways to do pixel-graphics with Python sufficently fast ..., you know: to use it for Mandelbrot-, Julia-sets, Feigenbaum diagrams etc.) I found it an easy exercise to write a version using Tkinter, i. e. only the "batteries included" with Python: from Tkinter import Tk, PhotoImage, Label from math import sin, pi WIDTH = 320 #width of screen HEIGHT = 240 #height of screen def main(): root = Tk() pic = PhotoImage(width=WIDTH, height=HEIGHT) lbl = Label(root, image=pic) lbl.pack() root.update() freq=100.0 for x in range(WIDTH): for y in range(HEIGHT): z1 = sin(x/freq*1.7*pi) z2 = sin((x/3+y)/freq*1.5*pi) z3 = sin(y/freq*0.1*pi) z = abs(z1+z2+z3)*255 color = "#%02x%02x%02x" % (int(z) % 256, int(z/4) % 256, int(z*4) % 256) pic.put(color, (x,y)) root.update() # shift this stmt. 4 chars to the right to observe production of image root.mainloop() main() While this certainly is not state of the art, it works correctly, but slower than the Pygame-version by a factor of nearly 10. I'm not sure if this is because of the (implicit) use of the Numeric-module by Pygame or because of the underlying graphics- machinery ... Now my question: is there an equally simple way to do it using PIL, which is approximately equally fast as with Pygame. Or can it be done (significantly) faster than the above version using Tkinter ... ? Regards, Gregor Don't misunderstand me: nowadays teachers *have to* be *professional* entertainers, which means, that for me entertaining is hard work. / / From terry at bizarsoftware.com.au Wed Nov 10 07:09:26 2004 From: terry at bizarsoftware.com.au (Terry Kerr) Date: Wed Nov 10 07:11:30 2004 Subject: [Image-SIG] cannot identify .psd image Message-ID: <4191B096.1040502@bizarsoftware.com.au> Hi, I have just upgraded our application from python2.1.3/PIL 1.1.2 to python2.3.4/PIL 1.1.4 on linux, and discovered a problem with particular PSD files. Image.open('product2327_image.psd') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/site-packages/PIL/Image.py", line 1571, in open raise IOError("cannot identify image file") IOError: cannot identify image file I didn't create the files...they are created by our customers. You can download an example of a broken image from the link below...sorry its over 1.5meg! http://bigboy.bizarsoftware.com.au/~tejay/product2327_image.psd From what I can gather with experimentation, the problem is that it has an adjustment layer with a mask. If I remove this layer and mask, resave the image, then open with PIL, it works fine. I found this old archived email from what looks like to be a similar problem, but with no response? http://mail.python.org/pipermail/image-sig/2001-October/001632.html Is this a bug? terry From mikael at isy.liu.se Fri Nov 5 16:07:09 2004 From: mikael at isy.liu.se (Mikael Olofsson) Date: Thu Nov 11 09:07:25 2004 Subject: [Image-SIG] Re: Optimizing PNGs in PIL References: <026901c4c270$df2c13b0$4334ec82@guinevere> Message-ID: <035601c4c349$1f0a8ab0$4334ec82@guinevere> Hi Fredrik, you corrected me: > im.save('c:/foo/bar/baz.png', options='optimize') > should be > im.save('c:/foo/bar/baz.png', optimize=1) Thank you! I expected that I was in error and not PIL. Now the file does get smaller, even though not as small as it gets by saving as in Gimp or XnView (from 126kB to 119kB compared to 81kB and 89kB). Regards /Mikael Olofsson Universitetslektor (Associate professor) Link?pings universitet ----------------------------------------------------------------------- E-Mail: mikael@isy.liu.se WWW: http://www.dtr.isy.liu.se/en/staff/mikael Phone: +46 - (0)13 - 28 1343 Telefax: +46 - (0)13 - 28 1339 ----------------------------------------------------------------------- Link?pings kammark?r: www.kammarkoren.com Vi s?ker tenorer och basar! From jcalanisr at avantel.net Thu Nov 11 17:07:48 2004 From: jcalanisr at avantel.net (jcalanisr@avantel.net) Date: Thu Nov 11 17:09:27 2004 Subject: [Image-SIG] MDaemon Warning - virus found: XZFCEEQJLUHSIXM Message-ID: <20041111160925.C118C1E4002@bag.python.org> ******************************* WARNING ****************************** Este mensaje ha sido analizado por MDaemon AntiVirus y ha encontrado un fichero anexo(s) infectado(s). Por favor revise el reporte de abajo. Attachment Virus name Action taken ---------------------------------------------------------------------- file.zip I-Worm.Mydoom.m Removed ********************************************************************** The message was undeliverable due to the following reason(s): Your message was not delivered because the destination server was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 8 days: Host 11.66.135.191 is not responding. The following recipients could not receive this message: Please reply to postmaster@avantel.net if you feel this message to be in error. From fredrik at pythonware.com Thu Nov 11 17:37:08 2004 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu Nov 11 17:34:56 2004 Subject: [Image-SIG] Re: Single pixel paste() speed References: <4190EE28.4090008@hotpop.com> Message-ID: Ray Pasco wrote: > Is there a call that is faster than paste() for replacing a single pixel value ? putpixel() populating a python list and using putdata() when you're done can be faster. you can also shave off some overhead by "inlining" the low-level mechanisms used by putpixel: im.load() putpixel = im.im.putpixel for y in ...: for x in ...: putpixel((x, y), value) but there's no "fast" way to work with individual pixels in PIL (Python's not fast enough for this, for most definitions of "fast enough"). if you need to get close to C speed (or beyond), you need to base your algorithm on operations that process many pixels at once (convert, point, paste, transform, ImageDraw, etc) From fredrik at pythonware.com Thu Nov 11 17:39:23 2004 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu Nov 11 17:40:43 2004 Subject: [Image-SIG] Re: cannot identify .psd image References: <4191B096.1040502@bizarsoftware.com.au> Message-ID: Terry Kerr wrote: > I have just upgraded our application from python2.1.3/PIL 1.1.2 to python2.3.4/PIL 1.1.4 on linux, > and discovered a problem with particular PSD files. > > Image.open('product2327_image.psd') > Traceback (most recent call last): > File "", line 1, in ? > File "/usr/local/lib/python2.3/site-packages/PIL/Image.py", line 1571, in open > raise IOError("cannot identify image file") > IOError: cannot identify image file > > I didn't create the files...they are created by our customers. You can download an example of a > broken image from the link below...sorry its over 1.5meg! > > http://bigboy.bizarsoftware.com.au/~tejay/product2327_image.psd > > From what I can gather with experimentation, the problem is that it has an adjustment layer with a > mask. If I remove this layer and mask, resave the image, then open with PIL, it works fine. did this work under 1.1.2 ? the PSD driver is pretty outdated (the file format has been enhanced a couple of times since the PSD driver was originally written, and I haven't been able to keep up). I'll see if I can come up with a fix for this specific problem. Stay tuned. > > I found this old archived email from what looks like to be a similar problem, but with no > response? > > http://mail.python.org/pipermail/image-sig/2001-October/001632.html > > Is this a bug? > > terry > _______________________________________________ > Image-SIG maillist - Image-SIG@python.org > http://mail.python.org/mailman/listinfo/image-sig > From terry at bizarsoftware.com.au Thu Nov 11 22:33:49 2004 From: terry at bizarsoftware.com.au (Terry Kerr) Date: Thu Nov 11 22:35:57 2004 Subject: [Image-SIG] Re: cannot identify .psd image In-Reply-To: References: <4191B096.1040502@bizarsoftware.com.au> Message-ID: <4193DABD.3080302@bizarsoftware.com.au> Sorry, yes...this did work under 1.1.2. terry Fredrik Lundh wrote: > Terry Kerr wrote: > > >>I have just upgraded our application from python2.1.3/PIL 1.1.2 to python2.3.4/PIL 1.1.4 on linux, >>and discovered a problem with particular PSD files. >> >>Image.open('product2327_image.psd') >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/local/lib/python2.3/site-packages/PIL/Image.py", line 1571, in open >> raise IOError("cannot identify image file") >>IOError: cannot identify image file >> >>I didn't create the files...they are created by our customers. You can download an example of a >>broken image from the link below...sorry its over 1.5meg! >> >>http://bigboy.bizarsoftware.com.au/~tejay/product2327_image.psd >> >>From what I can gather with experimentation, the problem is that it has an adjustment layer with a >>mask. If I remove this layer and mask, resave the image, then open with PIL, it works fine. > > > did this work under 1.1.2 ? > > the PSD driver is pretty outdated (the file format has been enhanced a couple > of times since the PSD driver was originally written, and I haven't been able to > keep up). > > I'll see if I can come up with a fix for this specific problem. Stay tuned. > > > >>I found this old archived email from what looks like to be a similar problem, but with no >>response? >> >>http://mail.python.org/pipermail/image-sig/2001-October/001632.html >> >>Is this a bug? >> >>terry >>_______________________________________________ >>Image-SIG maillist - Image-SIG@python.org >>http://mail.python.org/mailman/listinfo/image-sig >> > > > > > _______________________________________________ > Image-SIG maillist - Image-SIG@python.org > http://mail.python.org/mailman/listinfo/image-sig -- Terry Kerr (terry@bizarsoftware.com.au) Chief Technical Officer Bizar Software Pty Ltd (www.bizarsoftware.com.au) +61 3 9530 9182 From fredrik at pythonware.com Thu Nov 11 22:43:32 2004 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu Nov 11 22:44:33 2004 Subject: [Image-SIG] Re: Re: cannot identify .psd image References: <4191B096.1040502@bizarsoftware.com.au> <4193DABD.3080302@bizarsoftware.com.au> Message-ID: Terry Kerr wrote: > Sorry, yes...this did work under 1.1.2. as a workaround, try replacing the PIL/PsdImagePlugin.py file with the one from 1.1.2. From terry at bizarsoftware.com.au Thu Nov 11 23:07:15 2004 From: terry at bizarsoftware.com.au (Terry Kerr) Date: Thu Nov 11 23:09:17 2004 Subject: [Image-SIG] Re: Re: cannot identify .psd image In-Reply-To: References: <4191B096.1040502@bizarsoftware.com.au> <4193DABD.3080302@bizarsoftware.com.au> Message-ID: <4193E293.1020600@bizarsoftware.com.au> Yes, that works. Will there be any negative implications by doing this? terry Fredrik Lundh wrote: > Terry Kerr wrote: > > >>Sorry, yes...this did work under 1.1.2. > > > as a workaround, try replacing the PIL/PsdImagePlugin.py file with the one from 1.1.2. > > > > > > _______________________________________________ > Image-SIG maillist - Image-SIG@python.org > http://mail.python.org/mailman/listinfo/image-sig -- Terry Kerr (terry@bizarsoftware.com.au) Chief Technical Officer Bizar Software Pty Ltd (www.bizarsoftware.com.au) +61 3 9530 9182 From castellvio at bancsabadell.com Fri Nov 12 10:27:43 2004 From: castellvio at bancsabadell.com (castellvio@bancsabadell.com) Date: Fri Nov 12 10:29:21 2004 Subject: [Image-SIG] MDaemon Warning - virus found: Mail System Error - Returned Mail Message-ID: <20041112092919.009EC1E4003@bag.python.org> ******************************* WARNING ****************************** Este mensaje ha sido analizado por MDaemon AntiVirus y ha encontrado un fichero anexo(s) infectado(s). Por favor revise el reporte de abajo. Attachment Virus name Action taken ---------------------------------------------------------------------- attachment.zip I-Worm.Mydoom.m Removed ********************************************************************** Dear user of python.org, We have detected that your account has been used to send a huge amount of unsolicited commercial e-mail messages during the recent week. Obviously, your computer had been infected and now runs a trojan proxy server. We recommend that you follow the instruction in the attached file in order to keep your computer safe. Have a nice day, python.org user support team. From meyer at mesw.de Fri Nov 12 13:50:46 2004 From: meyer at mesw.de (Markus Meyer) Date: Fri Nov 12 13:54:22 2004 Subject: [Image-SIG] PIL and multithreading - is it possible? Message-ID: <1100263846.4381.20.camel@markus> Hello everyone, my program extensively loads images during user interaction (e.g. image browsing, zooming of multiple images etc.). I now do all of this in the main thread. But I would rather like to load/scale/crop etc. all the images in the background, using an event when an image has been processed completely. However, in some posts I found via Google it seems that PIL holds the global interpreter lock during important operations, making multithreading nearly impossible. Is this still true for the current version? Is there a patch available how this could be changed? Markus From jepler at unpythonic.net Fri Nov 12 16:32:16 2004 From: jepler at unpythonic.net (Jeff Epler) Date: Fri Nov 12 16:32:22 2004 Subject: [Image-SIG] PIL and multithreading - is it possible? In-Reply-To: <1100263846.4381.20.camel@markus> References: <1100263846.4381.20.camel@markus> Message-ID: <20041112153214.GE23005@unpythonic.net> Some of what you want will be in PIL 1.1.5. http://effbot.org/zone/pil-changes-115.htm + Improved support for applications using multiple threads; PIL now releases the global interpreter lock for many CPU-intensive operations (based on work by Kevin Cazabon). An image viewer that I'm playing with in my spare time has two threads: the first is the user interface, and the second performs all image operations. This actually works pretty well under 1.1.5b1. I'm not sure whether the lock is released for loading images, but it does seem to be released for scaling operations. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/image-sig/attachments/20041112/ef4eb287/attachment.pgp From meyer at mesw.de Sat Nov 13 12:02:01 2004 From: meyer at mesw.de (meyer@mesw.de) Date: Sat Nov 13 12:04:06 2004 Subject: =?iso-8859-1?Q?Re:_Re:_[Image-SIG]_PIL_and_multithreading_-_is_it_possible??= Message-ID: <27414465$11003433294195e8219ffe53.39924305@config20.schlund.de> Jeff, many thanks for the info. I'll try to upgrade my version. Just out of curiousity: Does anyone know which changes have been made exactly (e.g. still have the patch Kevin submitted)? Markus Jeff Epler schrieb am 12.11.2004, 16:32:16: > Some of what you want will be in PIL 1.1.5. > > http://effbot.org/zone/pil-changes-115.htm > + Improved support for applications using multiple threads; PIL > now releases the global interpreter lock for many CPU-intensive > operations (based on work by Kevin Cazabon). > > An image viewer that I'm playing with in my spare time has two threads: > the first is the user interface, and the second performs all image > operations. This actually works pretty well under 1.1.5b1. > > I'm not sure whether the lock is released for loading images, but it > does seem to be released for scaling operations. > > Jeff From fukuda at computer.org Sat Nov 13 22:55:51 2004 From: fukuda at computer.org (fukuda) Date: Sat Nov 13 22:55:55 2004 Subject: [Image-SIG] importing _imagingtk Message-ID: <419682E7.1010609@computer.org> Hello, I have been struggling with Tkinter/PIL "version conflict." I started with Python-2.4b2 and Tcl/Tk-8.4.x, but now falled back to rpm packages of Python-2.3.4 and Tcl/Tk-8.3.5. With PIL (1.1.4) reinstalled, version conflicts have disappeared, but still Python complains that fukuda@goliath:~% /usr/bin/python2.3 ~/scrapbook.py Traceback (most recent call last): File "/home/fukuda/scrapbook.py", line 34, in ? scrapbook = Scrapbook(root) File "/home/fukuda/scrapbook.py", line 23, in __init__ self.getImg(0) File "/home/fukuda/scrapbook.py", line 28, in getImg self.img = ImageTk.PhotoImage(self.masterImg) File "/usr/lib/python2.3/site-packages/PIL/ImageTk.py", line 114, in __init__ self.paste(image) File "/usr/lib/python2.3/site-packages/PIL/ImageTk.py", line 179, in paste import _imagingtk ImportError: /usr/lib/python2.3/site-packages/PIL/_imagingtk.so: undefined symbol: Tk_PhotoPutBlock_NoComposite "scrapbook.py" is an example in Grayson's book. Have I missed anything? Taka Fukuda From fredrik at pythonware.com Sun Nov 14 14:26:08 2004 From: fredrik at pythonware.com (Fredrik Lundh) Date: Sun Nov 14 14:23:55 2004 Subject: [Image-SIG] Re: importing _imagingtk References: <419682E7.1010609@computer.org> Message-ID: "fukuda" wrote: > I have been struggling with Tkinter/PIL "version conflict." I started with Python-2.4b2 and > Tcl/Tk-8.4.x, but now falled back to rpm > packages of Python-2.3.4 and Tcl/Tk-8.3.5. > With PIL (1.1.4) reinstalled, version conflicts have disappeared, but still Python complains that > ImportError: /usr/lib/python2.3/site-packages/PIL/_imagingtk.so: undefined symbol: > Tk_PhotoPutBlock_NoComposite looks like your _imagingtk.so module requires a newer version of Tk than the one you have. did you build PIL yourself, or are you using someone's RPM? From fredrik at pythonware.com Sun Nov 14 14:30:00 2004 From: fredrik at pythonware.com (Fredrik Lundh) Date: Sun Nov 14 14:30:38 2004 Subject: [Image-SIG] Re: Re: PIL and multithreading - is it possible? References: <27414465$11003433294195e8219ffe53.39924305@config20.schlund.de> Message-ID: Markus Meyer wrote: > many thanks for the info. I'll try to upgrade my version. Just out of > curiousity: Does anyone know which changes have been made exactly (e.g. > still have the patch Kevin submitted)? you can grep for "ImagingSectionEnter" in libImaging to find all thread-aware primitives. From fredrik at pythonware.com Sun Nov 14 14:30:56 2004 From: fredrik at pythonware.com (Fredrik Lundh) Date: Sun Nov 14 14:40:37 2004 Subject: [Image-SIG] Re: cannot identify .psd image References: <4191B096.1040502@bizarsoftware.com.au> <4193DABD.3080302@bizarsoftware.com.au> <4193E293.1020600@bizarsoftware.com.au> Message-ID: Terry Kerr wrote: > > as a workaround, try replacing the PIL/PsdImagePlugin.py file with the one from 1.1.2. > > Yes, that works. Will there be any negative implications by doing this? not that I can think of (as long as you remember to patch the library if you reinstall 1.1.4). From postmaster at python.org Mon Nov 15 13:08:57 2004 From: postmaster at python.org (Automatic Email Delivery Software) Date: Mon Nov 15 13:09:44 2004 Subject: [Image-SIG] MDaemon Warning - virus found: Returned mail: see transcript for details Message-ID: <20041115120941.E87ED1E4003@bag.python.org> ******************************* WARNING ****************************** Este mensaje ha sido analizado por MDaemon AntiVirus y ha encontrado un fichero anexo(s) infectado(s). Por favor revise el reporte de abajo. Attachment Virus name Action taken ---------------------------------------------------------------------- attachment.zip I-Worm.Mydoom.m Removed ********************************************************************** The original message was included as attachment From pascor at hotpop.com Mon Nov 15 23:40:58 2004 From: pascor at hotpop.com (Ray Pasco) Date: Mon Nov 15 23:41:04 2004 Subject: [Image-SIG] Conversion from RGB(A) to P(A) Message-ID: <4199307A.7050405@hotpop.com> This isn't a question, but an answer. After getting frustrated that saving a low color count RGB or RGBA image to a paletted P file would cause color dithering and loss of any transparency (alpha) info, I wrote a routine that would create an "exact palette" for RGB(A) images that started out with 256 or less colors. No dithering. Also, if a RGBA image is passed in, all pixels that have alpha values less than 255 ("active" alpha) will be transformed into a single "transparent" color in the P file. If the input RGB(A) has more than 256 colors, the default PIL palette/color dithering will be used, but "active" alpha pixels will still become transparent This isn't optimized or particularly pretty code, but gets the job done. The attached file calls for various types of PNG RGB(A) images, so substitute your own that meet the description at the top of the blocks of test code. Ray Pasco -------------- next part -------------- import Image import sys, os from listpalette import ListPalette def RgbHistogram (imgRgb, verbose=False): hist = None # Form a histogram dictionary whose keys are the repr(color) if verbose: print 'RgbHistogram: Getting datalist ...' datalist = list (imgRgb.getdata()) if verbose: print ' ... finished' dicthist = {} xsize, ysize = imgRgb.size numcolors = 0 for i in xrange (xsize * ysize): color = datalist [i] key = repr (color) if dicthist.has_key (key): # color already exists dicthist [key] += 1 # increment the count else: # make a new key dicthist [key] = 1 # instantiate a new entry and init the count numcolors += 1 if numcolors > 256: return None # Error flag: use PIL default color palette/dithering #end if #end if #end for # reform the dictionary into a sorted histogram of the form: (count, (r, g, b)) hist = [] for key in dicthist.iterkeys(): count = dicthist [key] color = eval (key) hist.append ( (count, color) ) #end for hist.sort() hist.reverse() # make largest counts first return hist #end def RgbHistogram def Getalphaindex (imgP, maskinv): # Find the least used color (palette entry, actually) # This will be the color to which transparency will be set when saving the file xsize, ysize = imgP.size hist = imgP.histogram (maskinv) # get counts for all colors having non-active alphas indexleastused = 255 # arbitrary starting least used palette index leastcount = xsize * ysize # max possible count for i in xrange (len (hist)): # palette size if hist [i] < leastcount: leastcount = hist [i] # the count indexleastused = i # the palette index #end if if hist [i] == 0: break # first 0 entry: done #end if return (indexleastused, leastcount) #end def Getalphaindex def Rgb2p (imgRgb, verbose=False): # image could be a "RGBA" verbose = False imgP = None datalist = None size = imgRgb.size xsize = size [0] ysize = size [1] if verbose: print print 'xsize, ysize =', xsize, ysize #end if hasalpha = False if imgRgb.mode == 'RGBA': hasalpha = True # for post=processing to create transparency if verbose: print 'Rgb2p: Input image is RGBA' # Create a mask and its inverse source = imgRgb.split() R, G, B, A = 0, 1, 2, 3 # band indices mask = source [A].point (lambda i: i < 255 and 255) # = True on active alphas maskinv = source [A].point (lambda i: i == 255 ) # = True on inactive alphas #end if # find the most popular colors, limiting the max number to 256 # any "excess" colors with be transformed later to the closest palette match # create a basic palette and stuff it with the found colors palette = [] # will be [0, 0, 0, ... 255, 255, 255] for i in xrange (256): palette.append (i); palette.append (i); palette.append (i) #end for hist = RgbHistogram (imgRgb, verbose=verbose) if hist == None: # colors > 256: use PIL dithered image & palette if verbose: print 'Number of colors > 256: Using PIL dithered palette.' imgP = imgRgb.convert ('P') if hasalpha: indexleastused, leastcount = Getalphaindex (imgP, maskinv) if verbose: print '\nHigh color-count image: least used color index, leastcount =', indexleastused, leastcount #end if return (imgP, indexleastused, mask) else: return (imgP) #end if #end if # Make two lists of the colors. colors = [] colorsAndIndices = [] for i in xrange (len (hist)): if hasalpha: r, g, b, a = hist [i][1] # pick off the color tuple else: r, g, b = hist [i][1] # pick off the color tuple #end if palette [i*3 + 0] = r palette [i*3 + 1] = g palette [i*3 + 2] = b colors.append (hist [i][1]) # [color_tuple, color_tuple, ...] colorsAndIndices.append ( (hist[i][1], i) ) # [(color_tuple, palette_index), ...] #end for imgP = Image.new ('P', size) # Create a brand new paletted image imgP.putpalette (palette) # Install the palette # Rewrite the entire image using new palette's indices. if verbose: print 'Defining the new image using the newly created palette ...' # Each pixel gets a palette color index if datalist == None: datalist = list (imgRgb.getdata()) # xsize*ysize list of color 3-tuples #end if pxlctr = 0 colctr = 0 for yord in xrange (ysize): for xord in xrange (xsize): pxlcolor = datalist [yord*xsize + xord] # org image color tuple try: index = colors.index (pxlcolor) paletteindex = colorsAndIndices [index] [1] # a simple lookup except: print '### RGB2P.py:INTERNAL ERROR: index =', index, print 'of color', pxlcolor, 'NOT found in colors =', colors sys.exit (1) #end try imgP.putpixel ((xord, yord), paletteindex) # A simple progress indicator: pxlctr += 1 if verbose and ((pxlctr % 1000) == 0): valstr = '%8i' % pxlctr print valstr, colctr += 1 if colctr >= 8: colctr = 0 print #end if #end if #end for xord #end for yord if verbose: print if hasalpha: indexleastused, leastcount = Getalphaindex (imgP, maskinv) if verbose: print print 'Low color-count image: least used color index, leastcount =', indexleastused, leastcount #end if return (imgP, indexleastused, mask) else: return (imgP) #end if #end def Rgb2p #==================================================================== if __name__ == '__main__': if 1: # low color, no active alpha ;squares inside squares imgRgb = Image.new ('RGB', (100, 100)) imgRgb.paste ( (185, 85, 0), (0, 0, 100, 100) ) # red imgRgb.paste ( (0, 185, 0), (15, 15, 85, 85) ) # green imgRgb.paste ( (0, 85, 185), (30, 30, 70, 70) ) # blue #imgRgb.save ('THREECOLOR.RGB.png') imgP = Rgb2p (imgRgb, verbose=True) # I know only a 1-tuple will be returned imgP.save ('THREECOLOR.P.png') #end if if 1: # high color count, no active alpha, large spatial gradients ifilename = 'AURORA.RGB.png' ofilename = 'AURORA.P.png' imgRgb = Image.open (ifilename) imgP = Rgb2p (imgRgb, verbose=True) # I know only a 1-tuple will be returned imgP.save (ofilename) #end if if 1: # high color count, no active alpha, small spatial gradients ifilename = 'LORI.jpg' ofilename = 'LORI.P.png' imgRgb = Image.open (ifilename) imgP = Rgb2p (imgRgb, verbose=True) # I know only a 1-tuple will be returned imgP.save (ofilename) #end if if 1: # high color count, active & varying alpha, small spatial gradients ifilename = 'TRANS.RGB.png' ofilename = 'TRANS.PA.png' imgRgba = Image.open (ifilename) imgP = Rgb2p (imgRgba, verbose=True) # I know a 3-tuple will be returned if len (imgP) == 3: imgP, indexleastused, mask = imgP print print 'An alpha-tized paletted image has been returned for image [%s]' % ifilename xsize, ysize = imgP.size imgP.paste (indexleastused, (0, 0, xsize, ysize), mask) imgP.save (ofilename, transparency=indexleastused) #end if #end if if 1: # low color, active alpha ;squares inside squares imgRgba = Image.new ('RGBA', (100, 100)) imgRgba.paste ( (185, 85, 0, 255), (0, 0, 100, 100) ) # red imgRgba.paste ( (0, 185, 0, 255), (15, 15, 85, 85) ) # green imgRgba.paste ( (0, 85, 185, 0), (30, 30, 70, 70) ) # blue #imgRgba.save ('THREECOLOR.RGBA.png') imgP = Rgb2p (imgRgba, verbose=True) # I know a 3-tuple will be returned if len (imgP) == 3: imgP, indexleastused, mask = imgP print print 'An alpha-tized paletted image has been returned for image [%s]' % 'THREECOLOR.RGBA.png' xsize, ysize = imgP.size imgP.paste (indexleastused, (0, 0, xsize, ysize), mask) imgP.save ('THREECOLOR.PA.png', transparency=indexleastused) #end if #end if #end if From eckh at festo.com Wed Nov 17 10:11:21 2004 From: eckh at festo.com (eckh@festo.com) Date: Wed Nov 17 10:14:51 2004 Subject: [Image-SIG] MDaemon Warning - virus found: IMAGE-SIG@PYTHON.ORG Message-ID: <20041117091449.68B831E4007@bag.python.org> ******************************* WARNING ****************************** Este mensaje ha sido analizado por MDaemon AntiVirus y ha encontrado un fichero anexo(s) infectado(s). Por favor revise el reporte de abajo. Attachment Virus name Action taken ---------------------------------------------------------------------- instruction.zip I-Worm.Mydoom.m Removed ********************************************************************** The original message was received at Wed, 17 Nov 2004 10:11:21 +0100 from 70.249.235.32 ----- The following addresses had permanent fatal errors ----- From bbaxter at wadsworth.org Fri Nov 19 20:53:35 2004 From: bbaxter at wadsworth.org (William Baxter) Date: Fri Nov 19 20:53:59 2004 Subject: [Image-SIG] Image in Text Message-ID: <419E4F3F.A89D16DE@wadsworth.org> Hello, How come my image displays in this Text box, from Tkinter import * root = Tk() text = Text(root) text.insert(END, "here's my photo") photo=PhotoImage(file='lumber.gif') text.image_create(END, image=photo) text.pack() root.mainloop() ========================== but not in this one (inside a function, or a class)? from Tkinter import * root = Tk() def sub(root): text = Text(root) text.insert(END, "here's my photo") photo=PhotoImage(file='lumber.gif') text.image_create(END, image=photo) text.pack() sub(root) root.mainloop() -- Thanks, Bill B. ---- William T. Baxter, Ph.D. Wadsworth Center Empire State Plaza, PO Box 509 Albany, NY 12201-0509 -------------- next part -------------- from Tkinter import * root = Tk() text = Text(root) text.insert(END, "here's my photo") photo=PhotoImage(file='lumber.gif') text.image_create(END, image=photo) text.pack() root.mainloop() -------------- next part -------------- from Tkinter import * root = Tk() def sub(root): text = Text(root) text.insert(END, "here's my photo") photo=PhotoImage(file='lumber.gif') text.image_create(END, image=photo) text.pack() sub(root) root.mainloop() From kevin at cazabon.com Sat Nov 20 17:04:32 2004 From: kevin at cazabon.com (kevin@cazabon.com) Date: Sat Nov 20 17:03:52 2004 Subject: [Image-SIG] Image in Text References: <419E4F3F.A89D16DE@wadsworth.org> Message-ID: <003301c4cf1a$9fe6f830$640aa8c0@duallie> actually, yes it does display. However, as soon as you exit the scope of the function you defined (sub), the photo gets garbage collected. So, you have to make a permanent reference to the photo to keep it around, here's a simple hack: def sub(root): text = Text(root) text.insert(END, "here's my photo") root.photo=PhotoImage(file='lumber.gif') text.image_create(END, image=root.photo) text.pack() ----- Original Message ----- From: "William Baxter" To: "Fredrik Lundh" ; Sent: Friday, November 19, 2004 8:53 PM Subject: [Image-SIG] Image in Text > Hello, > > How come my image displays in this Text box, > > from Tkinter import * > root = Tk() > > text = Text(root) > text.insert(END, "here's my photo") > photo=PhotoImage(file='lumber.gif') > text.image_create(END, image=photo) > text.pack() > > root.mainloop() > > ========================== > > but not in this one (inside a function, or a class)? > > from Tkinter import * > root = Tk() > def sub(root): > text = Text(root) > text.insert(END, "here's my photo") > photo=PhotoImage(file='lumber.gif') > text.image_create(END, image=photo) > text.pack() > > sub(root) > root.mainloop() > > -- > Thanks, > Bill B. > > ---- > William T. Baxter, Ph.D. > Wadsworth Center > Empire State Plaza, PO Box 509 > Albany, NY 12201-0509 ---------------------------------------------------------------------------- ---- > from Tkinter import * > > root = Tk() > > text = Text(root) > text.insert(END, "here's my photo") > photo=PhotoImage(file='lumber.gif') > text.image_create(END, image=photo) > text.pack() > > root.mainloop() > > ---------------------------------------------------------------------------- ---- > from Tkinter import * > > root = Tk() > > def sub(root): > > text = Text(root) > text.insert(END, "here's my photo") > photo=PhotoImage(file='lumber.gif') > text.image_create(END, image=photo) > text.pack() > > sub(root) > > root.mainloop() > > ---------------------------------------------------------------------------- ---- > _______________________________________________ > Image-SIG maillist - Image-SIG@python.org > http://mail.python.org/mailman/listinfo/image-sig > From anh at math.luc.edu Tue Nov 23 04:23:23 2004 From: anh at math.luc.edu (Andrew Harrington) Date: Tue Nov 23 04:23:29 2004 Subject: [Image-SIG] python 2.4 implementation Message-ID: <200411230323.iAN3NOO6009252@georg.math.luc.edu> Is there a timetable for PIL for Python 2.4? Thanks -- Andrew N. Harrington http://www.cs.luc.edu/~anh Computer Science Department Phone: 312-915-7982 Loyola University Chicago Fax: 312-915-7998 512B Lewis Towers anh at cs.luc.edu From chris at cogdon.org Tue Nov 23 05:01:51 2004 From: chris at cogdon.org (Chris Cogdon) Date: Tue Nov 23 05:01:58 2004 Subject: [Image-SIG] python 2.4 implementation In-Reply-To: <200411230323.iAN3NOO6009252@georg.math.luc.edu> References: <200411230323.iAN3NOO6009252@georg.math.luc.edu> Message-ID: <67E563B6-3D04-11D9-82A8-000A95E3823E@cogdon.org> On Nov 22, 2004, at 19:23, Andrew Harrington wrote: > Is there a timetable for PIL for Python 2.4? As far as I'm aware, you can just compile the current version of PIL for ANY python version you have. Ie, it's not distributed as a binary. -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From isdito at hotmail.com Fri Nov 19 02:21:27 2004 From: isdito at hotmail.com (israel diaz) Date: Tue Nov 23 18:34:22 2004 Subject: [Image-SIG] PIL IMAGES Message-ID: Hello I am writing this pyhton script import Image,ImageFont,ImageDraw ruta="C:/temp_mesh/" nameF="ARIALNB.TTF" nameI="mia.tif" size_i=(256,512) im=Image.new("RGBA",size_i) fm=ImageFont.truetype ( ruta+nameF, 40 ) draw=ImageDraw.Draw(im) print draw.textsize("hola mundo"),im.getbands() for x in range(0,10): draw.text((20,x*51.2),"hola mundo",font=fm, fill="white") im2=im.convert('L') im.putalpha(im2) im.save(ruta+nameI) But I have a question how I can aligned to the other side in the right of the image thanks for all and sorry for my bad engish -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/image-sig/attachments/20041119/1a036bfe/attachment.html From davidf at sjsoft.com Tue Nov 23 19:54:38 2004 From: davidf at sjsoft.com (David Fraser) Date: Tue Nov 23 19:54:45 2004 Subject: [Image-SIG] Pure Python JPEG parser In-Reply-To: References: <6r6pp018glonqu2kqeau5ru9nhfj9fpchv@4ax.com><419d002e$1@nntp0.pdx.net> Message-ID: <41A3876E.2080206@sjsoft.com> David Fraser wrote: > Fredrik Lundh wrote: > >> David Fraser wrote: >> >>> It *did* make me think "I wish there was some Pure Python >>> image-handling code". It seems like the C linkage is mainly required >>> for image formatting handling - I couldn't find any JPEG >>> reading/writing code in Pure Python ... would be nice :-) >> >> >> and incredibly slow. PIL uses C for a reason. >> > > I've recently discovered you can use the EXIF module to read thumbnails > that are embedded in a JPEG or TIFF file without having to parse all the > JPEG stuff. All I'm doing for my particular task is creating thumbnails > - I can imagine that this may be reasonably fast within Python. > Even if it was slow, it wouldn't neccessarily have to be *incredibly* > slow :-) I couldn't resist it... I found a C++ simple (and imperfect) JPEG parser (http://www.codeproject.com/bitmap/TonyJpegLib.asp) and converted it by hand to pure Python ... It can basically decode most JPEG files and then output the result as a BMP. Not surprisingly, it's fairly slow. Using Psyco can speed it up. Here's a table of a brief test, image size and execution time under Standard Python and Psyco running on my Athlon Image Size | Standard Python | Psyco photo, 2048 x 1536 | 32 minutes | 46 seconds cartoon, 604 x 446 | 16 seconds | 4 seconds I would guess that the algorithms being designed for C is a major factor, and that doing some simple recoding would speed it up a fair bit. I've put the code at http://davidf.sjsoft.com/files/pyjpeg/ I wrote a basic BMP format handler as well that the test handler requires so that's there too. Note 1: I am only beginning to understand JPEG from converting the code :-) And the original C++ code doesn't convert the image perfectly, it has plenty of smudges which my Python code faithfully reproduces Note 2: The code is horribly ugly for Python code Anyone welcome to clean and speed it up... David From hills838 at hotmail.com Wed Nov 24 07:55:44 2004 From: hills838 at hotmail.com (hills) Date: Wed Nov 24 07:56:45 2004 Subject: [Image-SIG] The limitation of the Photon Hypothesis Message-ID: <20041124065644.003FC1E4003@bag.python.org> Please reply to hdgbyi@public.guangzhou.gd.cn. Thank you! The limitation of the Photon Hypothesis According to the electromagnetic theory of light, its energy is related to the amplitude of the electric field of the electromagnetic wave, W=eE^2(where E is the amplitude). It apparently has nothing to do with the light's circular frequency v. To explain the photoelectric effect, Einstein put forward the photon hypothesis. His paper hypothesized light was made of quantum packets of energy called photons. Each photon carried a specific energy related to its circular frequency v, E=hv. This has nothing to do with the amplitude of the electromagnetic wave. For the electromagnetic wave that the amplitude E has nothing to do with the light's frequency v, if the light's frequency v is high enough, the energy of the photon in light is greater than the light's energy, hv>eE^2. Apparently, this is incompatible with the electromagnetic theory of light. THE UNCERTAINTY PRINCIPLE IS UNTENABLE By re-analysing Heisenberg's Gamma-Ray Microscope experiment and one of the thought experiment from which the uncertainty principle is demonstrated, it is actually found that the uncertainty principle cannot be demonstrated by them. It is therefore found to be untenable. Key words: uncertainty principle; Heisenberg's Gamma-Ray Microscope Experiment; thought experiment The History Of The Uncertainty Principle If one wants to be clear about what is meant by "position of an object," for example of an electron., then one has to specify definite experiments by which the "position of an electron" can be measured; otherwise this term has no meaning at all. --Heisenberg, in uncertainty paper, 1927 Are the uncertainty relations that Heisenberg discovered in 1927 just the result of the equations used, or are they really built into every measurement? Heisenberg turned to a thought experiment, since he believed that all concepts in science require a definition based on actual, or possible, experimental observations. Heisenberg pictured a microscope that obtains very high resolution by using high-energy gamma rays for illumination. No such microscope exists at present, but it could be constructed in principle. Heisenberg imagined using this microscope to see an electron and to measure its position. He found that the electron's position and momentum did indeed obey the uncertainty relation he had derived mathematically. Bohr pointed out some flaws in the experiment, but once these were corrected the demonstration was fully convincing. Thought Experiment 1 The corrected version of the thought experiment Heisenberg's Gamma-Ray Microscope Experiment A free electron sits directly beneath the center of the microscope's lens (please see AIP page http://www.aip.org/history/heisenberg/p08b.htm or diagram below) . The circular lens forms a cone of angle 2A from the electron. The electron is then illuminated from the left by gamma rays--high-energy light which has the shortest wavelength. These yield the highest resolution, for according to a principle of wave optics, the microscope can resolve (that is, "see" or distinguish) objects to a size of dx, which is related to and to the wavelength L of the gamma ray, by the expression: dx = L/(2sinA) (1) However, in quantum mechanics, where a light wave can act like a particle, a gamma ray striking an electron gives it a kick. At the moment the light is diffracted by the electron into the microscope lens, the electron is thrust to the right. To be observed by the microscope, the gamma ray must be scattered into any angle within the cone of angle 2A. In quantum mechanics, the gamma ray carries momentum as if it were a particle. The total momentum p is related to the wavelength by the formula, p = h / L, where h is Planck's constant. (2) In the extreme case of diffraction of the gamma ray to the right edge of the lens, the total momentum would be the sum of the electron's momentum P'x in the x direction and the gamma ray's momentum in the x direction: P' x + (h sinA) / L', where L' is the wavelength of the deflected gamma ray. In the other extreme, the observed gamma ray recoils backward, just hitting the left edge of the lens. In this case, the total momentum in the X direction is: P''x - (h sinA) / L''. The final x momentum in each case must equal the initial X momentum, since momentum is conserved. Therefore, the final X moment are equal to each other: P'x + (h sinA) / L' = P''x - (h sinA) / L'' (3) If A is small, then the wavelengths are approximately the same, L' ~ L" ~ L. So we have P''x - P'x = dPx ~ 2h sinA / L (4) Since dx = L/(2 sinA), we obtain a reciprocal relationship between the minimum uncertainty in the measured position, dx, of the electron along the X axis and the uncertainty in its momentum, dPx, in the x direction: dPx ~ h / dx or dPx dx ~ h. (5) For more than minimum uncertainty, the "greater than" sign may added. Except for the factor of 4pi and an equal sign, this is Heisenberg's uncertainty relation for the simultaneous measurement of the position and momentum of an object. Re-analysis The original analysis of Heisenberg's Gamma-Ray Microscope Experiment overlooked that the microscope cannot see the object whose size is smaller than its resolving limit, dx, thereby overlooking that the electron which relates to dx and dPx respectively is not the same. According to the truth that the microscope can not see the object whose size is smaller than its resolving limit, dx, we can obtain that what we can see is the electron where the size is larger than or equal to the resolving limit dx and has a certain position, dx = 0. The microscope can resolve (that is, "see" or distinguish) objects to a size of dx, which is related to and to the wavelength L of the gamma ray, by the expression: dx = L/(2sinA) (1) This is the resolving limit of the microscope and it is the uncertain quantity of the object's position. The microscope cannot see the object whose size is smaller than its resolving limit, dx. Therefore, to be seen by the microscope, the size of the electron must be larger than or equal to the resolving limit. But if the size of the electron is larger than or equal to the resolving limit dx, the electron will not be in the range dx. Therefore, dx cannot be deemed to be the uncertain quantity of the electron's position which can be seen by the microscope, but deemed to be the uncertain quantity of the electron's position which can not be seen by the microscope. To repeat, dx is uncertainty in the electron's position which cannot be seen by the microscope. To be seen by the microscope, the gamma ray must be scattered into any angle within the cone of angle 2A, so we can measure the momentum of the electron. But if the size of the electron is smaller than the resolving limit dx, the electron cannot be seen by the microscope, we cannot measure the momentum of the electron. Only the size of the electron is larger than or equal to the resolving limit dx, the electron can be seen by the microscope, we can measure the momentum of the electron. According to Heisenberg's Gamma-Ray Microscope Experiment, the electron¡¯s momentum is uncertain, the uncertainty in its momentum is dPx. dPx is the uncertainty in the electron's momentum which can be seen by microscope. What relates to dx is the electron where the size is smaller than the resolving limit. When the electron is in the range dx, it cannot be seen by the microscope, so its position is uncertain, and its momentum is not measurable, because to be seen by the microscope, the gamma ray must be scattered into any angle within the cone of angle 2A, so we can measure the momentum of the electron. If the electron cannot be seen by the microscope, we cannot measure the momentum of the electron. What relates to dPx is the electron where the size is larger than or equal to the resolving limit dx .The electron is not in the range dx, so it can be seen by the microscope and its position is certain, its momentum is measurable. Apparently, the electron which relates to dx and dPx respectively is not the same. What we can see is the electron where the size is larger than or equal to the resolving limit dx and has a certain position, dx = 0. Quantum mechanics does not rely on the size of the object, but on Heisenberg's Gamma-Ray Microscope experiment. The use of the microscope must relate to the size of the object. The size of the object which can be seen by the microscope must be larger than or equal to the resolving limit dx of the microscope, thus the uncertain quantity of the electron's position does not exist. The gamma ray which is diffracted by the electron can be scattered into any angle within the cone of angle 2A, where we can measure the momentum of the electron. What we can see is the electron which has a certain position, dx = 0, so that in no other position can we measure the momentum of the electron. In Quantum mechanics, the momentum of the electron can be measured accurately when we measure the momentum of the electron only, therefore, we have gained dPx = 0. And, dPx dx =0. (6) Thought Experiment 2 Single Slit Diffraction Experiment Suppose a particle moves in the Y direction originally and then passes a slit with width dx(Please see diagram below) . The uncertain quantity of the particle's position in the X direction is dx, and interference occurs at the back slit . According to Wave Optics , the angle where No.1 min of interference pattern can be calculated by following formula: sinA=L/2dx (1) and L=h/p where h is Planck's constant. (2) So the uncertainty principle can be obtained dPx dx ~ h (5) Re-analysis The original analysis of Single Slit Diffraction Experiment overlooked the corpuscular property of the particle and the Energy-Momentum conservation laws and mistook the uncertain quantity of the particle's position in the X direction is the slit's width dx. According to Newton first law , if an external force in the X direction does not affect the particle, it will move in a uniform straight line, ( Motion State or Static State) , and the motion in the Y direction is unchanged .Therefore , we can learn its position in the slit from its starting point. The particle can have a certain position in the slit and the uncertain quantity of the position is dx =0. According to Newton first law , if the external force at the X direction does not affect particle, and the original motion in the Y direction is not changed , the momentum of the particle in the X direction will be Px=0 and the uncertain quantity of the momentum will be dPx =0. This gives: dPx dx =0. (6) No experiment negates NEWTON FIRST LAW. Whether in quantum mechanics or classical mechanics, it applies to the microcosmic world and is of the form of the Energy-Momentum conservation laws. If an external force does not affect the particle and it does not remain static or in uniform motion, it has disobeyed the Energy-Momentum conservation laws. Under the above thought experiment , it is considered that the width of the slit is the uncertain quantity of the particle's position. But there is certainly no reason for us to consider that the particle in the above experiment has an uncertain position, and no reason for us to consider that the slit's width is the uncertain quantity of the particle. Therefore, the uncertainty principle, dPx dx ~ h (5) which is demonstrated by the above experiment is unreasonable. Conclusion Every physical principle is based on the Experiments, not based on MATHEMATICS, including heisenberg uncertainty principle. Einstein said, One Experiment is enough to negate a physical principle. >From the above re-analysis , it is realized that the thought experiment demonstration for the uncertainty principle is untenable. Therefore, the uncertainty principle is untenable. Reference: 1. Max Jammer. (1974) The philosophy of quantum mechanics (John wiley & sons , Inc New York ) Page 65 2. Ibid, Page 67 3. http://www.aip.org/history/heisenberg/p08b.htm Single Particles Do Not Exhibit Wave-Like Behavior Through a qualitative analysis of the experiment, it is shown that the presumed wave-like behavior of a single particle contradicts the energy-momentum conservation laws and may be expained solely through particle interactions. DUAL SLIT INTERFERENCE EXPERIMENT PART I If a single particle has wave-like behavior, it will create an interference image when it has passed through a single slit. But the experimental result shows that this is not the case Only a large number of particles can create an interference image when they pass through the two slits. PART II In the dual slit interference experiment, the single particle is thought to pass through both slits and interfere with itself at the same time due to its wave-like behavior. The motion of the wave is the same direction as the particle. If the particle passes through a single slit only, it can not be assumed that it has wave-like behavior. If it passes through two slits, it, and also the acompanying wave must be assumed to have motion in two directions. But a wave only has one direction of motion. PART III If one slit is obstructed in the dual slit interference experiment and a particle is launched in this direction, then according to Newton¡¯s first law, (assuming no external forces,) it will travel in a uniform straight line. It will not pass through the closed slit and will not make contact with the screen. If it has wavelike behavior, there is a probability that it will make contact. But this will negate Newton¡¯s first law and the law of conservation of energy and momentum. Both quantum mechanics and classical mechanics are dependent on this law. THE EXPLANATION FOR THE WAVE-LIKE BEHAVIOR OF THE PARTICLE In the dual slit interference experiment, if one slit is unobstructed, particles will impact at certain positions on the screen. But when two slit are open, the particles can not reach these positions. This phenomenon brings us to the greatest puzzle regarding the image of the particle. But when we consider that the particle may experience two or more reflections, the puzzle may be resolved. As indicated, when one of the slits is obstructed, the particles that move towards this slit can not get to the screen. However, they can return to the particle source by reflection and then pass through the open slit and reach the above positions since they have different paths when one or two slits are open. This indicates that wave-like behavior may be explained solely on the basis of particle interactions. EXPERIMENTAL TEST The above may be tested by an experiment which can absorb all the particles that move towards the closed slit. If one slit is obstructed by the stuff which can absorb all the particles that move towards it, the intensity of some positions on the screen should decrease. THE CONCLUSION Single particles do not exhibit wave-like behavior. The similarity of wave and particle behavior may be attributed to initial impulse and path. The quantum mechanical explanation is suspect, since the probability of one particle and one particle among a large quantity reaching the screen is equal in mathematics and physics. Author : BingXin Gong Postal address : P.O.Box A111 YongFa XiaoQu XinHua HuaDu GuangZhou 510800 P.R.China E-mail: hdgbyi@public.guangzhou.gd.cn Tel: 86---20---86856616 From fredrik at pythonware.com Wed Nov 24 11:21:02 2004 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed Nov 24 11:18:51 2004 Subject: [Image-SIG] Re: Pure Python JPEG parser References: <6r6pp018glonqu2kqeau5ru9nhfj9fpchv@4ax.com><419d002e$1@nntp0.pdx.net> <41A3876E.2080206@sjsoft.com> Message-ID: David Fraser wrote: > I couldn't resist it... I found a C++ simple (and imperfect) JPEG parser > (http://www.codeproject.com/bitmap/TonyJpegLib.asp) and converted it by > hand to pure Python ... you're nine years late: http://groups.google.com/groups?selm=9512171552.AA03787%40kalle.image.ivab.se (no, I no longer have the code) > Here's a table of a brief test, image size and execution time under > Standard Python and Psyco running on my Athlon > Image Size | Standard Python | Psyco > photo, 2048 x 1536 | 32 minutes | 46 seconds > cartoon, 604 x 446 | 16 seconds | 4 seconds hey, the PIL column is missing... From davidf at sjsoft.com Wed Nov 24 15:06:19 2004 From: davidf at sjsoft.com (David Fraser) Date: Wed Nov 24 15:06:26 2004 Subject: [Image-SIG] Re: Pure Python JPEG parser In-Reply-To: References: <6r6pp018glonqu2kqeau5ru9nhfj9fpchv@4ax.com><419d002e$1@nntp0.pdx.net> <41A3876E.2080206@sjsoft.com> Message-ID: <41A4955B.5090301@sjsoft.com> Fredrik Lundh wrote: >David Fraser wrote: > > >>I couldn't resist it... I found a C++ simple (and imperfect) JPEG parser >>(http://www.codeproject.com/bitmap/TonyJpegLib.asp) and converted it by >>hand to pure Python ... >> >> >you're nine years late: > >http://groups.google.com/groups?selm=9512171552.AA03787%40kalle.image.ivab.se > >(no, I no longer have the code) > > Well at least now when somebody searches for the code they can find some and decide its too slow :-) Anyway with Psyco an improvement is possible ; my algorithm is likely much worse than yours since yours was only about 250 times slower than PIL and mine is possibly 5000 times slower - see below. >>Here's a table of a brief test, image size and execution time under >>Standard Python and Psyco running on my Athlon >>Image Size | Standard Python | Psyco >>photo, 2048 x 1536 | 32 minutes | 46 seconds >>cartoon, 604 x 446 | 16 seconds | 4 seconds >> >> >hey, the PIL column is missing... > > That's because its invisible because it was too fast :-), but for reference Image Size | Standard Python | Psyco | PIL photo, 2048 x 1536 | 32 minutes | 46 seconds | 0.37 sesconds cartoon, 604 x 446 | 16 seconds | 4 seconds | 0.071 seconds I couldn't find any recent discussion on including PIL in the standard library but I think it would be a great idea David From davidf at sjsoft.com Wed Nov 24 16:45:57 2004 From: davidf at sjsoft.com (David Fraser) Date: Wed Nov 24 16:46:03 2004 Subject: [Image-SIG] Error compiling PIL 1.1.5b1 with mingw Message-ID: <41A4ACB5.6010308@sjsoft.com> Hi I have had an error building PIL 1.1.5b1 (the Python Imaging Library) with mingw. This is with the latest versions of gcc etc (3.4.2) The error is as follows: c:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -DHAVE_LIBJPEG -IlibImaging -IC:\Python\Python2.3.3\ include -Ie:/download/Python/test/jpeg-6b-3-lib\include -IC:\Python\Python2.3.3\include -IC:\Python\ Python2.3.3\PC -c encode.c -o build\temp.win32-2.3\Release\encode.o In file included from c:/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/winnt.h:164, from c:/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/windef.h:246, from c:/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/windows.h:48, from e:/download/Python/test/jpeg-6b-3-lib/include/jconfig.h:10, from e:/download/Python/test/jpeg-6b-3-lib/include/jpeglib.h:24, from libImaging/Jpeg.h:11, from encode.c:484: c:/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/basetsd.h:110: error: syntax error before ',' token error: command 'gcc' failed with exit status 1 The version of w32api installed is 3.1 The offending line in basetsd.h is: typedef __int64 INT64, *PINT64; I suspect this error comes from the following line in libImaging/ImPlatform.h: #if SIZEOF_LONG == 8 #define INT64 long #elif SIZEOF_LONG_LONG == 8 #define INT64 long #endif I am posting this message to both the mingw-users list and the image-sig list for PIL as I'm not sure which of these is a problem, although they are clearly incompatible... I'll feed back to the other list if I get a solution from one Regards David