[Image-SIG] PIL 1.1.6, python 64bit on Windows XP x64
Tim.Swan at disney.com
Thu Mar 5 19:23:57 CET 2009
I've been trying to get PIL 1.1.6 working on python 64bit:
Python version : 2.5.2 (r252:60911, Feb 21 2008, 13:17:27) [MSC v.1400
64 bit (AMD64)]
OS : Windows XP Professional x64 SP2.
The installer on the main download page appears to only be valid for
32bit python, causing a variety of import errors when used with 64bit
Is there any plan to provide an installer for 64bit versions of python
on 64 bit Windows in the future?
I've sucessfully built a version locally with DevStudio 2005, including
zlib and jpeg-6b support. I'll detail the steps required later for
posterity, it may be useful for someone browsing this forum at a later
time - I have no plans to provide an installer myself!
I did have to work around an issue, which I thought was worth raising
to you folks, in case there was a better way to fix this.
After building locally (setup.py build, setup.py install) and importing
PIL.Image, the quick test detailed below caused my python process to
Im = PIL.Image.open('my_image.gif')
Im2 = im.rotate(45)
At the point of saving, the process crashes with a windows IO exception.
Digging into the python, and then into the C extension code, I found the
problem appears to be due to some conflict with using the file
descriptor that's being passed into _encode_to_file (encode.c) from
_save in ImageFile.py (line 492 in ImageFile.py in the source I'm
looking at). After trying various different things, I found that I could
not use the file descriptor int (acquired via fp.fileno(), line 469 in
ImageFile.py) passed into encode_to_file - trying to write to a file
using that file descriptor was causing the crash (for example, line 164
in encode.c). I tried using _rdinfo to convert the file descriptor to a
FILE pointer, and work with that, but that crashed in _rdinfo, and I
tried a couple of different conversions using calls like _get_osfhandle
, but pretty much everything I tried continued to cause crashes. My
knowledge of Windows is pretty minimal, so I've no idea why using that
file descriptor should be problematic (and, presumably, works just fine
with the 32bit python version).
After taking a step back, I realised that the code in ImageFile has two
paths, and by putting a forced call to raise an AttributeError around
line 469 caused the _save function to take the top code path, and this
works just fine for me. I ended up modifying the code to look like this:
Line 467, ImageFile.py
# FIXME: force an AttributeError exception to use the python
file-compatible object path
fh = fp.fileno()
It's not clean, but it appears to work. Anyone got any ideas why? Can
someone suggest a cleaner way of doing this?
If anyone is interested, here's the steps I followed to get PIL 1.1.6
working locally for me - DevStudio 2005 required.
Step 1: unarchive the source to a location locally, I'll refer to this
as the build root directory (in my case, c:\temp\Imaging-1.1.6)
Step 2: run the visual studio 2005 command prompt for the relevant bits
of the OS
(in my case from Windows start menu: Programs -> (somewhere) ->
Microsoft Visual Studio 2005 -> Visual Studio Tools -> Visual Studio
2005 x64 Win64 Command Prompt
Step 3: set up the following environment variables at the command prompt
Step 4: edit ImageFile.py as described above
Step 5: (optional) edit setup.py to point to the correct locations for
zlib, jpeg-6b, etc. source and built libs
Step 6 : build PIL using "setup.py build" in the build root directory.
(it's worth at this point confirming that you're running setup.py with
the correct (64bit) version of python - slap a pdb break in there and
check sys.version if needed)
Step 7 : embed the manifests for the two DLLS by running mt.exe in the
build root directory:
Mt.exe -manifest build\lib.win32-2.5_imaging.pyd.manifest
Mt.exe -manifest build\lib.win32-2.5_imagingmath.pyd.manifest
Step 8: install PIL (setup.py install)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Image-SIG