[ptx] Error while stitching big pictures

[Hal V Engel]

On Saturday 16 April 2005 03:44 pm, Travis Good wrote:
> That's the same problem I encounter. Is there a simple fix for this?
> T.
>
> On 4/15/05, geppel geppel <geppel at gmx.net> wrote:
> > Hello,
> >
> > i always have the the problem that hugin shows the message "No space for
> > data buffer at scanline -1" while Reading Histogram and sttitching the
> > .tmp files.
> > It always happens when the Width of the Picture is bigger then 10 000px.
> >
> > But I have 1ghz Ram and 100gb free space on my HDD.
> > So what´s the matter?
> >
> > greets an thanks form germany g.
> >
> > --
> > +++ NEU: GMX DSL_Flatrate! Schon ab 14,99 EUR/Monat! +++
> >
> > GMX Garantie: Surfen ohne Tempo-Limit! http://www.gmx.net/de/go/ds

I have not been using nona so I just used nona to stitch an image that was 
11443x5531.  I used the Multilayer TIFF output and it worked without a 
problem.  The output image was 1.05 GB in size.  This was surprisingly quick 
taking about 4 1/2 minutes.  I have been using PTStitcher and it was taking 
about 15 minutes to stitch this same image on the same hardware (with 
brightness and color correction so it was doing more work).  

So I then tried TIFF output blended by enblend.   Nona passed the images off 
to enblend in about 4 minutes 25 seconds.  Enblend became memory bound maxing 
out at about 1152mb virt memory according to top.  Enblend finished blending 
the image in about an hour.   Slow but the resulting image was very nice.  So 
it was worth the wait but it would be nice if enblend were a little smarter 
about how it used memory.  Most of the time CPU utilization was < 10% and 
paging rates were very high.  So with more memory I would expect enblend to 
run much faster - perhaps as much as 5 to 8 times as fast might be possible.

This was a 1x5 stitch of images that were 3438x5156 (35mm film scans at 
3600dpi) 16 bit tiffs.   Image overlap was about 25%.  My machine has an 
amd64 winchester 3500 CPU with one gig of RAM, two gig of swap and lots of 
free disk space.  Hugin 0.5 beta 3, PTOptimizer 2.7.0.9, nona, enblend 2.2, 
mono 1.1.5 (for autopano-SIFT 2.3) and libpano 2.7.0.9 are all compiled as 64 
bit code.  My only optimization was to set CFLAGS=-O2 but libpano12 was 
compiled with optimization turned off (-O0) otherwise it would seg fault.  I 
am running Gentoo 2005.0 Linux as a 64 bit system and everything is compiled 
with gcc 3.4.3 (other than PTStitcher and the 32 bit libpano12 needed to run 
it - installed from binaries).  I have both 64 bit and 32 bit libpano12 
installed.

In any case I am not seeing the same problem.  Perhaps you could give us more 
info to go on so that others can try to reproduce the problem.  It could 
depend on your system configuration, how the code was compiled,  what type of 
input files you were using,  the type of output you selected.....  Who knows 
and you didn't give us much to go on.