|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 | Next > |
|
|
Re: OpenGL slow because of reloadingI have just tried out SVN 3929 on a large project with 161 images and ~12k control points. I found that image reloading was improved for the images tab. When I selected Align from the assistant tab, I found that during the "Leveling the Panorama" stage, hugin was reading in every image. When it was done reading all of the images, it started to read them in again, and gave an unhandled exception fault. Hugin memory usage in this test was 1.6GB, which is more than what I have seen in the past. Regards, Rick On Jun 10, 5:05 am, David Haberthür <david.haberth...@...> wrote: > Hello Guido. > > On 09.06.2009, at 22:38, Guido Kohlmeyer wrote: > > > > > The additional option is only a workaround that may work, but as you > > already percieved it will yield to higher memory consumption to > > generate > > the mask in a higher resolution. > > I guess the process runs out of memory. > > > Guido > > I suppose that must be the problem, since it crashes with the same > complaint in the logfile: > ---- > DSC_24160117.tif DSC_2284-DSC_24160118.tif DSC_2284-DSC_24160119.tif > DSC_2284-DSC_24160120.tif DSC_2284-DSC_24160121.tif DSC_2284- > DSC_24160122.tif > enblend(815) malloc: *** mmap(size=2097152) failed (error code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > enblend(815) malloc: *** mmap(size=2097152) failed (error code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > enblend(815) malloc: *** mmap(size=2097152) failed (error code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > enblend(815) malloc: *** mmap(size=2097152) failed (error code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > terminate called recursively > gnumake: *** [DSC_2284-DSC_2416.png] Abort trap > gnumake: *** Deleting file `DSC_2284-DSC_2416.png' > --- > even for the newest build from Harry (0.0.0-svn3923) > I guess I'll have to try at work, on a machine with 16 GB of RAM and > not on my puny laptop with 2GB :) > Habi > > David Haberthür schrieb: > > > > >> Dear Guido, > >> That only helped a bit, now enblend crashes lateron in the process. > >> The relevant lines of the stitching window are below: > > >> --- > >> DSC_2284-DSC_24160114.tif DSC_2284-DSC_24160115.tif > >> DSC_2284-DSC_24160116.tif DSC_2284-DSC_24160117.tif > >> DSC_2284-DSC_24160118.tif DSC_2284-DSC_24160119.tif > >> DSC_2284-DSC_24160120.tif DSC_2284-DSC_24160121.tif > >> DSC_2284-DSC_24160122.tif > >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12) > >> *** error: can't allocate region > >> *** set a breakpoint in malloc_error_break to debug > >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12) > >> *** error: can't allocate region > >> *** set a breakpoint in malloc_error_break to debug > >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12) > >> *** error: can't allocate region > >> *** set a breakpoint in malloc_error_break to debug > >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12) > >> *** error: can't allocate region > >> *** set a breakpoint in malloc_error_break to debug > >> terminate called recursively > >> gnumake: *** [DSC_2284-DSC_2416.png] Abort trap > >> gnumake: *** Deleting file `DSC_2284-DSC_2416.png' > >> --- > >> using hugin svn-3888, will try tomorrow with harrys freshly > >> compiled rc3. > >> have a good night. > >> habi/david > > >>> David Haberthür schrieb: > > >>>> On 07.06.2009, at 18:45, Harry van der Wolf wrote: > > >>>>> 2009/6/5 David Haberthür <david.haberth...@... > >>>>> <mailto:david.haberth...@...> > >>>>> <mailto:david.haberth...@...>> > > >>>>> i could help with providing a test-case, the panorama i shot > >>>>> last > >>>>> saturday evening [1] contains +100 images and +7000 control > >>>>> points > >>>>> generated with pan-o-matic. i'm still struggling with > >>>>> stitching it > >>>>> with full resolution, somehow i chokes at the fusing-step when > >>>>> trying > >>>>> to stitch it in sizes bigger than 10000px wide, now i've > >>>>> stitched it > >>>>> in "only" 2694 x 635 px (os x, with harrys newest svn-builld). > > >>>>> Hi Habi, > > >>>>> Nice pano. > >>>>> You are saying that it chokes on 10000px wide (10000 by ?). > >>>>> What error message do you get? > > >>>>> Harry > > >>>> Hoi Harry. > >>>> Thanks, i've tried to make a night-version of the panorama i've > >>>> shot > >>>> some weeks ago. > >>>> I've failed to thorougly investivate it, but the panorama fails to > >>>> stitch for sizes 10000x4122 and 12000x4946 px. It actually fails > >>>> with > >>>> an enblend warning: > >>>> "enblend: warning: failed to detect any seam > >>>> enblend: mask is entirely black, but white image was not > >>>> identified as > >>>> redundant > >>>> gnumake: *** [DSC_2284-DSC2416.png] Error 1" > >>>> are the last entries in the log window. The complete log is > >>>> attached > >>>> to this mail as "log.txt" > > >>>> I'm a bit confused, since the stitch to the smaller size worked > >>>> without a hitch... > >>>> Have a nice start into the week. > >>>> Habi > >>>> --- > > >>>> ------------------------------------------------------------------------- Hide quoted text - > > - Show quoted text - 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@... To unsubscribe from this group, send email to hugin-ptx-unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: OpenGL slow because of reloadingHi Habi,
(I missed these posts, so I kick in a little late). It is not a problem of your laptop. George Row experiences exactly the same problems with large panorama's. It has to do with the way OSXes malloc badly deals with memory. That's also why I built a Hugin version against dmalloc instead of OSXes malloc. Unfortunately that didn't help George and probably won't help you either. I assume you are on a dual-core Intel macbook. That's a 64 bit machine. You might give the older 0.7 final version a go. It's a 64bit version and that might help but ONLY on Leopard. It didn't help George as George also used masks in his tiff's which was another reason for enblend to crash (and that's why I built a hugin with the latest enblend from Christoph Spiel that has much better mask handling, but that one crashed again on the malloc allocation error.) Harry 2009/6/9 David Haberthür <david.haberthuer@...>
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx?hl=en -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: OpenGL slow because of reloadingI am still using SVN3811 due to align crash issues, so maybe this image loading problem has been fixed in later builds, but this is something I have just discovered. I am working with a large project that includes 125 images which includes 5 shot brackets. The project aligned with no problem and I had stitched a low resolution trial image. The sky was a bit over exposed so I decided to remove the most exposed shots from each bracket. With the Quick Preview screen displayed, I chose 10 images from hugin's "Images" tab and selected "Remove Selected Images". It then started reloading images. I then went to work and came home 5 hours later to find it still actively reloading images with no indications of any errors. It was still actively loading from files on disk. It appeared to be stuck in a loop. Regards, Rick On Jun 13, 12:34 am, Harry van der Wolf <hvdw...@...> wrote: > Hi Habi, > > (I missed these posts, so I kick in a little late). > > It is not a problem of your laptop. George Row experiences exactly the same > problems with large panorama's. It has to do with the way OSXes malloc badly > deals with memory. > That's also why I built a Hugin version against dmalloc instead of OSXes > malloc. Unfortunately that didn't help George and probably won't help you > either. > > I assume you are on a dual-core Intel macbook. That's a 64 bit machine. You > might give the older 0.7 final version a go. It's a 64bit version and that > might help but ONLY on Leopard. It didn't help George as George also used > masks in his tiff's which was another reason for enblend to crash (and > that's why I built a hugin with the latest enblend from Christoph Spiel that > has much better mask handling, but that one crashed again on the malloc > allocation error.) > > Harry > > 2009/6/9 David Haberthür <david.haberth...@...> > > > > > > > Hello Guido. > > > On 09.06.2009, at 22:38, Guido Kohlmeyer wrote: > > > > The additional option is only a workaround that may work, but as you > > > already percieved it will yield to higher memory consumption to > > > generate > > > the mask in a higher resolution. > > > I guess the process runs out of memory. > > > > Guido > > > I suppose that must be the problem, since it crashes with the same > > complaint in the logfile: > > ---- > > DSC_24160117.tif DSC_2284-DSC_24160118.tif DSC_2284-DSC_24160119.tif > > DSC_2284-DSC_24160120.tif DSC_2284-DSC_24160121.tif DSC_2284- > > DSC_24160122.tif > > enblend(815) malloc: *** mmap(size=2097152) failed (error code=12) > > *** error: can't allocate region > > *** set a breakpoint in malloc_error_break to debug > > enblend(815) malloc: *** mmap(size=2097152) failed (error code=12) > > *** error: can't allocate region > > *** set a breakpoint in malloc_error_break to debug > > enblend(815) malloc: *** mmap(size=2097152) failed (error code=12) > > *** error: can't allocate region > > *** set a breakpoint in malloc_error_break to debug > > enblend(815) malloc: *** mmap(size=2097152) failed (error code=12) > > *** error: can't allocate region > > *** set a breakpoint in malloc_error_break to debug > > terminate called recursively > > gnumake: *** [DSC_2284-DSC_2416.png] Abort trap > > gnumake: *** Deleting file `DSC_2284-DSC_2416.png' > > --- > > even for the newest build from Harry (0.0.0-svn3923) > > I guess I'll have to try at work, on a machine with 16 GB of RAM and > > not on my puny laptop with 2GB :) > > Habi > > > David Haberthür schrieb: > > >> Dear Guido, > > >> That only helped a bit, now enblend crashes lateron in the process. > > >> The relevant lines of the stitching window are below: > > > >> --- > > >> DSC_2284-DSC_24160114.tif DSC_2284-DSC_24160115.tif > > >> DSC_2284-DSC_24160116.tif DSC_2284-DSC_24160117.tif > > >> DSC_2284-DSC_24160118.tif DSC_2284-DSC_24160119.tif > > >> DSC_2284-DSC_24160120.tif DSC_2284-DSC_24160121.tif > > >> DSC_2284-DSC_24160122.tif > > >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12) > > >> *** error: can't allocate region > > >> *** set a breakpoint in malloc_error_break to debug > > >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12) > > >> *** error: can't allocate region > > >> *** set a breakpoint in malloc_error_break to debug > > >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12) > > >> *** error: can't allocate region > > >> *** set a breakpoint in malloc_error_break to debug > > >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12) > > >> *** error: can't allocate region > > >> *** set a breakpoint in malloc_error_break to debug > > >> terminate called recursively > > >> gnumake: *** [DSC_2284-DSC_2416.png] Abort trap > > >> gnumake: *** Deleting file `DSC_2284-DSC_2416.png' > > >> --- > > >> using hugin svn-3888, will try tomorrow with harrys freshly > > >> compiled rc3. > > >> have a good night. > > >> habi/david > > > >>> David Haberthür schrieb: > > > >>>> On 07.06.2009, at 18:45, Harry van der Wolf wrote: > > > >>>>> 2009/6/5 David Haberthür <david.haberth...@... > > >>>>> <mailto:david.haberth...@...> > > >>>>> <mailto:david.haberth...@...>> > > > >>>>> i could help with providing a test-case, the panorama i shot > > >>>>> last > > >>>>> saturday evening [1] contains +100 images and +7000 control > > >>>>> points > > >>>>> generated with pan-o-matic. i'm still struggling with > > >>>>> stitching it > > >>>>> with full resolution, somehow i chokes at the fusing-step when > > >>>>> trying > > >>>>> to stitch it in sizes bigger than 10000px wide, now i've > > >>>>> stitched it > > >>>>> in "only" 2694 x 635 px (os x, with harrys newest svn-builld). > > > >>>>> Hi Habi, > > > >>>>> Nice pano. > > >>>>> You are saying that it chokes on 10000px wide (10000 by ?). > > >>>>> What error message do you get? > > > >>>>> Harry > > > >>>> Hoi Harry. > > >>>> Thanks, i've tried to make a night-version of the panorama i've > > >>>> shot > > >>>> some weeks ago. > > >>>> I've failed to thorougly investivate it, but the panorama fails to > > >>>> stitch for sizes 10000x4122 and 12000x4946 px. It actually fails > > >>>> with > > >>>> an enblend warning: > > >>>> "enblend: warning: failed to detect any seam > > >>>> enblend: mask is entirely black, but white image was not > > >>>> identified as > > >>>> redundant > > >>>> gnumake: *** [DSC_2284-DSC2416.png] Error 1" > > >>>> are the last entries in the log window. The complete log is > > >>>> attached > > >>>> to this mail as "log.txt" > > > >>>> I'm a bit confused, since the stitch to the smaller size worked > > >>>> without a hitch... > > >>>> Have a nice start into the week. > > >>>> Habi > > >>>> --- > > > ------------------------------------------------------------------------- Hide quoted text - > > - Show quoted text - 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@... To unsubscribe from this group, send email to hugin-ptx-unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: OpenGL slow because of reloadingOn 07.06.2009, at 18:45, Harry van der Wolf wrote:
I'm happy to say that with hugin 0.8.0-RC5 I no longer have the problem with this panorama it stitched fine (with a size of 17806x4346, albeit it took approximately 5 hours to render :) Thanks for all the effort of all involved people! Habi --~--~---------~--~----~------------~-------~--~----~ 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@... To unsubscribe from this group, send email to hugin-ptx-unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: OpenGL slow because of reloadingDear David, regarding your comment "albeit it took approximately 5 hours to render", I expect you can speed up the calculation with more RAM. After upgrade my machine from 512MB to 2GB RAM the process was very quick compared to the less RAM configuration, especially enblend benefits from lot of free memory. My panos are commonly 14000x7000px built from about 32 pictures in eqirectangular projection. The enblend step needs about 1.5 to 1.7GB RAM to run quickly, otherwise enblend goes to disk with slows down the process. Guido > > On 07.06.2009, at 18:45, Harry van der Wolf wrote: > >> >> >> 2009/6/5 David Haberthür <david.haberthuer@...> >> >> >> >> i could help with providing a test-case, the panorama i shot last >> saturday evening [1] contains +100 images and +7000 control points >> generated with pan-o-matic. i'm still struggling with stitching it >> with full resolution, somehow i chokes at the fusing-step when trying >> to stitch it in sizes bigger than 10000px wide, now i've stitched it >> in "only" 2694 x 635 px (os x, with harrys newest svn-builld). >> >> Hi Habi, >> >> Nice pano. >> You are saying that it chokes on 10000px wide (10000 by ?). >> What error message do you get? >> >> Harry > > Dear all. > I'm happy to say that with hugin 0.8.0-RC5 I no longer have the > problem with this panorama it stitched fine (with a size of > 17806x4346, albeit it took approximately 5 hours to render :) > Thanks for all the effort of all involved people! > Habi > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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@... To unsubscribe from this group, send email to hugin-ptx-unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: OpenGL slow because of reloadingDear Guido > regarding your comment "albeit it took approximately 5 hours to > render", I > expect you can speed up the calculation with more RAM. After upgrade > my > machine from 512MB to 2GB RAM the process was very quick compared to > the > less RAM configuration, especially enblend benefits from lot of free > memory. > My panos are commonly 14000x7000px built from about 32 pictures in > eqirectangular projection. The enblend step needs about 1.5 to 1.7GB > RAM > to run quickly, otherwise enblend goes to disk with slows down the > process. My MacBook Pro has 2GB of RAM, and i could only upgrade it to 3GB if i'd swap one 1GB for a 2GB module, something which will come after the transplantation of a bigger HD :) As others said before, I'm happy that it runs, I don't really care if I let it render overnight, it will be finished in the morning, if it takes half an hour or if it takes 5 hours... Cheers Habi --~--~---------~--~----~------------~-------~--~----~ 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@... To unsubscribe from this group, send email to hugin-ptx-unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: OpenGL slow because of reloadingHi Habi,
The most prominent change is that the OSX RC5 bundle is 32/64bit. You run it on a macbook pro and I suppose with Leopard. It means that it will run in 64bit mode and use a 64bit address space. I think the enblend problems are related to the earlier 32bit versions. The 64bit enblend can allocate far more memory than the 32bit. It should(!) function correctly on 32bit, but malloc on OSX is not very good and leaves many chunks of memory behind. The 64bit version can allocate much more memory. I assume it is therefore "more forgiving" as it has more memory to use as garbage bin before choking itself in it's own garbage. It means that the Hugin builds in future should be preferably 32/64bit for those who can run in 64bit. Who will build these bundles? Hoi, Harry 2009/7/13 David Haberthür <david.haberthuer@...>
--~--~---------~--~----~------------~-------~--~----~ 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@... To unsubscribe from this group, send email to hugin-ptx-unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
| < Prev | 1 - 2 - 3 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |