Hi Tom, On December 26, 2010 10:11:23 am Tom Sharpless wrote: > I have 2010.2.0.d8ce0ba947cc open in front of me. Like most other > recent releases it is unable to generate any control points, and > offers no help to understand why. It does present under preferences/ > control point detectors a promising-looking option called "Autopano- > SIFT-C (multrow/stacked)". But of course that is not supported by the > files in the release.
I guess you are on Windows. "not supported by the files in the release" is a Windows-specific problem. It may have been solved recently with a better installer that compensates for Window's lack of package management. > Is that what you are talking about? If so, please state clearly: Yes > -- where do I get it? > -- how do I install it? The package manager or installer knows where to get third party CP generators from and how to install them. From the chatter on this ML I believe the 2010.4 Windows installer has been improved, but I can't tell for sure. As an extra bonus, 2010.4 will also bring you cpfind. That's Hugin's CP generator. It is still in its infancy, so you may prefer to use your tried tested and trusted third party CP generator. icpfind [0] enables the use of heuristic strategies with third party CP generators. > -- what do I need to know to run it? The PTO file is the interface that "tells" cpfind/icpfind about images and lenses. The strategy is described in [1]. > What I was talking about would be Hugin actually controlling CP > finding in an intelligent way; that's the above linked strategy. > behind an intelligible UI the *I*nterface is the PTO file. And Hugin is the UI to the PTO file. > that would let the user specify a 'shooting grid'; I see and understand the need to let the user specify a 'shooting grid'. Underlying such a 'shooting grid' is a 'shooting sequence'. cpfind/icpfind builds on that sequence and thus does not really need the grid. Would a 'shooting grid' optimize CP detection beyond what the 'shooting sequence' already does? Probably yes, but only marginally. icpfind/cpfind could go straight on to trying to connect all overlapping images. Where the grid would help even more is with the optimization; and there it is already taken into account, again, through the PTO file. So what is missing is the *UI* part. We already have templates (Menu -> File -> Apply Template) which covers the most important aspect: repeatabilit. What is missing is a 'Distribute' function/button on the Images Tab, where the user can specify the shooting pattern in terms of: - number of rows - number of columns - vertical shooting direction (topdown or bottomup) - horizontal shooting direction (leftright, rightleft, leftsnake, rightsnake) - number of brackets and that function would automatically distribute the hundred of pictures on the panosphere. Did I miss something? > the bottom line being automatic alignment of gigapixel (and smaller) > image sets. actually the automatism is already given with the sequence-based heuristic, and the whole UI would be just added manual intervention to make the process more robust. > Until Hugin ships with the ablility to auto-align a pano, it will > continue to be ignored by a lot of people who could benefit from it. No intention to stir up controversy but this argument is moot. Yuv [0] <http://wiki.panotools.org/Icpfind> [1] <http://wiki.panotools.org/Hugin_Parameters_for_Control_Point_Detectors_dialog#Multi- row_panorama>
signature.asc
Description: This is a digitally signed message part.
