[gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014

[Dmitriy Baryshnikov]

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 iPhone
>
> On Mar 15, 2014, at 12:50 PM, Kshitij Kansal <kansal.k at gmail.com 
> <mailto:kansal.k at 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.ch at gmail.com <mailto:chaitanya.ch at 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.dev at gmail.com <mailto:bishop.dev at 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 at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
>>     http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140316/eb632abc/attachment-0001.html>