Yes, absolutely. But...

The reason for the rather complex implementation with a backend is, that we actually did not have Social Media Image Cropping in mind when we started development more than two years ago. The problem we set out to solve is considerably larger: how to automatically crop an image into any aspect ratio with a guaranteed acceptable outcome (key elements intact and the image composition as good as possible). This challenge is a pestering problem whereever publication workflows are automated: "Content/XML first", Template Driven Publishing, eBooks, websites and so much more (how about destination mood images for the airplane eTicket on your mobile device?).

Standard procedure as of today is to decide for a set of primary aspect ratios (for example 1:1 for the thumbnail of the article list view, 4:3 for the article preview on the landing page and 16:10 for the actual article), manually crop the original image into each of those primary ar's, store them somewhere and build the publication workflows to automatically choose the respective version and scale it to the final dimensions. There are a couple of tools within modern DAM systems to assist with this approach (like dedicated cropping frames for each primary aspect ratio in an image editor), nevertheless this approach is cumbersome and inflexible. What, if the art director decides to change the website layout and go for a new aspect ratio for the article images? It would be necessary to recrop the entire image archive.

So we tried AI and image analysis. Some image types work very well - face recognition, or typical stock photography with a blurry background for example. But while the results of AI image recognition are sometimes astonishingly good, it nevertheless fails on multiple levels. A significant percentage of AI croppings fail completely for whatever reasons, or the result catches the focal area but loses composition aspects (e.g. asymmetry) unnecessarily early, or the AI is simply missing the context (if there are two people on the photo and I can only show one in portrait, who shall it be?). If there is only one percent failure in the AI approach, it cannot be used in fully automated workflows without a follow-up result verification process.

In the end we concluded that only a human can reliably decide about the recomposition of a motive upon aspect ratio change. So we invented a method to apply an universal cropping hint (once!), store it in the image metadata and then have an algorithm, that can calculate the resulting cropping rect for any aspect ratio from that cropping hint. The cropping hint consists of a number of elements (some user-interactionable, some hidden) and it took us more than a year to finetune the cropping algorithm. This technology is our core product (that we want to make money with) and it is called qCrop (certainly worth its own "Show HN" as soon as we have finalized the API). So, qCrop consists of the cropping hint format, the cropping algorithm and the services to use the technology in automated workflows: a client to visually apply the cropping hints and embedd them into the picture files (this part should actually be implemented in DAM systems) and the cropping service, which can deliver cropped versions of an image on demand with simple parameterized http GET requests.

Now this is complex stuff and how are we going to explain it to a potential customer?

Here comes Cropping.Rocks: a minimum viable product, a single page app with only a few lines of HTML and JS incorporating the qCrop backend. A technology showcase for our potential customers and a free time saver for social media professionals ;-)