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.
Version: 1.21.x
Severity: normal
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.
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
(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
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
@Qgil, was this problem fixed? I was looking at several images on Commons that were tagged with this bug and they all seem to be fixed now.
For instance https://commons.wikimedia.org/wiki/File:Ijazah3.jpg still shows a first version with wrong colors: https://upload.wikimedia.org/wikipedia/commons/archive/e/e3/20121207154620%21Ijazah3.jpg
Downloading that jpg and opening with GIMP, I can see the correct colors (not with GNOME's Image Viewer though, which offer yet another monochrome green variant). So no @Reguyla, this task seems to be still valid.
I'm not sure how that makes this a valid bug (Given you are looking at the original file). There's 2 possibilities:
Web browsers seem to render it blue, but the jpegicc command line tool does not seem to make the image blue (If I'm using it right), so maybe its a bug in qcms (I think that's what web browsers use) not present in lcms. Maybe its because the Connection space is LAB instead of XYZ.
Either way, not really a valid MediaWiki bug.
I'm not sure how that makes this a valid bug (Given you are looking at the original file). There's 2 possibilities:
Web browsers seem to render it blue, but the jpegicc command line tool does not seem to make the image blue (If I'm using it right), so maybe its a bug in qcms (I think that's what web browsers use) not present in lcms. Maybe its because the Connection space is LAB instead of XYZ (?)
Either way, not really a valid MediaWiki bug. (Although if we did discover there is some specific type of profile that didn't work with web browsers, we could perhaps detect and strip, although I don't really think that's a MediaWiki responsibility)
Although if we did discover there is some specific type of profile that didn't work with web browsers, we could perhaps detect and strip, although I don't really think that's a MediaWiki responsibility
Warning the uploader about it (and maybe offering a convert option, if that is safe to do) is certainly MW responsibility. Accepting the original with a dangerous color profile then silently fixing that in thumbnails is probably a bad idea. Changing the original without the uploader's knowledge/consent is definitely a bad idea.
(Just to be clear, I don't have an opinion about this bug. It sounds like a
bit of a corner case?)
I did some investigating of the file.
I think firefox, and chrome are in the wrong (I believe both use qcms to handle colour profiles, although not sure. I think they at least did at one point, not 100% sure they still do).
It appears they do not handle the case where there is an AToB0 tag (See section 6.3.1.2 of http://www.color.org/ICC_Minor_Revision_for_Web.pdf ). Instead firefox ignores it and uses the TRC field.
I don't really understant the fine details of colour management, and I found the spec a little confusing. Its unclear to me if falling back to the TRC fields in case AToB0 is not understood is valid behaviour. Actually, its unclear to me if including the TRC values in the profile for a LAB colour space connection is even allowed (Or on the other hand, if not including them would be invalid).
Anyways, qcms seems to have qcms_profile_is_bogus() function which should in theory stop the profile from being applied as this profiles as qcms understands it makes white not be white (https://bugzilla.mozilla.org/show_bug.cgi?id=460629)... but yet browsers still seem to be applying it.
So...
Filed upstream bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1179671
[Of course, even if that gets fixed, that doesn't help us in the near term. I think we should either ignore it and tell users to replace the colour profile, or we could maybe investigate converting images with weird profiles to sRGB/tinyrgb during the thumbnailing process]
Just fyi, mozilla just closed the bug on iccv4 support https://bugzilla.mozilla.org/show_bug.cgi?id=488800 which may affect this.