|Version 11 (modified by 8 years ago) (diff),|
Discussion about Thumbnail Contribution for Django
The majority of applications that have images, probably use thumbnails in some capacity. There is no standard thumbnail capability in Django but there are a couple of different options out there that people have created. This page is an attempt to gather them in one place and discuss the best strategy for integrating one in Django.
The original thread discussing this issue is here - Google Discussion
- sorl-thumbnail is excellent.
- Nesh's Thumbnail
- Here's a more simple filter from Django snippets - Simple filter
- In Ticket #4115 you will find a patch with a contrib.thumbnails package - good documented; read the Google Discussion mentioned above for some thoughts about the implementation.
- Quick tip for adding thumbnails - Blog posting
- Yet another approach to adding a thumbnail - CustomUploadAndFilters
- One more external approach - http://www.verdjn.com/
- Snippet that creates thumbnails on-demand using dynamics methods - Snippet 619
Whichever solution is considered should have the following features:
- Capability to define arbitrary thumbnail sizes in templates
- Caching of the files to disk and possibly to memory
Some key questions:
- Do we want to create a new field or just expand the existing image field?
- What dependencies are we comfortable with?
- Preference for limiting it to the Python Imaging Library only.
- Image Quality using PIL
- PIL has some serious quality problems for 'professional quality' images
- Metadata destruction issues with PIL (wiping IPTC data, ICC profiles, EXIF data for instance)
- No Color Profile Support (or 'hard to deal with' Profile support)
- PIL and Large Files (20 MB Tiffs for instance) in a Web Environment = Bad
- Lots of Thumbs on a page (i.e. 20+) .. In memory constant converting not so good for server performance ..
- file caching is a must
- Advanced Sharpening/Contrast enhancements for very small thumbs
- SOLUTION:: ImageMagick .. and 'convert' (http://www.imagemagick.org/script/convert.php) (PyMagick is really not suitable for most things)
- Yes! Command line, but in a 'web' environ .. separate fork to deal with Memory and _large_ files
- use of 'convert' should at least be a setting option for those that want quality
- Large Number of Originals + Thumbs scalability issues
- Simple 'upload_to=/my/dir/' will eventually die at 5000+ images
- Uploading needs to be able to be 'partitioned' into folder trees
- i.e. /photos/10000/9/99/my_file.jpg (or a 'squid' like cache partition structure)
- 200000+ images and 'super' partitioning is in order (partitions the partitions)
- NFS partitions .. try Rsyncing a filestructure with 200000+ things in it, you'll be there all day
- (i.e. images 1-50000 on NFS server 'A' images 50000-100000 on server 'B' etc)
- Separate Thumbs and Originals (for backup and sanity sake)
- thumbs on 'active/fast' server .. originals on slower/denser disk system
- External Backups/Asynchronous backups
- Integrate with S3 (or equivalent service)
- Auto 'purge' of old untouched cached thumbs
- Nesh's thumbnails can be used as a standalone templatetag without using his ImageWithThumbnails field. Just use the ordinary django ImageField