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

[Chaitanya kumar CH]

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
>
> 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 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/20140315/af89b2af/attachment-0001.html>