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