On 23 Okt., 21:58, Robert Krawitz <[email protected]> wrote:
> Well, it works on openSUSE just fine. good news :) > For my test panorama, I had to do it a few times, because part of the > foreground protruded much closer to the horizon than in the rest of > the scene (this was a 360 degree pano from an overlook just west of > Mono Lake; to the east, there was very little foreground, but to the > west, looking toward Tioga Pass, there was much more). But I didn't > have a lot of difficulty getting the max error down to 1.15 units (I > saw no point to trying any harder), especially with a 22 mm equivalent > lens (I optimized for everything except translation). 1.15 sounds good enough - around 1.0 is what I'm aiming for with my stick-assisted handhelds. I know the kind of problem you're having with your content (I do most of my photography in the Alps in Piemonte, Italy), and I've at times been annoyed by the box-limitation of my plugin, but not bothered enough (yet) to write code for using masks somehow. > Most of the remaining bad points were either in the sky just above the > mountains, or on the lake just above the shoreline. I guess celeste > doesn't try to kill points that are close to edges, unfortunately. > These aren't very good points anyway, and I had so many there was no > sense trying to tune them by hand. I usually just take everything out from the sky. I shoot six around, 1 up 60 degrees, two down 60, all in portrait with a stereographic fisheye. This way all images have a good part of the horizon, and I find this sufficient to get a good stitch. I don't mind throwing away good CPs elsewhere, hence my strip-along-the-horizon approach. If your lens is well-calibrated and your horizon is correct, stitching errors occur nearer the zenith and nadir and oftentimes aren't noticeable or bothersome, since enblend does such a good job at intelligent seam- picking in it's more recent incarnations. > > I use a sort of brute-force approach. I detect lots of CPs using > > cpfind with this parameter set in an 'all images at once' setup: > > > --fullscale --sieve2size 5 -o %o %s > > Eek. I'm going to need more memory to use --fullscale. It got up to > 14 GB, and that was only while working on the first 8 out of 16 > images. I'm going to need to add at least another 8 GB (or an SSD) to > make this practical, but I suspect it would help quite a lot. Really?! I have an old Thinkpad with a 32 bit system and 3G of RAM and I don't run into problems - maybe there's a bug in your cpfind? The -- fullscale should use more memory per image, but the memory usage should not really increase with more images - or only slightly so, since it'll find more key points. You might try using apsc with -- maxdim 0 instead, that's what I used before cpfind got so good and reliable. Or as a workaround you might consider having cpfind cache the keypoints for the individual images to disc, but it takes some fiddling because the silly thing doesn't take images as CL paramaters but only ptos, which you have to make first. But I have no problem here memorywise, even if I make panos with a few dozen images (12MP 16bit TIFFs, each about 70MB) - of course, if your images are much bigger that might be the cause of your problems. > While the initial optimization step with > 4200 points was rather slow This is, regrettably, the case. Hugin has a scaling problem - there must be some highly inefficient coding somewhere deep down from times when you still were setting CPs manually and noone anticpated having to deal with lierally thousands of them. With my woa plugin, I sometimes end up with tens of thousands of CPs, and it all becomes REALLY slow then. Mind you, it still works. > things were a lot faster once I cleaned > up the bad points with your script. I like to hear that :) So far there hasn't been much echo from people actually using hsi/hpi - it's in the source, but I think it hasn't really trickled down to the binary distros. > I wound up with about 1100 > points, which is quite ample indeed, and it's easier to just toss the > ones I don't want. Just what I do - start with many, then you can afford to be sloppy and it's no problem wasting a few. Kay -- 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
