Hi,I only proposed to use the exist API - GDALComputeMatchingPoints, or modify it to support new method BRISK. You have not to modify SimpleSurf, but only make it still working as now. GDAL is library, not the "Automatic geo-referencer utility" and some common methods and functions should be developed. This does not deny that such a tool can be developed but it must use this common methods and functions. For example see the console utilities in apps folder of GDAL source tree. They use GDAL functions and methods.*
*
Best regards,
Dmitry
16.03.2014 1:15, Seth Price ?????:
I have done something like this recently. You would be better off tearing out SURF & linking to OpenCV for all feature detection and extraction. Here is a link to the patch that OpenCV needs to support large & 16 bit imagery.https://github.com/Itseez/opencv/pull/1932 ~Seth via iPhoneOn Mar 15, 2014, at 12:50 PM, Kshitij Kansal <kansa...@gmail.com <mailto: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 HyderabadOn Sat, Mar 15, 2014 at 12:29 AM, Chaitanya kumar CH <chaitanya...@gmail.com <mailto: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 <mailto: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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org> http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org <mailto: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
