James Jackson-South

ImageSharp.Web (My continued plans for world image dominance)

Fri, 19 May 2017 06:08:11 Z

I better build this before someone else does!

I recently read a series of blog posts by Andrew Lock comparing ImageSharp to CoreCompat.System.Drawing in which he creates a simple ASP.NET Core Middleware for resizing image via a URI API. They're really, really great and I suggest you read them.

These posts got me thinking though... I knew I was always going to build a URI API, I just didn't know when I was going to get around to it. I mean... I spend every spare waking hour plus ones I should be sleeping just now building ImageSharp (Big HINT help me finish the bloody thing, it's been TWO YEARS!)

It had to happen sooner rather than later as people are getting twitchy and ImageSharp is getting very close to a beta release, so inspired by Andrew's brilliant writing I got busy...

Introducing ImageSharp.Web

ImageSharp.Web is everything I wished ImageProcessor.Web was and I've only been writing the code for two days. I'm that happy with it. :)

It runs on ASP.NET Core Middleware, is super extensible, and, should be able to support all your web-based imaging needs once finished.

You can see the codebase as of time of writing here

So how does it work?

The Pipeline

The hip bone's connected to the...

The Middleware intercepts the current request, an IUriParser parses the request looking for commands and creates a dictionary of results.
An IImageService is assigned to the request. This will grab the image if required.
An IImageCache checks the cache for any previously processed results, if one found, we return the correct response (304, 200) and exit.
Non cached? We process the file using a collection of IImageWebProcessor instances using our collected commands via a CommandParser.
The resultant image is cached using the IImageCache and we return the result with the correct headers.

Simples!

If all goes well you get something like the following.

So lets examine some of the interfaces I just mentioned.

Behind the Curtain

All the interfaces described in the pipeline are injected via the ASP.NET Core Dependency Injection container so you can replace them at will.

IUriParser

This is a neat little interface inspired by some feedback from Andrew that allows you to choose how commands are parsed from the URI.

public interface IUriParser
{
    IDictionary<string, string> ParseUriCommands(HttpContext context);
}

By default ImageSharp.Web will parse querystring parameters but there's nothing to stop you from replacing that with something else. Maybe you want to parse something like /resize/{width}/{height}/{path} who knows?!

IImageService

This interface is very similar to the ones found in ImageProcessor.Web except it's a bit simpler

public interface IImageService
{
    string Key { get; set; }

    IDictionary<string, string> Settings { get; set; }

    Task<bool> IsValidRequestAsync(HttpContext context, ILogger logger, string path);

    Task<byte[]> ResolveImageAsync(HttpContext context, ILogger logger, string path);
}

The key property there indicates an identifier in the URI that we use to choose which service to implement e.g http://mysite.com/remote/http://remote-image.jpg?width=200 would resolve to a RemoteImageService (not built yet) as it uses the remote prefix. Any implementations without a prefix match all requests.

I've put together one so far, the PhysicalFileImageService. You can see the code for that here. It's pretty simple but leverages the DI container to get certain functionality.

IImageCache

I didn't want to build this at first as I wanted to use the built in primitives like IDistributedCache but the API of those primitives was both more complicated than I needed and also lacked the functionality to check if a cached item existed without retrieving it.

public interface IImageCache
{
    IDictionary<string, string> Settings { get; set; }

    Task<CachedBuffer> GetAsync(string key);

    Task<CachedInfo> IsExpiredAsync(string key, DateTime minDateUtc);

    Task<DateTimeOffset> SetAsync(string key, byte[] value, int length);
}

It's again pretty simple but contains enough information to create any kind of cache you require. I've written a PhysicalFileSystemCache implementation so far for non-multi-tenant applications but I plan on creating others for Azure etc. (I will probably charge a small fee for those though as I need to start making some money off the back of my work )

IImageWebProcessor

This is how we actually process the image. We pass our commands and process the image accordingly. There's an overload to Image<TPixel> that loops through available processors.

public interface IImageWebProcessor
{
    IEnumerable<string> Commands { get; }

    Image<TPixel> Process<TPixel>(Image<TPixel> image, ILogger logger, IDictionary<string, string> commands)
        where TPixel : struct, IPixel<TPixel>;
}

Here's the source code for the ResizeWebProcessor. This allows you to choose all the available resize options including the size, mode, and sampler. I'll knock up another couple of processors also that ship out-of-the-box too. AutoRotate, Format & BackgroundColor. Any additional ones will require $$ I'm afraid.

Commands

Parsing input commands is a non-trivial task. The web is a hostile environment and you not only have to deal with potential attacks, you have to deal with developers who are not keen on reading documentation. As such I have had to write a pluggable system of ICommandConverter implementations that are used by the CommandParser singleton to deal with common parsing tasks. Again, this is extensible.

Rich Returns

The Middleware returns the correct response type for processed images (200, 304) and instructs the browser to cache the images for a configurable number of days (we max out by default at 365 days but of course this is configurable)!

As such you will see a server response like the following.

Default Response

The result is processed and returned as normal.

Cached Response

The result is cached so no request is made to the server.. Nippy!

There'll be an event that you can tap into also to add additional headers like Cors headers.

Gimme, Gimme, Gimme!

So when can you get your hands on this?

Well... As soon as the main ImageSharp library is ready for primetime I'll release a Nuget package for ImageSharp.Web. By then any issues will be long ironed out and you'll have a great solution to you image processing needs in .NET Core.

Of course, the sooner you give us a hand, the sooner that can happen ;)

Please comment below, your feedback is super useful!

ImageProcessor Core

Mon, 05 Sep 2016 09:45:56 Z

So its been a while...

It's been roughly a year since my last blog post. I wrote it about a recent ImageProcessor release and opened the last paragraph with the following.

For me this release marks the last I shall actively work on in this major version. It might well be the last I do ever depending on what Microsoft do with graphics with the next .NET releases. I've fallen out of love with the open source community a little over the years due to the lack of collaboration I've received on this project and others.

Sad eh?... Well it turns out I lied. Not only have I released several updates to the V2 branch with some great contributions from the community, but I've been hard at work on something a little special... ImageProcessor Core

A Little History

In 2014 Microsoft blew everyone's minds by announcing that they were building a new, open source, cross-platform framework containing a subset of the full .NET Framework. Everyone rightfully got very excited but a few people (me included) started to worry about the lack of discussion around a graphics API. Issues were opened up on the Github repo and quite a few people pitched in with their two cents.

Nobody was doing anything though and it was very frustrating for me to watch.

You see, I have a dream...

I originally wrote ImageProcessor to make it easier for developers to do common tasks with System.Drawing. I kept seeing blog posts with copy/pasted code examples full of memory leaks and slow code and I wanted to make a difference and give back to a community I learned from.

ImageProcessor Core is an extension of that idea.

The Elevator Pitch

Common imaging tasks should be accessible to all developers. If you want to resize or crop an image you should be able to use a simple API and do so easily. You shouldn't have to worry about memory leaks and you shouldn't have to worry about binding to native libraries or deploying in different environments. It should be cross-platform and it should Just Work ™

Oh and of course it needs to be scalable and allow for complex operations and different pixel formats. You know... Simple stuff!

ImageProcessor Core is designed with that in mind.

So what can it do? As of writing ImageProcessor Core is still very much in alpha status but it turns out quite a lot.

I have....

Algorithms for common operations. Resize, Crop, Flip, Rotate, Edge Detection and so on.
Almost complete support for four different codecs. Bmp, Png, Gif, and of course the most complicated but commonplace of all Jpeg.
Full EXIF read and write capability using a simple API.
A generic image class that is signature compatible with Microsoft XNA Game Studio and MonoGame.
A snazzy new logo that I designed myself :)

And much much more..

Example Time

To demonstrate the API I will show you some code demonstrating some common tasks. Here's how to resize an image using the default bicubic resampler.

using (FileStream input = File.OpenRead("foo.jpg"))
using (FileStream output = File.OpenWrite("bar.jpg"))
{
    Image image = new Image(input);
    image.Resize(image.Width / 2, image.Height / 2)
         .Save(output);
}

Want to use a different resampler? We've got you covered.

using (FileStream input = File.OpenRead("foo.jpg"))
using (FileStream output = File.OpenWrite("bar.jpg"))
{
    Image image = new Image(input);
    image.Resize(image.Width / 2, image.Height / 2, new MitchellNetravaliResampler())
         .Save(output);
}

How about companding the image to resize with gamma correction?

using (FileStream input = File.OpenRead("foo.jpg"))
using (FileStream output = File.OpenWrite("bar.jpg"))
{
    Image image = new Image(input);
    image.Resize(image.Width / 2, image.Height / 2, true)
         .Save(output);
}

How about setting individual pixel values?

Image image = new Image(400, 400);
using (PixelAccessor<Color, uint> pixels = image.Lock())
{
    pixels[200, 200] = Color.White;
}

How easy is that?

The Image class is actually an implementation of a generic class Image<TColor, TPacked> where TColor implements an interface identical to the Microsoft XNA Game Studio and MonoGame IPackedVector<T>. This allows the library to work well with those frameworks and tightly control memory usage. Underneath the hood it's actually an Image<Color, uint>.

Performance

A lot of developers say that C# can never be truly fast. A lot of developers are wrong. I've got a long way to go yet but I've been able to get some pretty decent performance going in this early stage.

Check out this benchmark using the awesome BenchMarkDotNet comparing a 2000x2000 pixel image downsampled to 400x400 pixels.

Host Process Environment Information:
BenchmarkDotNet-Dev.Core=v0.9.9.0
OS=Microsoft Windows NT 6.2.9200.0
Processor=Intel(R) Core(TM) i7-4712HQ CPU 2.30GHz, ProcessorCount=8
Frequency=2240907 ticks, Resolution=446.2479 ns, Timer=TSC
CLR=MS.NET 4.0.30319.42000, Arch=64-bit RELEASE [RyuJIT]
GC=Concurrent Workstation
JitModules=clrjit-v4.6.1080.0

Type=Resize  Mode=Throughput
                        Method |     Median |    StdDev | Scaled | Scaled-SD |
         System.Drawing Resize | 66.2606 ms | 1.2463 ms |   1.00 |      0.00 |
     ImageProcessorCore Resize | 56.4141 ms | 1.0673 ms |   0.85 |      0.02 |

Other methods like Crop are much faster and Get/Set pixel is ~94% faster than the System.Drawing equivalent on my test machine. I'm very happy with progress so far and I'm sure I can go much faster.

So What's The Plan?

It's been a very long alpha but I think the API is pretty solid so I shall be moving out of alpha and into beta status soon. Beta releases will be hosted on Nuget as opposed to the current MyGet server though you shouldn't use it in production environments until I reach Release Candidate status.

In beta I shall be concentrating on filling out missing encoder support (you can help!) and really cranking up the performance.

I'd love to get 2D drawing added to the API but that's probably better off in V1.1 as there's a lot of work involved.

Want To Help?

Please do... Spread the word, contribute algorithms, submit performance improvements, unit tests. Play around with the API and tell me what is missing.

If you know someone who works in image processing please try to convince them to get involved.

There's simply no reason why as a community we cannot build an absolute first-class imaging API that can benefit all levels of developer.

So come on, visit the repo and get mucked in!

Please let me know what you think in the comments below.

Update

Shannon below wanted to see the logo so drink it in. Pure design... Take that Instagram!

Mo Images Mo Processing

Sun, 20 Sep 2015 04:16:08 Z

Today marks another big ImageProcessor release, and my first antipodean one - There's a lot going on so here's a run through of new functionality that's been added to Imageprocessor v2.4 and ImageProcessor.Web. v4.4

tl;dr... Upgrade

ImageProcessor

New Stuff

Resolution

This method allows you to change the resolution of the given image.

public ImageFactory Resolution(int horizontal, int vertical, PropertyTagResolutionUnit unit = PropertyTagResolutionUnit.Inch)

If any EXIF data is to be preserved, the metadata will be updated to match the given resolution.

Resize

With this release I've added two new resize modes to the library: ResizeMode.BoxPad and ResizeMode.Min.

ResizeMode.BoxPad

When upscaling an image using this mode the image pixels themselves are not resized, rather the image is padded to fit the given dimensions. When downscaling the image is resized using the rules defined by ResizeMode.Pad. As with that mode you can recolour the background colour of the padded area for image types without transparency from the default black.

Here's an example resizing the original to 500x500px:

Original Image

Padded Image With Hot Pink Background

As with ResizeMode.Pad and ResizeMode.Crop the position of the image can be anchored to one of nine different anchor points.

ResizeMode.Min

This mode looks for the shortest difference in each dimension between the source length and intended length. it will then resize that side to the intended length on the result, the other dimension is resized maintaining the aspect ratio of the original image. Upscaling is disabled in this mode and the original image will be returned if attempted.

Here's an example downscaling a larger version of the original with target dimensions of 500x500px:

Performance

I've managed to reduce the memory usage by up to 25% in some circumstances in this version by rewriting the way I ensure certain methods performs their functionality in the correct colour space. These rewrites have also slightly improved the speed on earlier releases which is a nice bonus.

Bug fixes

In this release I've ironed out numerous bugs relating to image resolution. EXIF metadata for any method that changes the dimension of the image are now updated also where previously this was overlooked.

ImageProcessor.Web

New Stuff

PostProcessing

This is a big one and I'm very pleased with it...

I'm all about keeping the web lean but the default image encoders in .NET are not that efficient and you can sometimes actually end up with a larger image than what you started with. As such, I've been looking at a way to ensure that anything I output has been optimised as much as possible. For previous versions of ImageProcessor.Web I developed a plugin that post-processed any newly cached images using a variety of tools to reduce the file size as much as possible.

This worked... To a point. Firstly it only worked with the disk cache and not any other cache plugins. Secondly it only acted after the first requests so someone, somewhere would always get an unoptimised image, Thirdly one of the tools I used, optipng was incorrectly detected as malware by Windows Defender.... Not good enough.

As of this version, every image that is processed using ImageProcessor.Web is passed through a series of tools that reduce the output size. This works with whatever cache implementation is used and can dramatically reduce the weight of your pages. This all happens asynchronously and stays snappy so you shouldn't notice any increased processing time.

Here's the built in tools I use so you can check them out:

gifsicle : http://www.lcdf.org/gifsicle/
pngout : http://advsys.net/ken/utils.htm#pngout
pngquant : https://pngquant.org/
jpegtran : http://jpegclub.org/

It's possible to turn off this behaviour vie the config but you really shouldn't.

Bug fixes

There's been various minor little issues I've found and fixed while building this update, one of note though was an issue where prefix values were globally replaced within the request url.

So... What's Next?

For me this release marks the last I shall actively work on in this major version. It might well be the last I do ever depending on what Microsoft do with graphics with the next .NET releases. I've fallen out of love with the open source community a little over the years due to the lack of collaboration I've received on this project and others.

When I started ImageProcessor I didn't know much about images. I was a front end developer who decided to have a go at solving a problem colleagues were struggling with. I'd only been writing C# for a very short while and I was learning as I went on.... I still am.

These libraries are now hugely popular with hundreds of thousands of downloads but the number of people who contribute is still minuscule. If I can write this stuff I guarantee there are a very great number of people out there who could do it and do it better.

I'm very grateful for the work and encouragement of the team at Umbraco for their faith in me and contribution to my code but I feel somewhat that they are alone in doing what they do best in promoting a healthy community around developers.

I'll still fix bugs but I will not add any more new features nor work on making the library cross-platform for now. It's simply too much work for me to do.

Help Me To Help You

If you want to see ImageProcessor continue and you know anyone with the chops to help me or think you can spend an hour a week tinkering away, please get in touch. I'd love to build a v3 as part of a community of developers creating something amazing.

Anyhoo... Enjoy the new releases. As ever you can read about them in the documentation and download them from Nuget.

Announcing ImageProcessor.Web.PostProcessor

Thu, 18 Dec 2014 02:32:46 Z

The Nourishing Fruits of Boredom

So last night I got a little bored watching the old haunted fishtank and my mind, as it often does, drifted to code.

I started thinking about a talk that Mads Kristensen gave at CodeGarden this year that featured a tool he had written with Sayed I. Hashimi called Azure Image Optimizer which wraps various tools like Jpegtran and Gifsicle in an Azure Job to optimize your file based images. He writes about it here and the source can be found here.

I thought it was really nifty and since they've kindly released it under the wonderfully permissive Apache 2.0 license I decided to see if I could grab some of the goodies from the code and add something to ImageProcessor.Web.

Three hours later ImageProcessor.Web.PostProcessor was born...

How It Works

ImageProcessor.Web fires an event once an image has been processed and saved to the cache that can be wired up to asynchronously to further manipulate that file. Tapping into it is fairly simple.

ImageProcessingModule.OnPostProcessing += YOUR_POST_PROCESSING_METHOD_ASYNC;

private static async void YOUR_POST_PROCESSING_METHOD_ASYNC(object sender, PostProcessingEventArgs e)
{
     // Do your thang...
}

Where PostProcessingEventArgs contains a single property CachedImagePath.

In ImageProcessor.Web.PostProcessor I have embedded copies of the various image compressing tools: Gifsicle, Jpegtran, Optipng, and Pngout which are extracted into the running web applications folder and are used to further compress the cached images whenever the event is fired.

If a saving can be found then the cached file is replaced with the newly optimized image and voila your fancy-dancy website is now even leaner and you can celebrate by having a beverage of your choice.

Usage

Simply install the package from Nuget and it will instantly kick in; there's no configuration required so go and get it now.

As ever the source code can be found here.

Cheers M'dears!

ImageProcessor.Web 4.1.0 Released!

Wed, 12 Nov 2014 06:14:43 Z

Following yesterdays post charting the updates in the the core ImageProcessor library I'm going to take the time to chart the updates in the new 4.1.0 release of ImageProcessor.Web

New Stuff

Methods

All the new methods available to ImageProcessor are available to ImageProcessor.Web.

Pixelate
DetectEdges
EntropyCrop
Mask
Overlay

Syntactically they are invoked using familiar rules similar to preexisting methods.

For example.

http://your-image?detectedges=prewitt&greyscale=false

Will produce an image with a Prewitt operator applied that also retains the original image colours.

Original

Processed

Swish!

Handling Images in Instructions

Two of the new methods: Mask & Overlay accept images as parameters in part of their instruction sets. Rather than passing the entire path to the url (which would open up all sorts of security issues) you set the image name only as a parameter. These are mapped to two preconfigured locations.

Mask- ~/images/imageprocessor/mask/
Overlay - ~/images/imageprocessor/overlay/

These can both be overwritten by installing the ImageProcessor.Web.Config package from Nuget and changing the settings in the processing.config file.

Here's the two of them in action.

Mask

http://your-image??mask=mask.png&mask.position=30,30&format=png

Original

Masked

Overlay

http://your-image?overlay=monster.png&overlay.position=30,30&overlay.size=100,100&overlay.opacity=80

Original

Overlay Applied

Moar New Stuff

IImageService

With this version comes a new system for supplying ImageProcessor.Web images to process; IImageService.

The IImageService interface defines methods and properties which allow developers to extend ImageProcessor.Web to retrieve images from alternate locations to process. Think pulling images from from a SqlServer filestream or from another custom service.

Creating a new service simply requires implementing the interface to supply a prefix and a byte array.

The interface looks like this.

/// <summary>
///  Defines properties and methods for allowing retrieval of image from different sources.
/// </summary>
public interface IImageService
{
    /// <summary>
    /// Gets or sets the prefix for the given implementation.
    /// <remarks>
    /// This value is used as a prefix for any image requests that should use this service.
    /// </remarks>
    /// </summary>
    string Prefix { get; set; }
    /// <summary>
    /// Gets a value indicating whether the image service requests files from
    /// the locally based file system.
    /// </summary>
    bool IsFileLocalService { get; }
    /// <summary>
    /// Gets or sets any additional settings required by the service.
    /// </summary>
    Dictionary<string, string> Settings { get; set; }
    /// <summary>
    /// Gets or sets the white list of <see cref="System.Uri" />. 
    /// </summary>
    Uri[] WhiteList { get; set; }
    /// <summary>
    /// Gets a value indicating whether the current request passes sanitizing rules.
    /// </summary>
    /// <param name="path">
    /// The image path.
    /// </param>
    /// <returns>
    /// <c>True</c> if the request is valid; otherwise, <c>False</c>.
    /// </returns>
    bool IsValidRequest(string path);
    /// <summary>
    /// Gets the image using the given identifier.
    /// </summary>
    /// <param name="id">
    /// The value identifying the image to fetch.
    /// </param>
    /// <returns>
    /// The <see cref="System.Byte" /> array containing the image data.
    /// </returns>
    Task<byte[]> GetImage(object id);
}

Both the local and remote image service implement this interface. View the source code to see examples.

Extras

With this release I upped the cache to hold 100 images per folder. This now increases the theoretical cache limit to 409,600,000,000 images though I don't think anyone will be hitting that kind of limit any time soon.

There's a few performance improvements thrown in also that will make things snappier than ever.

In Summary

I'm pleased with this release and the benefits it offers. There's only a few feature I think that ImageProcessor.Web is missing (Face detection being one) so I hope you are enjoying using it as much as I do building it.

ImageProcessor 2.1.0 Released!

Tue, 11 Nov 2014 07:14:07 Z

Today marks the release of the latest version of ImageProcessor My super, fantastic open source imaging library.

This is a pretty big release with a multitude of new functionality, performance improvements and bug fixes. I'll run through some of them here and try not to ramble on too much in the process. It's gonna be very image heavy so I recommend a broadband connection.

New Stuff

Pixelate

This new method allows you to pixelate an image by passing a pixel size to the ImageFactory in the following format.

public ImageFactory Pixelate(int pixelSize, Rectangle? rectangle = null)

If a rectangle is passed that will constrain the method to only pixelate a portion of the original image.

Original

Pixelated

Cool eh?

DetectEdges

This method allows you to detect points within an image where the brightness changes sharply. There's lots of different algorithms available to do this using some pretty wild maths see Wikipedia.

The method is called as follows.

public ImageFactory DetectEdges(IEdgeFilter filter, bool greyscale = true)

I've added 9 different detection methods to get started with.

KayyaliEdgeFilter
KirschEdgeFilter
Laplacian3X3EdgeFilter
Laplacian5X5EdgeFilter
LaplacianOfGaussianEdgeFilter
PrewittEdgeFilter
RobertsCrossEdgeFilter
ScharrEdgeFilter
SobelEdgeFilter

Here an example of it in action using the PrewittEdgeFilter

Original

Edges Detected

Edges Detected - Keeping Original Colours

Edge detection is one of the fundamental tools of image processing. I use it internally for this method.

EntropyCrop

This one I built for my good friend Jeavon Leopold who preyed upon by inability to resist a challenge. It looks for the area of highest entropy within an image and crops around it. It works particularly well with images containing large areas of a single color or similar colors around the edges.

public ImageFactory EntropyCrop(byte threshold = 128)

Original

Cropped to Area of Highest Entropy

There's three other new methods added to the Imagefactory class but I'll just link to the docs as I don't want to go on.

Moar New Stuff

In this release I've also managed to add a shiny new quantizer based on a vastly improved version of nQuant. This dramatically improves the output of indexed png files. Considering these images contain only 256 colors the output is extraordinary!

Original

Indexed PNG

Performance

Performance under the hood has been vastly improved. Using a combination of Parallelisation techniques and a new FastBitmap class I was able to improve methods such as GaussianBlur by up to 7X which was very pleasing. Every single method that could be has been rewritten to take advantage of the new techniques which has made ImageProcessor purr like a wolverine.

I've also been testing continuously to ensure that memory usage is kept consistently low - I'm very pleased with the results.

Bug Fixes

Version 2.1 now correctly handles images of different resolutions. In some circumstances it was possible to throw certain combinations of methods off like Resize and Rotate for example by passing them an image of a higher resolution than the default 96dpi. This has now been fixed.

I've also fixed a timing ( rounding error) issue within animated gifs and an encoding one which was making them impossible to share on Twitter. You can now share them anywhere you like.

On that note I bet you didn't realise that all the methods can be applied to animated gifs did you?

Anyhoo

I hope this has got you all excited and you find it useful.

This release has been a LOT of hard work and as ever if you think you can help in anyway then please do. The .NET community needs a tool like this and I can only keep supporting and improving it with your help to please Get Involved.

Image Processing for Everybody!

Wed, 27 Aug 2014 02:51:45 Z

Happy ImageProcessing Day!

Today marks the new release of my open source project ImageProcessor. I'm very proud of it.

Inspired by the frantic codings of the brilliant people I met at this years Umbraco CodeGarden retreat this release has turned into an almost complete rewrite of the library. I've dramatically simplified the code required to write plugins whilst making the library much more robust and modular adding a few very cool (I think so anyway) features.

We now have the following:

ImageProcessor

Automatic image file type detection
Automatic plugin detection
Ability to extend image file type support via the ISupportedImageFormat interface
Ability to extend individual processors via the IGraphicsProcessor interface
Methods to load embedded native (unmanaged) libraries from within plugins
True separation of concerns from the .Web extension.
More specific error handling feedback

ImageProcessor.Web

Automatic plugin detection
Ability to extend individual processors via the IWebGraphicsProcessor interface
Improved and more consistent parsing syntax.
Improved processing and caching performance
More images are now cached (theoretically 409,600,000,000)
Post processing events to tap into. ImageProcessingModule.OnPostProcessing
Improved error handling for remote image requests
Url configurable EXIF preservation

There's more but it's probably best for you to read the documentation. As ever, it's a work in progress but I've tried to make them readable and precise. If you want to help at any point to improve the library, there is always a good place to start.

I'd really like to thank Scott Hanselman for sharing the library on his blog and the Umbraco team and community for their continuing support and faith in my ability. You guys absolutely rock! #h5yr's and approving nods all round!