On image cropping

Originally I would have implemented cropping the way Karina did, but I got it stuck in my head that it would be much more efficient to compute the source rectangle and only do a single crop operation when it came to building the rendition. My four reasons for this were:

• Performance (only crop once if possible)
• Something to do with better image quality (i.e. an intuitive thing that was stuck in my brain but had nothing to do with reality)
• Wanting to match the cropping rectangle’s aspect to the output aspect
• Wanting the rendition filename to only reflect the input box

Performance is a non-issue; even if it did make a measurable difference, renditions are cached as long as they’re being used, and thus don’t actually need to be recomputed every time.

Image quality was just something stuck in my head from when I was working on the Amazon image rendering service, because of some less-than-optimal things it did internally. It’s not an issue for how Pillow works though.

Aspect matching is still a thing I kind of wanted to do, but then that leads to a few things like, what gravity should be used when “uncropping” the rectangle, and what about honoring the intent of the crop for excluding stuff outside of the box, and so on? Anyway those are a lot of questions that had fiddly answers and the reality is that it’s easier to just leave it up to the user to match the aspect as appropriate, and use resize="fill" vs. resize="fit" as appropriate.

And the rendition filename? Who heckin' cares, the point to rendition filenames is that they’re unique, idempotent, and debuggable, not pretty. The basic tenet of humane URLs doesn’t apply to them.

Anyway, as mentioned above the cut I do want to make a change to how cropping works in that right now it uses Pillow’s rectangle specification of (left,top,right,bottom) but after using it for a day I’m finding that really annoying and basically all imaging software uses (x,y,width,height) with respect to the top-left corner, and it makes no sense to have right < left or bottom < top anyway. So, on the off chance you’re using Publ for your site and trimming thumbnails of your images, I’d recommend holding off until the next version.

Update: And then about an hour later I realized that there was actually a really easy way to make scale-cropping work correctly here and I’m feeling silly for not noticing it before. So this actually satisfies all of my original reasons except for the cropping rectangle aspect! Also while testing this I found a case where the (x,y,w,h) tuple syntax confuses the Markdown parser, so it now also accepts an 'x,y,w,h' string as well.

The road to v0.4.0

A lot has changed in Publ since v0.3.0, and I feel like a v0.4.0 release is overdue. If I were doing proper semantic versioning we’d be on, like, v2.29.0 by now, but I feel like Publ is more of a stream-of-updates thing than a scheduled-release thing. So the versioning scheme is pretty ad-hoc and more represents where I feel like Publ is in terms of being a Real Professional Publishing System vs. being a toy I made for myself.

So, I have two planned version milestones, v0.4 and v1.0. v0.4 is roughly where I feel like it should be stable enough for use by people who are into having a stable system to work with and don’t want to deal with fiddly stuff that’s an artifact of things being developed ad-hoc, and v1.0 is more like, hey, let’s get all of the Big Features done and also get it incredibly polished for large-scale adoption.

So, v0.4 is almost ready for release, I think, but v1.0 is going to be much further out, since it also involves much larger feature work (such as authenticated/private content), and likely I’ll end up establishing a closer milestone for major feature work like that but for now I’m just using 1.0 as a bucket for “everything that makes this a compelling blogging platform” (i.e. stuff to get people out of silos like LiveJournal or Facebook).