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! :)

1. Incremental enlarging: this is planned for a future release (not the next one, which will be out soon, but the following one will probably have it). Doing it one pixel at at a time would yield very bad results; therefore, an additional option will be required, to set the enlarging percentage at which more than one step would be performed. The main issue here is to find a sensible default value. This would be useless when reducing the size, however, since in practice this is what already happens (i.e. reducing by 25 pixels + another 25 pixels is the same as reducing by 50 pixels in a single run, while this is not true when enlarging)
2. Alternate shrinking (horizontal/vertical), possibly in an optimal way: this was already proposed in the paper by the algorithm's authors, but it has some drawbacks (you can find more information in that paper) and raises some issues with the current implementation of the carving engine (which of course are related to the drawbacks I mentioned before). However, a dedicated interface could in fact be a good idea, I have to think about how this could be implemented. It will require some work, however, so it won't be included anywhere soon (unless someone wants to help with the code, of course).

This feature would especially make a difference when expanding an image. Currently the recommendation for large expansions that have a preserved area is to manually perform incremental rescales. Having this solution available would greatly simplify such operations.

A future direction this could go in is for feature removal. The user would no longer have to do anything except to determine which feature to remove. Using an incremental method, the idea would be to first calculate both the horizontal and vertical seams that would be removed, then to compare the "cost" of removing the horizontal seam to that of the vertical seam (this might need to be scaled based on aspect ratio, testing would have to be done. Also I'm definitely glossing over some details, but I hope my intention is clear). Whichever seam has a lower "cost" would be the one removed, and the next iteration would repeat this process until the discard area is removed completely. (Of course, for efficiency reasons, it should again be possible to remove more than one seam per iteration, where the given number of seams would determine the number of either horizontal or vertical seams to remove — not a combination of both.) Since the discard area has a high negative value, each iteration would remove a maximal number of discard pixels, so I would expect the entire process to converge quickly.

In any case, I don't expect the initial request to require much new development since it's mainly the same functionality in a loop. The "future direction" also doesn't seem like much of a change, since I presume that the only new code would be that which compares a given horizontal seam(s) to a given vertical seam(s) and determines which is better to remove. The biggest changes would likely be in the interface code.

I think this is worthwhile as long as it does not add too much code complexity; I would expect it to result in higher-quality images while also lightening the workload on the user (manually iterating for large expansions, taking time to determine the number and orientation of pixels to remove while discarding parts of an image, etc.).

I'm interested to hear what you think: bmintern A+ gmail D0+ com

The best solution I can come up with is giving the user the control. Like I said, there is no simple solution to some of the impossible conditions the user may create, so, ultimately it will have to be up to the user to make the judgment call on the situation. Either they could force the algorithm to remove in a direction, limit the amount of attempts, or readjust the weights to allow the algorithm to find a possible solution to the removal. Cloning a portion of the image back over the unremoved section might be a possible crutch to the situation.