HI Kay, a bunch of nice ideas!
comments below On Monday, February 7, 2011 3:34:25 PM UTC+1, kfj wrote: > 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. > ok, with a minimum image width of say 320 (long side), this would be great, i think. just to start things out in a simple way, couldn't we (well, not me :) because I don't know how) just add a parameter to cpfind specifying how much to reduce source images (not only halfsize or fullsize as we have now) anyway, your idea is very interesting if in fact it would improve alignment of different FOV lenses. I fully agree that using CPG's in real life, this doesn't work so well. > > 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. > It is so easy, by all means! I'll be happy to test it. > > 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, maybe only reduce to 1/2.... ;) > 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<http://bazaar.launchpad.net/%7Ekfj/+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 always worries me..... after optimizing something and you see it works, optimizing again always has a risk that it will all go to hell again ;) but maybe in real life this will not happen much....? > > 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 - do you want some 2000 image panos to test it on? in that case the time savings might be very significant. what I mean is, sure for panos containing 4 or 10 images this just won't matter but for gigapixel images it might save minutes or hours. I'm interested to see where this leads.... Jeffrey -- 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
