Preserve color profile information for thumbs (ImageMagick update)
Closed, ResolvedPublic

Description

There are some large differences in color profile apparently between:

original: http://upload.wikimedia.org/wikipedia/commons/c/c7/Theridula_emertoni_Kaldari_02.jpg
thumb: http://commons.wikimedia.org/wiki/File:Theridula_emertoni_Kaldari_02.jpg

Possibly caused by usage of -thumbnail in phase3/includes/media/Bitmap.php
Thumbnail is actually a combination of -resize and -strip. The latter removes profile AND metadata. Perhaps we should not strip if target thumb size is larger than say 400x300 ?


Version: unspecified
Severity: trivial

bzimport set Reference to bz19960.
TheDJ created this task.Via LegacyJul 27 2009, 6:32 PM
kaldari added a comment.Via ConduitJul 27 2009, 6:53 PM

This issue has come up a couple times at Featured Picture Candidate discussions on the English Wikipedia. See http://en.wikipedia.org/wiki/Wikipedia:Picture_peer_review/Jimmy_Wales_Fundraiser_Appeal for example.

kaldari added a comment.Via ConduitJul 27 2009, 7:02 PM

Would it be possible to query for the profile before the convert, and then do...
convert -thumbnail -profile "[the original file's profile]"
in order to add the profile back in after it's been stripped?

TheDJ added a comment.Via ConduitJul 28 2009, 10:56 AM

yes, I have thought about this, but I can't see how to do that, because the syntax differs if a file has or a file does not have a profile. Thus making it impossible to create a 'generic' command I think. The documentation for this is here: http://www.imagemagick.org/Usage/formats/#profiles

kaldari added a comment.Via ConduitJul 28 2009, 2:46 PM

In that case, is the filesize difference between using -thumbnail and -resize prohibitive? i.e. could we just switch to using -resize?

TheDJ added a comment.Via ConduitJul 28 2009, 2:49 PM

It totally depends. but on a 800wide thumb, the size with metadata goes from 160 to 190 Kbyte. So on small thumbnails, that soon becomes HALF the size of the image. Perhaps we could do different things depending on how large the thumb is. That might be the wisest.

kaldari added a comment.Via ConduitJul 28 2009, 4:17 PM

Hmm, that doesn't sound like a great solution either. What about this really wacky idea: What if we approach ImageMagick about adding a new flag that just strips metadata, but not profile info. Then we could use "convert -metastrip -resize"

kaldari added a comment.Via ConduitJul 28 2009, 4:58 PM

I've opened a thread on the Imagemagick discussion board: http://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=14312

kaldari added a comment.Via ConduitJul 28 2009, 5:37 PM

Wow, that was easy:

"We will add a patch to the next ImageMagick point release such that -thumbnail removes all profiles except the color profile. Look for it in about a week or two. Thanks."

brion added a comment.Via ConduitJul 29 2009, 12:23 AM

Adjusting summary to clarify.

kaldari added a comment.Via ConduitJul 29 2009, 8:34 PM

Update from Imagemagick: "The fix will be available later this week with the ImageMagick 6.5.4-7 point release."

kaldari added a comment.Via ConduitAug 4 2009, 6:42 PM

This should be fixed in the current point release of ImageMagick. Any idea how often we upgrade our ImageMagick library?

Ilmari_Karonen added a comment.Via ConduitSep 9 2009, 9:53 PM

This may lead to some bloat in thumbnail sizes -- there are images out there with huge embedded color profiles. See for example the discussion which originally made me commit r16811, http://en.wikipedia.org/w/index.php?diff=prev&oldid=79660167&diffonly=0, which mentions [[File:AsakusaShrine1443.jpg]] apparently containing a 174 kb ICC color profile.

kaldari added a comment.Via ConduitSep 23 2009, 6:25 PM

I think some file bloat in exceptional cases is OK. Most color profiles are only 3-5 kb. Considering how often people complain about their images looking different (especially skin tones) after uploading them to Commons, I think the trade-off will be worth it. There was just a new complaint about it yesterday, in fact:
http://commons.wikimedia.org/wiki/Commons:Village_pump#Flickr_pictures_and_skin_tones

brion added a comment.Via ConduitSep 23 2009, 7:53 PM

Ok, so ImageMagick 6.5.4-7 and later should transparently do this for us... If it's in a safe state to package that wouldn't be hard to update on the image boxes, in theory... :)

bzimport added a comment.Via ConduitApr 7 2010, 11:51 AM

jacobolus wrote:

So has this actually been applied to current Wikipedia, in the 6 months since? It seems like it hasn’t...

compare:

http://upload.wikimedia.org/wikipedia/en/f/fc/Jacobolus_spectrum.png

http://upload.wikimedia.org/wikipedia/en/thumb/f/fc/Jacobolus_spectrum.png/799px-Jacobolus_spectrum.png

bzimport added a comment.Via ConduitApr 7 2010, 12:00 PM

jacobolus wrote:

One more thing, and maybe this should be a separate bug, but it’s somewhat
related...

The SVG specification says that images are sRGB by default. It also has some
facilities for specifying other color spaces, etc., but for the most part the
SVG files I’ve seen have all been sRGB.

Anyway, at the very least, Wikipedia/Mediawiki should embed an sRGB profile in
PNG renders/thumbnails of typical SVG files. I believe that PNG files can
include an “sRGB chunk” which tells image consumers that they are in sRGB
space, and therefore avoids the need for a complete embedded profile. I’d guess
the default rendering intent would be Relative Colorimetric, but it might be
Perceptual – someone should check the SVG spec to be sure.

Anyway, it’d be nice to do enact that change (adding an sRGB chunk to PNG
renders of SVG images), because it would pretty much fix/standardize the color
of SVG images used in wikimedia projects across the board, overnight.

demon added a comment.Via ConduitApr 7 2010, 12:02 PM

Changing to Wikimedia issue since it's a shell request.

bzimport added a comment.Via ConduitApr 7 2010, 12:03 PM

jacobolus wrote:

compare:

http://upload.wikimedia.org/wikipedia/en/f/fc/Jacobolus_spectrum.png

http://upload.wikimedia.org/wikipedia/en/thumb/f/fc/Jacobolus_spectrum.png/799px-Jacobolus_spectrum.png

(Oh, just to be clear, you’ll need to be in a browser that does something with
images w/ color profiles, but doesn’t interpret untagged images as sRGB (for
instance, Safari on the Mac) to necessarily see a difference there.)

kaldari added a comment.Via ConduitJun 9 2010, 5:25 AM

Here's a much more dramatic example:

compare:

http://upload.wikimedia.org/wikipedia/commons/f/f6/Janne_Laurila_dbtl_ICC_test.jpg

http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Janne_Laurila_dbtl_ICC_test.jpg/600px-Janne_Laurila_dbtl_ICC_test.jpg

The original image is mostly red and green, while our thumbnail is purple and yellow. There are thousands of images on Commons with this problem, although generally not as dramatic as this example.

kaldari added a comment.Via ConduitJun 29 2010, 1:29 AM

Changing from enhancement to trivial bug, as this does actually cause incorrect display of images.

tstarling added a comment.Via ConduitAug 11 2010, 12:29 PM

I've deployed ImageMagick 6.6.2-6. Please test and confirm that the bug is fixed.

MZMcBride added a comment.Via ConduitAug 11 2010, 3:32 PM

Seems to be working as expected to me. Test cases from comment 15 and comment 19 are rendering correctly after being purged or by slightly altering the image width in the URL.

Thanks, Tim!

kaldari added a comment.Via ConduitAug 11 2010, 4:47 PM

Looks like it's fixed. The photographers at Commons will be happy. Thanks, Tim!

bzimport added a comment.Via ConduitAug 12 2010, 6:11 PM

jacobolus wrote:

Should I file a separate bug about SVG thumbnails not having the sRGB chunk set in them? It seems related to this.

kaldari added a comment.Via ConduitAug 12 2010, 6:17 PM

I don't think we're using ImageMagick for SVG thumbnails, so it should probably be a separate bug, as the solution will be completely different.

If I remember correctly, I think we're using rsvg for all SVG rendering.

bzimport added a comment.Via ConduitAug 12 2010, 7:21 PM

jacobolus wrote:

Okay, I added a bug, here: https://bugzilla.wikimedia.org/show_bug.cgi?id=24768

kaldari added a comment.Via ConduitAug 17 2010, 7:04 PM

I've noticed since the ImageMagick upgrade that thumbnails seem to look softer than before. Is it possible that the sharpening option got turned off accidentally during the upgrade? Or is it possible this is just a result of having the color profile information preserved?

AdamCuerden added a comment.Via ConduitAug 18 2010, 2:46 AM

Also, has the sharpening of JPEGs gotten turned off? New thumbnails look VERY soft.

MZMcBride added a comment.Via ConduitAug 18 2010, 2:50 AM

(In reply to comment #27)

I've noticed since the ImageMagick upgrade that thumbnails seem to look softer
than before. Is it possible that the sharpening option got turned off
accidentally during the upgrade? Or is it possible this is just a result of
having the color profile information preserved?

(In reply to comment #28)

Also, has the sharpening of JPEGs gotten turned off? New thumbnails look VERY
soft.

If you suspect that sharpening has issues now, please open a new bug report, preferably with links to examples of the problem. This bug report is about a specific issue (color profiles) that has been adequately addressed.

TheDJ added a comment.Via ConduitAug 18 2010, 1:32 PM
  • Bug 16140 has been marked as a duplicate of this bug. ***
brion added a comment.Via ConduitAug 6 2011, 8:52 AM
  • Bug 30214 has been marked as a duplicate of this bug. ***

Add Comment