On Mon, 24 Oct 2011 00:24:03 -0700 (PDT), kfj wrote: > > On 23 Okt., 21:58, Robert Krawitz <[email protected]> wrote: > >> 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.
Something to think about for the future. Unfortunately, since the preview can't be magnified, it's hard to position the crop box very precisely. >> 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. The problems in the sky are usually just above the mountains, maybe within 20 or 50 pixels, so removing them is a bit more laborious. Fortunately, once I have enough clean points, they usually show up as outliers. I'm not doing spherical panoramas (usually they're simple strip panos, occasionally but not usually 360), so I don't have zenith or nadir problems. (But I wish I had done at least a hemispherical panorama at the Reno balloon festival last month. Oh well.) >> > 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. These are 18 megapixel images. I was using the JPEGs. This is also a 64 bit system. Even without --fullscale, cpfind still hits 5 GB. Also, it's examining 8 images concurrently (quad core hyperthreaded). I wonder if that's the issue. The cpfind I'm using is from the current master head. >> 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. Some of it may be due to SWIG 2; I think a fair number of distributions still use 1.3. -- 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
