Also, I wouldn't worry much about the multispectral part of the data. You're going to have more trouble with reliably finding the correct key point matches. Use RANSAC, also in OpenCV.
~Seth via iPhone > On Mar 15, 2014, at 12:50 PM, Kshitij Kansal <kansa...@gmail.com> wrote: > > Hello Again, > > @Dimitriy - Currently the GDALComputeMatchingPoints is using the SimpleSurf > algorithm for matching points. Are you proposing that, I should implement the > BRISK and then provide user the option of using either this or > SimpleSurf(already implemented)? > This is indeed a very interesting thought but the problem in this is that, > the GDALComputeMatchingPoints is developed with respect to the correlator > project and I feel that SimpleSurf algorithm implemented there won't work on > my Automatic geo-referencer as I would be considering the Multispectral > Imagery and Large Datasets which are not handled in the current > implementation. So this will require modification to SimpleSurf as well. > I hope I have made my doubt clear? Please convey your views on this. > > @Chaitanya - In comparison to the SURF, BRISK can definitely handle the large > imagery to great extent. But there is going to be some threshold upto which > this algorithm will work because we must not forget that these algorithms are > developed for Normal RGB images for Computer Vision related work and there > usage to Remote Sensing requires some modification. I will try to look for > this thing in more detail and then get back to you. > > > Also, should I prepare my initial draft of proposal based this BRISK idea > only? > I have already started work in this direction and will soon post it, for > review. > > With Regards, > > Kshitij Kansal > Lab For Spatial Informatics, > IIIT Hyderabad > > >> On Sat, Mar 15, 2014 at 12:29 AM, Chaitanya kumar CH >> <chaitanya...@gmail.com> wrote: >> 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 > > _______________________________________________ > 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
