yeah image segmentation seems to be the hardest part of it…
You are right. CA-fill is based on patch match and this is the part were my script should work better. Because with patch matching(which will also be used for the subdivided areas - this is the part of the resynthesize plugin) you get horrible artifacts on the edges of these areas. Once I figure out a good balance between much and sparse division the rest should be easy (nearly everything then is done by resynthesize).

Thanks for your answer

Let me just note that dividing images into areas (also called image segmentation) is in general far from being a trivial task.

Also, the CA-fill feature is much probably based on something like patch-match (google for it if interested), rather then image segmentation.

About the idea of cutting the image in strips: it might be worth trying something like that, thanks; currently however it would not fit well in the implementation (i.e. it would still slow down everything a lot, due to a "trick" which I've used to make the algorithm faster).

Also, I must agree about the script-fu language ;)

Thanks a lot for your answer, which was very informative and much faster than mine.

Regarding my script-fu command not working - the problem had a source in my mis-understanding of gimp script-fu (well, no wonder, for me the most terrible lenguage I've ever seen :) ).
The pre-defined script commands, (batch-gimp-lqr-full-use-id) expect to get a prepared xcf image with layers, while I wanted to use jpg files directly from disk. I wrote my own script with just the options I needed, here it is:
http://plant.ffa.vutbr.cz/~novak/dwnflz/liquirsmine.scm
as said, only difference is that I build layers from files and then call the plugin.

regarding possible optimisations:
reducing discard layer to 1 channel helped.
I didn't find time rebuilding the plugin yet, but I had an idea of how possibly the plugin could run with less memory, correct me if this is wrong/stupid:

If I get it right, the plugin builds an oriented weighted graph along 1 axis, with color differences as weights. Then it finds shortest paths with some options, these then become the discarded or copied seams.(?)
My idea is:
I presume the graph itself with operations done on it takes the most memory, not the cached seams.
Instead of using tiles the image could be split into strips. E.g. when scaling happens along x, the strips would be done along y axis. then you have strips (xmin,ymin,x1,ymax)(x1,ymin,x2,ymax)(xn,ymin… These can be processed separately and just a certain amount of best results of the paths can be saved. then another graph of these strip results can be done, where whole seams are used as nodes, and evaluated. I'm not sure if for this the strips would have to overlap by 1 pixel or not.
well, just ideas. I hope to buy a stronger computer this month and test a brute force approach with 12gb of ram ;)

Btw, my project are large collages made from text by a software which auto generates them, here's a sample:
http://plant.ffa.vutbr.cz/~novak/dwnflz/kolazewip/result1_0.jpg

About big images:
unfortunately it is currently impossible to do the rescaling per tile (this is because deciding where to rescale is a “global” operation); an implementation which could save some memory using the disk could maybe be done, but not in short time (and it would likely be extremely slow, too).
There are however a few ways to save some memory, which are:

• reducing as much as possible the number of colour channels of the images (e.g. you might remove the alpha channel from the main layer if not needed, and use monochrome preservation/discard/rigidity layers if needed)
• also, reducing as much as possible the size of the auxiliry layers might help (e.g. if you need to mask a region, crop the layer to such region)
• another way to save some momory is more aggressive, causes a considerable slowdown and requires fiddling in the code and recompiling the plugin, but in case you need it here it is: you should edit the file render.c under the src subdirectory of the plugin source code distribution, go to line 218 (i.e. after a number of lines which all begin with lqr_carver_set_…) and add exactly this line:

lqr_carver_set_use_cache(carver, FALSE);

Then save the file and recompile the plugin with make. BTW if you find this is actually useful I may consider adding somewhere an option for memory saving in the future, so let me know if you try this.

correct me if I am wrong, since I have ubuntu 8.10 and I currently try to compile the newer version.
First thing I am not able to add correct layer as 'discard features', I am trying to add the layer with (gimp-image-add-layer theImage theWLayer 0) where I put 0 also to the appropriate prop of the script-fu function, but even with setting the value to 4000 it doesn't work at all. I am running this from the commandline without interface.

I would also love to know if it is possible to extend the algorithm to rescale really big images, in doing rescaling per tile or hierarchically. since I end up with my 2gb ram on about 6000x6000(original size being scaled down) images. This is nice but for my current project I would love to do even much bigger images…

1. first you scale to some new size
2. then you click on the “reset” button in the “Map” section
3. then you click on the “reset” button in the “Set width and height” section

If what you want is instead to go back using standard scaling, I don't think this would actually fit within the interactive framework.

Can it be done? Without being confusing.

Julien

That is not a big problem for normal use( is quick rescale manually the result ) but become a problem for animations with hundreds of frames to rescale

Will be possible replace with something as "LqR+ Scale back to W" and/or "LqR+Scale back to H" where W and H are the Width and Height of the original?

That seems much more useful, because that will avoid additional
unnatural distortion , while "scale back " create always distortion except when locking imagine ratio

And result will have if not same imagine ratio of the original the same width or height (seems more logical for normal use…i believe most use liquid resize to change imagine ratio preserving the content )

BTW compatibility with GAP was on top of my wish list from the very first version i'm very grateful you added it
thank you !

I wasn't aware that incremental shrinking is identical to non-incremental. I didn't know that after removing a seam of pixels, the newly-neighboring pixels are used in calculating the next seam, although I suppose it would be hard to come up with any other sensible method. I will take your word that a one-pixel-wide seam increment would be a bad idea for enlarging, because surely you have better insight into the workings of the algorithm than I do.

As for the second point, I find it interesting that it was considered by the algorithm's authors. I didn't intend it as an imminently-necessary feature, only as an interesting continuation of the thought process involved in the first idea (incremental adjustments). I certainly wouldn't expect it to appear gimp-lqr-plugin anytime soon.

Thanks for considering my ideas! :)