hugin-devs team mailing list archive

[kaefert <kaefert@xxxxxxxxx>]

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