Page MenuHomePhabricator

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 ?

Details

Reference
bz19960

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:40 PM
bzimport set Reference to bz19960.

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.

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?

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

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

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.

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"

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

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

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

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.

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

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

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.

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

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

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.

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

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

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!

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

jacobolus wrote:

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

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.

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?

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

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

  • Bug 16140 has been marked as a duplicate of this bug. ***
  • Bug 30214 has been marked as a duplicate of this bug. ***