Bug 185203 - jpeg support broken in latest build
Summary: jpeg support broken in latest build
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: python-imaging
Version: 5
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: José Matos
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-03-11 18:40 UTC by Rick L Vinyard Jr
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version: 1.1.5-4
Clone Of:
Environment:
Last Closed: 2006-04-05 09:58:38 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Just to show where is the probl. (401 bytes, patch)
2006-03-27 19:35 UTC, Stanislav Polasek
no flags Details | Diff
.spec patch (1.27 KB, patch)
2006-03-31 18:27 UTC, Rick L Vinyard Jr
no flags Details | Diff
Modified Stanislav's patch (374 bytes, patch)
2006-03-31 18:30 UTC, Rick L Vinyard Jr
no flags Details | Diff

Description Rick L Vinyard Jr 2006-03-11 18:40:55 UTC
Description of problem:
jpeg support in PIL is broken in the latest build... resulting in broken python
apps that use PIL for jpeg manipulation.

Version-Release number of selected component (if applicable):
1.1.5-1

How reproducible:
Always

Steps to Reproduce:
1. Run python app that manipulates jpegs
2.
3.
  
Actual results:
PIL returns I/O error: no jpeg decoder available

Expected results:


Additional info:
Regression to 1.1.4-9 downgrades PIL to previous version, but has working jpeg
support.

Comment 1 José Matos 2006-03-17 21:27:56 UTC
It works for me. 
 
Could you give an example, please? 
 
If it fails could you install ImageMagick and use identify to give further 
details about those jpeg files: 
 
$ identify *.jpg 
 
As an example I run this in a directory full of jpeg images and I don't get 
any problem: 
 
import Image 
import glob 
 
for i in glob.glob("*.jpg"): 
    im[i] = Image.open(i) 
    print im[i].format, im[i].size, im[i].mode 

Comment 2 Stanislav Polasek 2006-03-27 19:35:24 UTC
Created attachment 126844 [details]
Just to show where is the probl.

Comment 3 Stanislav Polasek 2006-03-27 19:36:02 UTC
I have the same problem on the x86 platform. Trying rebuild the package, I got
error on the selftest.py phase. As I do not have much time to resolve this
issue, I just added explicitly the path to the /usr/lib64 libs to the setup.py
and recompiled the package. Please find atached "patch" for the details:

Comment 4 José Matos 2006-03-28 10:37:42 UTC
Aha, now I see the problem only occurs in x86-64, and it is a problem related 
with /usr/lib/ versus /usr/lib64. 
 
Now that I have a clue I will fix this issue soon. 
 
Thank your for the patch. 

Comment 5 Rick L Vinyard Jr 2006-03-31 18:27:57 UTC
Created attachment 127145 [details]
.spec patch

Modified .spec to apply modification of Stanislav's patch on x86_64.

Tested on x86_64 and fixes original bug.

Comment 6 Rick L Vinyard Jr 2006-03-31 18:30:31 UTC
Created attachment 127146 [details]
Modified Stanislav's patch

Stripped directories so patch can be -p0 instead of -p3

Comment 7 José Matos 2006-04-05 10:02:50 UTC
I have applied a similar fix. The reason why I have not applied the patch 
proposed in this report is that this would give two different src.rpm 
depending on the arch used.

This fix is also in line with other python-* fixes applied to solved this type 
of problem, see python-crypto.

Thank you for the reports.


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