Last modified: 2014-04-02 14:45:29 UTC
http://upload.wikimedia.org/wikipedia/commons/e/e3/Ijazah3.jpg is showing up as all-cyan. When downloaded. This was not true before, and this is not the first image I've seen affected. This is a rather disastrous situation for commons. You cannot be a repository of the world's art if you slowly destroy it.
It also affects new thumbnails, of course.
Have you still got the original? Can you attach it to this bug for reference?
Adam: Do you have examples for other files handy that are affected by this?
The original was uploaded by someone else, sorry. It was something like this thumbnail version: http://upload.wikimedia.org/wikipedia/commons/thumb/e/e3/Ijazah3.jpg/1024px-Ijazah3.jpg As for other files - I know I've seen one other, but I thought it was the fault of the uploader at the time. This is a file I nominated for FPC 3 years ago, so knew it was good then. I've shoved a message on COM:VP to encourage people to share examples.
I see the image ok if downloaded and opened locally, but cyan if opened in firefox or chrome.
Hmm. I *am* using Firefox, and checked it in Firefox. Would that make this a Firefox bug?
The image has an embedded color profile. I guess the image is cyan when it is ignored.
My tests using Mac OS X 10.7: - Safari 6.0 7536.25 => OK - Firefox 16.0.2 => cyan
See also https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2012/04#Corrupted_featured_picture_files Browser bug, and/or a dup of bug 30249.
I have converted https://commons.wikimedia.org/wiki/File:Ijazah3.jpg to sRGB but it seems this conversion was not ideally. Now the file is a bit yellow.
Arguably this is a dupe of bug 24854 (Even though that's CYMK, they all essentially have to do with different colour spaces not being converted to normal sRGB)
(In reply to comment #10) > I have converted https://commons.wikimedia.org/wiki/File:Ijazah3.jpg to sRGB > but it seems this conversion was not ideally. Now the file is a bit yellow. Managed to convert the file properly (In reply to comment #11) > Arguably this is a dupe of bug 24854 (Even though that's CYMK, they all > essentially have to do with different colour spaces not being converted to > normal sRGB) How do we encourage people to upload in sRGB only? Should all non-sRGB files be converted to sRGB?
Marco: Can you identify it at point of upload, preferably early in the upload? If you can, you could put up a warning box, and the competent editors would fix it, the others could skip it and have a {{Convert-to-sRGB}} tag added.
In my tests the image looks good in the two browsers in my desktop: Chromium Version 22.0.1229.94 Ubuntu 12.10 (161065) looks like Firefox / Aurora 19.0a2 (2012-11-27) for Ubuntu It also looks good in the mobile browsers I could check right now: Nokia N9 browser (WebKit based) Firefox for Nokia N9 Internet Explorer for Nokia Lumia 800 Collateral comment - no need to follow-up here: > You cannot be a repository of the world's art if you slowly destroy it. All of us (including you) are doing our best here. All the code we are handling is open source, which means that there is no clear you vs me/us. Your reports and your willingness to contribute is really helpful! But just consider how your sentences in the community channels sound if you change "you" by "us" e.g. "We cannot be a repository of the world's art if we slowly destroy it." Are _you_ destroying anything? Are _we_ destroying anything. No, we are building something together, sometimes bugs happen, and eventually all we (or an upstream project, as it might be the case of this bug) manages to fix them. Thank you for your understanding and please keep contributing your feedback and your attention to detail.
Quim: Realise that the link no longer works, as the image has been converted to sRGB.
Quim: Also., I hate to say it, but this is my first experience with a bug report that has been at all pleasant (and this one has been perfectly pleasant, I must say).
I was checking against http://upload.wikimedia.org/wikipedia/commons/e/e3/Ijazah3.jpg . If that is not the right URL to check now please share the new one and I will test again. PS: feel free CCing me directly in any bug report you feel the tone was not unpleasant. I want to help making bug reporting pleasant! :)
PS: feel free CCing me directly in any bug report you feel the tone WAS unpleasant. I want to help making bug reporting pleasant! :))) And sorry for the noise.
Quim, see https://commons.wikimedia.org/wiki/File:Ijazah3.jpg https://upload.wikimedia.org/wikipedia/commons/archive/e/e3/20121207154620!Ijazah3.jpg is the one showing up with the wrong colors in Firefox, but no problems in IE
Alright, this is getting weird now: https://upload.wikimedia.org/wikipedia/commons/archive/e/e3/20121207154620!Ijazah3.jpg Cyan: Chromium Version 22.0.1229.94 Ubuntu 12.10 (161065) looks like Firefox / Aurora 19.0a2 (2012-11-27) for Ubuntu Correct: Nokia N9 browser (WebKit based) Firefox for Nokia N9 Can't even load it (blank): Internet Explorer for Nokia Lumia 800
I wonder if Durova somehow got the wrong headers on it?
(In reply to comment #13) > Marco: Can you identify it at point of upload, preferably early in the > upload? > If you can, you could put up a warning box, and the competent editors would > fix > it, the others could skip it and have a {{Convert-to-sRGB}} tag added. I tried to identify such jpeg with the exif data available but I could not manage. At least GIMP can detect such Profiles and prompts you to convert them to sRGB. Could be helpful to determine how GIMP handles this.
> I tried to identify such jpeg with the exif data available but I could not > manage. Colour profiles are not usually embedded in exif data. They are usually embedded as an ICC colour profile (in jpg images an APP2 segment - see section B.4 of http://www.color.org/specification/ICC1v43_2010-12.pdf ). MediaWiki currently does not extract this data at the moment. Tools like exiftool do extract this data. For the curious, http://docs.oracle.com/javase/6/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color has some interesting information on how java determines colour profiles of jpeg images. ---- >Quim, see https://commons.wikimedia.org/wiki/File:Ijazah3.jpg >https://upload.wikimedia.org/wikipedia/commons/archive?/e/e3/20121207154620!Ijazah3.jpg >is the one showing up with the wrong colors in Firefox, but no problems in IE Maybe the image is wrong. Wikipedia says Google chrome supports icc v2 profiles on all platforms since version 22, firefox since version 3.5. and IE doesn't do it correctly at all. So if its only looking correct on incorrect software perhaps the image is wrong. ( The image in question has an icc v2 profile named "Phase One P 25 Product Flash" [1]) Note: There is a test page to see if your browser supports ICC profiles properly at http://www.color.org/version4html.xalter [1] http://regex.info/exif.cgi?imgurl=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2Farchive%2Fe%2Fe3%2F20121207154620!Ijazah3.jpg#ICC_Profile
This bug seems mostly as if it should be resolved INVALID/is a web browser problem. What action I think we should take is *Extract ICC colour profile info **Display it in the metadata box so people can see if the image is colour managed if they're curious. **Put a warning under the image (similar to the image cannot be animated warning) if the colourspace is not sRGB. Another action that could possibly be taken is to automatically convert to sRGB when thumbnailing (and also trigger mustRender() so we always profile). This would cause everything to be consistent across browsers. I'm not sure how appropriate this would be, someone more familiar with colour management than I would have to comment. My understanding is that converting colour spaces causes some information to be lost (some of the time) and the most appropriate conversion depends on the final device (and possibly human judgement/content of the image). That said if we auto converted, the original image would still be there for the super high end artists to do their thing with.
(In reply to comment #23) > Maybe the image is wrong. Wikipedia says Google chrome supports icc v2 > profiles > on all platforms since version 22, firefox since version 3.5. and IE doesn't > do > it correctly at all. So if its only looking correct on incorrect software > perhaps the image is wrong. ( The image in question has an icc v2 profile > named > "Phase One P 25 Product Flash") fun fact: You can turn off color management in firefox. [1] After setting the gfx.color_management.mode to "0" (turned off) the system should not support these ICC profiles anymore. But the actual picture[2] shows up in the "right" colors. [1] http://kb.mozillazine.org/Gfx.color_management.mode [2] https://upload.wikimedia.org/wikipedia/commons/archive/e/e3/20121207154620!Ijazah3.jpg (In reply to comment #24) Thanks for your work. The first action you suggested sound quite good. There is not much we can do wrong because the image source data remains untouched.
The test http://www.color.org/version4html.xalter shows the result «The system supports ICC version 2 profiles only» for me. Even when enabling gfx.color_management.enablev4 I see no difference on that page or 20121207154620!Ijazah3.jpg when changing gfx.color_management.mode from its default of 2. PS: Note that even if manually changed, the original file is there in the history. The approach suggested by Bawolff would be preferable, but I'm not sure if it's worth the effort.
(In reply to comment #26) > The test http://www.color.org/version4html.xalter shows the result «The > system > supports ICC version 2 profiles only» for me. Even when enabling > gfx.color_management.enablev4 I get some 'oversaturated' results for 'enablev4' > > I see no difference on that page or 20121207154620!Ijazah3.jpg when changing > gfx.color_management.mode from its default of 2. > Did you restart the browser after changing the config? > > PS: Note that even if manually changed, the original file is there in the > history. The approach suggested by Bawolff would be preferable, but I'm not > sure if it's worth the effort. Not sure about that either. Maybe putting all those files one stumbles upon over the time in a category is enough.
https://commons.wikimedia.org/wiki/Category:Bug_42827 Category with some sample files.
(In reply to Marco from comment #28) > https://commons.wikimedia.org/wiki/Category:Bug_42827 > > Category with some sample files. Except perhaps "Mirror writing.jpg", those images look correct. Does this mean that this bug has been fixed?
The current versions of all of those files were reencoded and reuploaded. You may refer to the file history to get the broken thumbnails
