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

[Kshitij Kansal]

Hello Everyone

I have submitted my proposal at the melange website. My proposal is
available here<https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/kansal/5629499534213120>
.
Please review my proposal and give me some suggestions to make this
proposal even more useful to the organization.

@Dmitriy & Chaitanya - I urge you to please specifically look into the
"common interface to various algorithms using some existing API" part
 apart from the whole proposal, in my timeline. I have devoted 7-8 days for
this work. If you people have some comments regarding this, kindly convey
it to me.

Thanking You all

With Regards,

Kshitij Kansal

Lab For Spatial Informatics,

IIIT Hyderabad



On Sun, Mar 16, 2014 at 11:46 AM, Chaitanya kumar CH <chaitanya.ch at gmail.com
> wrote:

> Kshitij,
>
> As suggested you should plan to allow user to select the algorithm for key
> point detection and matching.
>
> I'll explain how to do that later. But essentially you may get some input
> from the user to change the default algorithm to something else. So, all
> the steps should be done independent of each other.
>
> --
> Best regards,
> Chaitanya Kumar CH
> On 16-Mar-2014 2:58 am, "Dmitriy Baryshnikov" <bishop.dev at gmail.com>
> wrote:
>
>>  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> 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> 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>
>>> 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
>>> 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
>>
>>
>>
>> _______________________________________________
>> gdal-dev mailing listgdal-dev at lists.osgeo.orghttp://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/20140317/b5e831bc/attachment.html>