Thanks, Kay, I too think it is time for us to take a hard look at the whole problem of aligning source images.
Editing control points is one important aspect of that problem. Finding CPs in the first place is a more fundamental one. Your suggestions about focusing on local areas where images actually overlap is, I think, the key to both. It is amazing to me that Hugin (and the other PT based stitchers) still treat the alignment problem as if the source images were taken in random directions, when in fact all serious panographers take a lot of trouble to orient their views systematically. Simply taking advantage of what the photographer already knows about the alignment would eliminate a great deal of useless computation, and make it feasible to stitch large arrays automatically (inability to do that is one of Hugin's major weaknesses). Furthermore, it would let Hugin show us detail views of the overlapping areas right from the outset; then after some manual adjustments the CP finding problem should be almost trivial. Or CPs might even be bypassed altogether in favor of a direct optimization based on correlating patches within the overlaps. I strongly support the suggestion that any such detail views should be re-projected to rectilinear (or stereographic, for wide zoomed-out views). I'd suggest two ways to make those views even more useful: 1) the center of the rectilinear (or stereographic) projection should be at the middle of the region of interest (i.e. the 'overlap patch' we are examining); 2) any lens corrections we already know about should be applied. BTW if this were done, the 2 views of the overlap could then be submitted to an auto CP finder with very high probability of getting good CPs. I concur with Yuv about the horizon not being generally useful. Vertical lines are much more so, and should perhaps be given special status. But in fact the most important thing is to make it as easy as possible to designate the same straight line in both views, regardless of orientation. If backed up with some automatic edge-finding, that could make strong curved edges just as useful for alignment as straight lines. The general principle here is to let the user specify rough local alignments, and have the SW refine them into a precise global alignment. And to take advantage of pre-calibrated lenses and shooting patterns. Regards, Tom On Dec 25, 11:35 am, Yuval Levy <[email protected]> wrote: > Hey Kay, > > I finally have time to catch up with these and I agree with most of what you > write about editing control points. But.. > > On December 16, 2010 09:22:29 am kfj wrote: > > > > > Control point editing/visualisation is a core issue of the panorama > > creation mechanism used in hugin. It would deserve being focused on > > more. I'd like to advise caution and extensive discussion of the > > matter, and I've some ideas to share. When I first tried to get my > > head around it, the conceptual difficulties were great - particularly > > those arising from confusion about which features would be part of the > > input space and which part of the output space. I fear that if some > > quick fix is applied to add features in either the CP editor tab or > > the preview, the situation might not improve. > > > This post started out in another thread: > >http://groups.google.com/group/hugin-ptx/browse_thread/thread/dbb85da... > > 586/06bc804cf2d3a234#06bc804cf2d3a234 But I felt the topic deserved a new > > thread, so here it is. > > > The CP editor tab shows images in their original projection. Many > > users will not be aware that there is choice involved here - they have > > rectilinear images, lines look like lines, why can't they just draw > > lines, either on one image or on several, why not show lines in the > > editor? Features on overlapping images look the same, why can't they > > just overlay them somehow? Even seemingly rectilinear images, though, > > aren't perfectly free from distortion (a, b, c) and with a more wide- > > angled lens, lines towards the image's edges may well become visibly > > bent. Other users use different lenses, be they fisheye or > > stereographic, to maybe make 360 degree panos. These users would be > > well aware of the bent straight lines - after all it's extremely > > obvious in their case. They suffer from the opposite problem: Often > > parts of the images they try to match are so distorted or tilted they > > can't figure out what is where and offering them the images as > > captured by the sensor makes editing CPs at times excruciatingly > > difficult. > > > Displaying the native images, next to each other, in separate images, > > makes sense when there is no initial notion of the images' connection. > > This would be the case in a setup without an automatic CPG, or in a > > situation where automatic CP generation fails utterly. I would say > > that these situations are now rather the exception than the rule: > > automatic CPG are quite reliable, and hugin now has a distributable > > CPG, so there is at least one CPG available. To find oneself in a > > situation where CP editing has to start from scratch is now mainly a > > thing of the past; today it's more a matter of finetuning the CPG's > > result. > > But the option need to be available. Let's relegate the CP tab to a context > menu option on the connection between two images, as displayed in the layout > mode. > > > The preview on the other hand shows what the output would look like, > > given the current position and warping of the input images, and > > projected according to the chosen output projection. Again, different > > users will deal with different types of images, where for example, > > all, or only some straight lines will show up straight, and there are > > uses where large distortions are deliberate - noone would want to use > > those projections to edit control points with: The preview should be > > that - a preview of the final image. > > and a navigation tool to zoom in on those areas of the images that still need > manual work of some sort. > > > > > This is why I have at times > > wished for a preview-like display to edit CPs in rather than CP > > editing in the preview. > > > Considering these two intentions: working on the input images to find > > and/or manipulate control points, and previewing the output, there is > > a distance to travel, and the question is, how this distance can be > > made navigable for everyone's benefit. > > > Having considered the matter thoroughly, I feel that displaying the > > input images in the CP editor has relatively little merit. Direct > > visualisation of the input images would be useful to get a quick idea > > of what they look like - like you would navigate by looking at > > thumbnails when looking at a folder full of images. Such a facility > > would logically belong into the images tab - most file managers, image > > databases etc. will give you at least an option to see thumbnails of > > the objects they present to you, so as to allow you to do what you > > want in a GUI: point and click. It should be no different in a GUI for > > panorama creation, and hugin's way of showing a single thumbnail of > > the currently selected image is nice, but there should be an option to > > show thumbnails of all images at the same time, and I feel the UI > > would benefit from that. > > > When it comes to editing control points, the usefulness of displaying > > images in their native projection becomes more limited. I also feel > > that having to work on two separate images by default is at times > > awkward, particularly with the current UI, which doesn't seem very > > intuitive to me - it feels more like a relic from another time. My > > idea would be to use only one standard projection for the purpose > > agree > > > which lends itself particularly well to the task and can be > > efficiently calculated, and only one view. As far as standard > > panoramic work is concerned, I feel that equirectangular projection is > > best suited. > > disagree. Try placing a CP on the nadir. > > > Sine CP editing is mainly close-up work, the distortions > > would be small > > you assume rotating the sphere so that the point of interest is around the > horizon, where the distortion is indeed minimal; but this is also true of > every other perspective. If we go this way of zooming into close-up work, > then I would rather have that projection rectilinear (think: straight lines) > or stereographic (think: reducing distortion). > > > , and the most-commonly used line of reference - the > > horizon - comes out as a line in an equirect if all is well. > > wrong. the horizon is not the most commonly used line of reference. On many > pictures it does not appear (interiors!). I don't think we can make any > assumption about most commonly used lines of references. Verticals are for > interiors. Horizons for flat outdoors. And sometimes there is neither nor. > Rectlinear projection served both of them equally well (and can be used also > for horizontal lines parallel to the Horizon). > > Agree with the rest. > > Yuv > > > The > > projection could be done just like in the preview window. The images > > could be shown in the position they are currently thought to be in, > > there would be a mechanism to focus on individual images, pairs, > > groups of images and the lot to set points on one, two or several > > synchronously. I imagine controlling visibility and focus with an > > interface like a mixing desk, where you have solo buttons, mute > > buttons etc. - an extension of the switch on/off buttons in the > > preview window. CP setting would be in this display, with an interface > > which should be well thought-out and discussed and quite definitely > > new and not just the existing preview with a few features added. The > > idea is to always use this particular projection for CP editing and > > choose it for that purpose, not giving any choice in the matter - with > > the notable exception of mosaic mode, which would require a > > rectilinear display. The CP editor should allow zooming with good > > resolution and offer several overlay modes, like the 'normal' and > > 'difference' modes in the preview. > > > The preview, finally, is well as it is. There are even two of it > > already. These two may not be used so much anymore if the CP editor > > can be used as an equirect and rectilinear preview as well, but they > > wouldn't do any harm either - and to display the whole rich set of > > output projections and faithfully show a preview of the final product, > > their existence is well justified. Some editing capability which can > > be conceptualized more easily as belonging to the output space could > > remain in them. > > > Maybe a 'new CP editor' could start out alongside the current one, > > just as the openGL preview has come up alongside it's elder brother, > > as an experimental feature, to gain experience and feedback. Take it > > as my item on the wishlist. > > > with regards > > Kay > > > > signature.asc > < 1KViewDownload -- 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
