Bug 661505

Summary: JPEGs with sRGB IEC61966-2.1 color profiles have wrong colors
Product: [Fedora] Fedora Reporter: Joel Uckelman <uckelman>
Component: java-1.6.0-openjdkAssignee: Denis Lila <dlila>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: ahughes, dbhole, jvanek, langel, lkundrak, mjw, mmatejov, omajid
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-03 17:29:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Test program showing the problem
none
The bad image
none
The good image
none
A screenshot of the bad image looking purple instead of green none

Description Joel Uckelman 2010-12-08 21:07:29 UTC
Created attachment 467577 [details]
Test program showing the problem

Description of problem:

Some JPEGs with sRGB IEC61966-2.1 color profiles have completely wrong colors when loaded by ImageIO. The problem appears to afflict only OpenJDK---I can't reproduce this with the same images on Windows XP with Oracle's 6 Update 22.

Every other program I use to open bad.jpg displays it properly. This could be because ImageIO has a bug, or it could be because bad.jpg is broken, but ImageIO handles the brokenness differently from other programs. (I haven't been able to find any way to determine whether the image is a valid JPEG.)

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

java-1.6.0-openjdk-1.6.0.0-49.1.9.3.fc14.x86_64

How reproducible:

Always.

Steps to Reproduce:
1. java Test good.jpg
2. java Test bad.jpg
  
Actual results:

bad.jpg has incorrect colors (it's purplish instead of greenish).

Expected results:

If bad.jpg is ok, then it should look like good.jpg. If bad.jpg is actually broken, then ImageIO should complain.

Comment 1 Joel Uckelman 2010-12-08 21:08:35 UTC
Created attachment 467578 [details]
The bad image

Comment 2 Joel Uckelman 2010-12-08 21:09:28 UTC
Created attachment 467579 [details]
The good image

Comment 3 Joel Uckelman 2010-12-08 21:17:09 UTC
Created attachment 467584 [details]
A screenshot of the bad image looking purple instead of green

Comment 4 Andrew John Hughes 2010-12-08 21:52:38 UTC
The proprietary JDK has a proprietary colour management system which was never released as open source.  OpenJDK uses LCMS, as do many other applications on the GNU/Linux platform.

Comment 5 Joel Uckelman 2010-12-09 08:20:09 UTC
(In reply to comment #4)
> The proprietary JDK has a proprietary colour management system which was never
> released as open source.  OpenJDK uses LCMS, as do many other applications on
> the GNU/Linux platform.

GIMP uses LCMS, but the attached "bad" image has the correct colors in GIMP (and in every other application I've tried on Linux).

Comment 6 Andrew John Hughes 2010-12-09 12:33:18 UTC
Do you know what version of LCMS is being used by GIMP?  OpenJDK uses an in-tree version (due to local patching) which may have a bug that's been fixed in a newer version.

Comment 7 Joel Uckelman 2010-12-09 14:18:32 UTC
(In reply to comment #6)
> Do you know what version of LCMS is being used by GIMP? 

No, I don't. The only way that I knew that GIMP was using LCMS at all was from a diagnostic message it spit out to my terminal after I chose the "Keep" option for the color profile while loading the image.

Comment 8 Denis Lila 2011-05-03 17:29:10 UTC
This was fixed in head and 1.10 by this changeset:
http://icedtea.classpath.org/hg/release/icedtea6-1.10/rev/d2d762ec4dda

Comment 9 Andrew John Hughes 2013-09-23 23:38:38 UTC
Finally fixed in 7:

http://blog.fuseyism.com/index.php/2013/09/23/icedtea-2-4-2-released/