This kind of processing is better done async because it's quite time-consuming. Ideally you would issue a non-smart thumb on first request and serve the smart-cropped one once it's ready. But this something our thumbnail caching infrastructure doesn't currently support. All our thumbnails are rendered on the fly "as fast as possible". In that limited paradigm, something like smart cropping would slow down initial thumbnail requests considerably, meaning that clients might end up waiting seconds for a smart cropped thumbnail where the non-smart one would have taken milliseconds. I don't think this is a smart tradeoff.

A "quick thumb on first request" followed by a refined thumb is something desirable in general, which would allow us to perform time-consuming agressive visually lossless compression on our most popular thumbnails, for example.

I don't think there's an existing task for the work I'm describing, but it's a significant undertaking involving our entire thumbnail infrastructure from URL scheme, our various layers of caching, generation and storage.

So while this is very simple at the Thumbor level, it's everything else around it that makes it a big undertaking.