[hugin-ptx] Re: Layout panorama model (GSoC)
Hi James, I am a bit late on this thread and coding starts tomorrow. Nevertheless, here are my thoughts, hoping they can help you. At the core, Hugin makes sense of a series of photographs. In your project you get the unique opportunity to review how this is done. There are two parts to it: the underlying data model and the user interface. It is very unlikely that you can do both extensively and completely over a single GSoC project, but you can lay down the foundation for future work. The most important is the data structure. Many of the shortcoming of Hugin currently are the result of new needs (e.g. brackets) that were not on the radar screen when Hugin was first conceived. You want to have a flexible enough data structure that makes it possible to implement constrains such as "a group of images all use the same lens" or "a group of image is shot from a known tripod position and thus shares the same y/p/r parameters" and their opposites. Your input is a series of photographs. They can come from a single camera or from a set of different cameras. And most often they are spread over a lapse of time which can be of arbitrary length. You want to use available information such as exif or file timestamps to make an initial arrangement of these images in the sequence, but let the user the ability to override it. Within this sequence, you want to try to identify patterns based on that information, such as clustering in time (if the pictures are shot in very short intervals, chances are that they belong to the same panorama), exposure values, focal distance, etc. Each such pattern is a constraint. You want to user your knowledge of these constraints to infer the type of project that the user might want to run. And you want to give the user the ability to remove/edit/add such constrains. For example, if your code determines that 18 pictures are taken within a short time frame and have a repeating exposure pattern every three pictures, this is likely to be a panorama with three brackets. The user will have to tell you if they are from a tripod or if the registration within each bracket has to happen over control points. The user may give you a shooting pattern (e.g. six around at 60°; or four around at 90° + zenith and nadir; or six around at 60° with the odd ones pitched -10° and the even ones pitched +10°). I would probably take all current Hugin parameters that are associated with lenses and images and put them into a single big table, associating them with the individual image and thus freeing them from all constrains. Then I would model the constrains, e.g. if all images are shot with the same lens, the FOV, geometric distortion and photometric distortion parameters are constraint by the relationship that they must be the same value. In that sense, constrains are group of pictures with a description of what parameters are constraints and how are they constraints. In a bracket I could determine a single picture as being the "master" picture, and use only that one to find control points against other such master pictures, assuming that all other pictures in a bracket simply share the same y/p/r/fov/a/b/c/d/e params. For flexibility you want to make it easy to expand indefinitely the parameters list for an image. Maybe one day somebody will add a different geometric model? or a reference to a hand-painted blending mask? Reading through the list of pictures and the list of constrain, a "hub" would take control of all the necessary operations, scheduling them and running the appropriate tools with the appropriate parameters and feed back the results into the lists: - geometric optimization - photometric optimization - warping - masking - blending The idea being that the user interface and the sequence detection by your code are two ways to feed a list of operations to be taken, and those operations are managed by the "hub". The list itself would end up being a part of the project file. I hope that's not too confusing Yuv --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
On Mon, 2009-05-18 at 21:35 +0100, Bruno Postle wrote: > On Fri 24-Apr-2009 at 13:30 +0100, Bruno Postle wrote: > > > >Random thought: how about a 'layout' mode in the fast preview window > >that rearranges the photos to show the structure of the project. > > Following through with this idea, here is a mockup showing the > 'Preview' mode compared with the equivalent 'Layout' mode: > > http://www.flickr.com/photos/36383...@n00/3542328667/sizes/o/ > http://www.flickr.com/photos/36383...@n00/3543135618/sizes/o/ > > Images would need to be shown undistorted, but with the correct > roll, pitch and yaw. Dragging and rotating would work the same way > as with the fast preview. I would have thought that a graphical layout mode would only really need to show the relative order of the images, not using their actual yaw and pitch. Dragging the images would only reorder them. I don't need to be able to set absolute yaw and pitch: that is the optimiser's job. With this in mind, having an ordered set of rows each containing an ordered set of images wouldn't be too bad. The images could be shown larger and more of the screen space could be used. Reordering the images would be easier, you can drag an image anywhere and the other images just move out of the way. > The connecting lines could carry a lot of > information, width could represent quantity of control points and > colour quality. We could show more information with a line with multiple colours along its width. If we arrange the control points in order of quality across the width of the line, then assign each a colour you could see the distribution of errors. We could even show the distribution non-linearly so you could see single bad errors clearly (and encourage quality of control points over quantity). Having a good number of good control points would make a nice clear green line, where automatic alignment has picked many moving features, you would instead see a little green and and lots of red. In your mock up, you have two images which are overlapping in the layout view. The line between them is very short. If images are placed close together like this, either all the images would be scaled down (so the images become less identifiable in general, but there are none which overlap); or the lines would cover, or be covered by, the images. If the images were shown with equal spacing in layout mode, the images and lines between them will more often be clear enough. > Photos that overlap without any control points need > to be joined by a faint or dotted line, so it can be clicked for > opening in the Control Points tab. If I were to adopt your real yaw and pitch view, and the 'unconnected but overlapping' line appeared while you were dragging the images around, this would be a good visual cue to if your image is in roughly the right place. Perhaps the intensity of these lines should be proportional to the overlapping area. Diagonally overlapping image pairs would then have a very faint line, so we aren't encouraging users to try and match features in the most distorted parts of their photos. > A complication is that the > connecting lines need to follow the shortest 'great circle' path, > which is a curve that will exit and enter the edges of 360° > panoramas at funny angles. Yes, though this might be easier to correct for than with the fast preview, as it is just a single edge that cross the edge of the screen, where the fast preview had to split polygons with arbitrary projections. Maybe at some point we could have a rotatable 'exploded sphere' view as well. > (This is also a particularly difficult panorama to break down into > rows and columns) It is true that there will always be image sets that don't fit rows and columns, or even just rows. I don't think your set is too hard to fit into rows for Hugin's purposes. Perhaps it would be fine if Hugin remained largely tolerant of freeform layouts, but the layout mode only showed images in rows. The stitched panorama would still work (hopefully), but it will encourage the user to pick a more uniform layout for next time (if they use the layout view at all). A layout with well defined stacks and rows should be easier to align and stitch, and the user will be less likely to miss angles they need when taking photos. James --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
why not just outline the photo. you can turn off and turn on a photo on the top in addition, if you want one above the other or to move around you can click and drag it or raise it's level, similar to layers or levels in gimp, scribus, etc. > Date: Mon, 18 May 2009 21:35:38 +0100 > From: br...@postle.net > To: hugin-ptx@googlegroups.com > Subject: [hugin-ptx] Re: Layout panorama model (GSoC) > > > On Fri 24-Apr-2009 at 13:30 +0100, Bruno Postle wrote: > > > >Random thought: how about a 'layout' mode in the fast preview window > >that rearranges the photos to show the structure of the project. > > Following through with this idea, here is a mockup showing the > 'Preview' mode compared with the equivalent 'Layout' mode: > > http://www.flickr.com/photos/36383...@n00/3542328667/sizes/o/ > http://www.flickr.com/photos/36383...@n00/3543135618/sizes/o/ > > Images would need to be shown undistorted, but with the correct > roll, pitch and yaw. Dragging and rotating would work the same way > as with the fast preview. The connecting lines could carry a lot of > information, width could represent quantity of control points and > colour quality. Photos that overlap without any control points need > to be joined by a faint or dotted line, so it can be clicked for > opening in the Control Points tab. A complication is that the > connecting lines need to follow the shortest 'great circle' path, > which is a curve that will exit and enter the edges of 360° > panoramas at funny angles. > > (This is also a particularly difficult panorama to break down into > rows and columns) > > -- > Bruno > > > _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_BR_life_in_synch_052009 --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
On Fri 24-Apr-2009 at 13:30 +0100, Bruno Postle wrote: > >Random thought: how about a 'layout' mode in the fast preview window >that rearranges the photos to show the structure of the project. Following through with this idea, here is a mockup showing the 'Preview' mode compared with the equivalent 'Layout' mode: http://www.flickr.com/photos/36383...@n00/3542328667/sizes/o/ http://www.flickr.com/photos/36383...@n00/3543135618/sizes/o/ Images would need to be shown undistorted, but with the correct roll, pitch and yaw. Dragging and rotating would work the same way as with the fast preview. The connecting lines could carry a lot of information, width could represent quantity of control points and colour quality. Photos that overlap without any control points need to be joined by a faint or dotted line, so it can be clicked for opening in the Control Points tab. A complication is that the connecting lines need to follow the shortest 'great circle' path, which is a curve that will exit and enter the edges of 360° panoramas at funny angles. (This is also a particularly difficult panorama to break down into rows and columns) -- 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: Layout panorama model (GSoC)
On Sat 16-May-2009 at 19:13 -0700, Tom Sharpless wrote: > >I would like this facility to be able to generate regular layouts -- >both rectangular (for long lenses) and staggered (for fisheyes) -- >from simple specs such as "5 x 8" or "6 around: 3 up 15, 3 down 15". I'm not entirely sure why this is needed, we already have a template system, so you can reuse an existing layout. Otherwise the only advantage I can see for generating the layout like this is to speed up control point generation by only matching adjacent images - but none of the control point generators work like this currently, i.e. autopano-sift-c needs to be fixed to take positions into account at the matching stage. (actually this is probably not very difficult since autopano-sift-c already uses a .pto file as input) -- 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: Layout panorama model (GSoC)
Hi I guess there will always be 2 schools of thought about pano layouts. Being an engineer, I believe you shouldn't shoot a pano until you have planned the layout, and probably written it down. Bruno belongs to the "just shoot away and let Hugin sort it out" school, which is presumably larger. It would be nice if Hugin could do that; but it would also be nice if it could accept definite specifications when they are available. So I strongly disagree with this: > I don't think you need an interface that asks "how many rows did you > shoot?", because my answer is always going to be "I can't > remember!". If you can roughly arrange a 10x5 grid with a few > 'drags' of the mouse then that is all you need. Some of us can remember. I would like this facility to be able to generate regular layouts -- both rectangular (for long lenses) and staggered (for fisheyes) -- from simple specs such as "5 x 8" or "6 around: 3 up 15, 3 down 15". And I reiterate, the layout is on a sphere, not a plane. Regards, Tom On May 13, 12:33 pm, Bruno Postle wrote: > On Tue 12-May-2009 at 23:38 +0100, James Legg wrote: > > > > >> Yes, or if you position two photos, the software can assume that the > >> intermediate photos have intermediate positions. > > >I would think it would be difficult to choose when to make this > >assumption. You don't want photos to move by themselves, as this would > >likely confuse the user. You could suggest a movement, but it may get > >either intrusive or ignored if done wrong. > > If the photos have no other positional information (i.e. not part of > a stack, no control points, not moved manually) then interpolating > the positions of intermediate photos is probably always the right > thing to do. Note that due to the wraparound topology of the canvas > you can fill any sequence either right-to-left or left-to-right, but > the photo angle of view will help decide which is the most likely > fit. > > I don't think you need an interface that asks "how many rows did you > shoot?", because my answer is always going to be "I can't > remember!". If you can roughly arrange a 10x5 grid with a few > 'drags' of the mouse then that is all you need. > > >I don't know about animating the transition between preview and layout > >mode though. That would be doable, but it might take a couple of weeks > >that could be better spent on something else. > > For sure this is just eye-candy. > > Where I'm coming from is: as control point generators improve, all > the tables and options and switches in hugin become less > interesting. The more 'tactile' the interface the better, and if > the structure of the project is presented entirely graphically then > that is a good thing because using it won't be an everyday > experience even for people who use hugin everyday. > > -- > 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: Layout panorama model (GSoC)
On Tue 12-May-2009 at 23:38 +0100, James Legg wrote: > >> Yes, or if you position two photos, the software can assume that the >> intermediate photos have intermediate positions. > >I would think it would be difficult to choose when to make this >assumption. You don't want photos to move by themselves, as this would >likely confuse the user. You could suggest a movement, but it may get >either intrusive or ignored if done wrong. If the photos have no other positional information (i.e. not part of a stack, no control points, not moved manually) then interpolating the positions of intermediate photos is probably always the right thing to do. Note that due to the wraparound topology of the canvas you can fill any sequence either right-to-left or left-to-right, but the photo angle of view will help decide which is the most likely fit. I don't think you need an interface that asks "how many rows did you shoot?", because my answer is always going to be "I can't remember!". If you can roughly arrange a 10x5 grid with a few 'drags' of the mouse then that is all you need. >I don't know about animating the transition between preview and layout >mode though. That would be doable, but it might take a couple of weeks >that could be better spent on something else. For sure this is just eye-candy. Where I'm coming from is: as control point generators improve, all the tables and options and switches in hugin become less interesting. The more 'tactile' the interface the better, and if the structure of the project is presented entirely graphically then that is a good thing because using it won't be an everyday experience even for people who use hugin everyday. -- 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: Layout panorama model (GSoC)
Hi James, Just a quick note below: James Legg wrote: > It probably wouldn't take too long to combine this with the OpenGL > preview, and might even be less work than putting it in its own tab. Sounds good! > I don't know about animating the transition between preview and layout > mode though. That would be doable, but it might take a couple of weeks > that could be better spent on something else. I guess the simplest and hopefully useable method could be to temporarily use a smaller field of view for each image in the layout view. Stacks could probably shown by shifting their yaw and pitch values a little. ciao Pablo --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
On Tue, 2009-05-12 at 22:16 +0100, Bruno Postle wrote: > I think that in the case where the photographer has to fiddle with > settings on their camera between shots, then they probably need to > fiddle with their stitching software too - i.e you can't auto-detect > this stuff. Fair enough. > >If the images are ordered such that there are large adjacent sets > >partitioning the input images with the same exposure, it is likely that > >the user would like each set stitched into a panorama and then the > >resulting panoramas enfused / merged together. > > Probably yes, but you would only do a panorama this way if your > camera didn't have a bracketing mode. Mine does automatic bracketing, but I can't use automatic exposure bracketing in manual mode (well, not with the official firmware). So if I want equal exposure sets I might do this instead of fiddling with the exposure setting between every shot. Auto exposure and the maximum bracket step (+/-2ev) gets a fairly good range usually, but not always. > >It is, however, likely that each row was shot together either left to > >right or right to left. The user could mark the breaks in the rows and > >then specify if the row was shot right to left, or left to right. This > >would generally be quicker than dragging each image individually. > > Yes, or if you position two photos, the software can assume that the > intermediate photos have intermediate positions. I would think it would be difficult to choose when to make this assumption. You don't want photos to move by themselves, as this would likely confuse the user. You could suggest a movement, but it may get either intrusive or ignored if done wrong. > >Perhaps I could show the sequence of images (or image stacks if using > >bracketing), then the user would select the positions between images in > >different rows to split them up. Each row can be dragged by a row handle > >at the edge of the screen (to reorder the rows). Each row should also > >have button to flip the order of the images in that row. > > ..or allow selecting multiple photos (with window selection, and/or > Shift/Ctrl click) and allowing these to be dragged as a group or > 'flipped'. I don't think it makes sense to drag, or flip the order of, arbitrary selections, but perhaps a limited rectangle select could be used. > > >This could either be done mostly with OpenGL and share image textures > >with the fast preview, or done using only wxWidgets and the small image > >cache. > > I'd prefer to see it as part of the OpenGL preview, but you need to > decide what is achievable in the time you have available. > This isn't really a 'preview' type function, but I guess the preview is more than just preview already, and people would like it to become more of a hub for the whole process than a preview. It probably wouldn't take too long to combine this with the OpenGL preview, and might even be less work than putting it in its own tab. I don't know about animating the transition between preview and layout mode though. That would be doable, but it might take a couple of weeks that could be better spent on something else. James --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
On Tue 12-May-2009 at 20:38 +0100, James Legg wrote: > >This should cater for most camera's auto exposure bracketing, but won't >help if you bracket differently for each direction, depending on its >dynamic range. I think that in the case where the photographer has to fiddle with settings on their camera between shots, then they probably need to fiddle with their stitching software too - i.e you can't auto-detect this stuff. >If the images are ordered such that there are large adjacent sets >partitioning the input images with the same exposure, it is likely that >the user would like each set stitched into a panorama and then the >resulting panoramas enfused / merged together. Probably yes, but you would only do a panorama this way if your camera didn't have a bracketing mode. >I'm sure it is most likely that the length of the rows are different. >I don't have a massively wide angle lens, so I personally do 3 rows of >14 near the middle, 2 rows of 7 near the poles and 2 'rows' of 1 for the >poles themselves. An extreme example is Matthias Taugwalder's mountain-top gigapixel panoramas - These have something like ten rows, each row with a different number of shots. >It is, however, likely that each row was shot together either left to >right or right to left. The user could mark the breaks in the rows and >then specify if the row was shot right to left, or left to right. This >would generally be quicker than dragging each image individually. Yes, or if you position two photos, the software can assume that the intermediate photos have intermediate positions. Another example of a layout is the 'gigapanbot' this shoots backwards and forwards (to avoid wasting time returning to the start), it also shoots in columns for panoramas that are wider than tall (to reduce the maximum time interval between overlapping photos). >Perhaps I could show the sequence of images (or image stacks if using >bracketing), then the user would select the positions between images in >different rows to split them up. Each row can be dragged by a row handle >at the edge of the screen (to reorder the rows). Each row should also >have button to flip the order of the images in that row. ..or allow selecting multiple photos (with window selection, and/or Shift/Ctrl click) and allowing these to be dragged as a group or 'flipped'. >This could either be done mostly with OpenGL and share image textures >with the fast preview, or done using only wxWidgets and the small image >cache. I'd prefer to see it as part of the OpenGL preview, but you need to decide what is achievable in the time you have available. -- 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: Layout panorama model (GSoC)
On Tue, 2009-05-12 at 19:20 +0100, Bruno Postle wrote: > Hi James, some thoughts on using EXIF data to structure panorama > projects based on touching this stuff with panostart/match-n-shift: > > Identifying panoramas from timestamps. This isn't relevant to your > project, but it is actually quite practical to divide a folder full > of photos into separate panoramas by looking at timestamps. I found > that just setting a threshold (e.g intervals between photos of less > than 30 seconds indicate a single panorama) isn't very effective. > However the difference between intervals is a very good indicator, > individual photos in panoramas tend to be taken at a constant rate. > > Identifying stacks within a panorama. match-n-shift counts all the > different shutter speeds in the set and if the total number of > photos is divisible by this number then it assumes a camera on > bracketing 'mode' (e.g three different exposures, next position, > three different exposures, etc...). > > You could refine this by an additional check that the order of > exposures repeats itself (e.g 1/100, 1/400, 1/25, 1/100, 1/400, > 1/25, ...) this is then certain to be a bracketed set. > > Where this doesn't work is that you simply can't tell the difference > between a single bracket sequence or a camera on auto-exposure - > i.e. the software has to ask the user or try and align the photos. You could probably make a good guess using relative exposures. If the images can be grouped into equal sets consisting of a base exposure, and some equal pattern based on it, then there is mostly likely automatic exposure bracketing. The patterns could be increasing by a constant EV, decreasing by a constant EV, or oscillating between increasing and decreasing the EV. Perhaps some near misses might happen due to rounding in the camera or clamping to the range of exposure times the camera supports. I could evaluate some error term from several different bracketing schemes, pick the best one if it is a close enough match, and if it isn't, assume there is no bracketing. This should cater for most camera's auto exposure bracketing, but won't help if you bracket differently for each direction, depending on its dynamic range. If the images are ordered such that there are large adjacent sets partitioning the input images with the same exposure, it is likely that the user would like each set stitched into a panorama and then the resulting panoramas enfused / merged together. Focus bracketing can also be detected automatically in a very similar way. > Identifying rows/columns in a panorama. I don't know how you do > this, obviously a perfect rectangular grid can't have a prime number > of photos, but with handheld panoramas people don't count and are > likely to have different numbers of photos in each row. For > spherical panoramas, people do stuff like two rows of six, one up > and one down - I think you need to show the user all the photos and > let them drag and drop until everything is arranged. I'm sure it is most likely that the length of the rows are different. I don't have a massively wide angle lens, so I personally do 3 rows of 14 near the middle, 2 rows of 7 near the poles and 2 'rows' of 1 for the poles themselves. It is, however, likely that each row was shot together either left to right or right to left. The user could mark the breaks in the rows and then specify if the row was shot right to left, or left to right. This would generally be quicker than dragging each image individually. Perhaps I could show the sequence of images (or image stacks if using bracketing), then the user would select the positions between images in different rows to split them up. Each row can be dragged by a row handle at the edge of the screen (to reorder the rows). Each row should also have button to flip the order of the images in that row. Individual image stacks can be dragged (if shot out of order). Clicking on an image stack will show settings specific to that image stack and its row, and let you move the images in the stack independently. If the panorama was shot entirely at one exposure and then again at another, this interface should show one bracket at time, with the option to link the images into stacks if they align very well, or at least copy the layout of one exposure into another if they have the same number of images. This could either be done mostly with OpenGL and share image textures with the fast preview, or done using only wxWidgets and the small image cache. James --~--~-~--~~~---~--~~ 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, vis
[hugin-ptx] Re: Layout panorama model (GSoC)
On Thu 23-Apr-2009 at 15:48 +0100, James Legg wrote: > >Some feature ideas: > * If the layout was entered manually: > * The layout will provide an initial guess for the image >positions. > * You can do automatic control point generation on just >the image pairs that should overlap significantly, >rather than look at all possible combinations. This >could take less time if the feature detection can be >done separately to feature matching, as well as >providing less wrong control points. Hi James, some thoughts on using EXIF data to structure panorama projects based on touching this stuff with panostart/match-n-shift: Identifying panoramas from timestamps. This isn't relevant to your project, but it is actually quite practical to divide a folder full of photos into separate panoramas by looking at timestamps. I found that just setting a threshold (e.g intervals between photos of less than 30 seconds indicate a single panorama) isn't very effective. However the difference between intervals is a very good indicator, individual photos in panoramas tend to be taken at a constant rate. Identifying stacks within a panorama. match-n-shift counts all the different shutter speeds in the set and if the total number of photos is divisible by this number then it assumes a camera on bracketing 'mode' (e.g three different exposures, next position, three different exposures, etc...). You could refine this by an additional check that the order of exposures repeats itself (e.g 1/100, 1/400, 1/25, 1/100, 1/400, 1/25, ...) this is then certain to be a bracketed set. Where this doesn't work is that you simply can't tell the difference between a single bracket sequence or a camera on auto-exposure - i.e. the software has to ask the user or try and align the photos. Identifying rows/columns in a panorama. I don't know how you do this, obviously a perfect rectangular grid can't have a prime number of photos, but with handheld panoramas people don't count and are likely to have different numbers of photos in each row. For spherical panoramas, people do stuff like two rows of six, one up and one down - I think you need to show the user all the photos and let them drag and drop until everything is arranged. -- 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: Layout panorama model (GSoC)
Bravo, James! This is something obviously useful that for some reason none of the stitchers I use provides. I think the most important target is focusing control point finding on areas of actual overlap -- that should not only eliminate the stupid impossible CPs we sometimes get, but more important, should dramatically cut CP generation time for every pano, and probably improve CP quality too. I concur with Bruno that the layout model should be explicitly spherical, and accommodate the various clever schemes panographers use to cover the sphere (e.g. with an 8mm fisheye, "up 15 deg, 3 around; turn 60 deg; down 15 deg, 3 around; down 90 deg, 1" ). Some people rotate the camera to put a corner of the frame near the pole, so you need to cater for the full Y,P,R coordinates, too. Of course there is no need to burden long-lens users with all that, to them it can just look like a rectangular array :->. Regards, Tom On Apr 26, 10:20 pm, James Legg wrote: > On Sun, 2009-04-26 at 15:43 -0500, Gerry Patterson wrote: > > > On Thu, Apr 23, 2009 at 9:02 PM, Gerry Patterson > > wrote: > > > On Thu, Apr 23, 2009 at 6:05 PM, James Legg > > wrote: > > > Ideas are what I need at the moment. Perhaps when this > > thread has more > > responses you could summarise the ideas on the wiki? > > That would be > > helpful. :-) > > > I can try. It would probably be a good idea to get a page > > started or appended soon. I'll have to check about getting an > > account on the wiki. > > > - Gerry > > > Excuse my ignorance. Which wiki are we taking about here? I hunted > > around on wiki.panotools.org and couldn't find your proposal there. Is > > there another one? > > > I was going to start grabbing some of the ideas and putting them up > > there. > > > - Gerry > > Sorry, all my project proposals for this year are on my userpage, and > the one that got accepted was not the main focus of the > page:http://wiki.panotools.org/User:James_Legg > > I've made a new page that does what you were > expecting:http://wiki.panotools.org/SoC_2009_project_Layout_Model > > Thanks for your time! > > James --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
On Sun, 2009-04-26 at 15:43 -0500, Gerry Patterson wrote: > > > On Thu, Apr 23, 2009 at 9:02 PM, Gerry Patterson > wrote: > > > On Thu, Apr 23, 2009 at 6:05 PM, James Legg > wrote: > > > Ideas are what I need at the moment. Perhaps when this > thread has more > responses you could summarise the ideas on the wiki? > That would be > helpful. :-) > > > I can try. It would probably be a good idea to get a page > started or appended soon. I'll have to check about getting an > account on the wiki. > > > - Gerry > > Excuse my ignorance. Which wiki are we taking about here? I hunted > around on wiki.panotools.org and couldn't find your proposal there. Is > there another one? > > I was going to start grabbing some of the ideas and putting them up > there. > > - Gerry Sorry, all my project proposals for this year are on my userpage, and the one that got accepted was not the main focus of the page: http://wiki.panotools.org/User:James_Legg I've made a new page that does what you were expecting: http://wiki.panotools.org/SoC_2009_project_Layout_Model Thanks for your time! James --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
On Sun 26-Apr-2009 at 15:28 -0500, Gerry Patterson wrote: > > As of rev 3805, Hugin will now compute the errors for the control > points on project load. I placed this in a separate function that > can be called in other places as well (say when ever an image is > moved or a CP is modified). Great, it seems to work here. -- 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: Layout panorama model (GSoC)
On Thu, Apr 23, 2009 at 9:02 PM, Gerry Patterson wrote: > > > On Thu, Apr 23, 2009 at 6:05 PM, James Legg wrote: > >> >> Ideas are what I need at the moment. Perhaps when this thread has more >> responses you could summarise the ideas on the wiki? That would be >> helpful. :-) >> >> > I can try. It would probably be a good idea to get a page started or > appended soon. I'll have to check about getting an account on the wiki. > > > - Gerry > Excuse my ignorance. Which wiki are we taking about here? I hunted around on wiki.panotools.org and couldn't find your proposal there. Is there another one? I was going to start grabbing some of the ideas and putting them up there. - Gerry --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
On Thu, Apr 23, 2009 at 6:21 PM, Bruno Postle wrote: > > Note that hugin shows an 'error distance' for each control point, > this is actually supplied by the optimiser at the end of each > optimiser run (which is why all these fields are zeroed when you > reload a project). > > This is overdue for fixing, these distances could be calculated > on-demand by hugin. Also, any tool as you are suggesting that tries > to evaluate control points will need to do this calculation, as the > optimisation process is too slow for interactive use. > > I always thought that was weird. As of rev 3805, Hugin will now compute the errors for the control points on project load. I placed this in a separate function that can be called in other places as well (say when ever an image is moved or a CP is modified). Right now, it computes the errors for all of the control points. I am guessing this could be enhanced to only update particular CPs that would have changed. - Gerry --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
> * There can be brackets without stacks. For example, if shooting > by hand, you could take a row of pictures at one exposure, > change the exposure time and go back in the opposite direction. > It is unlikely that you can make stacks of the two different > exposures in this case. Therefore, instead of combining stacks > into a high dynamic range image and blending the stacks, it > would be suggested to blend the all images in each bracket > first, then combine the brackets to make the hdr image. Nice idea. I've done something similar by hand. Could you also consider a tolerance for the different brackets? This would help for the following method, which I used several times. Procedure: (mostly when there was a bright sky, but landscape rather dark) Shooting picture by hand, portrait mode, automatic exposure: first row - landscape, horizont at top border, second row - sky, horizont at bottom border Add all pictures to one project, optimize positions and exposure First stitch bottom row with one exposure setting, then second row with an other exposure setting. Finally enfuse both rows to final panorama. Pro: * wider _vertical_ field of view * good exposure in landscape and sky * less pictures are needed as when I would shoot 2 or more exposures for every position (picture count would be two or three times higher in this case) Contra: * doesn't work good with big trees over horizont (ghost removal for enfuse would help in this case, sometimes enblend instead of enfuse did a good job) Thomas --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
Oskar Sander wrote: > > If lines are used to visualize connections of control points, width and > colour could be used to show what connects that have many or few > control points (width), and where there are control points that have a > bad fit (e.g. red or green) > > With the correct positions, it would also be obvious if there is > connection where there shouldn't be any at all, the line would cross the > graph in an awkward way. Very nice thoughts. BugBear --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
2009/4/24 Bruno Postle > > > Photos would be iconised with inter-connections shown as lines, > similar to the undirected graph tests but with the correct relative > positions as in Roger Wolff's ptomap test. Stacks can be shown as a > 'cascade' of images on top of each other. Unconnected photos can be > dragged to the correct relative position and this information used > to interpolate their 'true' scene location or drive control-point > generation. > > If changing between modes would animate between the 'normal' view > and this 'layout' view then it would be fun and informative too. > > If lines are used to visualize connections of control points, width and colour could be used to show what connects that have many or few control points (width), and where there are control points that have a bad fit (e.g. red or green) With the correct positions, it would also be obvious if there is connection where there shouldn't be any at all, the line would cross the graph in an awkward way. -- /O --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
On Fri 24-Apr-2009 at 00:05 +0100, James Legg wrote: > >It is likely that each type of model has a most ideal stitch / fuse >order, so perhaps it doesn't make sense to present the choices on the >stitcher tab. > >I was planning a layout tab, for describing the set of pictures taken; Random thought: how about a 'layout' mode in the fast preview window that rearranges the photos to show the structure of the project. Photos would be iconised with inter-connections shown as lines, similar to the undirected graph tests but with the correct relative positions as in Roger Wolff's ptomap test. Stacks can be shown as a 'cascade' of images on top of each other. Unconnected photos can be dragged to the correct relative position and this information used to interpolate their 'true' scene location or drive control-point generation. If changing between modes would animate between the 'normal' view and this 'layout' view then it would be fun and informative too. -- 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: Layout panorama model (GSoC)
On Thu, Apr 23, 2009 at 6:05 PM, James Legg wrote: > > On Thu, 2009-04-23 at 11:33 -0500, Gerry Patterson wrote: > > > Would it make sense to be allow control of the blending and fusing > > order for the output. When I was looking at this earlier, there were > > two areas that needed to know about the model you are discussing: > > optimization, and then later, output.Although, perhaps it only > > makes sense to have one order to stitch and then fuse for each type of > > model. I haven't come up with enough use cases. I guess I am asking > > if you are planning changes to the stitcher tab as well. > > I do plan to change the output options on the stitcher tab, and makefile > generation. > > It is likely that each type of model has a most ideal stitch / fuse > order, so perhaps it doesn't make sense to present the choices on the > stitcher tab. > > I was planning a layout tab, for describing the set of pictures taken; > and the stitcher tab is for picking what pictures are wanted. Perhaps > only the plausible options will be shown on the stitcher tab, depending > on what was is specified in the layout tab. There would still be choice > as to what immediate files to keep and, if using exposure stacks, should > we blend them with enfuse or merge them to make an HDR image. > > I remember complaints when the blended panorama option greyed out when > stacks were detected, as it would often trigger on LDR panos with large > overlaps. The user response might be different if there is a way to say > "I don't have stacks!". > Yes, I remember that well. It was I that added that "feature" in response to users stacking images on top of each other and then calling for a blended panorama output. Enblend would fail with two images stacked on top of each other causing the rest of the stitch to fail. Bruno, Pablo and I discussed this and thought it would be a good idea to restrict the output options if stacks were detected. Unfortunately, we didn't consider enough use cases. So the feature was disabled. > > Perhaps we could allow the user to set up their own processing chain if > they want? The user could specify targets with the following bits of > information: > 1. Which command to run, with command line arguments, substituting >%o for output file, and %i for input files. > 2. What input type the command takes (images, remapped images, hdr >images, the project file, ...) > 3. How to partition that input type into a subset for each run (run >once with every image, once for each stack, once for each >row, ...) > 4. What to call the output file(s), substituting %n for a number if >using subsets. > 5. What to call the type of output in the GUI, so a different >target can use one in step 2. > Several of these can be set up, and used to write the makefile. The > default targets could also be internally represented in this way, but > only shown to the user when making non-standard processing chains. I had a mind map (http://freemind.sourceforge.net/wiki/index.php/Main_Page) that I had e-mailed to Yuval which described output chains with respect to bracketed exposures. It was an idea I had months ago, but never got around to testing out. I'll e-mail to you if you would like to look at it. > Ideas are what I need at the moment. Perhaps when this thread has more > responses you could summarise the ideas on the wiki? That would be > helpful. :-) > > I can try. It would probably be a good idea to get a page started or appended soon. I'll have to check about getting an account on the wiki. - Gerry --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
On Thu 23-Apr-2009 at 15:48 +0100, James Legg wrote: >The layout model can be either entered manually, or automatically >guessed after an initial alignment. The model describes the number of >images per stack, the number of stacks in each row, the total field of >view covered by each row, the direction you rotated between the shots, >and which images are exceptions to this. There should be enough >information to determine stacks of images, brackets of images with >similar settings, and which images / stacks should have a significant >overlap. Ok, bear in mind that although shooting in rows is very common, there are good reasons for not having columns. For spherical panoramas it makes sense to have different numbers of photos in each row. >Some feature ideas: > * If the layout was entered manually: > * The layout will provide an initial guess for the image >positions. > * You can do automatic control point generation on just >the image pairs that should overlap significantly, >rather than look at all possible combinations. This >could take less time if the feature detection can be >done separately to feature matching, as well as >providing less wrong control points. > * The optimiser can optionally link stacks together, useful for >when the tripod is so stable that the image positions will be >identical. I seem to remember the panotools optimiser supports linking positions internally, but after testing with autooptimiser it doesn't seem that the hugin optimiser does. This will need fixing. > * In a panorama composed from multiple brackets, you can filter >the images used in the previews, so that only one bracket shows. It will speed things up at least. > * Some extensions to control point editing: > * Control points between images which should not overlap >according to the model will be easily found. Note that hugin shows an 'error distance' for each control point, this is actually supplied by the optimiser at the end of each optimiser run (which is why all these fields are zeroed when you reload a project). This is overdue for fixing, these distances could be calculated on-demand by hugin. Also, any tool as you are suggesting that tries to evaluate control points will need to do this calculation, as the optimisation process is too slow for interactive use. > * Image pairs which have some relation to each other can >be identified depending on how much they need manual >work with control points. For example, in an exposure >bracketed panorama, it will be acceptable to have a well >connected bracket, and each stack well connected. >However, if the top row of a 360 degree panorama is >connected with a single control point, you will be asked >to put more control points connecting that row with the >one bellow it (with most priority opposite the image >pair in with the control point). > * Information from alignment can refine the model, and even place >images with no control points (very poorly exposed brackets, or >images containing only sky for example) in a "best guess" >position. > * The model will be used to suggest different ways of stitching >the panorama. For example if there are exposure brackets, HDR >and exposure blending with enfuse will be suggested. With no >bracketing, blending the images with enblend will be suggested. >If there are focus brackets, focus blending with enfuse will be >suggested. Currently this detection already happens in a crude way: any images that have yaw/pitch with a variation less than 10% of the hfov are considered to be part of a 'stack'. I've never actually seen this fail, but it clearly has limitations. Some time before 0.7.0 was released, hugin automatically disabled/enabled enfuse depending on whether stacks were detected, but this feature was removed because it confused users who didn't realise when they had two completely overlapping images. > * There can be brackets without stacks. For example, if shooting >by hand, you could take a row of pictures at one exposure, >change the exposure time and go back in the opposite direction. >It is unlikely that you can make stacks of the two different >exposures in this case. Therefore, instead of combining stacks >into a high dynamic range image and blending the stacks, it >would be suggested to blend the all images in each bracket >first, then combine the brackets to make the hdr image. This would be useful as a feature, obviously there are two ways of doing it: fuse stacks then blend, or blend then fuse. Th
[hugin-ptx] Re: Layout panorama model (GSoC)
On Thu, 2009-04-23 at 11:33 -0500, Gerry Patterson wrote: > Would it make sense to be allow control of the blending and fusing > order for the output. When I was looking at this earlier, there were > two areas that needed to know about the model you are discussing: > optimization, and then later, output.Although, perhaps it only > makes sense to have one order to stitch and then fuse for each type of > model. I haven't come up with enough use cases. I guess I am asking > if you are planning changes to the stitcher tab as well. I do plan to change the output options on the stitcher tab, and makefile generation. It is likely that each type of model has a most ideal stitch / fuse order, so perhaps it doesn't make sense to present the choices on the stitcher tab. I was planning a layout tab, for describing the set of pictures taken; and the stitcher tab is for picking what pictures are wanted. Perhaps only the plausible options will be shown on the stitcher tab, depending on what was is specified in the layout tab. There would still be choice as to what immediate files to keep and, if using exposure stacks, should we blend them with enfuse or merge them to make an HDR image. I remember complaints when the blended panorama option greyed out when stacks were detected, as it would often trigger on LDR panos with large overlaps. The user response might be different if there is a way to say "I don't have stacks!". Perhaps we could allow the user to set up their own processing chain if they want? The user could specify targets with the following bits of information: 1. Which command to run, with command line arguments, substituting %o for output file, and %i for input files. 2. What input type the command takes (images, remapped images, hdr images, the project file, ...) 3. How to partition that input type into a subset for each run (run once with every image, once for each stack, once for each row, ...) 4. What to call the output file(s), substituting %n for a number if using subsets. 5. What to call the type of output in the GUI, so a different target can use one in step 2. Several of these can be set up, and used to write the makefile. The default targets could also be internally represented in this way, but only shown to the user when making non-standard processing chains. James > > I look forward to this feature and would be happy to help in anyway I > can, (testing, debugging, ideas...) Ideas are what I need at the moment. Perhaps when this thread has more responses you could summarise the ideas on the wiki? That would be helpful. :-) > > Best of luck! > - Gerry James --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
2009/4/23 James Legg The layout model can be either entered manually, or automatically > guessed after an initial alignment. The model describes the number of > images per stack, the number of stacks in each row, the total field of > view covered by each row, the direction you rotated between the shots, > and which images are exceptions to this. There should be enough > information to determine stacks of images, brackets of images with > similar settings, and which images / stacks should have a significant > overlap. Great! This should be very useful for my photomosaics. Note that it may not always be even rows > Some feature ideas: > * If the layout was entered manually: > * The layout will provide an initial guess for the image >positions. > * You can do automatic control point generation on just >the image pairs that should overlap significantly, >rather than look at all possible combinations. This >could take less time if the feature detection can be >done separately to feature matching, as well as >providing less wrong control points. That would be good. I have a sample project with 3 lines of about 160-170 photos each. At first hugins current limitation of maximum photos hits., but even with a shrunk set of images, false controll points are found, and they are anoying to find. I've been discussing ways to visualize the layout and controll point connections elsewhere here in the forum. I think your project will solve that. > * Some extensions to control point editing: > * Control points between images which should not overlap >according to the model will be easily found. > * Image pairs which have some relation to each other can >be identified depending on how much they need manual >work with control points. For example, in an exposure >bracketed panorama, it will be acceptable to have a well >connected bracket, and each stack well connected. >However, if the top row of a 360 degree panorama is >connected with a single control point, you will be asked >to put more control points connecting that row with the >one bellow it (with most priority opposite the image >pair in with the control point). And to find unreasonable controll points... > > * Information from alignment can refine the model, and even place >images with no control points (very poorly exposed brackets, or >images containing only sky for example) in a "best guess" >position. I would *really *love a tiny little extension where the alignment is used to provide initial d & e values for optimization for photomosaics (once Dev Gosh finishes his new model, this can be camera X & Y coordinates) /O --~--~-~--~~~---~--~~ 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: Layout panorama model (GSoC)
Hello James, On Thu, Apr 23, 2009 at 9:48 AM, James Legg wrote: > > Hello, > > > * In a panorama composed from multiple brackets, you can filter >the images used in the previews, so that only one bracket shows. This is a good idea! > > * The model will be used to suggest different ways of stitching >the panorama. For example if there are exposure brackets, HDR >and exposure blending with enfuse will be suggested. With no >bracketing, blending the images with enblend will be suggested. >If there are focus brackets, focus blending with enfuse will be >suggested. Would it make sense to be allow control of the blending and fusing order for the output. When I was looking at this earlier, there were two areas that needed to know about the model you are discussing: optimization, and then later, output.Although, perhaps it only makes sense to have one order to stitch and then fuse for each type of model. I haven't come up with enough use cases. I guess I am asking if you are planning changes to the stitcher tab as well. I look forward to this feature and would be happy to help in anyway I can, (testing, debugging, ideas...) Best of luck! - Gerry --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
