Why was RMagick replaced?

[Shannon Carey]

Hi,

I'm trying to improve the performance of our Dragonfly-based image service. One of the ideas was to use a Ruby binding to ImageMagick rather than shelling out to a separate process. However, I see in the history that Dragonfly used to use RMagick, but it was removed in preference of the command-line approach.https://github.com/markevans/dragonfly/commit/922dfa738e304c02f0f4646a1be1fc4fafad542c

From my research, I can see three possible reasons for abandoning RMagick:

1. At the time of removal, it appears RMagick had been stale for one year. At this point, most of RMagick has been static for 3 years.
2. A post to this group mentions RMagick causing segfaults. The RMagick issue tracker also mentions segfaults.
3. Memory usage. High memory usage is the reason cited for authorship of mini_magick gem: https://github.com/minimagick/minimagick
   

However, I am curious to hear the reasons directly from Mark Evans (or someone who knows the history) if possible! I don't want to try using RMagick if other people have already determined it's a bad idea.

Thanks!
-Shannon

[Aidan Feldman]

What, those aren't enough reasons? :-)

P.S. I'd love to see the ImageMagick wrapper extracted from Dragonfly into a separate project.  It's only one part of the project, but is useful on it's own - if you don't need to handle file upload, for example.

P.P.S. We've had do so some workarounds in magickly to collapse convert statements into single commands, and to avoid calling `identify` at intermediate steps of multiple convert operations.  While making things a little more complex under the hood, it was a huge boost in performance, because ImageMagick doesn't need to decode/encode the file multiple times.  Would love to move this work back into Dragonfly if there's interest.

-Shannon

--
You received this message because you are subscribed to the Google Groups "Dragonfly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dragonfly-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Shannon Carey]

Those are enough reasons for me. I'm just not sure if they were the actual reasons. Maybe there were even more reasons. Or maybe segfaults/memory usage aren't really an issue.

RE: your P.P.S.: That looks very interesting, and it would be great to get it into Dragonfly at some point if possible. For example, we are performing a crop centered on a certain point (with the poorly named/misleading ':thumb' operation), and then subsequently resizing that (again with :thumb) to our desired dimension(s). Ideally, however, we'd be able to -crop and -resize in the same command. :thumb should be removed from Dragonfly imo, and the API changed to more closely match ImageMagick. I hadn't even noticed that we might actually be running 'identify' multiple times as well. Is that functionality complete in Magickly? Do you support the anti-DOS approach that Dragonfly has?

Thanks very much for your response!

[Aidan Feldman]

It's only complete for the Dragonfly commands we've overridden (otherwise I think it falls back to the default behavior), but we could be doing it in a much more generalized way.

Open issue regarding DoS in Magickly:

https://github.com/afeld/magickly/issues/26

[parndt]

I was around at the time and, if I recall correctly, RMagick was causing a great deal of pain when getting Dragonfly running on various systems. Replacing this with the direct ImageMagick bindings has GREATLY simplified using Dragonfly and in my opinion has made it more reliable and predictable.

[Mark Evans]

yes - all of the reasons stated above!

it's a great library I'm sure for many things but it was too unreliable across different systems, and despite using the common advice on avoiding memory leaks, it still seemed to have them.

@shannon you can use the "convert" method http://markevans.github.io/dragonfly/file.ImageMagick.html#Shortcuts to use convert a little bit more directly (see https://groups.google.com/forum/#!topic/dragonfly-users/sgOs7xat1a8)