Image Resizer

Highlights of ImageResizer v4

Image scaling and image sharpening are up to 43x faster - and are higher quality.

FastScaling provides a drop-in rendering engine to replace Graphics.DrawImage. It is the result of nearly 3 years of algorithm research, and provides unparalleled performance and quality.

It can work side-by-side with existing GDI+/System.Drawing-based plugins.

Among other improvements, it can perform gamma-correct scaling. System.Drawing is only capable of scaling in the sRGB color space, which destroys image highlights and expands shadows.

Scaling in a linear light (left) preserves more of the snowflakes than scaling in sRGB (right).

Scaling in linear Scaling in sRGB

Performance

Full benchmarking details here.

The short bars are how long v4 (with FastScaling) takes to resize a set of bitmaps. The skyscrapers are how long Graphics.DrawImage (v3) takes. On 15 threads, FastScaling is 43.5x faster. (Azure D14 instance). On my 4-core laptop, I still see a 30x delta.

FastScaling vs DrawImage (Azure D14 instance)

Bitmap scaling isn't the full picture, though. We have to decode and encode those bitmaps as well. This chart excludes I/O, but includes the full Stream-to-Stream BuildImage() process (decode, render, re-encode). Relative performance peaks at 9.6x faster (on 8 threads).

FastScaling vs DrawImage (including decode and encode) (Azure D14 instance)

Go buy a v4 license and shut down those wasted virtual servers. Hurry. Each sale funds a significant amount of open-source software, and with enough resources we could revolutionize on-demand image processing - and hopefully provide a graphics platform for .NET Core at the same time.

Pipeline changes

  • ImageResizer now applies URL rewriting performed in Config.Pipeline.Rewrite and Config.Pipeline.RewriteDefaults to all image requests if the rewriting results in an accessible physical or virtual file, even if the image is not processed by ImageResizer (this also fixes #8 and #113). If the file is from a VirtualPathProvider, ImageResizer will assign the StaticFileHandler to ensure it is served (.NET 4+ no longer automatically serves files from VPPs) (Fixes #140).
  • ImageResizer now fires Config.Pipeline.ImageMissing for all image 404s, not just those which would be processed.
  • ImageResizer now fires Config.Pipeline.AuthorizeImage for all image requests, not just those processed.
  • DirectoryNotFoundExceptions now cause a 404.

Pipeline configuration defaults in v4:

    <pipeline vppUsage="Fallback" fakeExtensions=".ashx" defaultCommands="" dropQuerystringKeys="" authorizeAllImages="true" /> <!-- Other values for vppUsage are "Always" and "Never" -->

Suggested configuration:

    <pipeline defaultCommands="autorotate.default=true&fastscale=true" />

ImageResizer now offers both synchronous and async HttpModules. Replace ImageResizer.InterceptModule with ImageResizer.AsyncInterceptModule in Web.config to switch to async mode. AsyncInterceptModule requires that all your image providers implement IVirtualImageProviderAsync or inherit from BlobProviderBase. Of the official providers, FFmpegPlugin and PsdComposerPlugin do not yet implement async.

Installing custom plugins

In v3, we used a convention-based approach to generate dozens of possible fully-qualified type names, and then tried those against each loaded assembly. This approach was slow, and broke with .NET 4, which only loads assemblies with explicit references. We now maintain a hints file (which includes the assembly name), and use that to ensure a faster and more reliable load-time experience.

New in v4: When installed via Web.config, custom plugins will need to be referenced by their fully-qualified name, such as "MyRootNamespace.MyPluginNamespace.MyPluginClass, MyAssembly"

Providers

ImageResizer.Storage provides a standard, unified BlobProviderBase class with 90% of the functionality you need. Override FetchMetadataAsync and OpenAsync, and you'll have a full-fledged provider with async/sync pipeline support, metadata caching, and even (optional) exposure through the ASP.NET VirtualPathProvider system.

Some configuration attributes have been changed to make providers more consistent.

Completely new PDF rendering system based on Pdfium.

Faster, more stable, and permissively licensed.