[ptx] autopano: first attempt at semi-automatic panorama stitching

[nowozin at cs.tu-berlin.de]

Hi Pablo, hi list :)



On Sat, Dec 27, 2003 at 05:41:22PM +0100, Pablo d'Angelo wrote:

> [...]
> when you create your rotationally invariant descriptor, by suming the
> polar image, one looses all rotation information. Probably it would be
> interesting to create a kind of "local" reference frame, from the center
> to the strongest feature. This could then be used for corrospondence
> analysis as well.

I am not sure if I understand completely what you mean with reference frame.

My idea is roughly this: As comparing all feature pixels with each other has
quadratic complexity, I first build a short rough fingerprint (the rotation
invariant one) of each feature pixel. Then, a number of closest matches by
this fingerprint are searched for each feature pixel (default is 48 ones, so
complexity is still quadratic in this step). The expensive comparison
follows on just this first matches, so the complexity is now
O(featurepixel_count). This second comparison finds the rotation required to
create the minimum difference.


> Have you read the "Recognizing Panoramas" Paper from Brown?
> http://www.cs.ubc.ca/~mbrown/panorama/panorama.html

Ahhhhhh.... I wish I would have had that link earlier. I will read it today
and let you know :) His results look very impressive, also his speed.

My guess is that the high speed comes from the second step (where I have
still O(n*m) complexity), but I have to read his paper.


> Alexandre has implemented some parts of that algorithm, but the SIFT
> features seem to be patented (don't know where, haven't found a patent in
> the german patent database). But since we do not really need scale
> invariant features (I think), we could replace the SIFT feature detector
> with something more simple.

Is there code of his implementation to review?


> > If the accuracy of the algorithm is improved and feedback arrives I may
> > be interested to optimize it and port it for use with hugin, but thats
> > still a long way to go, as the current version makes just too many
> > mistakes. (I could imagine some sort of batchmode, where the user first
> > marks all overlapping image pairs and afterwards runs the correlation
> > all in one batch overnight. For more explanations on that topic please
> > see the index.html and method.html file)
 
> For testing and first integration purposes it is probably easier write out
> a hugin project file, with the control point determined by your algorithm.
 
Thats what I thought.

At first (before complete automatic panorama stitching is in reach) I think
some semi-automatic step could be used, where the user just marks image
pairs which overlap and an external program returns a list of probable
control points for the user to review.


> ciao
>   Pablo

bye,
Sebastian
(nowozin at cs.tu-berlin.de)