Hi Stefan, 2009/10/8 Stefan Peter <s_pe...@swissonline.ch>: > > Hi List, > > Sorry if the following is "all known by the old hands". Please feel free > to correct me at your leisure, otherwise I may die dumb ;) > > I have downloaded the project in question, and here are some results. > I used Hugin 2009.2.0.4461 on linux X86_64 with 4GB Memory and 8 GB swap > for the first test. After creating a makefile from the pto, all tests > have been conducted on the command line. > > o The original project worked fine in relatively short time (~ 30 > minutes, IIRC). > o After adding an additional target (blended and fused equirect), the > system started to thrash after about 1 hour and I had to cancel the job > after a runtime of 9 hours without result. > These tests where done using enblend 4.0-da9bc1a1ed87 > > Afterwards, I switched to Linux X86_32 with 3GB of memory and 1 GB of swap: > o The original project did not finish. An strace of the final enblend > call (the one that creates the final equirect) showed that an mmap > operation on one of the source files (400 MBytes!) failed. > o Subsequent tests with various differently compiled enblend versions > had some influence, but did not provide a remedy. I was not able to > stitch the final pano, no matter what options i used for compiling > enblend. But the point of failure shifted from Image 2 to Image 17 when > disabling openmp and enabling image cache. > > As a preliminary statement, I'd say that > o Enblending/enfusing large panos with 16bit tiffs is very memory > intensive. If you don't have the RAM required, the final enblend step > will fail with an "out of memory" message". > o Having plenty of swap space is no cure: the system starts thrashing > and will get unresponsive up to the point where you cancel the job > voluntarily. > o Although I did some valgrind and dmalloc tests, I could not find any > leeks or problems beside the fact that all tiff files where accessed > using mmap. This results in a memory footprint that mostly depends on > the size of the input files. > > As a temporary fix, I would recommend to use "--disable--openmp" and > "--enable-image-cache" in order to limit the memory consumption. > However, this has a negative influence on the runtime of enblend / enfuse. > Another option is to reduce the size of the input images. It may be > sufficient to use a compression for tiffs (I have not tested this), but > reducing the color depth from 16 to 8 bit will have, most probably, the > largest influence. > > > The final solution for the memory problems in enblend / enfuse can only > be an access method that does not rely on being able to access the > _whole_ source files over memory maps. Without having looked at the code > responsible for this (and not being a C++ programmer at all), I think > that it should be possible to use a "window" (let's say 128 MBytes) for > accessing at least the input files. > > With kind regards > > Stefan Peter > > > >
Thank you very much for you in depth analysis. Here are my thoughts. Could anyone verify them? 1. the problem occurs when image cache is disabled or the limit exceeds (or almost fits almost exatly) memory size 2. the problem occurs when image cache is enabled but there is not enough memory to write temporary to disk. Both of them makes me think that it can be avoided by carefully setting image cache to let's say available memory minus 100MB. So the simplest solution may be setting apropriate image cache value at runtime. But it would have it's drawbacks on systems with hot pluggable memory. Lukas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
