[patch] Add automatic thumbnail generation to ImageFields

Isn't an import of a third-party library something Django tries to avoid?

ImageFields? already require PIL anyway.

Ah, you got me there. :-)

Well I'm using a different approach for this, instead wiring-up thumbnails into ImageField? I'm using img filter (attached) to display all images.

Embedding in ImageFiled? have some advantages (like automatic removal of thumbnail files) so I will try to merge this two things together and report back.

img filter implementation

This is a new implementation for automatic thumbnail generation (new_thumb.diff).

Main differences

• no changes in ImageField?, only get_%s_thumbnail method is added
• thumbnails are generated on the first request
• you can specify width and height
• all thumbnails are deleted when corresponding object is deleted
• if original image is changed thumbnail is recreated
• added a bunch of other image related helper functions to photos.py

new thumbnail patch

one more thing:

* if thumbnail do not exist (for example if PIL is not available) it will return original image url

second stab: thumb_mode, automatic deletion

Maybe it's a matter of personal style, but it seems that most applications will want thumbnails at given sizes, and these sizes are known to the developer. In that case, generating the thumbnails when the image is uploaded makes more sense, as they will be readily available the first time they are needed. Also, it seems like being able to specify arbitrary sizes (in both dimensions) is overkill -- who wants to change a thumbnail's aspect ratio?

In thumbnailing2.diff, I've added automatic thumbnail deletion when the original picture is deleted, and a thumb_mode parameter passed into ImageField?. Specifying meta.WIDTH and meta.HEIGHT create thumbnails with width/height no larger than the values in thumb_sizes, while meta.BOTH constrains both width and height while maintaining aspect ratio. I also moved generate_thumbnail to django.parts.media.photos where it makes more sense.

Actually what you want - at least what I want, I can't talk about your wishes ;-) - is to be able to give the "bounding box" of the thumbnail and the choice wether it should be scaled (and leaving part of the bounding box empty if your image has a different aspect ratio) or cropped (so that it fills the full bounding box, but part of the thumbnail is cut to make it fit th ebounding box, if it's aspect ratio is different). This because thumbnail size is very much a function of the layout, not the code itself - the layout later will decide what thumbnail size I need, not the upload of an image to the server.

Maybe it's a matter of personal style, but it seems that most applications will want thumbnails at given sizes, and these sizes are known to the developer.

Well, I thing that decision of image sizes is mostly done on the designer part (one which works with templates) and not developer. Our task (as a developers) is to make possible to designer (or template writer) to use whatever thumbnail size he chooses.

Also, it seems like being able to specify arbitrary sizes (in both dimensions) is overkill -- who wants to change a thumbnail's aspect ratio?

Actually, PIL function thumbnail always preserves aspect ratio, so required dimensions are just a request for no larger than size with preserving aspect ratio.

is to be able to give the "bounding box" of the thumbnail and the choice wether it should be scaled (and leaving part of the bounding box empty if your image has a different aspect ratio) or cropped (so that it fills the full bounding box, but part of the thumbnail is cut to make it fit th ebounding box, if it's aspect ratio is different).

"bounding box" part is already taken care of with thumbnail generation (see above), and "crop box" is very interesting idea (and not hard to add IMHO).

IMHO, suggested usage for all of this will be that thumbnail infrastructure will be coupled with some additional tags/filters (I'll add examples below) for accessing images from templates.

Some new tag/filters proposals:

• |thumbnail:"w=<width>|h=<height>" - get and/or generate thumbnail with required width and/or height. Works only with ImageFields?
• |crop_image:"top=<x>|left=<y>|w=<width>|h=<height>" - crop image from (top, left) position to size (width, height).
• {% image_size <url> as w, h %} - store image size in w and h variables in current context.
• |image_width, |image_height - as alternative to above

PS. I'll move this discussion to django-devel list to attract more opinions.

thumbnails implementation

small patch for core/meta/init.py

Here is a implementation of new ImageWithThumbnailField? (thumbnails.zip) with corresponding filters. Put it somewhere into python path under directory nesh/ (currently imports are set this way).

Also source:django/trunk/django/core/meta/__init__.py (meta.diff) patch to enable me to hook-up to model delete method.

Only a |crop filter is not implemented - it fill require new additions to field class to manage crop thumbnails deletion.

As is discused in django-devel I'm dropping out of custom ImageField? because it's not possible to attach to save/delete events in the model from field without patching django source.

This is out of the scope of what Django should do out of the box. In .92 it'll be very easy to define new field types, so this should become an add-on field type.

OK with me, I'm started to work on new ImageWithThumbnail? field for m-r branch already.

So, for people like me, trying to figure out what happens with this:

http://djangoutils.python-hosting.com/wiki/Thumbnails