I see this question asked all over the internet, and I\'ve tried following them all, but I still can\'t get PIL to work.
I tried symbolically linking the zlib, jpeg, et
As always, use the package manager:
sudo apt-get install python-imaging
It'll deal with it all for you. The packages are available.
Manually installing, in any Linux distro, is a wasted endeavour, unless the packages really don't exist. Package maintainers spend time ensuring that the package works and installs correctly, there is no point duplicating their effort. Especially not to manually install something that then doesn't have the advantages of a package - no automatic updating, no easy removal, etc...
I have successfully reinstalled PIL in Ubuntu 12.04 like this:
pip uninstall PIL
apt-get install libjpeg8 libjpeg62-dev libfreetype6 libfreetype6-dev
ln -s /usr/lib/x86_64-linux-gnu/libfreetype.so /usr/lib/
ln -s /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/
ln -s /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib/
pip install -U PIL
It does not raise the IOError: decoder zip not available
anymore after reinstalling the PIL. My error traceback was:
Traceback (most recent call last):
File "convert_image.py", line 15, in <module>
image.save('output.png')
File "/usr/local/lib/python2.7/dist-packages/PIL/Image.py", line 1406, in save
self.load()
File "/usr/local/lib/python2.7/dist-packages/PIL/ImageFile.py", line 189, in load
d = Image._getdecoder(self.mode, d, a, self.decoderconfig)
File "/usr/local/lib/python2.7/dist-packages/PIL/Image.py", line 385, in _getdecoder
raise IOError("decoder %s not available" % decoder_name)
IOError: decoder zip not available
Try reinstalling from scratch:
Look for lib/pythonXX/site-packages/PIL. Delete all this directory along with the file PIL.pth. This should completely remove te package.
Unpack the PIL installation files from the *tar.gz you downloaded.
Add the directories where your jpeg library is, with add_directory(...) as you did before. (Use ldconfig -P | grep jpeg to find where the libraries are).
Retry python setup.py build, then python setup.py install. Test it.
My experience was:
Not performing step 2 did not rebuild the package. Not performing step 3 was the root cause. Not performing step 1 may have played a part.
This seems to be a bug in PIL installation, not in Ubuntu's or any distro's package structure.
And just for the record: it is quite common to have more than one Python version installed on a system, which makes it necessary to install packages manually. Some people have a 2.x with a 3.x for experimenting, shared hostings have 2.5s and applications need a 2.7, just to give two examples.
I found it to be a combination of the two above when installing with a requirements.txt on Ubuntu. I'm using Vagrant to run a chef script, and found this approach works best for me:
First, I use a bash script to setup PIL:
#!/usr/bin/env bash
sudo apt-get build-dep python-imaging
sudo ln -s -f /usr/lib/`uname -i`-linux-gnu/libfreetype.so /usr/lib/
sudo ln -s -f /usr/lib/`uname -i`-linux-gnu/libjpeg.so /usr/lib/
sudo ln -s -f /usr/lib/`uname -i`-linux-gnu/libz.so /usr/lib/
Next, during the requirements.txt install, the top of the file looks like:
--allow-external PIL
--allow-unverified PIL
Django==1.5.4
PIL==1.1.7
...
Of course, this is an unsecured way of doing it, but works for dev and quick builds. For production, it's best to download and verify all packages manually and install them from a local managed repository.