Last June, I wrote up some initial thoughts about how Plone could to more to help folks with limited experience preparing images for the web. It got quite a bit of favorable response, but then I went off on sabbatical and haven’t followed up, until now. I’m more convinced than ever that this is a good idea, and I really want to build some energy and resources around it.
Here’s some updated thinking on what I think could be done, both in core Plone and in a new add-on product, along with a simple wireframe and some implementation notes.
Making core Plone smarter
Plone 4 includes a frequently-requested feature that makes images much smarter: through-the-web configurable image scales. Previously, these were hard-coded into ATContentTypes. Now, we have a new “Image Scales” control panel, and site admins can add, edit and remove image scales. This makes it much easier to provide the image scales site users need, and to eliminate the ones they don’t. Nice work!
There’s one more change that I think should happen here:
Let’s make the amount of JPEG compression that PIL applies be easily configurable. Right now, it’s hardcoded into our zope.conf, and it’s really, really high. When we prep images for the web here at Groundwire, we typically use a compression quality of 60. I think that it would make a lot of sense to expose this variable through-the-web in the Image Scales control panel configlet.
Rough Spec for an “Image Optimizer” Add-on Product
Ok, now here’s where the cool stuff starts. Here are my updated thoughts on an add-on product that I think would really make life easier for sites that have lots of poorly-optimized images.
I imagine an “Image Optimization” control panel configlet that will present a UI that allows the user to:
- Walk the site catalog, looking for all objects that are Image-ish (i.e. have an image field) and contain images that are in JPEG, PNG or GIF 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 images with dimensions that are larger than user-specified value, offer to resize them.
- For images that are too “heavy per pixel,” offer to apply more compression (for JPEGs) or convert to JPEG (for GIFs/PNGs)
- Apply changes via a separate process (via plone.app.async) with AJAX updates so that Zope doesn’t bog down.
- Afterwards, offer to rebuild Plone’s auto-resized images afterwards from this new original. Purge caches as necessary.
Here’s a wireframe of what I’ve got in mind:
A few more implementation notes/questions:
- Alec Mitchell recommended using ImageMagick, because it offers much better quality than PIL. I think this also seems sensible, because it would offer an easy way to spawn the intensive image manipulation work off into a separate process. An outside-of-Zope processing approach such as plone.app.async is probably worth looking at as a model.
- Resize, then convert, then compress.
- JPEGs should be compressed via ImageMagick.
- PNGs could potentially be compressed by running through OptiPNG.
- GIF’s can’t be compressed
- Use AJAX to refresh the screen on scan and as optimization proceeds. Show optimization results by crossing out weight/dimension/density and replacing with new values. (Hide unselected images when you hit Optimize.) Total up savings at the bottom when optimization is complete.
- Can Plone’s image scale rebuild be run in the background via plone.app.async so we don’t tie up a Zope process?
- Plone 4 support is required; Plone 3 support would be very nice and would probably greatly increase the value of this product.
- For extra bonus points, warn the user of unoptimized images right after upload, and offer to fix it “on the spot.”
Somewhat randomly, I also wanted to take note of Kurt Bendl’s useful recipes for limiting the max KB and pixel dimensions of uploaded AT Images and Files. This might be useful and/or worth exposing in a TTW setting.
Doing a mediocre job on this would probably be pretty easy, but it will take some focused effort to really nail the details that will make this sing. I think this is a project worth raising a little bit of money around, and hiring someone good to really own it.
If your clients would benefit from a tool like this, I encourage you to think about whether you can raise some cash from them for a bounty fund. I don’t have a hard total in mind just yet, but I’m thinking that $3000-$5000 might be a reasonable range.
I’ve got a couple of people in mind that I’d like to approach as possible developers on this, but if this description strikes a chord with you and you’ve got both the passion and skills, let me know!
This also might make a great Google Summer of Code project, in which case I’d love to supplement that by paying an experienced Plonista to be a strong, hands-on mentor and ensure that the project gets done and done right. (This worked really well with Martin Aspeli and Timo Stollenwerk on plone.app.discussion!)
I’m willing to PM this and be “the customer” and Groundwire can very likely help seed the bounty fund as well. Let’s make this happen!