views:

177

answers:

1

I'm using attachment_fu and RMagick to upload/resize images on a rails app. Currently I use the local file system as the storage but I have a plan to use AWS S3 for the job. Anyway I am quite interested to know what other peoples' experiences on using S3 and also I have a one big question for you. In my app when a user uploads an image I resize this image to 5 different sizes and store them along with the original images. (altogether 6 images) based on thumbnail sizes provied in the model:

 :thumbnails => { 
                 "thumb" => "120x80",
                  "extra_small"=>"480x320",
                  "small"=>"640x480", 
                  "medium" => "800x533",
                  "large"=>"2738x1825", 
                  "extra_large" => "3464x2309" 

Finally I get:

  • image_foo.jpg (Original Image)
  • image_foo_thumb.jpg
  • image_foo_extra_small.jpg
  • image_foo_small.jpg
  • image_foo_medium.jpg
  • image_foo_large.jpg
  • image_foo_extra_large.jpg

The reason why I re-size these images is I need the actual sizes of each image to be stored in the database. But actually even I specified the sizes for thumbnails I don't get the exact sizes. Anyway its OK, as the size is calculated based on the aspect ratio.

But I really don't like to waste the space on the server if I can calculate the thumbnails sizes without saving them to the file system. In other words, I only need to store the original file not the thumbnails, but still I need to get the sizes of the thumbnails. Is it possible to get the actual thumbnail sizes without creating them in RMagick?

+2  A: 

Space on S3 is relatively cheap. So I wouldn't worry too much. However, you could consider converting the images to fewer sizes. You could leave small and extra-small out and use the width and height attributes of the HTML img tag. However, that will make your side load slower and cause more traffic.

I guess what you are really looking for is a solution that converts the files on the fly when they are requested right? I am not sure if there is a solution for that off the shelf. However, this would be a major performance suck.

So my recommendation is to just stick with all the different sizes and pay a few cent more to amazon. This will yield best performance and will be easiest to maintain. You don't have to worry about scaling and the fact that storage is getting cheaper and cheaper works for this solution.

ajmurmann
S3 is really quite cheap and the JPGs we are talking about here should be in the KB range, rather than MB or GB.If you are concerned, as amurmann mentions, picking a subset of the required sizes will work pretty well - allow the browser to resize to the exact pixel dimensions required.
Toby Hede
Thanks guys. It's a stock images app for photographers, so most of the images will be hi-res images. I understand that S3 is the best solution for this and I'm happy to stick with that. First I was thinking of storing only the original image on the S3 and generate and download the re-sized version of images for every use request. But that will consume more memory on the server as I use ImageMagick. As you suggests, Its better to re-size all of them at once and then store in S3.
randika