PanoTools NG:
Re: New hardware testing on PTgui performance
matt_nolan_uaf 2007-Dec-26 19:37:10
Joost and Bernhard,
I just ran a few new tests. At 16 bit output, a 11704x5862 panorama
takes 8:00 minutes with blended-only PSD output and 10:02 with
blended and layer PSD output. A big part of the difference seems to
be the final output write (0.5GB vs 1.5GB). But I watched the temp
files being written, and they were about the same size in both cases
(about 0.5GB). I dont know what this means in terms of cropped tiffs
or not. There's not a lot overlap between images. But I'm not
really sure what's meant by cropped tiffs either.
The same file as 8 bit had half the final file size and half the temp
file size, I guess as expected, but took less than half the time
(3:30). I assume this is because the actual CPU time was more
relevant because the data got there faster.
In terms of performance, it seems to me now that 8 vs 16 bit speed is
not so much a function of CPU as disk drive speed. With larger
projects, my guess at this point is that stitching speed will
increase roughly linearly (or faster) with increased disk speed, up
until the point at which all of the cores are being utilized at 100%
or so, at which point increasing disk speed wont help. Does this
seem about right? The question then becomes, what disk speed is
necessary to saturate the CPU? I suspect the answer depends directly
on the size of the project, as this determines the size of the temp
files and therefore the bottleneck speed. That is, if a hard drive
system that can deliver 250MB/s might max out my CPU for an 8-bit
stitch, it might not for a 16 bit stitch which has 500MB temp files.
In terms of gigapixel stitching, yesterday I finally completed my
largest project, stitching 505 12MP images. It required about 250GB
of scratch space and took about 15 hours. The final PSB at 16 bit
(no layers) was 23GB and took an hour to open in Photoshop. What I
noticed along the way was that the temp file size grew over time,
such that progress slowed over time, I guess as new images were
added. So now I'm wondering whether it would be more efficient to
process panoramas like this in smaller chunks, each of which require
smaller temp files that could get delivered faster to the CPU? Or
will the time needed to stitch the chunks together equal the same
thing? Or if I broke the project into 7GB chunks that were small
enough to fit on iRAM in RAID0 at 280 MB/s average transfer (rather
than 90 MB/s on spinning disk) and process in batch mode, maybe this
could be a dramatic improvement? I suspect I'll have to try it to
find out... But maybe you might see some flaws in this approach
already?
One trick I just learned is to set the 3GB switch in Windows'
boot.ini file. For my standard spherical project at 1.5GB, this maks
an enormous difference as it eliminates the scratch disk access (at
least until new layers are added). The difference here is much
larger than the choice of disk drive used for scratch.
Cheers,
Matt
--
<*> Wiki: http://wiki.panotools.org
<*> User Guidelines: http://wiki.panotools.org/User_Guidelines
<*> Nabble (Web) http://www.nabble.com/PanoToolsNG-f15658.html
<*> NG Member Map http://www.panomaps.com/ng
<*> Moderators/List Admins: #removed#
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/PanoToolsNG/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/PanoToolsNG/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:#removed#
mailto:#removed#
<*> To unsubscribe from this group, send an email to:
#removed#
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/