Mark Everard

Hello, I'm Mark – a PhD physicist turned developer / architect.

Image resizing in EPiServer 7.5 CMS

with 10 comments

Dynamic image scaling is an often sought after feature for interface designers and content editors. Whilst not natively supporting this feature; EPiServer 7.5 CMS contains a neat hidden feature (Thanks @athraen for the heads up) that allows a limited but useful ability to automatically scale your images.

True dynamic scaling, and by that I mean that your http request for an image also contains your requested height, width and cropping options, is a complex operation to perform successfully, just check out the interesting blog posts at http://imageresizing.net/. Note there is a community integration of ImageResizer.Net with EPiServer 7.5.

The new media editing interface allows in-line preview of uploaded images via a scaled thumbnail representation of the image. These are created automatically by EPiServer for any ImageData content types that are created.  This is achieved via a ImageDescriptor attribute which can be placed on any ‘routed’ blob property (i.e those on ImageData content types).

Thumbnails in the media edit interface

The ImageDescriptor is pretty cool, but not so helpful when you start working with real images with differing aspect ratios.

A simple use case could be that for every uploaded image you want to create a version that has a maximum width of 300 px, which could be used in a site sidebar. The ImageDescriptor as-is forces you to define a height and width at compile time meaning that all uploaded images will be resized to the same width and height specified in the attribute. Any additional height or width will be filled with white-space.

The CHIEF2MORO.ImageDataExtensions nuget package I blogged about previously also contains a couple of additional attributes to help overcome this limitation. Extend your ImageData content object (ImageFile in Alloy) with a few Blob properties for the different sizes and mark up with the attributes. The blob routing feature in EPiServer means that these scaled images are available publically (<imagename>.jpg/image250 and <imagename>.jpg/half). Behind the scenes both of these descriptors use the underlying ThumbnailManager class contained in the EPiServer API.


   [ScaffoldColumn(false)]
   [ImageWidthDescriptor(Width = 250)]
   public virtual Blob image250 { get; set; }

   [ScaffoldColumn(false)]
   [ImageScaleDescriptor(Percent = 50)]
   public virtual Blob half { get; set; }

The ImageWidthDescriptor only requires you to specify the scaled width and will calculate the height at content publish time from the originally uploaded image dimensions to ensure that the aspect ratio is maintained (so you get no padding / whitespace)

The ImageScaleDescriptor allows you to specify a scale and will calculate the desired height and width from the original image.

Written by Mark

February 13th, 2014 at 10:00 am

Posted in ASP.NET,C#,EPiServer

  • http://www.dykkartan.se Thomas Krantz

    Personally, I like the approach of adding URL parameters to the image URL for defining width and height. Just a matter of taste, I guess. For those interested, my code is on https://github.com/PeachFront/Parrot and in the EPiServer nuget feed.

    • Linus Ekström

      I guess both ways have it’s pros and cons. Using URL:s you are more free to dynamically create custom dimensions without the need for a developer, for instance letting an editor change the settings. The drawback is that you cannot prepare images before a request is made (even though you can cache a certain image and size). Having dynamically created images through URL manipulation also opens up a nice posibility for DOS attacks since you can spam the image service quite easily.

      • http://ev2000.me/ Mark Everard

        As much as I’ve always thought from a developer perspective I wanted truly dynamic image scaling, I think in reality you don’t reall y need it. Between this sort of technique (ie a set of image scale presets) and a good quality image editor for CMS users, you are well covered for responsive design scenarios and the needs of editors to fill flexible designs.

      • Johan Petersson

        You could however prevent DOS attacks by having presets instead of dimensions in the url.

  • Joakim Jormelin

    I guess this will only work for images uploaded after you have extended your ImageData content?

    • http://ev2000.me/ Mark Everard

      Yes – the image resizing and blob creation occurs on content publish, so you’d have to republish all of your extended ImageData items. Nothing a quick win scheduled job couldn’t handle though……

      • Joakim Jormelin

        You’re right, i feared the event would occur on content created :) Is there any way to adjust quality on the generated thumbnails, I did a quick try yesterday but wasn’t so pleased with the output. Maybe It was a bad image…

        • http://ev2000.me/ Mark Everard

          Currently there isn’t a way to adjust the quality as this just uses the ThumbnailManager class within EPiServer. My guess is that this uses some level of compression as it was designed to create 50×50 pixels images for use in the edit interface. You could just replace this with a standard call to the ImageService where you can specify a compression factor. Source code is on GitHub!

          • Sven Tegelmo

            You can change the ImageService on Thumbnailmanager to your own (which uses the original service to render the image of desired mimeType, jpeqcompression.
            Just rempember to set back the original ImageService on Thumbnailmanager since it is a singleton.

          • Sven Tegelmo

            By the way: The “Clear Thumbnail Properties” scheduled jobs takes care of updating/creating the images. Nice! :) So you don´t have to recreate/publish content if you change the blob generation.