On 7 Feb., 12:30, Jeffrey Martin <[email protected]> wrote: > I found that reducing source images to 25% (or less) of original size seemed > to produce a good stitch. although I wasn't rendering the full size to > check, it aligned a screen-size version of the pano perfectly. I wonder if > cpfind should allow reducing image size by any arbitrary amount (not only > half, or fullsize)? I mean, half of what? Autopano sift C has a setting that > allows you to set the size the images are reduced to for analysis.... in > terms of speed, this is where the tweaking needs to happen, i think.
Good thing you touch the issue. I'd like to make a proposition concerning the modification of image size. I agree that it would be very helpful to have more precise control over the process by allowing arbitrary scaling. But I'd go one step further. What would that be? My idea is to pass a parameter to the CPG that defines magnification of the images based on their field of view. Why that? I sometimes mix images taken with different lenses: Fisheye shots for the 360x180 side of things, and for those parts of the image where it doesn't matter so much (sky, ocean etc.) - and rectilinear shots, sometimes even zoomed for super-clear details, where it matters. In my experience, the CPGs work best when they are presented with images which roughly share the same amount of pixels per degree of fov. To achieve this with the current CPGs, which, if at all, only allow scaling by a factor, I have to blow up some images and shrink some, and then the CPG generation works best - but it's laborious. If I could tell the CPG to scale all images to, say, 50 pixels per degree overall, I would achieve precisely the effect I want by specifying one single parameter. It'd make things so much easier for mixed-lens takes. I know that theoretically SURF and SIFT features are (quite) scale- insenstive, but my experience tells me that this truth only goes so far. I'm not sure how scale-insenstive the gradient-based detector in cpfind is. But I feel that implementing my proposition might be easy and it'd give us the opportunity to see if this might be a cheaply bought improvement in performance. Also, it'd instantly put an estimate on the images: if it's 1000 pixels from a consumer point-and-shoot camera, you may want to go fullscale, whereas 1000 pixels from an SLR sensor might as well be scaled down for the CPG: The first 1000 pixels might represent 50 degrees, whereas the second might represent 15. Setting a default of, say 50 pixels per degree, would make more sense for both images than any fixed scaling. > taking it a step further, could it be possible to first run cpfind first on > very small versions of the images, and then after some optimization, to run > cpfind again on only the overlapping portions of the image pairs at a higher > sensitivity, to align the images more precisely? i could imagine that that > could increase the speed of cpfind dramatically. would that be possible, or > is this a bad idea? I have made experiments in this direction using up- and downscaling of pto files. You can find a working prototype of my Python script here: http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/scale_pto.py The idea is to run the process on smaller images and once the orientations are established, to replace the images with full scale versions and have all pto parameters that build on image coordinates rescaled. I wrote this because I wanted to work on the screen-sized images I carry with me on my laptop and apply the results to the full- scale images back home with the fat data corpus. It works, and surprisingly well. The scaled-down versions are usually a fair bit crisper than the full-sized images, so there is enough detail for the CPGs to work on - and since the feature detectors produce subpixel accuracy, the scaled-up pto often stitches without any need for further intervention - if you want you can run a global fine-tune on the CPs. This method seems promising, and it's on my list of scripts to convert into a plugin for the python plugin interface I've written to whet everyone's appetite. Until then there's the pure python implementation, and there is also a perl script by Bruno Postle, which scales by factors of two: http://www.google.com/url?sa=D&q=http://panotools.svn.sourceforge.net/viewvc/panotools/trunk/Panotools-Script/bin/ptohalve%3Fview%3Dmarkup%26pathrev%3D1291 The next idea, to look at the overlapping parts once the overlap has been roughly established, is also promising and heas been previously exploited, though I'm not entirely sure where the code is. Another interesting aspect along these lines is to warp the overlapping parts of two images to a common projection and run the CPGs on those warped partial images, to later retransform the CPs to original image coordinates. This has also been done, and I've experimented with it myself, but found the gain not so noteworthy as to make me want to investigate the matter more deeply - it would be more interesting if the CPGs didn't have facilities to deal with projections like fisheye which, if not taken into account, can well make CP generation very difficult. 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
