Harry, With the current version the stitch has now run: at 6,000 x 3,000 to successful conclusion at 9,000 x 4,500 it crashed at the same input image as before (number 25 out of 27 I think it was)
I am trying to get some time with a Intel-based Mac-Pro a friend a few streets away has one - and if I can I will install Hugin and test on that. all the best George On May 3, 10:07 am, grow <[email protected]> wrote: > Harry, (and everyone else) > > Thanks for all your continuing efforts on this front. > > As I said in my message while you were away (27 April) > [http://groups.google.com/group/hugin-ptx/msg/3518fe2aa86e5b83?hl=en-GB > ] > I had already established that the stitch would run successfully at > quarter the area. > > 1. I will try it on some intermediate sizes and see if I can find a > specific threshold. > > 2. Usually I quit most other applications and free up as much memory > as possible before starting a "full-size" stitch. Would it be a > worthwhile experiment to compare performance starting in that state > and one with a lot of other programs open? > > 3. Based on the comment that you quoted from Christoph is there a > buffer size that I can adjust (in a preference or an individual > option) that would be worth experimenting with ... either to find the > "bug" or as a way for me to dodge around something that may be left as > a "feature". > > all the best > > George > > On 3 May, 09:34, Harry van der Wolf <[email protected]> wrote: > > > Hi, > > > I "moved back in time" and did see that Christoph Spiel said something the > > same: > > > * The implementation of realloc on Darwin never frees memory, so > > when using a large buffer size on incomplete reads you end up > > with lots of small strings that actually take up a large > > allocation. > > In other words the VM sub-system of the OS causes the trouble. > > > * Harry > > > 2009/5/3 Lukáš Jirkovský <[email protected]> > > > > I'm looking the sources of enblend/enfuse. In fact there are only two > > > places where malloc is directly used (I don't count the boost::pool > > > implementation and the use in implementation of specific image types > > > like in the vigra_impex/rgbe.c). It's in the vigra/cachedfileimage.hxx > > > and in vigra_ext/NearestFeatureTransform.h. > > > > I've been searching for some information about this issue around the > > > Internet. It seems quite common. Most often it was said that it's > > > caused by realloc not freeing the memory correctly, but I can't find > > > any use of it. > > > > IMO the problem is not in the code, but in fact that the memory > > > becomes fragmented so it's not possible to allocate continuous memory > > > at the requested size. Maybe it could be solved be splitting these > > > mallocs into more smaller allocations. Question is if it's possible > > > wihout adding too much complexity to the code and if it's worthy. --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
