Harry, Bruno, I tried including the images that had had "grey" Alpha masks but with their Alpha Channels deleted. the stitch ran to successful completion.
I have now tried adding a simple black Alpha Channel to each of those images and it crashes again. So much for my "grey theory"! all the best George On 20 Apr, 12:29, grow <[email protected]> wrote: > Harry, Bruno, > > I have now experimented a bit more with this stitch. > Using the preview panel I removed various images and exposure-stack > image-triples in turn and re-ran the stitch over and over ... It kept > crashing at what looks like the same place UNTIL I removed a > particular triple of images. When I put them back in it crashes > again. > > Now I have looked closely at those three images. Each has an Alpha- > channel mask that was created from a "feathered" selection so I think > the mask has shades of grey in it, not just black ... is that a known > problem? > > My next plan is to preserve those images in case they are useful > evidence for a bug hunter and then replace them by images with a solid > black mask ... I'll let you know what happens. > > all the best > > George > > On 20 Apr, 09:45, Harry van der Wolf <[email protected]> wrote: > > > 2009/4/20 cspiel <[email protected]> > > > > Harry - > > > > > This same error was reported on Newyears day by "nobody" > > > (hugin-Bugs-2480029). > > > > Despite my request for more info we didn't get it. > > > > From the study of the ticket I conclude > > > you are talking about a problem with Enblend not > > > with Hugin. Right? > > > Correct! To end users is is hugin that crashes, be it through enblend or > > "whatever else". > > > > > I know there are some "irregularities" with malloc on OSX. > > > > Error code 3 means: > > > /* The address range specified is already in use, or > > > * no address range of the size specified could be > > > * found. */ > > > > Googling the problem suggests that... > > > 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. > > > > > Ippei made a hack for it in the scripts we use and he added some > > > > (subtle) > > > > comments: > > > > # hack; AC_FUNC_MALLOC sucks!! > > > > mv "./config.h" "./config.h-copy"; > > > > sed -e 's/HAVE_MALLOC\ 0/HAVE_MALLOC\ 1/' \ > > > > -e 's/rpl_malloc/malloc/' \ > > > > "./config.h-copy" > "./config.h"; > > > > Cargo cult. > > > > It is known that AC_FUNC_MALLOC does not go well > > > with cross-compiling, sure. However, the fix the > > > rpl_* wrappers should perform has nothing to do > > > with OOM conditions. > > > > > Maybe by now it hurst more than it helps. > > > > Well, at least it gives me a hearty laugh: > > > "Fixes" the wrong thing at the wrong place. > > > Do you mean that I should remove that "fix" or change it somehow? > > > > While we are at it: can somebody tell me whether > > > I better remove AC_FUNC_MALLOC from > > > "configure.in" in the staging branch? Neither > > > Enblend nor Enfuse rely directly on the > > > preprocessor symbols that the m4 macro > > > generates. > > > I can't answer that. Maybe Andrew can if he is reading this thread (I now > > copied him in) > > > Harry --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
