saw that the other day -- very cool.

On 8/29/07, Dotan Cohen wrote:

There is an amazing video describing an image resizing algorithm that removes (or adds) pixels based upon their importance to the subjecto of the photo. Can this be implemented in The Gimp? Apparently it will soon be a part of Photoshop.

The video is here:

http://www.techcrunch.com/2007/08/28/adobe-hires-co-inventor-of-image-resizer-technology/

Dotan Cohen

http://what-is-what.com/what_is/gimp.html _______________________________________________ Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

Dotan Cohen wrote:

There is an amazing video describing an image resizing algorithm that removes (or adds) pixels based upon their importance to the subjecto of the photo. Can this be implemented in The Gimp?

Of course it can be implemented in GIMP. It just takes someone with the time and ability to write the code for a plug-in that implements the algorithm.

Kevin Cozens wrote:

Dotan Cohen wrote:

There is an amazing video describing an image resizing algorithm that removes (or adds) pixels based upon their importance to the subjecto of the photo. Can this be implemented in The Gimp?

Of course it can be implemented in GIMP. It just takes someone with the time and ability to write the code for a plug-in that implements the algorithm.

The approach of using energy (I wonder that really means entropy) approach to finding "boring" seams through the image is very clever. The first thing to find out is whether any of this has been patented yet. If it has, then there are probably other approaches to identifying interesting areas of the image - graph-cut algorithms or other feature-identification systems. It looks like the sort of thing Paul Harrison (author of the Resynthesizer plugin) would be able to knock up in a lunchtime or too :-)

Cheers, Toby Haynes

Kevin Cozens wrote:

Dotan Cohen wrote:

There is an amazing video describing an image resizing algorithm that removes (or adds) pixels based upon their importance to the subjecto of the photo. Can this be implemented in The Gimp?

Of course it can be implemented in GIMP. It just takes someone with the time and ability to write the code for a plug-in that implements the algorithm.

Looks like someone has implemented it already: http://registry.gimp.org/plugin?id=5479 http://zinx.xmms.org/colorize/

Trying to compile the supporting libraries.. it's a PITA, unfortunately.

On Thursday 04 October 2007, Konstantin Svist wrote:

Kevin Cozens wrote:

Dotan Cohen wrote:

There is an amazing video describing an image resizing algorithm that removes (or adds) pixels based upon their importance to the subjecto of the photo. Can this be implemented in The Gimp?

http://liquidrescale.wikidot.com/ and the video for it is here
http://liquidrescale.wikidot.com/en:examples

Only problem now: It's located in the layers menu, which should be changed to filters->something

Daniel Hornung wrote:

On Thursday 04 October 2007, Konstantin Svist wrote:

Kevin Cozens wrote:

Dotan Cohen wrote:

There is an amazing video describing an image resizing algorithm that removes (or adds) pixels based upon their importance to the subjecto of the photo. Can this be implemented in The Gimp?

http://liquidrescale.wikidot.com/ and the video for it is here
http://liquidrescale.wikidot.com/en:examples

Only problem now: It's located in the layers menu, which should be changed to filters->something

Actually, I think it's a feature. See, it uses different layers to mark areas which should be preserved and areas to be removed (just paint it with paintbrush and go). Unfortunately, it's nowhere near as fast as the one shown in the video. And, as a corollary, it can't be used to see the difference while resizing. Someone mentioned (on some blog) that this plugin uses some generic math library and would work better with specialized algorithms.

Online tool which does this : http://rsizr.com/

I realise I sent this from my gmail address instead of the one registered on the list

Konstantin Svist said on Oct 04, 2007 15:54 -0400 (in part):

Kevin Cozens wrote:

Dotan Cohen wrote:

There is an amazing video describing an image resizing algorithm that removes (or adds) pixels based upon their importance to the subjecto of the photo. Can this be implemented in The Gimp?

Of course it can be implemented in GIMP. It just takes someone with the time and ability to write the code for a plug-in that implements the algorithm.

I don't think the one you point to below is the same as Liquid Resizer (see http://schumaml.gmxhome.de/downloads/gimp/ and d/l http://schumaml.gmxhome.de/downloads/gimp/gimp-lqr-plugin-0.1.3.zip for it).

Looks like someone has implemented it already: http://registry.gimp.org/plugin?id=5479 http://zinx.xmms.org/colorize/

Trying to compile the supporting libraries.. it's a PITA, unfortunately.

I hope you succeed - the colorizer looks like it would be a lot of fun to play with.
From the Readme there, here is a pdf and an abstract from the algorithm author:

* http://www.cs.huji.ac.il/~alevin/papers/colorization-siggraph04.pdf * http://www.cs.huji.ac.il/~yweiss/Colorization/

Popping up to his home page it looks like he's done a lot of interesting "stuff":
http://www.cs.huji.ac.il/~yweiss/

If you succeed would you be generating for Win32 platform? (hopefully :-) )

Regards ... Alec -- buralex-gmail

buralex@gmail.com wrote:

Konstantin Svist said on Oct 04, 2007 15:54 -0400 (in part):

Kevin Cozens wrote:

Dotan Cohen wrote:

There is an amazing video describing an image resizing algorithm that removes (or adds) pixels based upon their importance to the subjecto of the photo. Can this be implemented in The Gimp?

Of course it can be implemented in GIMP. It just takes someone with the time and ability to write the code for a plug-in that implements the algorithm.

I don't think the one you point to below is the same as Liquid Resizer (see http://schumaml.gmxhome.de/downloads/gimp/ and d/l http://schumaml.gmxhome.de/downloads/gimp/gimp-lqr-plugin-0.1.3.zip for it).

Looks like someone has implemented it already: http://registry.gimp.org/plugin?id=5479 http://zinx.xmms.org/colorize/

Trying to compile the supporting libraries.. it's a PITA, unfortunately.

I hope you succeed - the colorizer looks like it would be a lot of fun to play with.

From the Readme there, here is a pdf and an abstract from the

algorithm author:

* http://www.cs.huji.ac.il/~alevin/papers/colorization-siggraph04.pdf * http://www.cs.huji.ac.il/~yweiss/Colorization/

Popping up to his home page it looks like he's done a lot of interesting "stuff":
http://www.cs.huji.ac.il/~yweiss/

If you succeed would you be generating for Win32 platform? (hopefully :-) )

You're absolutely right. The plugin for context-sensitive resizing is located at http://liquidrescale.wikidot.com/ (is it the same one as in your links?). I got it to work fairly easily. I was hunting for it and the colorizer plugin and got the two confused in my head :D
The colorizer plugin seems very cool, especially since I have a lot of old b/w photos that I'd love to colorize

As far as generating it for win32.. I'm using Linux, so probably no. I'll post what I've done if you're interested (when I get it working, of course).

oops, this didn't get sent to the list. Also, I think the problems I'm encountering are because: A) YIQ tends to oversaturate too readily B) the image ICC profile is AFAIK undefined, and is, anyway, disregarded. C) L*a*b* colorspace is not being used. In my experience L*a*b* represents saturation accurately, as well as intensity If this plugin could use L*a*b* space (with GEGL's help?) for the application of colorization effect, it would be more useful.

---------- Forwarded message ---------- From: David Gowers
Date: Oct 6, 2007 4:39 PM
Subject: Re: [Gimp-user] Image resizing based upon image content To: "buralex@gmail.com"

On 10/6/07, buralex@gmail.com wrote:

Konstantin Svist said on Oct 04, 2007 15:54 -0400 (in part):

Kevin Cozens wrote:

> Dotan Cohen wrote:

>> There is an amazing video describing an image resizing algorithm that

removes (or adds) pixels based upon their importance to the subjecto of the photo. Can this be implemented in The Gimp?

> Of course it can be implemented in GIMP. It just takes someone with the time

and ability to write the code for a plug-in that implements the algorithm.

I don't think the one you point to below is the same as Liquid Resizer (see http://schumaml.gmxhome.de/downloads/gimp/ and d/l http://schumaml.gmxhome.de/downloads/gimp/gimp-lqr-plugin-0.1.3.zip for it).

Looks like someone has implemented it already: http://registry.gimp.org/plugin?id=5479 http://zinx.xmms.org/colorize/

Trying to compile the supporting libraries.. it's a PITA, unfortunately.

On linux (ubuntu 7.10), at least, it's simple. Install 'libsuitesparse' and the matching 'dev' package, and apply the following patch to the Makefile:

--- Makefile.old 2007-10-01 05:54:38.000000000 +0930 +++ Makefile 2007-10-06 15:48:22.000000000 +0930 @@ -6,7 +6,11 @@
GIMP_CFLAGS=`$(GIMPTOOL) --cflags`

UMFPACK_CFLAGS=-I/usr/include/suitesparse -I/usr/include/umfpack -UMFPACK_LDFLAGS=-lumfpack -lamd -lcholmod -lm +# FIXED -- works on Ubuntu 7.10;
+# Only requirement is libsuitesparse package (make sure it's installed cleanly; +# 'umfpack' package conflicts with it. I removed umfpack and reinstalled libsuitesparse
+# + libsuitesparse-dev.)
+UMFPACK_LDFLAGS=-lumfpack -lamd -lcholmod -lcolamd -lblas -llapack -lm

CFLAGS=-g -Wall -O3 $(GIMP_CFLAGS) $(UMFPACK_CFLAGS) LDFLAGS=$(GIMP_LDFLAGS) $(UMFPACK_LDFLAGS)

Using this, I currently have the colorizer plugin installed :) My experiments have not turned out as well as those shown on the page, though.

David Gowers wrote:

oops, this didn't get sent to the list. Also, I think the problems I'm encountering are because: A) YIQ tends to oversaturate too readily B) the image ICC profile is AFAIK undefined, and is, anyway, disregarded. C) L*a*b* colorspace is not being used. In my experience L*a*b* represents saturation accurately, as well as intensity If this plugin could use L*a*b* space (with GEGL's help?) for the application of colorization effect, it would be more useful.

---------- Forwarded message ---------- From: David Gowers
Date: Oct 6, 2007 4:39 PM
Subject: Re: [Gimp-user] Image resizing based upon image content To: "buralex@gmail.com"

On 10/6/07, buralex@gmail.com wrote:

Konstantin Svist said on Oct 04, 2007 15:54 -0400 (in part):

Kevin Cozens wrote:

> Dotan Cohen wrote:
>> There is an amazing video describing an image resizing algorithm that

removes (or adds) pixels based upon their importance to the subjecto of the photo. Can this be implemented in The Gimp?

> Of course it can be implemented in GIMP. It just takes someone with the time

and ability to write the code for a plug-in that implements the algorithm.

I don't think the one you point to below is the same as Liquid Resizer (see http://schumaml.gmxhome.de/downloads/gimp/ and d/l http://schumaml.gmxhome.de/downloads/gimp/gimp-lqr-plugin-0.1.3.zip for it).

Looks like someone has implemented it already: http://registry.gimp.org/plugin?id=5479 http://zinx.xmms.org/colorize/

Trying to compile the supporting libraries.. it's a PITA, unfortunately.

On linux (ubuntu 7.10), at least, it's simple. Install 'libsuitesparse' and the matching 'dev' package, and apply the following patch to the Makefile:

--- Makefile.old 2007-10-01 05:54:38.000000000 +0930 +++ Makefile 2007-10-06 15:48:22.000000000 +0930 @@ -6,7 +6,11 @@
GIMP_CFLAGS=`$(GIMPTOOL) --cflags`

UMFPACK_CFLAGS=-I/usr/include/suitesparse -I/usr/include/umfpack -UMFPACK_LDFLAGS=-lumfpack -lamd -lcholmod -lm +# FIXED -- works on Ubuntu 7.10;
+# Only requirement is libsuitesparse package (make sure it's installed cleanly; +# 'umfpack' package conflicts with it. I removed umfpack and reinstalled libsuitesparse
+# + libsuitesparse-dev.)
+UMFPACK_LDFLAGS=-lumfpack -lamd -lcholmod -lcolamd -lblas -llapack -lm

CFLAGS=-g -Wall -O3 $(GIMP_CFLAGS) $(UMFPACK_CFLAGS) LDFLAGS=$(GIMP_LDFLAGS) $(UMFPACK_LDFLAGS)

Using this, I currently have the colorizer plugin installed :) My experiments have not turned out as well as those shown on the page, though.

Nice!
But on Fedora there's only ufsparse library (as of now, anyway) and SuiteSparse has to be installed by hand :(

As for email not making it to the list.. I think it's because whoever maintains this list forgot to set reply-to header. To work around this, just use "Reply All" and (optionally) delete the user's email, leaving the list email only.

Konstantin Svist wrote:

David Gowers wrote:

oops, this didn't get sent to the list. Also, I think the problems I'm encountering are because: A) YIQ tends to oversaturate too readily B) the image ICC profile is AFAIK undefined, and is, anyway, disregarded. C) L*a*b* colorspace is not being used. In my experience L*a*b* represents saturation accurately, as well as intensity If this plugin could use L*a*b* space (with GEGL's help?) for the application of colorization effect, it would be more useful.

---------- Forwarded message ---------- From: David Gowers
Date: Oct 6, 2007 4:39 PM
Subject: Re: [Gimp-user] Image resizing based upon image content To: "buralex@gmail.com"

On 10/6/07, buralex@gmail.com wrote:

Konstantin Svist said on Oct 04, 2007 15:54 -0400 (in part):

Kevin Cozens wrote:

> Dotan Cohen wrote:
>> There is an amazing video describing an image resizing algorithm that

removes (or adds) pixels based upon their importance to the subjecto of the photo. Can this be implemented in The Gimp?

> Of course it can be implemented in GIMP. It just takes someone with the time

and ability to write the code for a plug-in that implements the algorithm.

I don't think the one you point to below is the same as Liquid Resizer (see http://schumaml.gmxhome.de/downloads/gimp/ and d/l http://schumaml.gmxhome.de/downloads/gimp/gimp-lqr-plugin-0.1.3.zip for it).

Having tried out Liquid Rescale I'm very impressed. But does anyone have an idea about the size of image it can deal with in terms of memory requirements (I presume the Gimp setting Tile Cache size)?

I've crashed it with a 700MB jpg setting Tile Cache Size to 3 GB (using Linux Mandriva 2007.0).

Doug

Doug wrote:

Having tried out Liquid Rescale I'm very impressed. But does anyone have an idea about the size of image it can deal with in terms of memory requirements (I presume the Gimp setting Tile Cache size)?

I've crashed it with a 700MB jpg setting Tile Cache Size to 3 GB (using Linux Mandriva 2007.0)

There should be best/worst-case estimates in the paper, but if not, it probably depends on the algorithm.
But 700MB jpeg... that's pretty hard core :)

Konstantin Svist wrote:

Doug wrote:

Having tried out Liquid Rescale I'm very impressed. But does anyone have an idea about the size of image it can deal with in terms of memory requirements (I presume the Gimp setting Tile Cache size)?

I've crashed it with a 700MB jpg setting Tile Cache Size to 3 GB (using Linux Mandriva 2007.0)

There should be best/worst-case estimates in the paper, but if not, it probably depends on the algorithm.
But 700MB jpeg... that's pretty hard core :)

Thanks, I'll go have a look at the paper. The jpeg was a mosaic of some 25 sensible-sized pics ;-)

Doug

Doug wrote:

Konstantin Svist wrote:

Doug wrote:

Having tried out Liquid Rescale I'm very impressed. But does anyone have an idea about the size of image it can deal with in terms of memory requirements (I presume the Gimp setting Tile Cache size)?

I've crashed it with a 700MB jpg setting Tile Cache Size to 3 GB (using Linux Mandriva 2007.0)

There should be best/worst-case estimates in the paper, but if not, it probably depends on the algorithm. But 700MB jpeg... that's pretty hard core :)

Thanks, I'll go have a look at the paper. The jpeg was a mosaic of some 25 sensible-sized pics ;-)

Doug

P.S. the paper is beyond me, but I couldn't recognise any sort of estimates. Thanks anyway.
Doug

Hi,

On Sun, 2007-10-07 at 16:28 -0700, Konstantin Svist wrote:

Having tried out Liquid Rescale I'm very impressed. But does anyone have an idea about the size of image it can deal with in terms of memory requirements (I presume the Gimp setting Tile Cache size)?

I've crashed it with a 700MB jpg setting Tile Cache Size to 3 GB (using Linux Mandriva 2007.0)

There should be best/worst-case estimates in the paper, but if not, it probably depends on the algorithm.

It also very much depends on how the plug-in is implemented. If it transfers the full image data from GIMP to the plug-in, then it's basically unusable with large images. Unfortunately quite a lot of plug-ins are implemented that way.

Sven

Sven Neumann wrote:

Hi,

On Sun, 2007-10-07 at 16:28 -0700, Konstantin Svist wrote:

Having tried out Liquid Rescale I'm very impressed. But does anyone have an idea about the size of image it can deal with in terms of memory requirements (I presume the Gimp setting Tile Cache size)?

I've crashed it with a 700MB jpg setting Tile Cache Size to 3 GB (using Linux Mandriva 2007.0)

There should be best/worst-case estimates in the paper, but if not, it probably depends on the algorithm.

It also very much depends on how the plug-in is implemented. If it transfers the full image data from GIMP to the plug-in, then it's basically unusable with large images. Unfortunately quite a lot of plug-ins are implemented that way.

Sven

I don't see any information about the implementation. If that's the case, it's a great pity - it's a very nice plug-in :-(

Doug

--- Simon Nickau wrote:

Online tool which does this : http://rsizr.com/

I tried this but the image resets as soon as its done. You don't even get a chance to view the final output.

_____________________________________

Greg wrote:

--- Simon Nickau wrote:

Online tool which does this : http://rsizr.com/

I tried this but the image resets as soon as its done. You don't even get a chance to view the final output.

I saw the same thing.. are you using linux, perchance? Maybe it's limux-flash-specific bug...
Anyway, I think it keeps the result but doesn't -- try saving it and see if you get the final image.

Hi,

Am Donnerstag, den 11.10.2007, 15:45 -0700 schrieb Greg:

--- Simon Nickau wrote:

Online tool which does this : http://rsizr.com/

I tried this but the image resets as soon as its done. You don't even get a chance to view the final output.

... and I use this chance to shamelessly plug my tutorial video about the liquid resize plugin for the Gimp: http://meetthegimp.org/?p=60

Why use some Flash if you can do it in the Gimp? ;-)

Rolf

Online tool which does this : http://rsizr.com/

I tried this but the image resets as soon as its done. You don't even get a chance to view the final output.

... and I use this chance to shamelessly plug my tutorial video about the liquid resize plugin for the Gimp: http://meetthegimp.org/?p=60

Why use some Flash if you can do it in the Gimp? ;-)

I would like to endorse what Rolf has written. I watched the video 3 days ago and have had great fun resizing and removing parts of images ever since.

Norman

Rolf Steinort wrote:

... and I use this chance to shamelessly plug my tutorial video about the liquid resize plugin for the Gimp: http://meetthegimp.org/?p=60

Why use some Flash if you can do it in the Gimp? ;-)

Indeed :)

Very nice tutorial, Rolf! However, I think you must've made some mistake when resizing to double the width. If you didn't notice, the plugin doesn't get rid of the cows you marked in the "loose" layer - that's because these markings are only *hints* for the algorithm. I'm not sure what it would do when you give it info to remove and ask to scale up at the same time.. Also, try enabling recalculation of energy after every step (it's a checkbox in advanced options). This should allow you to double the size of the image.

Oh, one last thing - where did you get that using white vs. black changes the intensity? I didn't see it on the plugin info page..

HTH

Am Freitag, den 12.10.2007, 09:10 -0700 schrieb Konstantin Svist:

Rolf Steinort wrote:

... and I use this chance to shamelessly plug my tutorial video about the liquid resize plugin for the Gimp: http://meetthegimp.org/?p=60

Why use some Flash if you can do it in the Gimp? ;-)

Indeed :)

Very nice tutorial, Rolf! However, I think you must've made some mistake when resizing to double the width. If you didn't notice, the plugin doesn't get rid of the cows you marked in the "loose" layer - that's because these markings are only *hints* for the algorithm.

I didn't expect the cow to vanish - this happens only if you shrink the image. But I expected to get a "stretch cow" (got it) and to keep the others. They were stretched too, but less.

I'm not sure what it would do when you give it info to remove and ask to scale up at the same time..

The content of the "to be discarded" part of the image is set to the lowest energy and so expanded most likely.

Also, try enabling recalculation of energy after every step (it's a checkbox in advanced options). This should allow you to double the size of the image.

Yes, I overlooked that option. :-(

I made another blunder by overestimating the run time on large images. It scales much friendlier than I feared - I had a problem with my machine during testing this stuff for the show.

Oh, one last thing - where did you get that using white vs. black changes the intensity? I didn't see it on the plugin info page..

It's on the help page.

/usr/local/share/gimp-lqr-plugin/help/en/index.html

--------------------- quote ------------------ In the Feature preservation selection section it is possible to specify if there are regions of the image which should be preserved from modification, by checking the Activate feature preservation box, and by choosing a layer among the ones which belong to the current image (different from the active one, which is to be rescaled) in the Available layers menu.
The intensity of the effect on each pixel is obtained as the average on the pixel's channels, including the alpha channel. Thus for an RGB layer with an alpha channel, the maximum value is achieved on white pixels, while black ones are worth one quarter of the white ones and transparent pixels are ignored.
--------------------- /quote ------------------

Oh, BTW, a viewer informed me, that the plugin compiles under Mac OS without problems - there are just no binaries floating around.

Rolf

< big snip >

Whatever the fine points may be and the tweaking that will inevitably go on, the importance to a learner like me and others, is that a process was brought to our attention in an understandable and practical way. What would be useful, however, is if those who try out the process could report their findings whenever they are new or different to those in the video and backed up by evidence, so that the rest of us may benefit from their experience.

Norman

--- Konstantin Svist wrote:

I saw the same thing.. are you using linux, perchance? Maybe it's limux-flash-specific bug...

Nope, XP Pro.

Anyway, I think it keeps the result but doesn't -- try saving it and see if you get the final image.

Did that. You get the original image.

_____________________________________

Greg wrote:

--- Konstantin Svist wrote:

I saw the same thing.. are you using linux, perchance? Maybe it's limux-flash-specific bug...

Nope, XP Pro.

Anyway, I think it keeps the result but doesn't -- try saving it and see if you get the final image.

Did that. You get the original image.

Guess it's a glitch in the Matrix, then ;)

--- Rolf Steinort wrote:

... and I use this chance to shamelessly plug my tutorial video about the liquid resize plugin for the Gimp: http://meetthegimp.org/?p=60

And thanks to your shamelessness, I've installed said plug-in. One thing though, except for the image dimensions, all of the controls are inactive.

_____________________________________

Greg wrote:

--- Rolf Steinort wrote:

... and I use this chance to shamelessly plug my tutorial video about the liquid resize plugin for the Gimp: http://meetthegimp.org/?p=60

And thanks to your shamelessness, I've installed said plug-in. One thing though, except for the image dimensions, all of the controls are inactive.

You need to create a new layer if you want to mark the areas to keep/remove. If you run LR on 1 layer, it'll disable the extra controls, of course.