I am porting an old eCommerce site to MVC 3 and would like to take advantage of design improvements. The site currently has product images stored in 3 sizes: thumbnail, medium (for display in a list) and expanded for a zoomed look. Right now we are having to upload 3 separate images that are sized exactly right, provide 3 different names that match what the site expects, etc., it is a pain.

I'd like to upload just 1 file, the large one, then let the site reduce it to needed sizes, and I'd like the flexibility to change the thumbnail and list sizes depending on user preferences, form factor (e.g. mobile, iPad, desktop), etc. so might need many copies of the same image. My question is should the image be reduced then saved several times upon upload and if so what is a good storage/naming convention?

The other idea is to store just the single image but resize it programmatically before serving it to the client. Has anybody done this and what are the tradeoffs besides a few more machine cycles? How do you pass a temporary image in memory to the client (there is no URL)?


I am lead developer for a UK-based travel company. One of the projects I implemented was a web version of our image library which can be queried automatically to provide photography for our site. It contains about 150k images, of which about 60-70k are available to the website (the highest rated).

We started off by defining about 5 sizes, creating these size versions on the fly and storing them in Amazon S3. Price was minimal but Amazon is built to fail gracefully, so we'd often see missing images. The more we developed our site, the more we hated only having five sizes of image available.

We moved to a dynamic resize model, in that we can add width and/or height parameters to the URI of any image to have it render in that size on the fly. We cache the resized image (using an MD5 hash of the request URI as filename).

To get image #12345 (our images are fetched via a db, but you could replace this with a file path) at width 200 and jpg quality 80%, the URI format would be:


This solution was easy to implement and works seamlessly - there is no discernable delay to the website visitor, even on pages with 20-30 images.

We're doing this all with .net, although I've also written a PHP image resize script which does the same thing.

Hope that helps, Adam

  • 1
    The funny thing to me is that the "anticipatory resizing" is, actually, a form of caching - just an extremely primitive and limited one. Caching after the first request is the usual approach, and - usually - the better one. The exception is when you'd otherwise be dealing with huge volumes of data all at once, which is probably not the case here.
    – Aaronaught
    Jun 23 '11 at 22:38
  • Brilliant @Adam (that's my best UK-speak), thank you for the thoughtful post. I'm off.
    – Steve
    Jun 23 '11 at 23:21

ImageProcessor ImageProcessor

Imageprocessor is a lightweight, extensible library written in C# that allows you to manipulate images on-the-fly using .NET

Resizing on the fly:

<!--Automatic height based on width-->
<!--Automatic width based on height-->
<!--Both dimensions specified-->
<!--Both dimensions specified with the image anchored to the top-->
<!--Height ratio passed for automatic scaling-->
<!--Width ratio passed for automatic scaling-->
<!--Background color added to padded image-->

ImageProcessor.Web comes with caching as standard. Any processed image are asynchronously cached both in the browser and on the server for a length of your choosing. The server cache intelligently stores millions of images and silently updates itself should the original image change or the cache expire.


Assuming that the thumbnail is simply a resized version of the main image, then I think it should be done at upload time, but perhaps scheduled as a background job so as not to impact other processes. If you resize on the fly, make sure you cache the image.

The catch in all of this is that the best thumbnail for some images is not a simple resize of the master; you may need to zoom-and-crop in a way that is human-driven. You might want to to the auto-resize thing, but have a mechanism that allows an override in these particular cases.


A slight variation on what Adam has mentioned:

(1) create a custom error page (rule for images)

(2) The structure of the image filenames should be:


The only exception is the original image and should be named:


(3) On file upload eg: 1245_Original -> all files with 1245_* should be deleted

(4) The custom error page (assuming that 1245_Original Exists) should create dynamically the requested image file eg:


and also serve it first time round.

In effect uploading a new image purges the cache.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.