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…

Can it be done? Without being confusing.

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 !

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