Last modified: 2014-09-24 00:04:36 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.
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.
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.
Created attachment 6191 [details] add graphicsmagick option I had accidentally replaced thumbnail with resize for imagemagick. oops
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.
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)
Created attachment 6196 [details] add graphicsmagick option Updated patch to apply against trunk
Thanks. The patch applies cleanly now. Added keyword 'need-review'.
Created attachment 6197 [details] add option for graphicsmagick support cleanup. was missing a tab
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. :)
(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?
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.
(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.
CC'ing a few people to ask whether this question/issue something we should follow up on.
(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
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.
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.