Okey, thanks, will use with me continued tests, will make it quicker, since the nano stuff also takes around an hour every time..
So when I compile enblend (both the version 4.1.1 downloaded from sourceforge and the version 4.0 from the ubuntu repos) with the option --enable-image-cache=no it fails really fast (with the same memory error) - even before it prints the first "enblend: info: loading next image:" line. Memory Usage doesn't spike when this happens, so no idea how he manages to produce an out of memory exception in this case. Now I compiled 4.1.1 with the default options. This failed after 7 1/2 hours (the last nano tiff got a timestamp of 0:44, crash happened at 8:15) And with this the memory usage does spike, but the SWAP space still was only half filled (9,7GB filled out of 19,94GiB available) Here's the story with commented dstat output: http://pastebin.com/raw.php?i=7AATfsXz -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/685105 Title: enblend fails to blend large pano Status in Enblend: Confirmed Bug description: Enblend failed with: enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif .... ... enblend: info: loading next image: pano8110_l0000.tif 1/1 enblend: out of memory enblend: std::bad_alloc This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn me that it might take a lot of memory. The thing is: There is no other tool to stitch this with, so I'll have to make do with hugin and its toolset.... I thought there was an "imagecache" that would swap parts of images to disk... To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/685105/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~hugin-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
