Comments on: Image retargeting

By: orlop

orlop — Thu, 31 Jul 2008 10:01:10 +0000

According to what I’ve read, the algorithm of Image Ratergeting is much mor complex in detail.

It finds salient areas of the image and fixes them – using algorithms like Whatershed, Graphcut etc. – after that it doesn’t resize any of these and interpolates only other areas of the image.

For every pixel of the image its “energy” (term) is calculated, ie. sand, water or sky has the lowest energy, human faces the highest. When resizing the image (and especially, which is the point of this algorithm, changing scale), the areas with points of lowest energy are interpolated, while the highest energy areas are fixed until the last moment. The chosen points with same energy or semantics are connected with “seams” and resized together.

It also counts with the fact that human brain senses much more in horizontal way than in vertical.

(source: “Pixel” 139-140, graphics magazine, Czech republic)

By: A Blogging Experiment - kometbomb

A Blogging Experiment - kometbomb — Fri, 18 Apr 2008 13:47:00 +0000

[...] example, people are often looking for image re-targeting when they click their way to my post about a crap example of the seam carving algorithm. There are much nicer examples out there. I’d like the random visitor to know that so the [...]

By: kometbomb

kometbomb — Thu, 28 Feb 2008 19:34:17 +0000

Actually, now that I thought of this again, you could try this: When drawing a polygon, figure out the polygon dimensions on the screen. Retarget the texture to those dimensions, send the new texture to the hardware and draw the polygon using the new texture. The result should be something between perspective and retargeting.

My routine is not an implementation of the algorithm described in the paper. The original routine should be more than fast enough for real-time use.

By: kometbomb

kometbomb — Thu, 28 Feb 2008 19:23:57 +0000

Hmm, I don’t think it would be useful at all, considering a mipmap pixel essentially is an average of four pixels from the larger image. E.g. when applying trilinear texturing (i.e. you crossfade between mipmaps), the two pixels from the two different mipmap levels would not match at all.

I have to say I can’t imagine what it would look like in motion. Maybe it would look cool (especially, if you need to keep important details visible even if a polygon is very small on the screen). But it definitely wouldn’t look right.

If you decide to do this, it’s worth of telling how it went. :)

By: Craigb

Craigb — Thu, 28 Feb 2008 19:07:16 +0000

Hey I have a question. Could this be helpful for procedurally generating mipmapping textures for openGL? I know its very process intensive to create the images, but if it were done at loading time that would fix that problem. The question is do you think it would be worth it at all?

By: kometbomb

kometbomb — Sun, 04 Nov 2007 19:09:33 +0000

I agree this one is a pretty cool programming puzzle for anyone interested, because it’s relatively simple to solve and also doesn’t have just one correct solution. And best of all, it produces interesting if not usable results even if the algorithm doesn’t work that well.

By: Gabe Rudy

Gabe Rudy — Sun, 04 Nov 2007 18:51:41 +0000

I like how many implementations have sprung up around this. I did a Qt4 GUI based on Andy Owen’s library, which now uses CAIR (a multi-threaded C++ retargeting library).

So if you looking for a fast desktop version (for Mac,Windows or Linux) you might want to take a look at http://code.google.com/p/seam-carving-gui/

By: selfblog » Blog Archiv » Retargeting / Intelligentes Ändern der Größe von Bildern

Thu, 01 Nov 2007 13:27:25 +0000

[...] Image Retargeting [...]

By: Will

Will — Sat, 29 Sep 2007 05:29:59 +0000

Check out rsizr.com for a free Flash-based implementation of seam carving that lets you resize your own images, both in height and width simultaneously, in real time. (You can rescale and crop images too!)

http://rsizr.com/about/gallery/ for example images

By: kometbomb

kometbomb — Tue, 11 Sep 2007 14:20:24 +0000

Thanks for the links.

OK, in the second version of my algorithm there’s a fundamental difference: I use only one gradient map and the algorithm described by the paper uses two gradient maps depending of along which axis we want to shrink the image. A quick trial shows that simply adding that feature to my algorithm makes it work much better. However, I noticed it started to evenly squash images much more. :(