[hugin-ptx] Re: How to use geometry vs. feature based control points?
HI Martin, I beg you to use papywizard anyway - at least to produce a Papywizard-equivalent set of XML, which can be imported into Autopano Giga (and eventually, Hugin also...) Also, considering the head needs a "controller" of some sort, it is not standalone, strictly speaking - it has a little computer of some kind attached to it, to configure the pano routine you're shooting. If you'd like more thoughts on the matter, feel free to contact me offlist. I've used robotic panoheads quite extensively so I might be able to offer you a few things to think about that you might not have considered already. either way, I look forward to seeing your results. Pano robots are great! 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: How to use geometry vs. feature based control points?
The head will still take some time, I'm just in the design fase right now. But I will certainly post some pictures as I go along. At the moment I dont want to use papywizard because I want the product to be standalone. No need for a phone, tablet, notebook in the field. On Mar 3, 6:50 pm, Jeffrey Martin <360cit...@gmail.com> wrote: > let's see some photos of your motorized head? :-) I'm very curious :-) > > will your head calculate the optimum number of shots per row? if it doesn't, > the utility is very very limited in my experience. you need a motorized head > only for >200 shot panos, and with that type of lens, the number of shots > when your camera is pointing nearly straight up or down is so much less than > when it's pointing straight ahead, that the time wasted if you don't > optimize for this, is huge. > > and yes, you should use papywizard. > > 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: How to use geometry vs. feature based control points?
let's see some photos of your motorized head? :-) I'm very curious :-) will your head calculate the optimum number of shots per row? if it doesn't, the utility is very very limited in my experience. you need a motorized head only for >200 shot panos, and with that type of lens, the number of shots when your camera is pointing nearly straight up or down is so much less than when it's pointing straight ahead, that the time wasted if you don't optimize for this, is huge. and yes, you should use papywizard. 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: How to use geometry vs. feature based control points?
On Sat 26-Feb-2011 at 00:29 -0800, Martin Terblanche wrote: I'm doing a project where I'm building a motorized head which will save all the positions to a log file. I want to automate the entire process of creating a panorama in Hugin. So i'm basically doing exactly the same thing as Bruno. I want to use a log file to help Hugin to place photos in areas with no control points. It seems like Papy wizard can create such a file (xml) and APP can then use this. But APP is expensive and I would like to use Hugin. Papywizard is open source, so it would be a good choice for controlling your panoramic head. Would you set the y,p,r of all the photos and then run the optimizer, all in a script? What train of thought must I follow here :) Unfortunately (as mentioned elsewhere in this thread) you can place the photos according to a log file, but photos move around as soon as you optimise, so you lose any benefit of aligning them beforehand. -- Bruno -- 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: How to use geometry vs. feature based control points?
I'm doing a project where I'm building a motorized head which will save all the positions to a log file. I want to automate the entire process of creating a panorama in Hugin. So i'm basically doing exactly the same thing as Bruno. I want to use a log file to help Hugin to place photos in areas with no control points. It seems like Papy wizard can create such a file (xml) and APP can then use this. But APP is expensive and I would like to use Hugin. Would you set the y,p,r of all the photos and then run the optimizer, all in a script? What train of thought must I follow here :) On Feb 19, 1:58 am, Bruno Postle wrote: > On Fri 18-Feb-2011 at 10:54 -0500, Bill Sherman wrote: > > > > >1) I'm having trouble with the Move/Drag portion of the Preview (actually, > >to tell the truth, much of how to use the Preview window is a > >mystery to me). I just reran Hugin, using my sample images, and > >then go to the Move/Drag operation. At this point, I can move > >some of the images independently, but some stay stuck together -- and > >I want to move one relative to the others. > > The fast preview lets you drag connected image groups separately, a > connected group is defined as any set that is connected by control > points. > > >3) I noticed an image referred to in a post from yesterday an "Overview" > >sub window for the preview, but I do not see that in my version. Will > >this be in the next release? Will there be a new release soon? Here's > >the picture: > > -http://www.flickr.com/photos/36383814@N00/5451289889 > > Yes the overview will be in the next release, currently you need to > build a snapshot from Mercurial to get it. > > >The robot device does not directly communicate with any computer, so > >there is no log. However, it reports on the screen the angle between > >shots, so I could easily provide command line arguments of the MxN > >array, with both horizontal and vertical movement angles. > > >And I'd be happy to help figure out the best procedure for this. > > What other ways do robots allow you to specify a sequence? > Presumably you have an option to start at the top/bottom or > left/right, or to specify the total angle rather than number of > shots, or specify the total angle and angle between shots. > > -- > Bruno -- 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: How to use geometry vs. feature based control points?
i agree, guessing of orphan images would be awesome. autopano pro has this and it works wonders. i guess it is relatively simple, at least for "simple cases" where the orphan images are from a row of images that are spaced quite evenly. (this brings up the subject of robot shooting - if you shot with a robot it would be better to load the output of that. if you shot by hand you could still enter the approx. positions for images on each row, presumably - although I've never been organized enough to succeed with that, personally :) finally, i think vertical line detection and improved (smarter) enblend are more important, if i may give my .02 about what the priorities should be :) On Tuesday, February 22, 2011 1:10:15 AM UTC+1, Bruno Postle wrote: > > On Mon 21-Feb-2011 at 14:52 -0800, Bill Sherman wrote: > > > >Perhaps a ray of hope: if one could prevent (or delete) control points > >from being generated in featureless images, then those portion of > >the images that have pre-set pitch & yaw would -- I presume! -- be > >calculated relative to whatever image is set as the position anchor? > >(and thus basically fit with the rest of the images). > > Usually the anchor needs to move around some to get everything > level. > > If you try a very recent snapshot, the built in control point > generator is very good and gets many less 'false' control points. > > >Thinking about all this has led me to yet another question regarding > >the setting of pitch and yaw values to "place" a featureless image: > >is there an implied "distance" value applied to the pitch & yaw? I.e. > >pitch and yaw values without some distance from a viewing location > >don't fully specify the relationship between images -- right? > > The roll, pitch and yaw values define the location relative to the > centre of the output panorama. > > -- > Bruno > -- 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
Re: [hugin-ptx] Re: How to use geometry vs. feature based control points?
On Mon 21-Feb-2011 at 14:52 -0800, Bill Sherman wrote: Perhaps a ray of hope: if one could prevent (or delete) control points from being generated in featureless images, then those portion of the images that have pre-set pitch & yaw would -- I presume! -- be calculated relative to whatever image is set as the position anchor? (and thus basically fit with the rest of the images). Usually the anchor needs to move around some to get everything level. If you try a very recent snapshot, the built in control point generator is very good and gets many less 'false' control points. Thinking about all this has led me to yet another question regarding the setting of pitch and yaw values to "place" a featureless image: is there an implied "distance" value applied to the pitch & yaw? I.e. pitch and yaw values without some distance from a viewing location don't fully specify the relationship between images -- right? The roll, pitch and yaw values define the location relative to the centre of the output panorama. -- Bruno -- 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: How to use geometry vs. feature based control points?
[Dang, I didn't change the subject line earlier to match the thread, so now I've gone and started a separate thread.] On Feb 21, 4:08 pm, Bruno Postle wrote: > On Mon 21-Feb-2011 at 15:53 -0500, Bill Sherman wrote: > > > > >Okay -- is there an easy way to disassociate an image from a group (one > >of the images in a calculated group was wrong). > > Remove its control points. > > >I'll do snapshots if necessary, but prefer official releases -- will there > >be a new release soon, or should I bite the bullet and go with the > >snapshot? > > The 2011.0.0 release process hasn't started yet, though I think it > is about ready (at least on Linux, I'm not sure about other > platforms). Okay, so perhaps I'll be patient and at least wait for a release candidate. > >With my limited feel for how things come together, I wonder: is it a > >problem that all the images would be specified with an initial pitch & > >yaw, even though some could be fine-tuned with control points? > > Yes this is a problem. You either fix all positions and parameters > at the start, or create control points and optimise. Mixing the two > approaches isn't likely to work very well since optimising moves > stuff around. Perhaps a ray of hope: if one could prevent (or delete) control points from being generated in featureless images, then those portion of the images that have pre-set pitch & yaw would -- I presume! -- be calculated relative to whatever image is set as the position anchor? (and thus basically fit with the rest of the images). [Aside: I guess this is why at one point I was thinking it might be good to create control points based on geometry, and then the optimization process would treat the featureless images the same as any other.] Thinking about all this has led me to yet another question regarding the setting of pitch and yaw values to "place" a featureless image: is there an implied "distance" value applied to the pitch & yaw? I.e. pitch and yaw values without some distance from a viewing location don't fully specify the relationship between images -- right? > Interpolating positions for unconnected photos after optimisation > will work if there is no other way to it, however this tool doesn't > exist yet - This would be a nice thing to write as a python plugin. > > -- > Bruno Bill -- 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: How to use geometry vs. feature based control points?
On 18 Feb., 16:54, Bill Sherman wrote: > 1) I'm having trouble with the Move/Drag portion of the Preview (actually, > to tell the truth, much of how to use the Preview window is a > mystery to me). I just reran Hugin, using my sample images, and > then go to the Move/Drag operation. At this point, I can move > some of the images independently, but some stay stuck together -- and > I want to move one relative to the others. I think that maybe you're using the 'plain' preview, which is the old way of previewing, offereing some features some people won't do without. Most things are easier to do in the openGL preview, that's the icon next to it with GL on it. > 2) What units are the X, Y, & Z values under the "Image Orientation" > label in the Image tab? Are they percentages? And is there a way > to "lock" them? (or is the way to lock them simply to delete any > control points that get generated for that image?) X, Y and Z are for translation coefficients for use with mosaics. If your project isn't a mosaic, best leave them at 0. The relevant parameters for panoramas are yaw, pitch and roll (y, p and r) > 3) I noticed an image referred to in a post from yesterday an "Overview" > sub window for the preview, but I do not see that in my version. Will > this be in the next release? Will there be a new release soon? Here's > the picture: what's shown is the openGL preview > The robot device does not directly communicate with any computer, so > there is no log. However, it reports on the screen the angle between > shots, so I could easily provide command line arguments of the MxN > array, with both horizontal and vertical movement angles. > > If you can set me on the right course, I could potentially write a .pto > generator myself -- though a template would be helpful. A first question: > would I create control points, or are the image locations stored in > the .pto file? What documentation should I read first? The pto format is documented at http://wiki.panotools.org/PTStitcher The Wiki is a treasuretrove of information, but at times it's not so easy to find what you are looking for. If you want to look at scripting panotools, have a look at http://wiki.panotools.org/Panorama_scripting_in_a_nutshell Bruno has many perl scripts at http://search.cpan.org/dist/Panotools-Script/ and if you're into Python, there is a bit of code at my Bazaar repo at http://bazaar.launchpad.net/~kfj/+junk/script/files/head:/main/ 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
[hugin-ptx] Re: How to use geometry vs. feature based control points?
On 17 Feb., 19:57, Bill Sherman wrote: > Has anyone successfully created a workflow that adds control points > based on geometry rather than feature matches? > > If one were to somehow calculate these control points, how best to > get them into the system, and then not have them altered by the > optimizer stage, etc.? Hi Bill! What you need for your images is correct yaw, pitch and roll values - control points are only a means to get them. As Bruno has pointed out, these values might be derived from the capture process, be it from it's parameters as passed to the robotic head, be it as a log file of sorts. If the 'featureless' images are placed (roughly) by using the capture process y, p and r values, and if they're not connected by control points with other images, they'll be left where they are by the optimizer. Putting the y, p and r values into the pto script, which is a mere text file, isn't difficult. On the other hand, where you have images with features, you can do the last bit of nudging via CPs and the optimizer. In corner cases, when you have only little usable content somewhere in an image, you need to manually intervene if the stitch isn't perfect. Another method to deal with featureless areas is to have some more wide-angle material to use as backdrop, in which case you can omit those images that don't yield (usable) CPs. Setting CPs following the shooting pattern is not a good idea, because CPs should reflect matching content, as determined by the feature detector in the CP generator - or your eyes, if you set them manually. 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
