
This document describes several GDI+ bugs and how we avoid them.

Image and Bitmap classes - they require that the underlying stream stay open for the life of the object. 
If the managed reference is garbage collected, operations will fail.
They do not dispose of the underlying stream when disposed. 

http://support.microsoft.com/kb/814675


Cloning the image would cause all frames and metadata to be lost.

We solve the issue by cloning the stream into a MemoryStream. We then place a reference to the MemoryStream inside the Bitmap.Tag.Source property, which keeps it alive for the duration of the Bitmap instance.

All ImageResizer code first disposes Bitmap.Tag.Source, then the Bitmap itself.


TODO: Investigate if this might be slowing things down at all: http://support.microsoft.com/kb/831419


Windows Server 2008 R2 and Windows 7 may generate an OutOfMemoryException for CMYK jpegs

wherever you set your PixelFormat, and you check for the original image's format and/or set the output image's format, I now include this check...
[11/9/11 12:24:02 PM] Percipient Studios: // for cmyk jpeg files running on Win7 or Win2008r2, the pixel format will be '8207' (when I re-code for .net3.5 and up and stop using GDI it'll be fine... it's only a GDI problem)
                // for cmyk jpeg images on XP, Vista, etc. the cmyk is automatically converted to rgb so this code isn't required.
                // no matter what happens, cmyk jpegs will experience a color shift.
                else if (_originalImg.PixelFormat.ToString() == "8207")
                    _workingImg = new System.Drawing.Bitmap(Convert.ToInt32(Math.Ceiling(_finalWidth)),