strange script-fu behaviour and rescaling huge images and some script-fu weirdness

strange script-fu behaviour and rescaling huge images and some script-fu weirdness

vilem novak (guest) 03 Nov 2009 14:46

first - thanks for this great plugin! it's very usefull and great.

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…

Re: strange script-fu behaviour and rescaling huge images and some script-fu weirdness

CarloB 03 Nov 2009 15:44

About your troubles with script-fu:
I assume you're using the script “batch-gimp-lqr-full-use-id”, right? Did you also try with “batch-gimp-lqr-full”? Did you try to do the job in steps (with small images) and check what exactly is going wrong (e.g. using the graphical interface to inspect the intermediate results)?
Can you post the script (or the command line) you're using, or the relevant part of it?

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.

Re: strange script-fu behaviour and rescaling huge images and some script-fu weirdness

vilem novak (guest) 29 Dec 2009 00:08

Hello, I am very sorry to answer so late :(
I had lots of work and didn't have time to answer properly.

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

Re: strange script-fu behaviour and rescaling huge images and some script-fu weirdness

CarloB 20 Mar 2010 17:24

I just noticed that in my previous message I forgot about another very simple way to same some memory, which is to untick the option "Resize auxiliary layers" in the "Output" tab. Sorry.

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 ;)