Last modified: 2014-09-24 00:04:36 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T21073, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 19073 - Add support for using graphicsmagick instead of imagemagick for thumbnailing
Add support for using graphicsmagick instead of imagemagick for thumbnailing
Status: NEW
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
Blocks: multimedia
  Show dependency treegraph
 
Reported: 2009-06-03 23:04 UTC by Jools Wills
Modified: 2014-09-24 00:04 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
patch to implement a graphicsmagick option (3.44 KB, text/plain)
2009-06-04 00:32 UTC, Jools Wills
Details
add graphicsmagick option (3.44 KB, text/plain)
2009-06-04 00:37 UTC, Jools Wills
Details
add graphicsmagick option (3.47 KB, patch)
2009-06-04 12:53 UTC, Jools Wills
Details
add option for graphicsmagick support (3.48 KB, patch)
2009-06-04 13:01 UTC, Jools Wills
Details

Description Jools Wills 2009-06-03 23:04:21 UTC
Graphicsmagick (http://www.graphicsmagick.org/) is a fork of imagemagick, that is smaller, faster and has more api stability. It also seems to have improved documentation (or at least it has examples and descriptions in the man file that imagemagick does not)

example performance chart:

http://rmagick.rubyforge.org/resizing-charts.html

it comes with a compatibility package to provide the imagemagick convert/mogrify etc commands but has dropped some of the imagemagick shortcuts like "-thumbnail"

to thumbnail on graphicsmagick you would do

gm convert -size 120x120 cockatoo.jpg -resize 120x120 +profile "*" thumbnail.jpg

the -thumbnail on imagemagick is a shortcut to "-resize 120x120 -strip". GraphicsMagick integrates the -strip with the profile option that already is there to manage image profiles

It is quite easy to add support for this. I made a quick patch for my system, however I would think it might be better to actually replace imagemagick with graphicsmagick (for the reasons listed above). If it was to be added as an option, would you prefer a new set of config options or to modify how the current ones are used? also would you prefer it was handled in a separate "if" block or merged with the current imagemagick support?

I vote for switching to graphicsmagick anyway.
Comment 1 Jools Wills 2009-06-03 23:19:56 UTC
I have just seen that in defaultsettings it refers to using customconvert command for example with graphicsmagick. However, this doesn't make it as easy as not everyone will know about the various workaround in imagemagick (such as white background for older browsers on transparent images), that would also apply to graphicsmagick.
Comment 2 Jools Wills 2009-06-04 00:32:20 UTC
Created attachment 6190 [details]
patch to implement a graphicsmagick option

Here is my patch against 1.14.0 that implements a new variable $wgUseGraphicsMagick.
It uses the config values from the imagemagick config like

$wgUseGraphicsMagick = true;
$wgImageMagickConvertCommand = "/usr/bin/gm";

This is just one way to implement it, and I'm not suggesting it is the best way.
it is more useful than using the custom command as it handles the differing compression for png/jpeg quality as well as other workarounds for animated gifs etc.
Comment 3 Jools Wills 2009-06-04 00:37:25 UTC
Created attachment 6191 [details]
add graphicsmagick option

I had accidentally replaced thumbnail with resize for imagemagick. oops
Comment 4 Siebrand Mazeland 2009-06-04 11:46:24 UTC
Patches should be against trunk (most recent development version). 1.14.0 is based on r45489, while trunk is at r51464 (1.16alpha). You patch does not apply in a clean way. Please provide an updated patch.
Comment 5 Jools Wills 2009-06-04 12:41:34 UTC
Sorry. I didn't consider that it would be accepted anyway, but for reference so get any feedback on what would be the "right" way to implement this (and to get comments on whether it should be the default)
Comment 6 Jools Wills 2009-06-04 12:53:04 UTC
Created attachment 6196 [details]
add graphicsmagick option

Updated patch to apply against trunk
Comment 7 Siebrand Mazeland 2009-06-04 12:56:11 UTC
Thanks. The patch applies cleanly now. Added keyword 'need-review'.
Comment 8 Jools Wills 2009-06-04 13:01:47 UTC
Created attachment 6197 [details]
add option for graphicsmagick support

cleanup. was missing a tab
Comment 9 Brion Vibber 2009-06-23 00:01:20 UTC
Hm, it'd probably be wise to break up the thumbnailing code to make it easier to extend. We've got a loooot of things in this big giant if/switch block. :)
Comment 10 Bryan Tong Minh 2009-11-12 22:16:29 UTC
(In reply to comment #9)
> Hm, it'd probably be wise to break up the thumbnailing code to make it easier
> to extend. We've got a loooot of things in this big giant if/switch block. :)
> 
Do you suggest not applying this patch until somebody rewrites that code or apply it and hope somebody will clean it up someday?
Comment 11 Jools Wills 2011-11-22 02:44:08 UTC
I'm still happy to rework the patch. just got a notification as this bug was tweaked and reverted perhaps by accident, but I think this is still a good issue. for my and my wiki personally, the switch was a significant performance increase.
Comment 12 Bryan Tong Minh 2011-11-22 08:38:18 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > Hm, it'd probably be wise to break up the thumbnailing code to make it easier
> > to extend. We've got a loooot of things in this big giant if/switch block. :)
> > 
> Do you suggest not applying this patch until somebody rewrites that code or
> apply it and hope somebody will clean it up someday?

Note, did this some months ago. So the patch won't apply without significant rework effort.
Comment 13 Sumana Harihareswara 2012-08-17 19:45:25 UTC
CC'ing a few people to ask whether this question/issue something we should follow up on.
Comment 14 Bawolff (Brian Wolff) 2012-08-17 20:26:21 UTC
(In reply to comment #13)
> CC'ing a few people to ask whether this question/issue something we should
> follow up on.

You mean supporting graphikmagic? I would call it a low priority issue. If someone wants to write support/adapt the patch on this bug, by all means, but we already support several thumbnailers, so not something to spend large effort on, unless someone is specifically independently interested
Comment 15 Jools Wills 2012-08-17 23:50:01 UTC
it's very similar to imagemagick so I don't think it should be a massive issue to integrate it. I already made a patch before (here) which I realise is no longer good with the current codebase. I may well update it, but then, it would be good to know if it would be accepted so I'm not wasting any time. It's worth noting, when using graphicsmagick before, thumbnailing was significantly faster on my hardware at the time, however this was some time ago.
Comment 16 Jarry1250 2012-08-20 11:14:58 UTC
I think it would be worth changing the focus of any patch to the definition of a global with a string input rather than multiple booleans, similar to the way we handle SVG conversion at the moment. Then, $wgUseImageMagick could be deprecated and the whole thing would be more future proof.

If that were the case, I can't see any reason not to merge a patch that added support for an alternative renderer but didn't even seek to make it the default.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links