Posts Tagged ‘Fiddler’

Image Renditions

October 18, 2012 Leave a comment

Image Renditions are a new feature in SharePoint 2013 that allow you to create multiple views of a given image uploaded to SharePoint. This allows for the same image to be displayed differently in different parts of the site through the application of different renditions. The following are findings from my playing around with the feature on SharePoint 2013 Preview.

You will find Image Renditions in Site Settings under the "Look and Feel" section


In order to use Image Renditions, the blob cache will need to be configured for the web application that is hosting your SharePoint site. If you have not already done this, the following is what you’ll see when you try to configure Image Renditions.


To set the blob cache, the web.config file for the web application containing the SharePoint site in question needs to be edited. This should be found typically at <OSDrive>:\inetpub\wwwroot\wss\Virtual Directories\<portnumber>. You can open the file using notepad or something similar and find the following line:

<BlobCache location="C:\BlobCache\14" path="\.(gif|jpg|jpeg|jpe|jfif|bmp|dib|tif|tiff|ico|png|wdp|hdp
|rmvb|wma|wmv|ogg|ogv|oga|webm|xap)$" maxSize="10" enabled="false" />

I have not changed the location although it is recommended that you set the blob cache location to a disk that does not have the OS installed for the server and is not the one where the server log files are written. The list of available file types seemed fine for my testing purposes. The only thing I really needed to change was set enabled="true", save web.config and exit.

Here is a reference for different cache settings you can make for a SharePoint web application on TechNet.

When done, you should be able to go back to the Image Rendition listing page. You should be able to add a new rendition, edit an existing one or delete one from the list. Here’s what you can edit with a rendition – the same set of attributes you can control when you create a new one:


Any rendition that you place here is available to all images that are added to this site. To test this out, I headed next to the "Images" asset library that comes by default with the Publishing site template and uploaded an image. Now I am not going to get into exactly how I uploaded an image to an asset library because that is pretty standard experience. The only thing I will remark about is metadata relating to the picture that when available is auto-captured by the image property dialog.


When done uploading, I headed back to the publishing page where I was experimenting with all content authoring features, checked out and edited it and embedded the image on the page using the Insert > Picture > From SharePoint option shown below.


Then of course you get to navigate to the asset library of your choice and pick an image that has been uploaded there.


Once you have picked and inserted your image, the image tab on the ribbon is where you see the new option to pick a rendition – this will list all renditions in the list of renditions available centrally to the site. The first option – "Full size image" is not a rendition option – it is the default selection for the image. Note that you can also "Edit Renditions" from here.


If you click on "Edit Renditions", you will see the several renditions available applied to the selected image in the dialog that pops up as shown below. Note that there is a "Click to Change" link on each. It is also interesting to note that there are four URLs here for each rendition. Each of these basically shows you the image with the rendition applied.


If you click on the "Click to Change" link, the following message asking you to check out the image to be altered is shown


When you click on "Cancel", nothing happens and you are thrown back on to the prior dialog, which is fine. When you click on "OK" though, again, nothing happens except that the message disappears. The image has been checked out but you don’t know that because you are not told so. The only way you know is by clicking on one of the "Click to Change" links again. If you don’t see the above message this time, you know that check out worked. When you do, you end up on the following dialog.


So what is this? It essentially draws a rectangle on your image – or you can draw your own – of the same aspect ratio as the width and height specified on the chosen rendition. You can adjust the boundaries of that rectangle while not disturbing that aspect ratio to focus on the part of the image that you would like to show in the width and height you’ve been provided which in the above example is 120 pixels wide and 68 pixels high. For illustration, refer to the rectangle I drew below to change what part of the image is enclosed in the rendition. You can see what your image will look like in the preview provided below.


So what did we do? When we add a rendition or use one that’s available with SharePoint 2013, we get to define only the width and height of the bounding box that will be used upon the image to which the rendition will be applied. We do not get to specify the coordinates of where that box should start – like the left and top settings you would make in CSS for example. This is because those settings are very image specific and should be made when applying the rendition on an image. Therefore, we applied that through the image cropping function on the combination of an image and a specific rendition. We end up with the following.


I edited the one that is called "Display Template Video". All others are as SharePoint would normally crop them. The default cropping scheme essentially tries to fit in the largest bounding box with the specified aspect ratio that can fit into the dimensions of the image provided. Where this results in one dimension being accommodated but the image having available real estate along the other dimension, the box is centered (vertically or horizontally as the case may be). This is what results in the decapitated penguins you see above.

The bounding box drawn on the image may be larger (or smaller) than the dimensions of the rendition specified. As long as the aspect ratio is maintained, as in this case it is forced to, the actual image placed on a publishing page will be scaled up or down to show the contents specified by the bounding box in the size specified by the rendition. So for instance, I could have drawn a box on my image as I was customizing the rendition for it that was 240×136. The contents of that box would scale down by 50% when displayed on the page to fit the 120×68 rendition.

Now it stands to reason that the information relating to the rendition customization for the image was stored with the image itself – especially since we had to check the image out before we made the changes. So how do we get to that information?

If you head back to the asset library where you uploaded the image, you should be able to place your cursor on the image, click on the ellipsis and pull up the menu where you can "Edit Renditions".


When you click on "Edit Renditions" here, you are brought back to the "Edit Renditions" screen with all the different renditions applied to the current image as seen before and you can go back to changing the renditions again.


Incidentally, you can use the URL provided against the rendition for the image as a way to directly reference a specific rendition for the image. So for instance, you could use an image tag and set the source directly to the URL with the RenditionID and the specific rendition of the image would load.


The above source edit on the HTML field on the publishing page would have the following effect.


So how else are these useful? You can use the one image with several renditions to display several images on your publishing page without actually using several cropped images. This way, only one image loads during your page load and this could have significant impact on the amount of time it takes for your page to render.

I added a few new renditions to the list on the site as shown below


The 3 new items I added are seen now in the list below – each starts with the word ‘Headshot’.


Now I go back to my image and specify the rendition settings for these three new ones I just created to focus on the faces of each of the chipmunks as shown below.


After having done the same for the other two and saved, this is what I end up with. One thing to note is that since the bounding box scales to be exactly 100×100, I didn’t have to spend much time worrying about resizing cropped images as I would have had to do to fit Theodore’s rather large (and adorable) head.


Now that I have these available, I can put the following code on a page. As you can see, I have used just the one image several times over with different renditions applied. As a side note: there is still no respite for people using the HTML field source editor with doing indentations and so forth with HTML. The control now does a very good job with formatting HTML after you hit the "OK" button, to be XHTML compliant. In fact, I forgot to place my <th> tag in the code below inside of its own <tr> and the editor went ahead and corrected that. Pretty impressive. I still wish I was able to indent code as I was putting it in.


The effect of doing this is the following publishing page on SharePoint.


Now to see how this works. In order to check what the page is loading as it is being rendered, I used fiddler to trace the page load after having cleared the cache.


To see how this compares to loading a page that has the full image (without renditions) loaded with any compression accounted for, I also traced the load on a page that has the full size image embedded:


From what we see, the following observations can be made:

  1. The image we uploaded is 320 KB in size but since we always only get a portion of it through a rendition, the cumulative size of all image downloads is only around 25 KB.
  2. You see the actual JPEG file download happen four times where highlighted in the first image of Fiddler. So each rendition, has its own image downloaded separately.
  3. Each of the 3 smaller renditions were around 3KB in size but they were not all the same size. This is because of the slight differences in the sizes of the bounding boxes we drew as we framed the faces of the characters in the larger picture.

So how does all this help?

  1. Saves a graphic designer the trouble of slicing up images to create different bits that can be used on different pages or the same page. Remember that the scaling of images to fit specific sized boxes is handled by the rendition definition.
  2. Since we are effectively only storing one image in the content database, it saves the additional space used up by different size versions of the image that a designer may have to create.

NOTE: We do not save anything with the number of images that are downloaded during the page load. Therefore, this is not to be confused with concepts such as CSS sprites and other techniques that are used to reduce either the number of HTTP requests made for individual images or the sizes of images downloaded.

One last thing to check before we close this topic – what happens if you apply a rendition on an image that is larger than the image itself? As expected the image size would be scaled up to match the rendition and could make it look rather ugly depending on the how large the ratio of rendition size to image size is. That said, this is probably something no one would ever do so it should be fine.


Overall, it is a very useful feature to have to quickly produce scaled and alternate views of an image very quickly instead of slicing images or using tricky CSS.

%d bloggers like this: