Reduce your gallery’s drive space requirements up to 99%

Reduce your gallery’s drive space requirements up to 99%

By | 2016-12-01T16:37:39+00:00 March 4th, 2015|Tips & Tricks|0 Comments

When you add a media asset to your gallery, Gallery Server creates a thumbnail and web-optimized file that is used for most gallery activities. For example, clicking the thumbnail image in an album shows the web-optimized version, not the original. By default, web-optimized images are about 640 px on the longest side and – for JPG images – created with a compression quality setting of 70 (you can change this on the Media Objects – Images page).

A typical web-optimized image is about 30-70 KB regardless of the size of the original image. It is common for today’s digital cameras to produce files that are 8MB and even higher. That’s huge, so it’s highly beneficial to use the smaller file whenever possible. It downloads and renders quickly and uses far less bandwidth and server resources than the original would have.

The original still exists on the server and can be downloaded through the Download objects page or on the download/share dialog triggered by the button sitting on top of the web-optimized image.

But those originals take up a lot of space on the server. Some web hosting companies limit drive space, effectively limiting the number of media assets you can have in your gallery. Or they charge extra for more disk space. And even when you have your own server, a lot of 8MB images can quickly turn into gigabytes of space. Videos have an even more dramatic impact on server space.

Gallery Server doesn’t actually need those original files. It’ll do just fine with the thumbnail and web-optimized ones. So in this month’s tip we’ll look at different ways you can get rid of those original files and hum happily along with your optimized gallery.

Option 1 – Smoke ’em for your existing media assets

Select the task Delete original files from the Actions menu and you’ll see page where you can select one or more media assets whose original file will be deleted.


The page will show the amount of disk space you can recover for each asset as well as a total savings if you choose all of them. In this example, I can free up 293 MB of hard drive space by deleting the original images.

Once the originals are deleted, the gallery behaves pretty the same as it did before. The assets are still there, you can still browse them, edit them, and download them. But what happened under the hood?

Let’s look at one of the files as an example. Before we started, we had 3 files sitting in the album directory – the original, thumbnail and web-optimized:


After we deleted the original, we are left with two:


The original file was deleted and the optimized one was renamed to take the place of the original. Gallery Server now considers the 32 KB file the original and – because this new original file is already efficiently sized, no separate web-optimized file is needed. Even if you were to synchronize the album with the ‘overwrite web-optimized version’ option selected, Gallery Server still will not create a new file because it knows the original one is a good size for a web browser.

In an album full of 8 MB photos, deleting the originals will reduce the hard drive space used by about 99%. That’s huge.

Option 2 – Let the browser smoke ’em when adding to the gallery

Wouldn’t it be nice if you could have the browser create resized images and then send *those* to the server? Instead of sending a bulky 8 MB photo to the server only to later discard it, you’d send a 60 KB file, which will upload nearly instantaneously.

Well, you can by selecting the option on the Add objects page.


With this option selected, browsers will resize the image to the width and compression quality you specified on the Media Objects – Images page. This makes for a dramatically faster upload. Uploading 50 images that are 60 KB each is far faster than uploading ones that are 5 MB each (2.9 MB vs 250 MB).

You can even force users to use client-side resizing with an option on the Media Objects – Images page.


Unfortunately, this technique has a significant drawback. Browsers do a pretty terrible job of resizing images. Look at this example. The left image shows an image resized by the .NET Framework on the server. The right image is the same image, processed client-side in Firefox. The Firefox image is more pixelated while the .NET image is softer and overall looks better. In general I see consistently poor resizing behavior in every web browser I’ve tested.


Another problem, albeit temporary, is one I discovered while writing this post. In Gallery Server 3.2.1, client-side resizing doesn’t even work. Apparently the plUpload control, which is what Gallery Server uses to handle the uploading, introduced breaking behavior in the API in one of their recent releases. After a little digging I discovered you now have to set the enabled property. To fix this yourself, open the file gs\pages\task\addobjects.ascx in a text browser and look for this JavaScript:

if (discardOriginal) {
uploader.settings.resize = {
width : <%= GallerySettings.MaxOptimizedLength %>,
height : <%= GallerySettings.MaxOptimizedLength %>,
quality : <%= GallerySettings.OptimizedImageJpegQuality %>

Change it to this:

if (discardOriginal) {
uploader.settings.resize = {
width : <%= GallerySettings.MaxOptimizedLength %>,
height : <%= GallerySettings.MaxOptimizedLength %>,
quality : <%= GallerySettings.OptimizedImageJpegQuality %>,
enabled: true

This may be a blessing in disguise, because the broken behavior effectively delegates all resizing to the server, where the quality ends up so much better. Until browsers get better at resizing, I would stick with letting the server handle the task. So, instead of checking the ‘discard original’ box when adding your media files, use the ‘delete original files’ task page after the files have been uploaded and added to the gallery.


About the Author:

Founder and Lead Developer of Gallery Server

Leave A Comment