Kshitij, What is the performance of the proposed algorithms for very large rasters? If one of them is good with large images that's a cleaner choice without all the workaround with scaling the rasters.
-- Best regards, Chaitanya Kumar CH On 15-Mar-2014 12:22 am, "Dmitriy Baryshnikov" <bishop....@gmail.com> wrote: > Hi, > > I think we need to decide it here, not to create lot of proposals. The > second idea is very interesting. Maybe it worth to create some common > interface (or API) to add new methods BRISK, SURF, SIFT etc. > You can develop you realisation of BRISK and demonstrate how-to one can > use it via such common interface. > E.g. in GDALComputeMatchingPoints add enum for algorithms or use exist > papszOptions. > > Best regards, > Dmitry > > 14.03.2014 17:28, Kshitij Kansal пишет: > > Hello everyone > > Continuing the previous discussion, I would like to propose something > and the community's suggestions are welcomed/needed. I can understand that > this thread is a little old, so let me remind you that its regarding the > automatic geo-referencer idea. The idea is also proposed on the GDAL ideas > page (http://trac.osgeo.org/gdal/wiki/SummerOfCode). > > Based on the previous discussions, what came out was that we can improve > the current implementation of SIMPLE SURF in GDAL which was developed as a > part of 2012 GSOC GDAL Correlator project, to support *large data* and *multi > spectral imagery*. And then apply this *modified* algorithm for the > geo-reference purposes. Now I have been in touch with Chaitanya, who is > willing to mentor this project, and there are some things on which we would > like to know community's suggestions/response. > > There are basically two things that can be done regarding this project: > > 1. As mentioned above, we can modify the SIMPLE SURF algorithm and make > it much better for the geo-reference purposes. Already, a lot had been > discussed on this and we have a fairly good idea about what is to be done. > > 2. One more thing that can be done is that we can implement BRISK > algorithm[1] instead of SURF along with the FLANN matcher for this purpose. > What advantages this thing offers is that it is fairly fast and gives > comparable outputs along with that it works well with fairly large data > sets. So we do not need to segment the imagery as we would have done in the > case of SURF. Also added to this, this algorithm also has no patent issues. > We had a lot of problem regarding patent issues in SIFT/SURF and we > discussed them at length on the mailing list as well. > > One thing that I fell can be done is that two proposal can be written, > one for each and then community can decide accordingly which one is more > useful. Or we can decide it here itself..? > > Kindly provide your valuable comments and suggestion.. > > With Regards, > > Kshitij Kansal > > Lab For Spatial Informatics, > > IIIT Hyderabad > > 1. http://www.robots.ox.ac.uk/~vgg/rg/papers/brisk.pdf > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev