I just committed a change to Mephisto that makes Image Science the new default thumbnailer, instead of RMagick. What is Image Science?
ImageScience is a clean and happy Ruby library that generates thumbnails—and kicks the living crap out of RMagick. Oh, and it doesn’t leak memory like a sieve. :)
All I used RMagick for was thumbnailing. It seemed to wreak havoc with your memory, especially on shared hosts, so I commonly recommended disabling RMagick. In a few local tests, I watched the memory jump up to about 90MB from uploading < 1MB of images with RMagick. Yikes. ImageScience tears through them without much of a blip in memory usage.
Course, since no ruby host has ImageScience and FreeImage installed probably, you probably won’t see any benefits. Don’t worry, it should drop back to RMagick if it’s not installed, and should skip thumbnailing altogether if RMagick isn’t installed. You can customize this in environment.rb now too: ASSET_IMAGE_PROCESSOR = :image_science || :rmagick || :none (Only add :image_science, :rmagick, or :none).
Let me know how it works out. Also, I’d try hitting up your hosts and seeing if they’re up for installing FreeImage and ImageScience. I hope so, this covers probably the majority of RMagick usage, which is widely known to cause problems on shared hosts.
Awesome.
Does this mean http://svn.techno-weenie.net/projects/plugins/attachment_fu/ is ready for third party use?
Well, the tests pass. It’s mostly rearranged code and tests from acts_as_attachment, and has been in Mephisto for over a week. Last night I just made ImageScience the default processor, that’s all.
I am new to RoR and Mephisto and just starting to understand the issues associated with shared hosting. So i guess to clarify -
• Image Science means an over all increase in memory performance on shared hosting?
I would love to hear of some comparative results from those peeps who take Image Science for a spin.
Michael – in my tests, yes. From what I’ve seen, using RMagick makes the memory spike from about 40MB to 90MB. Now, this seems to be reclaimed by garbage collection soon after (by the next request even), but that’s enough to kill it on most Rails hosts. It’s still close to the limit for Textdrive (the only shared host with posted limits that I know of), so it probably won’t help that much. I of course would welcome any assistance in this area too :)
Ok, that’s great to hear Rick.
I am mid way through ‘Agile Web Dev with Rails’. So hopefully soon I will be able to contribute, something small anyways!
Mephisto rocks!
Hi Rick,
I think an easier solution would be to just use the mini_magick plugin: http://rubyforge.org/projects/mini-magick/
Or just borrow their technique of shelling out to the mogrify command.
I have been using this technique on my site for over 6 months on TextDrive and the memory usage stays well beneath the limits. For example, to resize an image to 100×100 and maintain the aspect ratio:
For MiniMagick:
Or for the command line:
Since all you need is the thumbnail I would say the direct command line way would be best for you.
ImageMagick’s default resampling filter used for image resizing is the Lanczos filter. For Image Science it’s bilinear filter. Bilinear is faster but it’s not the best for creating thumbnails of photographic images. It’s only possible to set Lanczos as the default by patching FreeImage source. It’s pretty straightforward though …
Tom: I’d love to have minimagick support in attachment_fu…
Martins: That decision came up when I asked Ryan Davis to include the resizing functions in ImageScience. He was dead set on keeping the gem simple, so decided to hardwire the filter choice. It may be worth being able to override it in Ruby without having to hack c though.
Hi Rick,
I won’t have time to dive into attachment_fu to add minimagick support in the next couple of weeks. However, I took a quick look and as far as I can tell all that is needed is the thumbnail code I listed above plus this code to get the width and height of an image:
Or alternatively you could just run the identify command directly like so:
If this still needs to be implemented by the time I get some free time I can try to take a stab at it.
Tom
Just my two cents – as one who has been plagued with image memory limits on TextDrive with Rails for almost two years… I love Tom’s idea of just shelling out to another app. I’ve done something like that myself, and it works far better than any Ruby library I’ve tried. It seems to me the biggest issue, by far, holding the brilliant Mephisto back from its well-deserved critical success (for what that’s worth) is this problem.
Anyway, no patch to offer at this time. Just my two cents. Anything but ImageMagick!!! Argh!
Rick,
I think there’s a memory leak in the image processor stuff – unfortunately, I haven’t been able figure out exactly where it is. (I’ve seen this happen without uploading any images at all, BTW). With the ASSET_IMAGE_PROCESSOR set to either :rmagick or :image_science, I’ve been seeing memory usage increase steadily while clicking around the admin UI. However, with the image processor turned off, memory usage stabilizes at around 58MB.
Cheers, Vivek
Is this in development or production?
This is in production.
Vivek – I did some investigation and didn’t see any memory leaks. Please continue this in this Mephisto group thread so we can hopefully figure out the cause of this.
Rick,
I’ve done some further testing as well, and it turns out that what I thought was a leak was in fact Rails 1.2’s larger footprint. Mephisto’s memory usage does indeed stabilize at around 60mb with the imagescience processor. Apologies for the wild goose chase!