Monkey has a point in suggesting multiblend [at the sacrifice of some accuracy] but the most positive performance improvement you can make is additional RAM.
Over the past several years I've gone from using Hugin on a single-core 32-bit system [running XP] with 2GB to a quad-core AMD64 system [with Win7 x64] with 4GB to a quad-core intel system [Win7 x64 again] with 8GB. The increase in RAM available in both cases brought a performance increase for Enblend in particular of at least an order of magnitude [several with the first leap from single to quad core] with each upgrade. Rendering 18*16Mp panos went from an overnight process [single-core, <3GB RAM] to an hour or so [quad-core with 4GB] to 5-10 minutes [quad-core with 8GB]. CPU speed, mp-enabled Enblend, etc. have all had an effect, but my observation is that the biggest single bottleneck when there's a surplus of available RAM [i.e. more free than needed to process the images] is the speed of the RAM, while on RAM-constrained systems depending on swap [like yours] the bottleneck is instead your storage bandwidth [how fast your hard drive is]. Increasing the amount of memory with -m xxxx will likely not have much of an advantage on a RAM-constrained system and will induce constant swap activity [using the hard drive], which might only make the process even slower by doing little more than increasing swap activity. I realise that upgrading RAM may not be a practical option for you, but given your hardware constraints it may be the only way to appreciably increase performance. Enblend realistically needs at least as much free RAM to work in as the size of the completely-uncompressed final output image. For a 10k*5k equirectangular pano with input images of 16 bits per colour channel (bpc), the *uncompressed* output is 3.2GB (that's 10000*5000 pixels * 64 bits (including the alpha channel)). If my math is bad there, please do correct me, but my just-woke-up only-half-of-my-coffee-consumed brain seems to think that looks right. Tweaking your workflow may help you a lot more: render smaller versions first [logically, the smaller the final output, the faster the whole process is] for test purposes, or even small sections at full-res using crops to verify that the stitch is taking place without bad artefacts in the section in question. If you're using JPEG images as input, the following is not relevant.. But if you're using 16bpc input images [like 16bpc TIFFs from processed raw images], try using 8bpc images first as a "draft mode"; this means less data to manipulate during all stages of processing. When you're done making sure things fit right you can replace the 8bpc images with 16bpc ones [they must have the same filenames, of course] and the only stage in Hugin that might need redoing is exposure compensation. When you've verified that things look right with smaller output, cropped output for trouble sections, and/or lower bit-res images as "draft" - *then* invest the time in doing the final full-sized output that takes more time. Hope that helps in some way, D -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/58b5d7c1-bf5a-470f-b87e-0b920475595c%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
