Already did. This is one of the other details I found weird. 36 * 15mpx images will blow up after 30-32 images, regardless of the value of maxdim. I've used the default of 1600, and tried many values, even down to 100. Still an out of memory.
nick Timothy Leary<http://www.brainyquote.com/quotes/authors/t/timothy_leary.html> - "Women who seek to be equal with men lack ambition." On Wed, Jul 15, 2009 at 8:14 AM, Andrew Chanler <achan...@gmail.com> wrote: > By default all the images are down-sized so that the largest dimension is > 1600 pixels. There is a command line option called -maxdim which you can > set this setting with. Try setting this to something like 1200 or 800. > > > On Wed, Jul 15, 2009 at 7:54 AM, Nicolas Pelletier < > nicolas.pellet...@gmail.com> wrote: > >> Thanks Andrew, I appreciate. >> In my case, the out of memory happens in the first phase, i.e. when >> searching for keypoints for each individual images. >> >> I did not write down the exact numbers, but it did "keep" much memory >> between images. (For example, before processing image X, process at 200 >> megs. While processing, peak at 800. As it's starting the next image, down >> to 315. 200 and 315 seems far apart, even if we consider that the task >> manager might not update fast enough). >> >> I'll also add that the more I use it, the more I think that much memory >> is\will be used by the software and it will reach a pix limit quickly. >> >> But what is boggling me a little is that, if that was the end of this >> (i.e. I'm just hitting the software\memory limit), then there would be more >> reports of this. At least I'd think there would. Specially since I saw >> people mentioning making giga pans with this. >> >> I appreciate the work Andrew. When I have a moment, I'll try to setup the >> computer for dev. >> >> nick >> >> >> >> On Wed, Jul 15, 2009 at 7:05 AM, Andrew Chanler <achan...@gmail.com>wrote: >> >>> I found the largest leak. And now my build only leaks a few KB, however >>> I think the main problem is the amount of memory the application uses Let me >>> summarize the memory usage with 2 images. >>> >>> 1) During GenerateKeyspp an enormousness amount of memory is allocated >>> for image processing. For a single 1536x1024 image I saw 217MB get >>> allocated and freed during this function. Then at the end of the function >>> 7.4MB was allocated for the keypoints that were found in that image >>> (1092Bytes per keypoint and it found 7000+ keypoints). >>> >>> 2) This repeated for each image. So another large chunk was allocated to >>> find keypoints in it. But it was also freed. And another roughly 7.5MB were >>> allocated for keypoints. So roughly 15.5MB are now allocated for keypoints. >>> >>> 3) Next MultiMatch_ANN will run to find keypoints that match in different >>> images. This is where the largest abuse of memory was. It for each >>> Keypoint it allocates a KeypointN. This doubles the memory used by >>> keypoints to 31MB. Then when it finds a match it creates a Match which >>> points to two KeypointN's. In my case it found 40 matches between the two >>> images.Then at the end of the function it frees all the Keypoint's. However >>> out of the 13755 KeypointN's that were allocated we only need 80 that are >>> used in each Match. These extra KeypointN's represent the largest leak in >>> the program. >>> >>> Now taking a look at your case, if you have 36 images that each found >>> 7000 points. that would be 263MB for keypoints. Then when you call >>> MultiMatch_ANN that would double when you allocate KeypointN's to 526MB. >>> >>> When you go to the larger image sets does it fail before it finishes >>> processing all the images? Or does it fail while it searches for matches? >>> >>> I'll have to clean up my workspace and submit my patch that only >>> allocates KeypointN's when they are needed. I have some other ideas to >>> reduce the memory usage by during the image processing but I need to >>> investigate it more. >>> >>> Andrew >>> >>> >>> On Tue, Jul 14, 2009 at 11:38 PM, Nicolas Pelletier < >>> nicolas.pellet...@gmail.com> wrote: >>> >>>> Tried some more cases to try and find something weird. >>>> Unfortunately, nothing. >>>> >>>> I consistently run out of memory, whenever I take big images (threeshold >>>> seems to be 36 images of 10 mpix). >>>> >>>> Bigger pictures and out of memory. >>>> >>>> I have not tried more smaller pictures. >>>> >>>> Of the people who stitch many pictures anybody has a 15+ mpix camera? >>>> >>>> nick >>>> >>>> >>>> On Mon, Jul 13, 2009 at 5:34 PM, Andrew Chanler <achan...@gmail.com>wrote: >>>> >>>>> I have only found 1 small memory leak so far... 16bytes * number of >>>>> images I believe. Here is the fix. >>>>> >>>>> Index: APSCpp/APSCpp.c >>>>> =================================================================== >>>>> --- APSCpp/APSCpp.c (revision 4038) >>>>> +++ APSCpp/APSCpp.c (working copy) >>>>> @@ -415,6 +415,8 @@ >>>>> kpp->imageFile = strdup(imgname); >>>>> kpp->xDim = pW; >>>>> kpp->yDim = pH; >>>>> + // free preallocated array before over-writing pointer... >>>>> + ArrayList_delete(kpp->array); >>>>> if( mode == 0 ){ >>>>> // return the KeypointN list >>>>> kpp->array = globalNaturalKeypoints; >>>>> >>>>> Hopefully I'll find something more fruitful than this... >>>>> >>>>> Andrew >>>>> >>>>> >>>>> On Sun, Jul 12, 2009 at 2:13 PM, Tom Sharpless >>>>> <tksharpl...@gmail.com>wrote: >>>>> >>>>>> >>>>>> Hi, I'm starting a new thread on this as the old one has gotten too >>>>>> long. >>>>>> >>>>>> First some background. Hugin's autopano-sift-C project builds 3 >>>>>> programs: >>>>>> generatekeys finds SIFT keypoints in one image and puts them in an >>>>>> XML file; >>>>>> autopano reads those files and constructs control points linking >>>>>> pairs of images; >>>>>> autopano-sift-c combines both function, plus several enhancements, >>>>>> in one program. >>>>>> The combined program shares a great deal of code with the separate >>>>>> ones. The main differences are that it processes all the images; does >>>>>> not write keypoint data to, or read them from, XML files; can convert >>>>>> images to stereographic projection before finding keypoints; and can >>>>>> read source image information from a Hugin project file. Although it >>>>>> ships as "autopano-sift-c", that name has always designated the two- >>>>>> program package as well, so to avoid confusion let us call the >>>>>> combined program by its name in the source code tree, "APSCpp". >>>>>> >>>>>> There have been several reports of out-of-memory errors while running >>>>>> "autopano-sift-c". It is possible that some might refer to >>>>>> generatekeys/autopano, however nowadays people mostly run APSCpp, as a >>>>>> Hugin plugin. Moreover, the combined program would be more likely to >>>>>> fail due to problems in the image processing stages, because it >>>>>> processes a series of images while generatekeys handles only one. >>>>>> However it is not clear whether these failures happened at the image >>>>>> processing or the control point processing stage. I am guessing it >>>>>> was the first stage, because that normally has a far higher peak >>>>>> memory demand than the second. >>>>>> >>>>>> I know of no case in which such a failure has been replicated by a >>>>>> second observer. I have not yet been able to get APSCpp to exhaust >>>>>> memory on either Windows or Linux. And when I run it under a leak- >>>>>> checking debugger (MSVC on Windows, valgrind on Linux) I see no sign >>>>>> of memory leaks during the image processing phase. Both tools report >>>>>> a fairly large leak in the control point phase, which I will fix. >>>>>> That is a one-time thing and could not cause a crash during image >>>>>> processing. But under some conditions (that I have not found) it >>>>>> might conceivably build up to the point of exhausting all memory. >>>>>> >>>>>> In short, the reported failures remain undiagnosed. So I am appealing >>>>>> to all interested parties to try to create a repeatable case where >>>>>> APSCpp runs out of memory. >>>>>> >>>>>> Meanwhile I propose to do the following: >>>>>> -- fix the leaks that valgrind detects, in both the split and combined >>>>>> programs; >>>>>> -- enable APSCpp to read PTAssembler and PTGui project files; >>>>>> -- read image alignments from project files, in preparation for >>>>>> layout- >>>>>> guided CP placement; >>>>>> -- remove the alignment options, as they don't work and are not likely >>>>>> to be fixed; >>>>>> >>>>>> And start thinking about how to use a preliminary alignment to guide >>>>>> better placement of control points -- maybe even close that loop, >>>>>> refining the alignment and CP selection iteratively. This would be in >>>>>> the spirit of autopano (which is apparently based on an early version >>>>>> of Janney's excellent aligner). I fully agree with Bruno that the >>>>>> goal should just be to select better control points, not to determine >>>>>> optimum image placement. But I think we all agree that a decent trial >>>>>> alignment would let us come up with better CPs (if only by throwing >>>>>> out the completely bogus ones that APSC now produces fairly often) and >>>>>> that some consistency checks on such a trial alignment would be >>>>>> useful. >>>>>> >>>>>> Best, Tom >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> At some point it might be nice to give APSCpp options to dump >>>>>> keypoints to and read them from files (binary or plain text, not XML). >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
