Based on cool work by Shai Avidan and Ariel Shamir. Thanks dudes.

Move the dashed bar to change the size. You can select horizontal or vertical resizing down on the lower left. You'll get the best results if you carve 20 or 30 seams in one dimension, then 20 or 30 in the other, and so on.


You can load an image into the resizer by entering the URL in the box. Be aware though, flash is very particular about finding a crossdomain.xml file in the directory with your pictures or at the server root.

If you aren't hosting your own photos, which is probably the case, flickr has all the crossdomain stuff set up intelligently so you can browse that for images. If you are hosting your own images you can just drop this guy in the directory with them.

If all you see is a white box, we have a crossdomain.xml problem. If that happens with a flickr image, or another one you know should work, just try loading it a couple more times and curse flash.

Most photos seem to put the subject right in the middle—and big too. These photos are boring to resize. It's a little tricky to find photos that can be resized by a large amount with cool results. Here are some flickr tag starting points:

Use images larger than the medium or small sizes at your own risk—flash is slow.

Some Favorites


I know switching between horizontal and vertical resizing seems a little limiting, but check out section 5 and the appendix of the paper to see why real-time two-dimensional resizing is harder than it seems. Also if you watch the video closely you'll see that pretty much all the real-time resizings are in one dimension. Don't worry though, you can switch dimensions as much as you want to get down to the right size.

To implement this in flash we've had to take a couple liberties with the algorithm. Primarily, we only recompute the path maps on a dimension change. So if we start chopping off the wrong parts or doing something weird, just switch dimensions and switch back to force a recompute. (It may be possible to detect this and handle it automatically, but computing the path map takes so much time it would ruin the experience if we guess wrong.)

Our energy function is based on instantaneous differences in pixel value, so it may get confused and think a noisy bunch of leaves is more important than a model's smooth skin. Like they note in the paper, there's no perfect solution here.

For now you can only reduce the image size. Also, when you switch between horizontal and vertical we recompute some things and you'll be unable to expand back to a larger size. Sorry, if you mess up you'll just have to reload the image.


This post is a good introduction. Apparently there are some security issues with flash-based cross-site-scripting, but I can't imagine they apply to using images like this. Especially since flash will load images from anywhere until it's blue in the face, however you can only access and modify the pixels if the site explicitly adds a crossdomain.xml file saying it's OK.

This behavior is really stupid and I can't believe Adobe made me waste time figuring out what was going on.

Adobe: If you're really worried about websites getting angry at you for letting flash access image pixels just add an HTTP header to the image requests, or modify the User-Agent, or do something that allows servers to block flash image requests. Don't cripple your products and don't do this idiotic opt-in thing!


Patrick Swieskowski <>