Three approaches for obtaining different sized versions of an image from the server

Question

My android app needs different sized versions of images for different purpose and bandwidth preservation.

Approach one:

• when the user uploads their avatar or another image, my php script creates 4 versions of that image: mini_200, medium_300, big_400 and original. those paths are then taken and stored in the database. Then, when I need the smallest image, I load it from http://myserver.com/item_images/200_mini_27304lkewsjfimage.jpg

Approach two:

• same as approach one, but instead of adding prefixes to the names of the files, I store them in different folders - big, medium, mini. and in My app I just pass a parameter for which folder to look in

Approach three:

• when the user uploads their avatar or another image, I only store the original. Then, when I need the smallest image, I load if this way: http://myserver.com/image_resizer.php?image="93_iosdfj0sd9fj.jpg"&new_width=200&new_height=200

Which one is better and why? I feel like reinventing the wheel here, because this topic is too broad and I dont know where to read about it

Answer 1

Your first two options are similar. In your second solution, since you could have two files with the same name in different folders, I would recommend using the size as a suffix in the file name such as images/mini/user_image_1482823_mini.jpg, images/large/user_image_1482823_large.jpg.

Your third approach has an advantage in that it uses less disk space than the other two as well as not needing to manage sets of files and variants for all images, but it must resize images in the fly. This has the potential to cause performance problems if the source images are very large and there are many requests coming in for many different images of different sizes. You could deal with that by caching commonly requested images at different sizes. This may add a bit of complexity the overall architecture of the system, but could be a very good solution if implemented properly.

Since all of this activity would be happening on the server side, I don't thin it would affect your app too much. Your app would only ever submit one image and receive one image. Right?

Answer 2

You do not want to store static images within a GET query (i.e. a URL with a "?"), as most HTTP caches will not hold on to the results.

An improvement on option 3 would be to use custom routing so that a path like "/images/large/foo.gif" gets interpreted on the server as something like "/resize_image?size=large&name=foo.gif" (see your specific programming language, library framework and web server for details).

A further benefit of this mechanism is that you're now using a regular path structure that's easily shared between options #2 and #3 - the only difference is server-side configuration. That gives you the flexibility to trade off storage space and CPU time to obtain the best balance possible for your application.

Answer 3

It sounds like your third option is the simplest and requires the least storage, but is potentially also the slowest because the server will end up generating the same files over and over. Start with that method, but be prepared to switch to the first or second option if and when you find that the server is becoming taxed.