I’ve been brainstorming a bit about how Plone do an even better job of helping non-technical website editors manage and optimize their images for the web, and I’ve come up with what I think is a pretty clever idea. I have neither the time nor the skill to implement it, and so I thought I’d float it out there to see if
A) it holds water;
B) if I can’t interest someone in implementing it 😉
The problem: big-ass images
Lots of people who edit Plone websites don’t really understand how to properly optimize images for the web via resizing and compression. Plone is not entirely unhelpful here; if you upload an image, we automatically create several different resized versions for you to use in your pages. However, Plone doesn’t currently do anything to help you make sure that original image you’re uploading is appropriately sized and compressed.
When you couple user inexperience with the massive image sizes that today’s digital cameras produce (6/8/10/12 megapixels!), the result is often a situation where users are uploading massive digital camera photos to their Plone sites, then using the PIL resizes in page. While this works, it quickly produces a bloated ZODB. In addition, the automatic PIL resizes don’t apply much compression, so the resized images aren’t very well optimized either. This slows down site performance and causes lots of unnecessary server load.
There are a number of add-on products that can help in various ways, among them:
- Plone.app.blob and Filesystem storage, which push large binary objects such as images to the filesystem, reducing ZODB bloat.
- ImageEditor, the amazing Photoshop-like image editing program that runs inside of Plone. It can do resizing and compression, but only one image at a time. It’s a great solution for end-users, though.
These are great, but I think we can do better.
Some possible clever solutions
Here’s how I think we can do better.
First, some changes to Plone’s default behavior:
- Make the amount of compression that PIL applies to its resizes settable in the Plone control panel. Right now it is hardcoded into ATContentTypes, and it’s hard to customize without rolling your own content types.
- Automatically resize all “original” uploaded images to 1024px. Make it user-configurable, and disable-able for those rare occasions when you need to upload really high-resolution originals.
More daringly, I think that someone could write a clever add-on product for site administrators that would do the following:
- Walk the site catalog, looking for all objects that are Image-ish and in JPEG format.
- Look at the pixel dimensions and the filesize of each image.
- Find images where the “bytes per pixel” (filesize/*(height*width)) is higher than a certain “reasonable” value. (0.5 bytes per pixel seems about right to me, based on the idea that a 150X150 pixel JPEG image shouldn’t weigh much more than 10kb. (Obviously, these settings should be user-editable.)
- Present the user with a list of “suspiciously large” images, along with their pixel dimensions, filesize, bytes per pixel and a preview.
- For the JPEG images, offer to apply additional compression to some or all of the selected images. (Make value user-settable, maybe offer an opportunity to test it against 2-3 images, and estimate the savings you’d realize.)
- For images that have larger pixel dimensions than anyone would want to display in a web browser, offer to resize the original image down to a user-specified size (1024 pixels seems like a reasonable default to me).
- Apply compression via PIL, presumably in a background process so that Zope doesn’t bog down. Rebuild Plone’s auto-resized images afterwards from this new original. Purge caches as necessary.
So, whaddya think? Is this sane? Would you get value from these things? Are there other low-hanging fruit I’ve overlooked? Interested in helping roll the first two ideas into PLIPs for Plone 4? Or building out the bulk image optimizer? Or helping raise some money to sponsor such a project? I’d love to hear from you.