Quite impressive. But is it really that slow or did you just make the demo slower to visualize the algorithm?

@markus : I’ve noticed different rendering speeds on different platforms. However, the algorithm makes a lot of computation and furthermore is iterative. It means the image “width – 2px” cannot be computed before the image “width – 1px” has been computed. That’s some of the reason it seems slow.
To improve performance it is worse trying to uncheck “Refresh images during process”. Displaying intermediates images results in lost of time for computing. The algorithm tries to compute as fast as it can and stores the intermediate results. So you can play with it while process.

Not sure how much web workers would help there, except for not blocking JS execution while they are running. For multiple workers to lead to a big speedup, I would expect the algorithm to be required to be parallelizable.

I don’t get it. How is driving my hard-drive into a fit for 10 minutes to produce strange distortions in parts of the image an improvement in the web? The initial codebase of searching the image for “inactive” regions should just be used to CROP the image. Most images fall into one of three catagories… left or right heavy, center heavy, top or bottom heavy. It seems like it would be rediculously faster to scan an image, figure out which it is, and simply crop to effect. Maybe their could even be a tag included in the image description to specify which to use, which would not only cut down on all this crazy computation, but allow the designer to make sure the wrong thing doesn’t get cropped accidentally.

I’m not saying this to just be cross, as a member of the photographic community you would be surprised how upset photographers will be when they find out their web-browser is destroying the integrity of their images. Typical image resizing by squishing may be crude and even ugly… but it is at least honest… and someone can always “resquish” an image to see how it basically originally looked. This “feature” goes so far down the path of corrupting the integrity of the original image, it’s just about criminal. Not to say that the programmers haven’t done an excellent job, it’s a really sophisticated piece of programming… but there’s a moral issue to consider here. Just because you CAN do advanced level Photoshop editing right in the browser doesn’t mean you should.

Consider the multiple cases last year alone of journalists caught in the midst of scandals for Photoshopping images. And especially for artists and professional art photographers… the “dead space” being stolen out of these images isn’t just dead space. It’s called negative space and it’s often as and sometimes MORE crucial than the apparent subject in conveying the meaning of the image. The groups of people sitting on the steps is a great example… in the initial photo, there is plenty of space between the people and the photo is friendly and inviting. After being “resized” it’s a cramped claustrophobic atmosphere. The supposedly same image now has a completely different feeling. Cropping can be just as dangerous to image integrity, but at least it’s considered a normal publishing practice.

Having a CSS property to define method to use when resizing image could be useful :
.img {
resize-policy: liquid;
resize-policy: linear;
resize-policy: crop;
}

Urgh, no, liquid resize (which is what this is) is terrible for day-to-day resizing. It has value from a content production point of view, but it introduces so many artifacts and weirdnesses to images that Id never want my browser to do it automatically to any image I view.

Nice tool, but as a webdeveloper you don’t know anymore what your user is seeing.