Overlap Minimizer  

Got some great idea or a feature request? Post it here and discuss it. The most requested concepts are usually implemented, as Autopano Pro / Giga is very community driven.
no avatar
hankkarl
Member
 
Topic author
Posts: 1284
Likes: 0 post
Liked in: 0 post
Joined: Tue Feb 21, 2006 5:32 pm
Location: Connecticut, USA
Info

Overlap Minimizer

by hankkarl » Wed Jan 19, 2011 4:10 pm

How about adding a feature that minimizes overlapping regions? I envision that it would work this way:

After a normal detection, the minimizer could be invoked automatically (but only if RMS is less than a configurable number and there is no link significantly longer than the average link) or manually from the CP editor.

The minimizer would examine the links on each image, and remove all the links except the shortest in each direction.
- "direction" may have to be configurable: 4-directions (north, south, east, west), or diagonal 4-directions (northeast, southeast...) or 8-direcitons (north, northeast, ....)

The minimizer would then work on image pairs, and find the center of each overlap. All CPs would be deleted, and new CPs found within some given distance from the center of each overlap. Then the pano would be re-optimized.
- Each image would have three areas--the area containing the centermost pixel, the overlap region, and the area outside the overlap region that does not contain the centermost pixel of the image. Call these regions "inside" "overlap" and "outside". The outside region could optionally be thrown away when rendering.

this may help insure that straight lines actually line up between images.

User avatar
gkaefer
Member
 
Posts: 3549
Likes: 0 post
Liked in: 15 posts
Joined: Tue Jun 09, 2009 1:01 pm
Location: Salzburg
Info

by gkaefer » Wed Jan 19, 2011 8:01 pm

I just wonder for what this feature would be good for?
I only imagine a case where in planning phase of the pano a too big overlap was estimated...

the overlap of an image set for a pano is in general always equal (where a panohead was used). So why not realizing such a feature more simpler: crop x pixels of each image on left and right side any y pixel on top and bottom side of image and than doing the detection?

Georg

no avatar
GURL
Member
 
Posts: 2943
Likes: 0 post
Liked in: 0 post
Joined: Tue Dec 06, 2005 1:57 pm
Location: Grenoble
Info

by GURL » Wed Jan 19, 2011 8:57 pm

Two different situations occur:
- every row in the panorama includes the same number of images (rectangular panoramas)
- spherical panoramas where a larger amount of source images is needed next to the horizon while a single image is often enough for the zenith and a small number of them for the intermediate row(s) if some are needed.

In rectangular panos the overlap should not vary, especially when a click pano-head is used.

On the contrary for spherical panos the overlap varies widely: it can be low next to the horizon but it's often impossible to avoid large ovelapping areas next to the zenith (and nadir if the nadir is included.)

Having too many long links (corner to corner links) an too many control points being located in the top part or bottom part of the sphere is a common cause of problems for spherical panos and a total nightmare when bracketing is used for these and links are allowed between images of any exposure levels. New Detection options Detect links in one stack level and For a stack use hard links help a lot to avoid having to manually delete most links after the first detection!

As far as I understand it, the rendering options Remove ghosts and Remove HDR ghosts would interfere with hankkarl's proposal of 3 areas "inside" "overlap" and "outside" but I agree with him that being able to easily locate long links and being able to delete them would often help when the optimization of a spherical pano failed (when too much links exist the global RMS is often good or very good while the RMS of some links is not good enough and broken lines are visible...)

For a stack detect control points option used for bracketed panos seems to cause too much link being devoted to link the different exposures in each of the stacks while Detect links in one stack level option causes a much lower number of links between stacks being established...

In a few words: many different situations can arise depending of the panorama category (rectangular/spherical, single exposure/bracketed exposures, regular spacing/manual spacing, etc.) I doubt a one-fit-all solution being possible...
Georges

User avatar
gkaefer
Member
 
Posts: 3549
Likes: 0 post
Liked in: 15 posts
Joined: Tue Jun 09, 2009 1:01 pm
Location: Salzburg
Info

by gkaefer » Wed Jan 19, 2011 11:35 pm

Hi Georges,

ok I see.
following is only applicable for motorized/logging panoheads, not for klickstop panohead solutions:

Wouldnt it better to avoid getting a general 20% or 25% overlap for all images and running into troubles while stitching depending on the sort of shooting/pano you're working on.
Instead trying to correct the inproper overlap with autopano it would be better to adopt e.g. papywizzard so that user has option to choose like sperical/rectangular/bracketing etc. and depending on this setting the according optimal overlap and image matrix is choosen?

Liebe Gruesse,
Georg

User avatar
klausesser
Member
 
Posts: 8836
Likes: 5 posts
Liked in: 64 posts
Joined: Mon May 22, 2006 12:18 am
Location: Duesseldorf, Germany
Info

by klausesser » Thu Jan 20, 2011 12:20 am

A way to handle that might be to run a spherical pano with a motorized head like Merlin and read it´s xml to use the positions/angles to set a manual head.
The problem is to touch the manual head when changing the clickstops between upper/mid/lower rows.

The T&C controller calculates the steps related to the focal-length and the overlap setting - it can export a file which can be usewd to setup a manual head.

Upper and lower rows have lesser images than middle rows automatically calculated when using the T&C - PapyWizard needs to be given a pre-edited xml file.

best, Klaus
Last edited by klausesser on Thu Jan 20, 2011 12:21 am, edited 1 time in total.
Simplicity is the keynote of all true elegance. Coco Chanel

no avatar
hankkarl
Member
 
Topic author
Posts: 1284
Likes: 0 post
Liked in: 0 post
Joined: Tue Feb 21, 2006 5:32 pm
Location: Connecticut, USA
Info

by hankkarl » Thu Jan 20, 2011 12:35 am

Hi Georg,
I do shoot with too much overlap, but I can only go down to about a 30% overlap. The issue I'm facing is that this is using a 12mm rectilinear lens. So I've got lots of distortion and a high overlap. But this solution should help people with smaller overlaps.

What I hope to do is to have APP "lens correct" the image so that only pixels in the narrow band near the seam will be used for CPs. I hope that this means that the image is corrected so that power lines, railroad tracks, trees, fence posts, etc line up better.

If you were using cut and paste (scissors and a tube of glue, not PS) you'd probably line up pictures by matching items on the edges, not by matching the middles (or you'd line up the edge of one image to the middle of the other if you didn't want to cut the one on the bottom, but that's still matching the edges of the visible areas.) This algorithm may help APP give us a better stitch.

User avatar
klausesser
Member
 
Posts: 8836
Likes: 5 posts
Liked in: 64 posts
Joined: Mon May 22, 2006 12:18 am
Location: Duesseldorf, Germany
Info

by klausesser » Thu Jan 20, 2011 1:33 am

Hello Hank!

Did you try "multiple viewpoints"?

best, Klaus
Simplicity is the keynote of all true elegance. Coco Chanel

no avatar
hankkarl
Member
 
Topic author
Posts: 1284
Likes: 0 post
Liked in: 0 post
Joined: Tue Feb 21, 2006 5:32 pm
Location: Connecticut, USA
Info

by hankkarl » Sun Jan 23, 2011 6:24 am

Multiple viewpoints sometimes helps if I shot handheld. I suspect that my lens, and other very wide lenses, may have some of the same issues an 8mm has with center of the optical elements vs center of the sensor. And very wide rectilinear lenses intentionally distort the image to make vertical and horizontal lines straight.

changing the Ransac model to Homography helps for stitching.

But what I think this suggestion will accomplish is to better line up features where the images match up. For example a power line (or curb, building edge, etc) will not have a break from one edge of a picture to another (it may bend, but the edges will match)


Who is online

Users browsing this forum: No registered users and 2 guests