PanoTools NG:
Re: New hardware testing on PTgui performance
Pablo dAngelo 2007-Dec-30 13:36:07
Hi Helmut,
Hugin (using the nona stitcher), as well as pano13 (using the reengineered
PTStitcher called PTmender) can render to "cropped" output files directly. A
recent post by Joost also mentioned that PTGui stitcher does not need to
render to full sized output images either.
In both nona and PTmender, the compression of the remapped files can be
specified in the p line, and no intermediate uncompressed data is written
to disk.
Today, blending is mostly done with enblend, smartblend, or other external
blenders anyway, so panotools is mostly used for remapping only, but not for
blending.
The next speed improvment would be to optimize the coordinate transform
stack. Since more than 50% of the time during remapping is spend in cos()
and sin(), I wanted to rewrite the transform stack to use 3d vectors to
represent the ray of sight instead of using spherical coordinates. I suspect
this will be much faster, however, I didn't have the time to start working
on this, as I'm (slowly) preparing the next hugin release.
ciao
Pablo
> Hi Matt (and others),
>
> thanks a lot for the interesting speeddata! I was about to
> ask for benchmark data of current stitching software/hardware
> for my current project of a fast stitcher.
>
> As has been mentioned in this thread, IO related bottlenecks
> are due to the use of uncompressed fileformats, if not for
> the final then for intermediate tempfiles. A request to
> the authors of frontends to my pano-libraries (ptgui, nona,...):
> please insert the line
>
> TIFFSetField(tif, TIFFTAG_COMPRESSION, COMPRESSION_PACKBITS );
>
> when writing tempfiles and you will save those poor users the need
> to buy terabyte-drives, and execution will be much faster.
> My own stitcher frontend PTStitcher used this format since the
> first release. Even gigapixel panoramas with > 1000 source images
> should never require more than 100 GByte scratch.
>
> As to RAM-requirements and speed:
> All pano12-based stitchers scale poorly with target panorama size.
> This is due to the original design as plug-in for graphics programs
> (first for GraphicConverter on Macs, then Photoshop and Gimp).
> One source and one full sized copy of the target panorama must fit
> into memory, which is no problem for a plugin, since the host program
> provides this storage. Also, a fullscaled panorama image is created
> for each input image.
>
> However, there is no need for all this in a standalone stitcher.
> No random access to either source nor target image is required,
> and only a small fraction of the target panorama actually needs to
> be rendered for each image. Therefor, image processing can
> be done in a streaming fashion, with minimal RAM requirements.
> At most one source image should fit into memory, and even that
> can be relaxed without significant penalty. I am currently
> looking into this and will post some results for a reworked
> fast pano-library hopefully soon.
>
> Regards
>
> Helmut Dersch
>
>
>
>
>
>
--
<*> 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/