Bug 1044939

Summary: IOError: decoder jpeg not available => NO SUPPORT for JPEG in PIL
Product: [Fedora] Fedora Reporter: a.thiaville
Component: python-pillowAssignee: Sandro Mani <manisandro>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: a.thiaville, manisandro, rrakus
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-19 13:18:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
steps to reproduce, and to patch the problem none

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