Commons images with embedded color profiles shown incorrectly
OpenPublic

Description

Author: cuerden

Description:
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

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz42827.
bzimport created this task.Via LegacyDec 7 2012, 2:36 PM
bzimport added a comment.Via ConduitDec 7 2012, 2:38 PM

cuerden wrote:

It also affects new thumbnails, of course.

Reedy added a comment.Via ConduitDec 7 2012, 2:49 PM

Have you still got the original? Can you attach it to this bug for reference?

Aklapper added a comment.Via ConduitDec 7 2012, 2:53 PM

Adam: Do you have examples for other files handy that are affected by this?

bzimport added a comment.Via ConduitDec 7 2012, 2:58 PM

cuerden wrote:

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.

Platonides added a comment.Via ConduitDec 7 2012, 3:01 PM

I see the image ok if downloaded and opened locally, but cyan if opened in firefox or chrome.

bzimport added a comment.Via ConduitDec 7 2012, 3:03 PM

cuerden wrote:

Hmm. I *am* using Firefox, and checked it in Firefox. Would that make this a Firefox bug?

Platonides added a comment.Via ConduitDec 7 2012, 3:04 PM

The image has an embedded color profile. I guess the image is cyan when it is ignored.

hashar added a comment.Via ConduitDec 7 2012, 3:12 PM

My tests using Mac OS X 10.7:

  • Safari 6.0 7536.25 => OK
  • Firefox 16.0.2 => cyan
McZusatz added a comment.Via ConduitDec 7 2012, 3:49 PM

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.

Bawolff added a comment.Via ConduitDec 7 2012, 4:15 PM

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)

McZusatz added a comment.Via ConduitDec 7 2012, 4:25 PM

(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?

bzimport added a comment.Via ConduitDec 7 2012, 4:29 PM

cuerden wrote:

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.

Qgil added a comment.Via ConduitDec 7 2012, 5:56 PM

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.

bzimport added a comment.Via ConduitDec 7 2012, 7:22 PM

cuerden wrote:

Quim: Realise that the link no longer works, as the image has been converted to sRGB.

bzimport added a comment.Via ConduitDec 7 2012, 7:26 PM

cuerden wrote:

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).

Qgil added a comment.Via ConduitDec 7 2012, 8:12 PM

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! :)

Qgil added a comment.Via ConduitDec 7 2012, 8:13 PM

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.

Multichill added a comment.Via ConduitDec 7 2012, 9:05 PM
Qgil added a comment.Via ConduitDec 7 2012, 9:18 PM

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

bzimport added a comment.Via ConduitDec 7 2012, 10:49 PM

cuerden wrote:

I wonder if Durova somehow got the wrong headers on it?

McZusatz added a comment.Via ConduitDec 8 2012, 1:43 PM

(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.

Bawolff added a comment.Via ConduitDec 9 2012, 5:49 PM

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

Bawolff added a comment.Via ConduitDec 9 2012, 6:13 PM

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.

McZusatz added a comment.Via ConduitDec 9 2012, 8:57 PM

(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.

Platonides added a comment.Via ConduitDec 9 2012, 9:33 PM

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.

McZusatz added a comment.Via ConduitDec 9 2012, 9:49 PM

(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.

McZusatz added a comment.Via ConduitDec 11 2012, 2:30 PM
Qgil added a comment.Via ConduitApr 1 2014, 8:18 PM

(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?

McZusatz added a comment.Via ConduitApr 2 2014, 2:45 PM

The current versions of all of those files were reencoded and reuploaded. You may refer to the file history to get the broken thumbnails

Gilles added a project: Multimedia.Via WebNov 24 2014, 3:33 PM
Reguyla added a subscriber: Reguyla.Via WebWed, Jul 1, 9:01 PM

@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.

Restricted Application added subscribers: Steinsplitter, Matanya. · View Herald TranscriptVia HeraldWed, Jul 1, 9:01 PM
Qgil added a comment.Via WebWed, Jul 1, 9:59 PM

The current versions of all of those files were reencoded and reuploaded. You may refer to the file history to get the broken thumbnails

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.

Bawolff added a comment.Via WebThu, Jul 2, 2:43 AM

The current versions of all of those files were reencoded and reuploaded. You may refer to the file history to get the broken thumbnails

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:

  • User uploaded a blue file (due to colour profile). Some broken software handles it incorrectly and displays it the way most people expect (which is wrong). This is a combination of the user's fault, and the other software which incorrectly handles colour profiles.
  • Popular web browsers are handling the colour profile incorrectly. Then this is a bug in their software.

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.

Bawolff added a comment.Via WebThu, Jul 2, 2:47 AM

The current versions of all of those files were reencoded and reuploaded. You may refer to the file history to get the broken thumbnails

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:

  • User uploaded a blue file (due to colour profile). Some broken software handles it incorrectly and displays it the way most people expect (which is wrong). This is a combination of the user's fault, and the other software which incorrectly handles colour profiles.
  • Popular web browsers are handling the colour profile incorrectly. Then this is a bug in their software.

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)

Tgr added a subscriber: Tgr.Via WebThu, Jul 2, 3:30 AM

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.

Qgil added a comment.Via EmailThu, Jul 2, 5:51 AM

(Just to be clear, I don't have an opinion about this bug. It sounds like a
bit of a corner case?)

Bawolff added a comment.Via WebThu, Jul 2, 6:09 AM

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.

Bawolff added a comment.Via WebThu, Jul 2, 6:35 AM

Hmm, I was looking at a really old version of qcms, which was part of my confusion

Tgr added a comment.Via WebThu, Jul 2, 7:05 AM

So...

  1. can we upstream this?
  2. is there a practical way to detect on upload whether a file is affected?
  3. is there a practical way to convert affected files without quality loss?
Bawolff added a project: Upstream.Via WebThu, Jul 2, 7:23 AM
Bawolff set Security to None.

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]

Multichill removed a subscriber: Multichill.Via WebThu, Jul 2, 8:04 PM

Add Comment