Created attachment 176544 [details] test image Image colors look inverted on Chromium Linux They look fine on Mac chrome.
They look inverted in the attachment-picker dialog as well (I'm not sure if chrome draws that or the OS does).
The OS draws the image in the attachment-picker. Looks the same to me on Windows as on Linux.
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.
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)
The original file is from: http://lh6.ggpht.com/-gr_xmoxExCA/TkA5hKvxBfI/AAAAAAAAWyE/ISfFk6Ke1mc/j4.JPG
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.
I updated to M25 (25.0.1323.1 (Official Build 167142) dev) and it still looks wrong on my machine.
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.
Firefox looks the same on the link in comment #5
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). :)
(In reply to comment #9) > Firefox looks the same on the link in comment #5 Note "the same" as m24 beta on linux.
For reference, my Mac is a MacPro (10.8) connected to an HP LP3065 monitor.
http://regex.info/exif.cgi and load the image URL from comment 5. No color profile.
Eric - when you saved the comment 5 image to your desktop prior to uploading, did the image have a color-inverted desktop thumbnail?
Corollary: find some system jpg image on said Linux machine (aka an image that chrome has never touched), and upload that.
The image in comment #5 is color inverted on Mac 10.8, Firefox, Safari, Chrome for me.
Created attachment 176618 [details] mac.10.8.firefox.safari.chrome.comment5.png
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?
Image renders fine in Chrome Dev 25.0.1331519 OS Android 4.2.1; Galaxy Nexus
Image color inverted IE10 10.0.9200.16438 Win7
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?
This could be some sort of obscure libjpeg bug?
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?
(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.
(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.
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.
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.
(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?
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.
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.
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.
Btw, lh6.ggpht.com resolves to photos-ugc.l.google.com aka 74.125.224.138 for me.
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.
This appears to be a Google-Network bug. Will report to the appropriate internal tracker.
This was filed internally as b/7656227