Bug 103549 - Image colors look inverted on Chromium Linux
Summary: Image colors look inverted on Chromium Linux
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Images (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P4 Normal
Assignee: Nobody
URL: http://lh6.ggpht.com/-gr_xmoxExCA/TkA...
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-28 12:22 PST by Eric Seidel (no email)
Modified: 2012-12-02 22:21 PST (History)
6 users (show)

See Also:


Attachments
test image (75.10 KB, image/jpeg)
2012-11-28 12:22 PST, Eric Seidel (no email)
no flags Details
test iamge (75.10 KB, image/jpeg)
2012-11-28 12:38 PST, Eric Seidel (no email)
no flags Details
bugzilla appears to be changing the image when I upload it (or something is) (75.10 KB, application/octet-stream)
2012-11-28 12:40 PST, Eric Seidel (no email)
no flags Details
mac.10.8.firefox.safari.chrome.comment5.png (604.16 KB, image/png)
2012-11-28 17:58 PST, noel gordon
no flags Details
Image served to Chrome Dev 25.0.1331519 OS Android 4.2.1; Galaxy Nexus (75.21 KB, image/jpeg)
2012-11-28 23:23 PST, noel gordon
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2012-11-28 12:22:03 PST
Created attachment 176544 [details]
test image

Image colors look inverted on Chromium Linux

They look fine on Mac chrome.
Comment 1 Eric Seidel (no email) 2012-11-28 12:22:47 PST
They look inverted in the attachment-picker dialog as well (I'm not sure if chrome draws that or the OS does).
Comment 2 Tony Chang 2012-11-28 12:29:12 PST
The OS draws the image in the attachment-picker.

Looks the same to me on Windows as on Linux.
Comment 3 Eric Seidel (no email) 2012-11-28 12:38:01 PST
Created attachment 176548 [details]
test iamge

chrome must have modified the image when I saved it.  Here is a curl'd image from the original site.
Comment 4 Eric Seidel (no email) 2012-11-28 12:40:31 PST
Created attachment 176549 [details]
bugzilla appears to be changing the image when I upload it (or something is)

Trying re-uploading as binary file in hopes b.w.o won't change it (assuming they were)
Comment 5 Eric Seidel (no email) 2012-11-28 12:41:59 PST
The original file is from:
http://lh6.ggpht.com/-gr_xmoxExCA/TkA5hKvxBfI/AAAAAAAAWyE/ISfFk6Ke1mc/j4.JPG
Comment 6 Eric Seidel (no email) 2012-11-28 12:43:47 PST
The link looks "right" for PDR on his Mac.  The link looks "wrong" for tony (on m23) and all teh uploads (which all seem to get a different sha1sum!) look wrong for tc on m23.
Comment 7 Tony Chang 2012-11-28 12:47:16 PST
I updated to M25 (25.0.1323.1 (Official Build 167142) dev) and it still looks wrong on my machine.
Comment 8 Eric Seidel (no email) 2012-11-28 13:15:39 PST
Clearly it looked right for the original designer. :)  And we've seen it look right on one machine (pdr'd Mac).  I'm not sure what's going on here.  But somehow we're getting inverted colors on most machines, yet not on all.  I'm not sure if this is even WebKit's bug, but likely warrants a tiny bit of triage from someone familiar with these codepaths. :)

I've CC'd various folks who have worked in this area or who might know enough about color profiles/jpegs to inform our discussion.
Comment 9 Stephen Chenney 2012-11-28 13:24:28 PST
Firefox looks the same on the link in comment #5
Comment 10 Eric Seidel (no email) 2012-11-28 13:29:09 PST
The file seems to get modified when i try to upload it, so for now I suggest we use the URL in comment 5.

The question is when the image appears inverted vs. not.  So far we've only seen it non-inverted (correctly colored) on pdr's mac (in all browsers). :)
Comment 11 Stephen Chenney 2012-11-28 13:31:03 PST
(In reply to comment #9)
> Firefox looks the same on the link in comment #5

Note "the same" as m24 beta on linux.
Comment 12 Tony Chang 2012-11-28 13:32:58 PST
For reference, my Mac is a MacPro (10.8) connected to an HP LP3065 monitor.
Comment 13 noel gordon 2012-11-28 15:10:50 PST
http://regex.info/exif.cgi and load the image URL from comment 5.  No color profile.
Comment 14 noel gordon 2012-11-28 15:12:15 PST
Eric - when you saved the comment 5 image to your desktop prior to uploading, did the image have a color-inverted desktop thumbnail?
Comment 15 noel gordon 2012-11-28 15:34:42 PST
Corollary: find some system jpg image on said Linux machine (aka an image that chrome has never touched), and upload that.
Comment 16 noel gordon 2012-11-28 17:56:53 PST
The image in comment #5 is color inverted on Mac 10.8, Firefox, Safari, Chrome for me.
Comment 17 noel gordon 2012-11-28 17:58:23 PST
Created attachment 176618 [details]
mac.10.8.firefox.safari.chrome.comment5.png
Comment 18 noel gordon 2012-11-28 18:23:29 PST
Image color inverted Chrome Mac 12.0.737.0 (81691), Chrome Mac 10.0.643.0 (71768).  Seems we've had this some time.  Other JPG images look fine to me, anyone confirm?
Comment 19 noel gordon 2012-11-28 20:33:35 PST
Image renders fine in Chrome Dev 25.0.1331519 OS Android 4.2.1; Galaxy Nexus
Comment 20 noel gordon 2012-11-28 20:39:58 PST
Image color inverted IE10 10.0.9200.16438 Win7
Comment 21 noel gordon 2012-11-28 23:23:22 PST
Created attachment 176656 [details]
Image served to Chrome Dev 25.0.1331519 OS Android 4.2.1; Galaxy Nexus

Does that image look fine in chrome linux?
Comment 22 Eric Seidel (no email) 2012-11-29 00:19:40 PST
This could be some sort of obscure libjpeg bug?
Comment 23 Eric Seidel (no email) 2012-11-30 14:15:59 PST
I'm really not sure what to do with this Heisenbug.

As far as I've seen so far, it's *machine* dependent, not *browser* dependent.  Which I just don't understand.  Has anyone seen multiple browsers show different behavior on a single machine?
Comment 24 noel gordon 2012-11-30 14:25:52 PST
(In reply to comment #14)
> Eric - when you saved the comment 5 image to your desktop prior to uploading, did the image have a color-inverted desktop thumbnail?

I'd love an answer here.
Comment 25 Eric Seidel (no email) 2012-11-30 14:32:40 PST
(In reply to comment #24)
> (In reply to comment #14)
> > Eric - when you saved the comment 5 image to your desktop prior to uploading, did the image have a color-inverted desktop thumbnail?
> 
> I'd love an answer here.

Sorry!   I assume you mean my Linux box, and I'll get you one first-thing Monday.
Comment 26 noel gordon 2012-11-30 15:42:35 PST
No worries.  And I loaded that image in IE9, Chrome Canary, and Chrome Dev (all Win7) today and the image renders fine in each :)

Hmmm, if the image thumbnail is color inverted on your desktop, well those compressed image bytes came from the server and we don't fiddle with those bytes on saving to a file, ever.
Comment 27 noel gordon 2012-12-02 20:22:12 PST
My week start earlier than yours:)  On my linux box:

% curl http://lh6.ggpht.com/-gr_xmoxExCA/TkA5hKvxBfI/AAAAAAAAWyE/ISfFk6Ke1mc/j4.JPG > j4.jpg 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 76902  100 76902    0     0   475k      0 --:--:-- --:--:-- --:--:--  490k

% open j4.jpg 

The image from the server is inverted when viewed with the dektop image viewer, and in Nautilus.  Seems like the problem is a server-side problem.
Comment 28 Eric Seidel (no email) 2012-12-02 20:43:15 PST
(In reply to comment #27)
> My week start earlier than yours:)  On my linux box:
> 
> % curl http://lh6.ggpht.com/-gr_xmoxExCA/TkA5hKvxBfI/AAAAAAAAWyE/ISfFk6Ke1mc/j4.JPG > j4.jpg 
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
>                                  Dload  Upload   Total   Spent    Left  Speed
> 100 76902  100 76902    0     0   475k      0 --:--:-- --:--:-- --:--:--  490k
> 
> % open j4.jpg 
> 
> The image from the server is inverted when viewed with the dektop image viewer, and in Nautilus.  Seems like the problem is a server-side problem.

So you think that the server is sending different bytes to different UAs?
Comment 29 noel gordon 2012-12-02 20:50:14 PST
The image served to android devices comment #21 is correct, the image served to linux and curl is not.

So maybe it is UA dependent.  Most I can say is there's something wrong server-side.
Comment 30 Eric Seidel (no email) 2012-12-02 20:53:46 PST
My mac says:

curl -s http://lh6.ggpht.com/-gr_xmoxExCA/TkA5hKvxBfI/AAAAAAAAWyE/ISfFk6Ke1mc/j4.JPG | md5
49a11b2e7eda19dcd8d8f7a38e9fd997

The image looks correct on mac.  Both curl'd (and viewed in preview) and viewed directly from the link in Chrome.
Comment 31 Eric Seidel (no email) 2012-12-02 21:13:28 PST
To rule out the possibility of proxies, I've tried via https as well:

curl -s "https://lh6.ggpht.com/-gr_xmoxExCA/TkA5hKvxBfI/AAAAAAAAWyE/ISfFk6Ke1mc/j4.JPG" | md5
49a11b2e7eda19dcd8d8f7a38e9fd997

Same md5.  Again, looks fine in Chrome/Preview.
Comment 32 Eric Seidel (no email) 2012-12-02 21:14:42 PST
Btw, lh6.ggpht.com resolves to photos-ugc.l.google.com aka 74.125.224.138 for me.
Comment 33 noel gordon 2012-12-02 21:15:19 PST
Per comment #16, my mac says color inverted

% curl -s http://lh6.ggpht.com/-gr_xmoxExCA/TkA5hKvxBfI/AAAAAAAAWyE/ISfFk6Ke1mc/j4.JPG | md5
b3f13efcf9d36bc5b1d9f525d94f9097

and same for https.
Comment 34 Eric Seidel (no email) 2012-12-02 21:26:37 PST
This appears to be a Google-Network bug.  Will report to the appropriate internal tracker.
Comment 35 Eric Seidel (no email) 2012-12-02 22:21:47 PST
This was filed internally as b/7656227