[ptx] hugin has problems with particular imageset

[Rich]

pablo.dangelo at informatik.uni-ulm.de wrote:
> Zitat von Rich <rich at hq.vsaa.lv>:
...
>>panorama is 31570x15580 - size calculated by hugin.
> 
> This is a very big image, 491 Megapixels. A single remapped image of the entire
> panorama requires
> 31570*15580 * 4 = 1.8 GB. Nona might need 2 times the output image size
> in TIFF_m mode, so this is up to 2.6 GB. A future version will be much more
> memory efficient. Remember that on a 32 bit processor, each process can only
> access up to 2 or 3 GB, no matter how big your swapspace is.

oh. this seems to be the most probable reason - for each image hugin 
really took 2gb for extended periods of time.

  ...
>>>One more thing you could try, is to use nona with the multilayer tiff
>>>output and use tiffcp to extract the single images. Then you can use
>>>enblend on these images. This should need less memory
>>
>>yep, i also can stich it by separating the panorama before the process,
>>but i would like to find out what exactly caused the problem.
> 
> Seems that you are running out of virtual memory. I will add an error message
> when that occurs.

there was enough of virtual memory free, but the process itself took 2gb

> Using the TIFF_multilayer option of nona is more memory efficent, since it will
> only need memory for the cropped, remapped images. Can you try if that works?

yep, this worked just fine.
so there probably should be an error message for out of memory 
conditiond and also for the cases when the process itself exceeds 2gb - 
how hard would the latter be ?

> Running enblend on these files should also be much faster. Do not forget to
> tell enblend how much physical memory it is allowed to use. (using the -m
> option)

yep, i am setting -m to enblend so that ~100 megs are left free - it 
goes a lot faster if there is no need for swapping. i suppose internal 
caching is much better, as it knows what is better to cache.
...
-- 
  Rich