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
-~----------~----~----~----~------~----~------~--~---
