Auto Fit problems with various projections  

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
ssprengel
Member
 
Topic author
Posts: 34
Likes: 0 post
Liked in: 0 post
Joined: Fri Sep 01, 2006 3:20 pm
Location: Nebraska, USA
Info

Auto Fit problems with various projections

by ssprengel » Fri Dec 01, 2006 7:34 am

Judging by the four outward pointing red errors on the Auto Fit button and how it works most of the time, Auto Fit should show the full extent of the panorama, but it does not and the only way to see the full extent of some panos, especially Planar projection is to use the [Auto] Crop button to the right of Auto Fit and then drag it wider than the extents of the images, but by hand is the only way, usually, with Planar.

In the following composite series of images it is easy to see the problems with a Planar projected panorama, even when rotated 90-degrees the new top and bottom are chopped off quite a bit, but even with a spherical projection it appears there is perhaps one row of pixels missing along the bottom and an extra blank row at the top, no matter what resolution 800x400 up to 3200x1600, there is one blank row...which turns into one BLACK row if rendered at 100% as a JPG--this was the topic of another thread.

If I switch to cylindrical projection (not shown) there are two rows of blank pixels at the top--cylindrical is usually a little taller than spherical for the same width so this makes sense if the error is scaled up a bit, but what doesn't make sense is that things are off at all.

I would expect Auto Fit to show the entire extent of the panorama even if it's highly distorted and certainly it should work with a simple planar projection but is does not. Am I expecting too much or does something need changed to make it work more precisely?

The captions of the images in the series, from top to bottom are:

1) Auto Fit of planar projection is severely truncated at the top and bottom.
2) Auto Fit spherical projection looks ok, except there is no bulge along the bottom left.
3) Auto Fit spherical projection magnified to 800% showing one blank row of pixels.
4) Crop box expanded beyond Auto Fit shows a slight bulge at the bottom left which suggests the Auto Fit may have truncated one row of pixels off the bottom just as it added one along the top.
5) Auto Fit of 90-degree rotation of original planar projection is severely truncated along the new top and bottom.
6) Manually expanded crop box...
7) ...when applied, shows full extent of planar projection more like it should have done with Auto Fit.

[I had to downsize the uploaded image to make it fit within the upload limits so the screen captures are slightly blurry]


Last edited by ssprengel on Fri Dec 01, 2006 7:47 am, edited 1 time in total.

User avatar
AlexandreJ
Kolor Team
 
Posts: 5988
Likes: 7 posts
Liked in: 10 posts
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France
Info

by AlexandreJ » Fri Dec 01, 2006 10:12 am

I'm aware of this limitation.

To find the bigger enclosed area within a general polygon is a NP-complete algorithm (for definition : NP-Complete).
The result is that finding the real solution is hard really hard.
So I designed a novel algorithm to find an approximate solution and this solution is not always the right one. In planar for example, it ignores the hole that can arise in the middle top edge or middle bottom edge. In fact, it works good with convex polygons but less good with concave.

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 » Fri Dec 01, 2006 11:33 am

AlexandreJ wrote:The result is that finding the real solution is hard, really hard.

I'm not certain we actually need the real and perfect solution. In most cases it looks like your algorithm(s) can find a rather good one, so that (possibily after scanning this result along the borders) removing one or two pixel lines or columns looks like an acceptable work-around!

No camera have a viewfinder where the precision is up to one pixel !

Happily enough, 360° panos where the connexion could be visible when a few columns are removed and 360° x 180° spherical where programs like Pano2QTVR want equirectangular image where width = 2 x height exactly are easy to handle...
Last edited by GURL on Fri Dec 01, 2006 11:37 am, edited 1 time in total.
Georges

no avatar
ssprengel
Member
 
Topic author
Posts: 34
Likes: 0 post
Liked in: 0 post
Joined: Fri Sep 01, 2006 3:20 pm
Location: Nebraska, USA
Info

by ssprengel » Fri Dec 01, 2006 3:14 pm

AlexandreJ wrote:I'm aware of this limitation.

To find the bigger enclosed area within a general polygon is a NP-complete algorithm (for definition : NP-Complete).
The result is that finding the real solution is hard really hard.
So I designed a novel algorithm to find an approximate solution and this solution is not always the right one. In planar for example, it ignores the hole that can arise in the middle top edge or middle bottom edge. In fact, it works good with convex polygons but less good with concave.

It's been a long-time since I considered the NP-completeness of an algorithm...

I may not be thinking about this correctly, but it would seem that dealing with convex shapes would be much harder than concave since there are only four corners of each image, not an infinite number of points along the curve of a bulge, so finding the larger of the bounding box of the transformed corners of all images and the novel-convex thing you do now would work for most things, wouldn't it?
Last edited by ssprengel on Fri Dec 01, 2006 3:18 pm, edited 1 time in total.


Who is online

Users browsing this forum: No registered users and 1 guest