Why…?

I believe that keeping the implementation of this package as simple as possible. When I say simple, I mean in comparison to other image transformation packages in Django.

The Alternative

The most popular apps, such as sorl-thumbnail, generate the transformed images in the request-response cycle, in the template or the views. That was the images are never out of date and are not stored in the database, which makes sense because there isn’t really anything new that should be stored by a scaled down image. And it makes sense that it is present in the template, because it really is a presentation detail. And it is the easiest method, and can be implemented with a few lines of code. For example:

{% thumbnail item.image "100x100" crop="center" as im %}
    <img src="{{ im.url }}" width="{{ im.width }}" height="{{ im.height }}">
{% endthumbnail %}

Performance Problems

I ran into performance problems with this approach. Since images are generated in the request-response cycle, caching strategies are essential to minimize database and storage access. I then found django-imagekit, which is much more advanced and allows a great flexibility on every bit of the image generation process. However I still found myself struggling to understand the exact implementation details of how and when the images were generated. This isn’t something I should have been worrying about, apart from the fact that some of my pages were timing out generating hundreds of thumbnails.

My Solution

So I decided to write an implementation that anyone could understand. django-simpleimages uses the standard Even though is more verbose, and requires an extra database column, storing transformed images in their own fields presents several advantages. It allows caching of image dimensions, using Django’s built in solution. It also is easy to understand when the storage backend is being accessed, because you are simply accessing a normal ImageField.