Fixed

• I finally tracked down a simple, yet elusive performance bug  that was particularly problematic for users with many thousands of images. Performance should be much better for everyone now, so upgrading is highly suggested.  This bug was introduced with version 2.0., and caused a filesystem listing hit for each request.
• All requests are now forced to pass through the UrlAuthorizationModule now. Previously, any URL rewriting (like customfolders.cs) caused URL auth rules to be circumvented. This was documented behavior, but a secure solution has now been found.

Added

• New users will find it much easier to get things working – Messing with IIS is now completely optional!
  Instead of writing  “image.jpg?width=500″ as you normally would, type “image.jpg.axd?width=500″. If you use the new syntax, you won’t be forced to configure wildcard mapping on IIS6/IIS7 classic.
  Both syntaxes will be supported in the future.
  The suggested extension is .axd, but that can be changed or disabled using the ResizeExtension application setting.
  
• Dithering support added! You can dither an 8-bit image using the ?dither= command. You can specify a dither percent, “true”, or “4pass”.
• UploadSample  project (in VB). Resizing images as they are uploaded is now trivally easy. ImageManager.BuildImage now accepts an HttpPostedFile instance for resizing.
• DisableCustomQuantization setting to allow GIFs to be generated on servers where the Marshal class is prohibited.
• PerfTests project to run benchmarks on the image resizing and encoding code.

Upgrade proccess

1. Replace the old files with the new files from the ImageResizer folder. If you are using the .DLL, replace the DLL in the bin folder. Keep your old CustomFolders.cs and WatermarkSettings.cs files if you have modified them.
2. Delete the /imagecache directory.
3. Insert/change the following application settings in web.config if you want to use the new syntax.

<add key="ResizeExtension" value=".axd"/>

<add key="AllowURLRewriting" value="true"/>

If you are upgrading from 1.2, follow the 1.2->2.0 upgrade instructions first.

Read 20 Image Resizing Pitfalls first (part 1). It explains why you need an HttpModule instead of an HttpHandler, why disk caching is a requirement, and why you always want to let IIS serve static files.

This article gives an architectural overview of my image resizer. The design has evolved several times as my needs grew, but I think the design has now matured to be very simple, modular, and extensible.

Request flow

1. Only intercept image requests that include certain querystring commands. Leave other requests intact.
2. Check to see if the resized image for the request URL is already cached. If cached and still up-to-date with the source file, goto step 4.
3. If not already cached, process the image and cache it.
4. Rewrite the request (not redirect) to the cached file. This will allow IIS to serve the file with full HTTP support (range requests, caching, not-modified support, etc).

A few other goals

1. Allow custom syntaxes like /resize(50,50)/image.jpg or ?theme=smallthumb to be easily added without bloating the core module.
2. Permit or disable filename rewriting from Web.config. /resize(50,50)/ would be path rewriting, wheras ?theme=smallthumb would be just rewriting the querystring. This configurability is important, since path rewriting could make subfolder-based web.config authorization settings on image files have no effect.
3. Allow client caching time to be configurable. This will keep requests down, since clients won’t check for updates until the specified amount of time expires.
4. Make both server-side memory and disk caching invalidate when the source file changes.
5. Allow a easily extensible and large set of commands, affecting the cropping/sizing, visual effects, color choices/border/padding, and image output format/compression.
6. Prevent DOS attacks by limiting the disk cache to a configurable number of images.
7. Allow easy watermarking or post-processing of resized images

Overview of classes

With these goals in mind, I found it optimal to segment the logic into the following classes. While you may question my decision to split querystring parsing into 4 classes, it resulted in much cleaner code, and a much more usable interface for image manipulation from other classes.

• InterceptModule
  IHttpModule that checks for relevant requests during PostAuthorizeRequest, caches the ImageManger-proccessed images using DiskCache, and rewrites the request to the cached file. It also sets HTTP caching headers later in PreSendRequestHeaders. The disk-cached filename is an SHA256, base16 encoded hash of the request URL. Although the image is coming from a different file, the user never sees the URL of the cached file – the original filename is maintained.
• DiskCache

  Completely abstracts away disk caching, cleanup, and the associated threading issues. InterceptModule calls method UpdateCachedVersionIfNeeded(sourceFile,cachedFile, delegate updateMethod, int fileLockTimeout) with ImageManager.getBestInstance().BuildImage(sourcePath, cachedPath, queryString); as the contents of the delegate. DiskCache performs the modified date checks, cache cleanup, and thread locking to prevent the same image from being resizied by two different threads at the same time (it happens frequently!). The delegate is only executed if the cached file needs to be created or updated.

• CustomFolders
  Exposes a single method, static string processPath(string filePath, NameValueCollection q). This allows both URL rewriting and modifications to the querystring, such as /resize(w,h)/ syntax. InterceptModule simply calls this once prior to checking the querystring for valid commands.
• ImageManager

  exposes several overloads of a method called BuildImage() which allow both querystring and settings class configuration, and both bitmap and filename source and output. While BuildImage performs all the actual GDI calls, the querystring parsing, mathematics, and image writing are handled by other classes below.

• ResizeSettings(querystring)
  Accepts a single NameValueCollection (Querystring) as the constructor argument. Stretch, crop, scale, flip, sourceFlip, width, height, maxwidth, and maxheight are parsed into member variables. Exposes a ImageSizingData CalculateSizingData(SizeF originalImageSize, SizeF maxBounds) method that handles all mathematics. ImageSizingData includes the source rectangle on the image to copy from, the destination polygon for the image data, and a polygon that includes any whitespace.
• ImageOutputSettings(querystring)

  Parses the format, colors, and quality commands. It also exposes a SaveImage(Stream s, Image i) method that handles the writing of the various image types based on the querystring arguments. Static methods for saving images are also available.

• ImageSettings(querystring)
  Parses the bgcolor, paddingWidth, paddingColor, borderWidth, and borderColor commands. BuildImage() uses this data when drawing the image.
• WatermarkSettings(querystring)
  allows for custom drawing on images. It exposes a ModifySettings(ResizeSettings rs, ImageSettings opts, ImageFilter adjustments, ImageOutputSettings ios) method for adjusting settings prior to resizing, and a Process(Bitmap b, Graphics g) method for post-processing of resized images.

InterceptModule code

I hope this overview is clear enough – if not, please leave a question below. Understanding the design, the source code for InterceptModule should now make sense. Thankfully, this is one of the shortest classes, but it should help you write your own HttpModule. I’ve removed the class declaration, imports, and profiling code for clarity. The original source code comments explain everything pretty clearly.

/// <summary>
/// This is where we filter requests and intercet those that want resizing performed.
/// We first check for image extensions...
/// If it is one, then we run it through the CustomFolders method to see if if there is custom resizing for it..
/// If there still aren't any querystring params after that, then we ignore the request.
/// If the file doesn't exist, we also ignore the request. They're going to cause a 404 anyway.
///
/// </summary>

/// <param name="sender"></param>
/// <param name="e"></param>
protected virtual void CheckRequest_PostAuthorizeRequest(object sender, EventArgs e)
{
	//Get the http context, and only intercept requests where the Request object is actually populated
	HttpApplication app = sender as HttpApplication;
	if (app != null && app.Context != null && app.Context.Request != null)
	{

		//Is this an image request? Checks the file extension for .jpg, .png, .tiff, etc.
		if (ImageOutputSettings.IsAcceptedImageType(app.Context.Request.FilePath))
		{
			//Init the caching settings. These only take effect if the image is actually resized
			//CustomFolders.cs can override these during processPath
			app.Context.Items["ContentExpires"] = DateTime.Now.AddHours(24); //Default to 24 hours
			string cacheSetting = ConfigurationManager.AppSettings["ImageResizerClientCacheMinutes"];
			if (!string.IsNullOrEmpty(cacheSetting)){
				double f;
				if (double.TryParse(cacheSetting,out f)){
					if (f >= 0)
						app.Context.Items["ContentExpires"] = DateTime.Now.AddMinutes(f);
					else
						app.Context.Items["ContentExpires"] = null;
				}
			}

			//Copy the querystring
			NameValueCollection q = new NameValueCollection(app.Context.Request.QueryString);

			//Call CustomFolders.cs to do resize(w,h,f)/ parsing and any other custom syntax.
			//The real virtual path should be returned (with the resize() stuff removed)
			//And q should be populated with the querystring values
			string basePath = CustomFolders.processPath(app.Context.Request.Path, q);

			//If the path has changed, this will circumvent the URL auth system.
			//Make sure the user has explicity allowed it through web.config
			if (!basePath.Equals(app.Context.Request.Path))
			{
				//Make sure the resize() notation is allowed.
				string allow = ConfigurationManager.AppSettings["AllowURLRewriting"];
				if (string.IsNullOrEmpty(allow)) allow =ConfigurationManager.AppSettings["AllowFolderResizeNotation"];
				if (string.IsNullOrEmpty(allow) || allow.Equals("false", StringComparison.OrdinalIgnoreCase)){
					return; //Skip the request
				}
				//Prevent access to the /imagecache/ directory (URL auth won't be protecting it now)
				if (new yrl(basePath).Local.StartsWith(DiskCache.GetCacheDir(), StringComparison.OrdinalIgnoreCase))
				{
					throw new HttpException(403, "Access denied to image cache folder.");
				}
			}
			//See if resizing is wanted (i.e. one of the querystring commands is present).
			//Called after processPath so processPath can add them if needed.
			//Checks for thumnail, format, width, height, maxwidth, maxheight and a lot more
			if (ImageManager.getBestInstance().HasResizingDirective(q))
			{
				//Build a URL using the new basePath and the new Querystring q
				yrl current = new yrl(basePath);
				current.QueryString = q;

				//If the file exists, resize it
				if (current.FileExists)
					ResizeRequest(app.Context,current);

			}
		}
	}
}

/// <summary>

/// Builds the physical path for the cached version, using the hashcode of the normalized URL.
/// </summary>
/// <param name="request"></param>
/// <returns></returns>
protected string getCachedVersionFilename(yrl request)
{
	string dir = DiskCache.GetCacheDir();
	if (dir == null) return null;
	//Build the physical path of the cached version, using the hashcode of the normalized URL.
        //We don't use String.GetHashCode(), since it returns a 32-bit integer. Chances of a hash collision are low, but possible.
        // So, we use a 256-bit hash instead.
	SHA256 h = System.Security.Cryptography.SHA256.Create();
	byte[] hash = h.ComputeHash(new System.Text.UTF8Encoding().GetBytes(request.ToString().ToLower()));
	//Can't use base64 hash... filesystem has case-insensitive lookup.
	//Would use base32, but too much code to bloat the resizer. Simple base16 encoding is fine
	return dir.TrimEnd('/', '\\') + "\\" + Base16Encode(hash) + "." + new ImageOutputSettings(request).GetFinalExtension();
}
/// <summary>

/// Returns a lowercase hexadecimal encoding of the specified binary data
/// </summary>
protected string Base16Encode(byte[] bytes)
{
	StringBuilder sb = new StringBuilder(bytes.Length * 2);
	foreach (byte b in bytes)
		sb.Append(b.ToString("x").PadLeft(2, '0'));
	return sb.ToString();
}

/// <summary>
/// Generates the resized image to disk (if needed), then rewrites the request to that location.
/// Perform 404 checking before calling this method. Assumes file exists.
/// Called during PostAuthorizeRequest
/// </summary>
/// <param name="r"></param>
/// <param name="extension"></param>

protected virtual void ResizeRequest(HttpContext context, yrl current)
{
	//This is where the cached version goes
	string cachedFile = getCachedVersionFilename(current);

	//Disk caching is good for images because they change much less often than the application restarts.

	//Make sure the resized image is in the disk cache.
	bool succeeded = DiskCache.UpdateCachedVersionIfNeeded(current.Local, cachedFile,
		delegate(){

			//This runs if the update is needed. This delegate is preventing from running in more
			//than one thread at a time for the specified source file (current.Local)
			ImageManager.getBestInstance().BuildImage(current.Local, cachedFile, current.QueryString);
		},30000);

	//If a co-occurring resize has the file locked for more than 30 seconds, quit with an error.
	if (!succeeded)
		throw new ApplicationException("Failed to acquire a lock on file \"" + current.Virtual +
                                              "\" within 30 seconds. Image resizing failed.");

	//Get domain-relative path of cached file.
	string virtualPath = yrl.GetAppFolderName().TrimEnd(new char[] { '/' }) + "/" + yrl.FromPhysicalString(cachedFile).ToString();

	//Add content-type headers (they're not added correctly when the source URL extension is wrong)
	//Determine content-type string;
	string contentType = new ImageOutputSettings(current).GetContentType();

	context.Items["FinalContentType"] = contentType;
	context.Items["FinalCachedFile"] = cachedFile;

	//Rewrite to cached, resized image.
	context.RewritePath(virtualPath, false);
}
/// <summary>

/// We don't actually send the data - but we still want to control the headers on the data.
/// PreSendRequestHeaders allows us to change the content-type and cache headers at excatly the last
/// second. We populate the headers from context.Items["FinalContentType"],
/// context.Items["ContentExpires"], and context.Items["FinalCachedFile"].
/// This also indirectly enables server-side mem caching. (HttpCacheability.Public does it)
/// We set the file dependency to FinalCachedFile so changes are update quickly server-side
/// - however, clients will not check for updates until ContentExpires occurs.
///
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>

protected void context_PreSendRequestHeaders(object sender, EventArgs e)
{
	HttpApplication app = sender as HttpApplication;
	HttpContext context = (app != null) ? app.Context : null;
	//Check to ensure the context and Response is in good shape (it's needed)
	if (context != null && context.Items != null && context.Items["FinalContentType"] != null
                          && context.Items["FinalCachedFile"] != null)
	{
		//Clear previous output
		//context.Response.Clear();
		context.Response.ContentType = context.Items["FinalContentType"].ToString();
		//Add caching headers
		context.Response.AddFileDependency(context.Items["FinalCachedFile"].ToString());

		//It's not UTC - server time zone.
		if (context.Items["ContentExpires"] != null)
			context.Response.Cache.SetExpires((DateTime)context.Items["ContentExpires"]);

		//Enables in-memory caching
		context.Response.Cache.SetCacheability(HttpCacheability.Public);
		context.Response.Cache.SetLastModifiedFromFileDependencies();
		context.Response.Cache.SetValidUntilExpires(false);
	}

}

I’m sure a lot of people will think I’m nuts for posting the source code to the main class of my image resizer,
but I know that this will help a lot of people.

Based on the response I get to this article, I may continue with additional parts. I would like to cover the math behind scaling and cropping, the GDI bugs, and maybe even image output/compression.

Hope this helps!
Nathanael

Installation is the same as for the full version.

Download Trial version and sample project (4MB)

When you upgrade to the full version, remember to delete the imagecache directory, or you will continue to see the word “Unlicensed” on old pictures.

So why am I writing another?

Because each article I have read includes one of the errors below, leading readers to write either
slow, insecure, or incorrectly functioning code. I have discovered many of these pitfalls the hard way.
I hope others won’t have to.

Instead of giving step-by-step instructions, this article will simply list pitfalls and the alternatives. I hope to publish my approach in a Part 2.

Security and Performance Pitfalls

1. Not using using(){}. You *must* wrap your Graphics, Bitmap, and MemoryStream objects
   in a using(){} clause, or else they will not get cleaned out of memory for a while.
   Under load this can cause *serious* issues. Read
   
   to dispose, or not to dispose, that’s the 1GB question if you have
   any doubts regarding the severity of this error.

   If you find yourself nesting a lot of using(){} statements, you can also use equivalent try{}finally{} code.

   //Using method. object must implement IDisposable for this to work
   using (object a = new object())
   {
       using (object b = new object())
       {
           using (object c = new object())
           {
   
           }
       }
   }
   
   //Try finally method
   object a = null;
   object b = null;
   object c = null;
   try
   {
       a = new object();
       b = new object();
       c = new object();
   }
   finally
   {
       if (a != null) a.Dispose(); //If one of the Dispose methods throws an error, the others will not execute.
       if (b != null) b.Dispose(); //So there is an advantage to using nested using(){} clauses
       if (c != null) c.Dispose(); //You could nest try{} finally{ try{} finally{ try{} finally{}}} to solve that...
       //Two different techniques - take your pick
   }
   

2. Using on-the-fly image resizing without disk caching! The ASP.NET
   memory cache won’t cut it here folks – it gets cleaned out every application reboot,
   and besides, you probably have more images than RAM. Resizing an image is fast,
   but it will still flood the CPU if a single user browses a single page with 20 or more
   resized images on it. This is a do-it-yourself
   DOS attack. On-the-fly resizing is fine if you have disk caching.
3. Not using on-the-fly resizing. This one bites also. If you decide to convert all
   your images up-front, please realize how difficult it will be to track down the
   originals and resizing them again next time you make a resolution jump. I’ve been
   through this enough, and it’s painful – that’s why I wrote a dynamic image resizer!
4. Disk-caching without checking for updated (or reverted!) source files. Debugging
   a resized image that won’t update can eat up lots of time. Make sure you set the
   LastWriteTimeUTC on your cached images to match the source image file (and check
   they match) – don’t simply check to see if the source file is newer than the cached
   file, since that will break if you copy an older file over a source image. Always
   use something like RoughCompare() to compare filesystem dates – *never* inequalities.
   Remember that filesystem dates are less precise than DateTime, and get rounded.

   /// <summary>
   /// Returns true if both dates are equal (to the nearest 200th of a second)
   /// </summary>
   /// <param name="modifiedOn"></param>
   /// <param name="dateTime"></param>
   /// <returns></returns>
   private static bool RoughCompare(DateTime d1, DateTime d2)
   {
   	return (new TimeSpan((long)Math.Abs(d1.Ticks - d2.Ticks)).Milliseconds <= 5);
   }
   

5. Disk-caching without cleanup! Another do-it-yourself
   DOS attack, although not quite as bad as the first. Left unchecked, your cache
   directory could grow very large over a few years as orphaned
   image versions accumulate. If a malicious visitor realizes that you have automatic resizing,
   he could try to fill up your hard drive by requesting an endless variety of resolutions
   for a given image. Of course, security-conscious developers will have cache-limiting
   systems in place. I suggest cleaning out the least recently used 10-20% of the cache
   directory whenever the file limit is reached. Handle locked files gracefully.
6. Checking the cache size for cleanup every image request. This will swamp your I/O.
   Instead of running that directory listing each time, keep a static counter that tracks how many new images have been resized
   since the application started. Run the cache cleanup on the first image request and each time the counter passes the cleanup threshold.
7. Disk caching without protecting the cache directory. Unless you want anonymous users to potentially view the same images
   as authorized users, you need your cache directory locked down. A Web.config file in the directory can do this – just verify your URL rewriting rules
   don’t leave another way to access the directory.

   The cache directory needs to stay inside the application to permit request rewriting to the cached files.

8. Disk caching without proper locking code. This is a minor problem, since the
   consequences are light – but it is good to remember that 2 image requests for the
   same image size could happen at the same time, and (if they aren’t cached), they
   may conflict when trying to write to the same file at the same time. You’ll probably
   get a “The process cannot access the file because it is being used by another process.”
   message if this happens. You can prevent this by creating a locking system so that
   only one thread can save a give resized image at a time. Optimally, you want multiple resizes for different images to occur at the same time. If you’re
   not as concerned about concurrency performance as I was, you could cheat at make the whole resizing method locked. (For new image requests only!)
9. Writing directly to the output stream. If you’re caching to disk, but still serving
   the image contents in code, you’re only supporting a little bit of the HTTP standard,
   and you’re bypassing all of the work Thomas
   Marquardt did to bring StaticFileHandler up to snuff . Implement your resizer
   as and HttpModule, not an HttpHandler or you’re stuck.
10. Serving a file from disk by loading it into memory. Think about how much RAM your server has,
    how large a single image is, how long
    it has to stay in memory before users finish downloading it, and how many users
    you have requesting images. Don’t load anything into memory after the initial resize.

    WriteFile()
    serves directly from disk, and is *much* safer and more efficient. However – you
    shouldn’t be using WriteFile() either if you can avoid it. Letting StaticFileHandler
    do its job is a much better choice.

11. Making an HttpHandler instead of an HttpModule. I actually did this in
    v1.0, and it was a *mess*, as well as being non-optimal from a performance standpoint.
    There are several problems with doing this as an HttpHandler.
    1. It’s very difficult to make an HttpHandler catch only *some* requests (i.e., those
       requesting resizing), for a certain extension. It’s very hard, in fact, and involves
       subclassing DefaultHttpHandler and re-implementing a lot of code. While that’s possible
       on IIS5/6/7 classic, it doesn’t work on IIS7 Integrated. So IIS7 integrated is a
       complete deal-breaker if you want to let standard images alone.
    2. It’s difficult to pass a request from one HttpHandler to another. When building
       an image resizer, we don’t want to be responsible for serving the resized file,
       just making sure the resized version has been cached to disk, and then rewriting
       the request to point to that file. An HttpModule, on the other hand, is perfectly
       suited to checking for image resize requests, caching the results, and rewriting
       the request so StaticFileHandler or whatever is the default in IIS 8 , 9, or 10
       can take of it. I do this in PostAuthorizeRequest, by calling context.RewritePath(virtualPath, false);
12. Not setting context.Response.ContentType properly. You’ll get all kinds of interesting,
    varied, and peculiar results from browsers if you omit this step. Things can be really
    interesting if the format is changed during the resize, since the extension will
    match the original format.
13. Obvious, but you should have caching enabled for your images, regardless
    of whether they are being resized or not. Disk caching is great, but memory caching allows for even faster responses to frequently requested images, and shouldn’t be omitted.
    In addition, HttpCacheability.Public enables client and proxy caching too, so browsers and some firewalls will cache the result from the server. You can adjust the amount of time
    the files are cached with SetExpires.

    This is the code I use during PreSendRequestHeaders

    HttpApplication app = sender as HttpApplication;
    HttpContext context = (app != null) ? app.Context : null;
    
    if (context != null && context.Items != null && context.Items["FinalContentType"] != null && context.Items["FinalCachedFile"] != null)
    {
    	//Clear previous output
    	//context.Response.Clear();
    	context.Response.ContentType = context.Items["FinalContentType"].ToString(); //FinalContentType is set to image/jpeg or whatever the image mime-type is earlier in code.
    	//Add caching headers
    	context.Response.AddFileDependency(context.Items["FinalCachedFile"].ToString());
    
    	if (context.Items["ContentExpires"] != null)
    		context.Response.Cache.SetExpires((DateTime)context.Items["ContentExpires"]); //ContentExpires is set to DateTime.Now.AddMinutes(x), where x is how long the clients should locally cache the image before checking for updates.
    
    	//Enables in-memory caching
    	context.Response.Cache.SetCacheability(HttpCacheability.Public);
    	context.Response.Cache.SetLastModifiedFromFileDependencies();
    	context.Response.Cache.SetValidUntilExpires(false);
    }
    

14. Accepting the file path as a querystring parameter. This mistake makes me cringe
    – I find it amazing each time how much people trust their filtering code to prevent
    abuse of this feature. (If they have path filtering code at all!) Just… don’t…
    do it… please. Do you know how many ways there are to encode filenames and circumvent
    pattern-matching techniques? Yes, there are ways to protect this kind of system, but why?

    Why choose /resizeimage.ashx?path=~%2fimg%2fproducts%2fbox.jpg&maxwidth=100&maxheight=100
    over /img/products/box.jpg?maxwidth=100&maxheight=100 ?

    If you’re stuck in IIS6 and you aren’t allowed to modify handler mappings, you should look for a better host.

Pitfalls in Image Resizing

1. Using GetThumbnailImage().
   GetThumbnailImage() seems the obvious choice, and many articles recommend its
   use.
   Unfortunately, it always grabs the embedded jpeg thumbnail if present.
   Some photos have these, some don’t – it usually depends on your camera. You’ll wonder
   why GetThumbnailImage works good on some photo, but on others is horribly
   blurred. GetThumbnailImage() isn’t reliable for photos larger than 10px by 10px for that reason.
2. Forgetting to set InterpolationMode, SmoothingMode, CompositingQuality, and PixelOffsetMode.
   With all these set properly, you
   should be able to get resized images indistinguishable from Photoshop results. If
   you don’t, you’ll end up with trash. GDI has dumb defaults. (BTW, the low-quality
   settings aren’t always much faster)
   This article explains why those are needed to make DrawImage compose the
   image well.

   graphics.InterpolationMode = InterpolationMode.HighQualityBicubic;
   graphics.SmoothingMode  = SmoothingMode.HighQuality;
   graphics.CompositingQuality = CompositingQuality.HighQuality;
   graphics.PixelOffsetMode = PixelOffsetMode.HighQuality;
               

3. Not maintaining aspect ratio. I see this often, and I’m not sure why – the math
   isn’t too hard. Well, for those who are wondering how, I hope this code is rather
   transparent (no pun intended).

   double aspectRatio = imageWidth/imageHeight;
   double boxRatio = maxWidth/maxHeight;
   double scaleFactor = 0;
   if (boxRatio > aspectRatio)
    //Use height, since that is the most restrictive dimension of box.
    scaleFactor = maxHeight / imageHeight;
   else
    scaleFactor = maxWidth / imageWidth;
   
   double newWidth = imageWidth * scaleFactor;
   double newHeight = imageHeight * scaleFactor;
   

4. Not setting the Jpeg quality to 90. You’ll get huge Jpegs from Image.Save unless
   you pass in the proper parameters. 90 seems to be the magic value – great quality
   and much lower file size than 100.

   int quality = 90; //90 is the magic setting - really. It has excellent quality and file size.
   System.Drawing.Imaging.EncoderParameters encoderParameters = new System.Drawing.Imaging.EncoderParameters(1);
   encoderParameters.Param[0] = new System.Drawing.Imaging.EncoderParameter(System.Drawing.Imaging.Encoder.Quality, (long)quality);
   thumb.Save(stream, GetImageCodeInfo("image/jpeg"), encoderParameters);
   
   /// <summary>
   /// Returns the first ImageCodeInfo instance with the specified mime type. Some people try to get the ImageCodeInfo instance by index - sounds rather fragile to me.
   /// </summary>
   /// <param name="mimeType"></param>
   /// <returns></returns>
   public static ImageCodecInfo GetImageCodeInfo(string mimeType)
   {
   	ImageCodecInfo[] info = ImageCodecInfo.GetImageEncoders();
   	foreach (ImageCodecInfo ici in info)
   		if (ici.MimeType.Equals(mimeType, StringComparison.OrdinalIgnoreCase)) return ici;
   	return null;
   }
   

5. Using the built-in quantization (palette creation) for GIFs, 8-bit PNGs and BMPs.
   The default palette is truly terrible, and while you can specify your own set of
   255 colors – which ones should they be? The process of determining which colors
   to choose for the palette and to produce the best quality images is call quantization.
   I recommend the very efficient and decent-quality
   octree quantization algorithm. It does have a number of bugs you will have
   to patch. Follow the transparency patch instructions found in the comments. Use the safe version of the library. Patch the Marshal.ReadInt32() bug (original is ReadByte()).
   Change any casts from IntPtr->int to IntPtr->long to make the code 64-bit safe.

   I’m working on adding adjustable Floyd-Steinberg dithering to the version in my resizer , and
   the results have been very promising so far.

6. Inheriting the palette from the original image. While at first this seems like an
   
   easy way to solve the palette problem for GIFs, realize that the bicubic
   resizing will have combined colors, and the new thumbnail may not have any of colors
   of the original image. Also, any operations performed on the bitmap in 8-bit mode
   will be poor quality, and this won’t allow conversion between image formats. There are
   other ways to keep transparency. This is probably better than leaving the default palette, but YMMV.
7. Resizing images that don’t request it. Your code should only activate when an image has a querystring with one of the supported
   commands. Pushing all images through your code is unnecessary.
8. And one last piece of advice. Have Good Defaults. Always.

   The output image type should default to the source image type, unless it’s a BMP or TIFF.
   Default behavior should always preserve aspect ratio.

   Many developers stop after making their code configurable. They don’t take that extra 10 minutes to give
   everything smart defaults. Smart defaults distinguish good software from great software.

I hope to post Part 2 soon. I plan on revealing the architecture that has evolved in my resizer,
and how to design a IIS5/6/7 compatible HttpModule.

• When both ?width=x&height=y are specified, the default behavior has changed. Instead of stretching the image and losing aspect ratio, whitespace is added (controlled with &bgcolor=color name|code). You can reinstate the original behavor by adding &stretch=fill. Based on customer feedback.
• ICC profiles are now read on source images, but changes are merged into the image before output. Since most browsers (including Firefox) do not read ICC profiles, this should produce consistent cross-browser behavior. If you want to ignore the original ICC profile for an image, add &ignoreicc=true.
• The CustomFolders.cs format has changed, and is now much, much more powerful. All querystring commands can be used, and URL rewriting can be performed. (AllowURLRewriting must be true).

New features

Check out the samples page to see these features in action.

• Automatic cropping and centering can be performed with ?crop=auto&width=x&height=y. You can also choose a crop rectangle from the source image manually with &crop=(x1,y1,x2,y2). Negative values indicate distances relative to the bottom-right corner. (10,10,-10,-10) would crop a 10-pixel border off the source image.
• Support for 8-bit PNG file output with &colors=2-255. Sets the palette size for both PNG and GIF images.
• GIF and 8-bit PNG files are now much, much better. Instead of using the GDI default palette, octree quantization is used to calculate the optimal color palette for each image.
• Upscaling can be enabled using &scale=both. The default is &scale=downscaleonly. &scale=upscaleonly is also available for certain zooming situations.
• Image rotation is supported in degrees. Ex. &rotate=45. Image sizing is performed before rotation, so rotation will cause the final image size to be larger than the size specified in the querystring.
• Image flipping can be performed using &flip=h|v|both. To flip the source image before other commands occur, use &sourceFlip=h|v|both.
• BMP and TIFF source files are now supported.
• You can add padding around the image with &paddingWidth=px&paddingColor=color|hex. paddingColor defaults to bgcolor, which defaults to white.
• You can add a border around the image with &borderWidth=px&borderColor=color|hex.
• Transparency is maintained while resizng PNG files, and when converting from PNG to GIF.
• DisableCacheCleanup=true|false is now supported in Web.config. If you have plenty of disk space and wish to manually purge old files from the cache, this setting will allow it. Leave the default value to false unless you have a very good reason.
• DiskCacheAlwaysInvalid=true|false is a new Web.config setting for debugging. It forces every request to update the disk cache before responding. Very, very slow, so make *sure* this is false before you launch.
• Websites located on UNC paths are now supported. (Ex. \\server\share\website).

Installation

1. Replace the old files with the new files from the ImageResizer folder. If you are using the .DLL, replace the DLL in the bin folder. Keep a copy of your old CustomFolders.cs if you have modified it.
2. Delete the /imagecache directory.
3. If you use both width and height to stretch any images, add &stretch=fill to those URLs to maintain the same behavior.
4. Migrate CustomFolders.cs if you have modified it. The new file includes source comments explaining the process.

If you haven’t upgraded to 1.2, follow these instructions first

Hover over the images to view the querystrings used. All commands can be combined.

Resizing using maxwidth and/or maxheight

Aspect ratio is always maintained with maxwidth and maxheight. The image is scaled to fit within those bounds.

Resizing using width and height

Specifying only one of width or height will behave the same as using maxwidth
or maxheight. The difference is when you specify both.

Specifying both width and height will force the image to those exact dimensions, unless the
image is already smaller (see scale). This is done by adding whitespace to the image. To center and crop instead, use
&crop=auto. To lose aspect ratio and fill the specified rectangle, use &stretch=fill.

Scaling

By default, images are not upscaled. If an image is already smaller than width/height/maxwidth/maxheight, it is not resized.
To upscale images, use ?scale=both. ?scale=downscaleonly is the default.

The slight blur around the edges is a bug in Graphics.DrawImage(). You can control the color by setting &bgcolor=color|hex.

Cropping

To enable cropping, you can use &crop=auto, which minimally crops and centers to preserve aspect ratio, or custom cropping.

&crop=(x1,y1,x2,y2) specifies the rectangle to crop on the image. You can still resize and modify the cropped portion
using the other commands as normal. Negative coordinates are relative to the bottom-right corner –
which makes it easy to trim off a 50-pixel border by specifying &crop=(50,50,-50,-50).

Rotation

Rotation is easy – just specify the number of degrees. You may want to set bgcolor also.

Flipping

You can horizontally or verically flip an image, as well as both. &flip=h|v|both

Source flipping

Since normal flipping applies after rotation and cropping occur, it can be
difficult to work with if you are just wanting the source image flipped before the other
adjustments are applied. To flip the source prior to work, use &sourceFlip=h|v|both.

Note how the same crop coordinates return different sections of the image. This is because the source image is flipped before *anything* happens.

Stretching

To stretch an image to width and height, use &stretch=fill.

Padding

You can add padding around the image with &paddingWidth=px and
&paddingColor=color|hex. paddingColor defaults to bgcolor, which defaults to white.
This setting can be…. useful.

Borders

You can add a border around the image with &borderWidth=px,
&borderColor=color|hex.

Output format

GIF, JPG, and PNG output is supported. BMP and TIFF input fils are additionally supported, and every format can be converted to any other format with &format=jpg|png|gif

Jpeg compression levels 0-100 (&quality=0-100)

The sizes of these images range from 855B to 12KB. The largest size jump is from 90 to 100 (5KB to 12KB). I think 90 is a good balance, and is therefore the default.

Quantization (8-bit PNG and GIFs)

The default GDI quantization is terrible, and produces lousy GIFs. Using the Octree quantizer, you can
control the number of colors (and therefore the size and quality) of an image using &colors=2-255

GIFs, in 4,8,16,32,64,128, and 256 colors

PNGs, in 4,8,16,32,64,128, 256, and 16 million colors

Transparent GIFs and PNGs

Transparency is maintained when resizing PNGs

Matte backgrounds can be applied with bgcolor.

Transparent PNGs can be converted to transparent GIFs

It’s ugly, but GIFs only get 1 bit for transparency.

Single frames can be extracted from animated GIFs with &frame=x

/resize(width,height,format)/ syntax

For the URL-conscious, you can replace img/image.jpg?maxwidth=x&maxheight=y with
img/resize(x,y)/image.jpg. A third argument, format, is also allowed.

However, enabling this (AllowURLRewriting) will make the ASP.NET URL authorization system unable to match URLs…. But that only affects you if you set permissions in web.config.

This integration isn’t valuable to most people, however, since they aren’t protecting any static files.
Users who don’t need this protection can enable the “AllowFolderResizeNotation” setting to gain additional URL flexibility in exchange.

Version 1.2 now passes *all* file serving work back to IIS. The cached image is now written to disk first rather than last, allowing a simple RewritePath call to handle the work.

The same code can now be used for both IIS5, 6, 7c and 7i. The httpModules section handles IIS5/6/7c, and the modules section handles IIS7 integrated mode.

<system.web>
  ...
  <httpModules>
    <add name="ImageResizer" type="fbs.ImageResizer.InterceptModule"/>
  </httpModules>
  ...
</system.web>
<system.webServer>
  <validation validateIntegratedModeConfiguration="false"/>
  ...
  <modules>
    <add name="ImageResizer" type="fbs.ImageResizer.InterceptModule"/>
  </modules>
</system.webServer>

Configuration

You will need to insert the following settings into web.config in the designated places.

<system.web>
  ...
  <httpModules>
    <add name="ImageResizer" type="fbs.ImageResizer.InterceptModule"/>
  </httpModules>
  ...
</system.web>
<system.webServer>
  <validation validateIntegratedModeConfiguration="false"/>
  ...
  <modules>
    <add name="ImageResizer" type="fbs.ImageResizer.InterceptModule"/>
  </modules>
</system.webServer>

Last, some app settings for the resizer. You can use the following safely with v2.1 and up. Full configuration reference and notes for other versions can be found in the next section.

<appSettings>
    ...
    <add key="ImageDiskCacheDir" value="imagecache" />
    <add key="MaxCachedImages" value="30000" />
    <add key="ImageResizerMaxWidth" value="1680" />
    <add key="ImageResizerMaxHeight" value="1680" />
    <add key="ImageResizerClientCacheMinutes" value="1440" />
    <add key="AllowURLRewriting" value="true" />
    <add key ="ResizeExtension" value=".axd"/>
    ...
</appSettings>

Complete reference

    <!-- The directory to store cached version of images. Relative to the application root -->
    <add key="ImageDiskCacheDir" value="imagecache" />  

    <!-- How many files to keep in the cache. The 10% least recently used files will be deleted
when this limit is reached. Don't set this lower than the number of images on your site. 2x the image count is a
 good default. If you are getting "Access Denied" messages, this is the cuplrit - you need to increase it -->
    <add key="MaxCachedImages" value="30000" />  

    <!-- The following settings are optional: -->  

    <!-- The maximum size to permit images to be resized to. -->
    <add key="ImageResizerMaxWidth" value="1680" />
    <add key="ImageResizerMaxHeight" value="1680" />  

    <!-- Takes effect in version 1.2. The default (for all versions) is 1440 minutes (24 hours).
        Set to 0 to disable *client* caching (304 "Not Modified" responses will still be returned
        if nothing has changed). Client caching is not related to disk caching. -->
    <add key="ImageResizerClientCacheMinutes" value="1440" />  

    <!-- This enables /resize(x,y,f)/image.jpg notation in v1.2+. Enabling this
      will make URL authorization ineffective on image files. Changed to AllowURLRewriting in 2.0-->
    <add key="AllowFolderResizeNotation" value="true" />  

    <!-- This enables /resize(x,y,f)/image.jpg notation and other CustomFolders.cs
rewriting (other than querystring-only changes) in v2.0. Enabling this
      will make URL authorization ineffective on image files on version prior to 2.1b.-->
    <add key="AllowURLRewriting" value="true" />  

    <!-- (v2.0a+ only) Prevents use of cached files - useful for development when changing resizing algorithms.
          Causes terrible performance - don't leave enabled.-->
        <add key="DiskCacheAlwaysInvalid" value="false"/>  

    <!-- (v2.0b+ only) Prevents the cache cleanup routine from running. If you want to
        manually purge the image cache yourself, and aren't worried about running out
        of disk space via a DOS attack, you can disable this. Not advised. -->
    <add key="DisableCacheCleanup" value="false"/>  

  <!-- (v2.1+ only) Disabling custom quantization allows the resizer to function in low trust
     environments where managed pointer access and data type marshaling is prohibited.
     However, PNGs and BMPs can only be output in 32-bit mode, and GIFs will use the default
     halftone pallete. Enable this if JPGs and PNGs work, but GIFs don't, and using colors=255
      on PNGs causes them to break also.
     Causes much lower quality GIFs to be generated.
      Version 2.1+.
    -->
    <add key ="DisableCustomQuantization" value="false"/>  

     <!-- (v2.1b+ only) This allows images to be resized without any IIS configuration whatsoever.
        Just set this value to ".axd", ".ashx", ".aspx", or any extension
        already registered in IIS, and add the same extension to your image URLs when you are resizing them.
    Doesn't conflict with other pages/files with that extension, unless you name them .jpeg.ashx., etc.

        Ex. /images/media/flower.jpg -> /images/media/flower.jpg.axd?width=x&height=y  

        AllowURLRewriting must be true.   

      Version 2.1b+.
    -->
    <add key ="ResizeExtension" value=".axd"/>

1. Modify and use the component in all of your projects.
2. Redistribute the source code as part of another project, provided the component
   is less than 5% of the project (in lines of code), and you keep this information attached.

You may not

1. Extract it from a project for re-use (in a different project) without purchasing a download
   from http://nathanaeljones.com/. If nathanaeljones.com is no longer running, and a download
   cannot be purchased, then you may extract the code.

This is basically a developer license – if you aren’t a developer (i.e., a hosting company wanting a site or server license), please e-mail me (nathanael.jones@gmail.com).

Aaand… the stock software disclaimer, in highly annoying all caps

Disclaimer of Warranty

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

Limitation of Liability

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.