[ptx] autopanos?

[JD Smith]

On Thu, 2004-05-06 at 00:13, Sebastian Nowozin wrote:
> Hi :)
> 
> 
> On Thu, May 06, 2004 at 08:09:48AM +0200, alexandre jenny wrote:
>  
> > Autopano Alexandre Jenny (That's me ;-))
> >  + Speed, it's c++.
> >  + Very low memory usage.
> >  + Ransac check (removes many false point).
> >  - Accuracy. Around 5 % of false points still remains.
> >  - Not open source yet.
>  
> Yes, RANSAC is a great plus, I am looking into implementing some further
> postprocessing, too. It really helps.

Do you use Lowe's keypoints directly, or have you just been hesitant to
release the source?  So you'd say that you have fewer false positives
thanks to RANSAC, but Sebastian's keypoints, when they are correct, are
placed more accurately and register more cleanly?  So the best of both
worlds auto-pano tool would include Sebastian's keypoint finder (more
accurate, no copyright issues, potential patent issues) and your ransac
and yaw/pitch/roll/fov optimizer?

Thanks,

JD


> 
> > Autopano_sift Sebastian
> >  + Accuracy. It seems to be more accurate.
> >  + Open source.
> >  - Speed.
> >  - Memory usage.
> 
> I do not know where the additional accuracy comes from, but I improved a lot of
> the SIFT code in the latest version. Especially for diffuse surroundings and
> soft gradients, the filtering is stricter, which leads to fewer keypoints and
> better reproducability. Also, I think the very simple measure I implemented
> about the quality of a single match really helps, as it weights of the overall
> quality of the match (the absolute distance between the two keypoints), and the
> relative stick-out-from-rest quality (the ratio of distance to the next second
> best match). As some small helper, the matching also removes join-matches,
> which appear in repeating image elements, where many keypoints from one image
> are mapped to the same in another.
> 
> The speed and memory usage is really a pitty, yes. I like to think its not a C#
> thing, although the floating point code generated by the Mono IA32-JIT is
> really not the best. The only part where the speed is really bad is at the
> matching. In the latest version I replaced a lot of FPU intense code with
> integer code, which doubles the speed. For the memory, I plan to change the
> order of the octave processing to a linear one, which would reduce the peak
> memory usage. But still, images eat memory :) Maybe replacing all double's with
> float or some fixed-point 16bit format will help. Mhhh.. if we would just have
> more time for all this optimization stuff ;)
> 
> 
> > Am I right ?
>  
> Yes. :)
> 
> 
> > Bye
> >   Alexandre 
>  
> > We should use some test case to make a real comparison ... Hum ...
>  
> Not just for comparison of our programs, but also for relative versions of the
> same program, changed threshhold values and - more importantly - so we can
> discuss results on this list.
> 
> bye,
> Sebastian