Bug 1044939 - IOError: decoder jpeg not available => NO SUPPORT for JPEG in PIL
Summary: IOError: decoder jpeg not available => NO SUPPORT for JPEG in PIL
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: python-pillow
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Sandro Mani
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-19 09:28 UTC by a.thiaville
Modified: 2013-12-19 13:18 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-19 13:18:36 UTC
Type: Bug


Attachments (Terms of Use)
steps to reproduce, and to patch the problem (3.88 KB, text/plain)
2013-12-19 09:28 UTC, a.thiaville
no flags Details

Description a.thiaville 2013-12-19 09:28:29 UTC
Created attachment 838889 [details]
steps to reproduce, and to patch the problem

Description of problem: IOError: at /usr/lib64/python2.7/site-packages/PIL/Image.py:56 => line:56:  "import _imaging as core"

Version-Release number of selected component (if applicable):
python-pillow-2.0.0-11.gitd1c6db8.fc19.x86_64

How reproducible: always


Steps to Reproduce:
1. see attachment
2.
3.

Actual results: exception IOError because method jpeg_decoder ABSENT in Image.core (alias _imaging)


Expected results:jpeg_decoder found in Image.core


Additional info: There is a (dirty) fix at the end of the attachment. ( re-import
_imaging c lib and overwrite Image.core with the good import)

Comment 1 Sandro Mani 2013-12-19 10:26:43 UTC
I cannot reproduce this:

$ python
Python 2.7.5 (default, Nov 12 2013, 16:18:42) 
[GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from PIL import Image
>>> i=Image.open('image.jpg')
>>> i.load()
<PixelAccess object at 0x7fd070cda130>

Also, jpeg support is tested when the package is built, so in principle it should work. Are there any environment particularities on your side? Does your script alter something to the environment before importing PIL and opening the image?

Comment 2 a.thiaville 2013-12-19 13:12:45 UTC
yes, thanks you can close the bug. 
It was caused by a second (illegal) _imaging.so under the PIL directory. I presume that I installed with "pip", some day and when i installed it, libjpeg-dev was missing. so the bug is for me :
the first import in the Image.py: "import _imaging as core" found the "bad" pip 
_image.so in the PIL directory i.e /usr/lib64/python2.7/site-packages/PIL/. The  patch i.e the same statement "import _imaging as core" found the right _image.so i.e : "rpm -qf /usr/lib64/python2.7/site-packages/_imaging.so" says : python-pillow-2.0.0-11.gitd1c6db8.fc19.x86_64.

To Finish i consider it WOULD BE BETTER, as PIP does,  in the rpm distribution to move the C modules (.so lib) under /usr/lib64/python2.7/site-packages/PIL/  because these modules belong to PIL and that the correct way (pure python) to import these modules (since python 2.5) it "from PIL import _imaging"

Comment 3 Sandro Mani 2013-12-19 13:18:36 UTC
In F20+ the *.so modules are indeed in /usr/lib{64}/python2.7/site-packages/PIL/. It was an upstream change for python-pillow-2.1+ (see [1]). Since pillow is a core dependency for many packages, I won't be updating to a newer version in F19 however in the interest of stability.


[1] https://github.com/python-imaging/Pillow/pull/191


Note You need to log in before you can comment on or make changes to this bug.