Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Hi, I think 7-8 days will be enough. According to you plan this issue will raise on 4-5 week then you'll export BRISK algorithm to GDAL. By now I don't see any problems - don't worry. Best regards, Dmitry 17.03.2014 22:05, 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 ___ 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
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Hello Dmitry Thank you. Is there anything else you can suggest regarding the proposal or Should I consider the current draft as the final one? I have planned it to the best way I could think of. I have tried to give enough time for testing, documentation and code cleaning also as it is a completely new implementation. If anything else comes up, please do let me know. Thanks for the support and ideas. With Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Thu, Mar 20, 2014 at 1:34 AM, Dmitriy Baryshnikov bishop@gmail.comwrote: Hi, I think 7-8 days will be enough. According to you plan this issue will raise on 4-5 week then you'll export BRISK algorithm to GDAL. By now I don't see any problems - don't worry. Best regards, Dmitry 17.03.2014 22:05, Kshitij Kansal пишет: Hello Everyone I have submitted my proposal at the melange website. My proposal is available herehttps://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 ___ 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
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Hello Everyone I have submitted my proposal at the melange website. My proposal is available herehttps://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...@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@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 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 ___ 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 listgdal-dev@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
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@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 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 ___ 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 listgdal-dev@lists.osgeo.orghttp://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
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
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
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
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 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
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
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
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
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 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 Hyderabad On 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
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
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 On Thu, Feb 13, 2014 at 2:23 PM, Kshitij Kansal kansa...@gmail.com wrote: Hello Everyone I have updated the Summer Of Code Ideas Page for GDAL. I have Introduced the above idea in that page also. Mr. Chaitanya Kumar is willing to mentor the project. Please look into this. Suggestions and Comments are welcomed. Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Sat, Feb 8, 2014 at 2:07 PM, Dmitriy Baryshnikov bishop@gmail.comwrote: Hi, Even note that you cannot get the code from this projects and merge it to GDAL, but you free to develop you own implementation of this algorithms as path of GDAL. This is a same situation with correlator. Andrew cannot get code from OpenCV and GRASS as incompatible licenses, so the own (simple) implementation was provided. One can change this implementation to be more advanced: support large datasets, more bands, etc. Everybody welcome to do it. Best regards, Dmitry 08.02.2014 2:15, Kshitij Kansal пишет: Sir I am providing the links for both the algorithms that I talked. I am new to this licence issues thing so I would be highly grateful if you can clarify doubts and if can proceed on working for this idea. http://www.cs.ubc.ca/~lowe/keypoints/ (SIFT) http://www.ipol.im/pub/art/2011/my-asift/ (ASIFT) [here source code is provided. It contains license ] http://www.cmap.polytechnique.fr/~yu/research/ASIFT/demo.html (Demo Page for ASIFT) The SIFT algorithm in itself is patented. They only provide binaries. I am not sure If we can use those binaries or not. As far as ASIFT is concerned, i think its implementation is only patented. Kindly clarify this. Thanking You With Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Sat, Feb 8, 2014 at 2:23 AM, Even Rouault even.roua...@mines-paris.org wrote: Selon Kshitij Kansal kansa...@gmail.com: Kshitij, I'm surprised that you mention licenses for algorithms. What are your sources for that? Only *implementations* can be licensed not algorithms themselves. So if you develop your own implementation you are free to select the license you wish. There might be issues linked to potential pattents in some countries but that is acceptable in my opinion as software parents are not valid in all contries so mentionning potential issues with them in the documentation is sufficient . Hello Based on all suggestion ins and comments above, I have come up with one thing. The most important thing that could have been a road block for this project was licence issues which was pointed by Even Rouault. I am interested in implementing the SIFT or ASIFT algorithms for automatic geo-referencing which I proposed in above mails. I am interested in making a separate tool which will be completely based on the GDAL and maintained by GDAL community. I
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
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 http://www.robots.ox.ac.uk/%7Evgg/rg/papers/brisk.pdf ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
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
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Hello Everyone I have updated the Summer Of Code Ideas Page for GDAL. I have Introduced the above idea in that page also. Mr. Chaitanya Kumar is willing to mentor the project. Please look into this. Suggestions and Comments are welcomed. Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Sat, Feb 8, 2014 at 2:07 PM, Dmitriy Baryshnikov bishop@gmail.comwrote: Hi, Even note that you cannot get the code from this projects and merge it to GDAL, but you free to develop you own implementation of this algorithms as path of GDAL. This is a same situation with correlator. Andrew cannot get code from OpenCV and GRASS as incompatible licenses, so the own (simple) implementation was provided. One can change this implementation to be more advanced: support large datasets, more bands, etc. Everybody welcome to do it. Best regards, Dmitry 08.02.2014 2:15, Kshitij Kansal пишет: Sir I am providing the links for both the algorithms that I talked. I am new to this licence issues thing so I would be highly grateful if you can clarify doubts and if can proceed on working for this idea. http://www.cs.ubc.ca/~lowe/keypoints/ (SIFT) http://www.ipol.im/pub/art/2011/my-asift/ (ASIFT) [here source code is provided. It contains license ] http://www.cmap.polytechnique.fr/~yu/research/ASIFT/demo.html (Demo Page for ASIFT) The SIFT algorithm in itself is patented. They only provide binaries. I am not sure If we can use those binaries or not. As far as ASIFT is concerned, i think its implementation is only patented. Kindly clarify this. Thanking You With Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Sat, Feb 8, 2014 at 2:23 AM, Even Rouault even.roua...@mines-paris.org wrote: Selon Kshitij Kansal kansa...@gmail.com: Kshitij, I'm surprised that you mention licenses for algorithms. What are your sources for that? Only *implementations* can be licensed not algorithms themselves. So if you develop your own implementation you are free to select the license you wish. There might be issues linked to potential pattents in some countries but that is acceptable in my opinion as software parents are not valid in all contries so mentionning potential issues with them in the documentation is sufficient . Hello Based on all suggestion ins and comments above, I have come up with one thing. The most important thing that could have been a road block for this project was licence issues which was pointed by Even Rouault. I am interested in implementing the SIFT or ASIFT algorithms for automatic geo-referencing which I proposed in above mails. I am interested in making a separate tool which will be completely based on the GDAL and maintained by GDAL community. I looked into the GDAL-correlator idea which was also implemented as a part of GSoC. That idea uses only *SIMPLE SURF *algorithm for control point detection and is only *limited to small size three band imagery(RGB)*. I am interested in developing something that is fully automated and works on large multi band imagery.But the above two algorithms that I am planning to use come up with the licence that does not allows the free use for commercial purposes. The free use of above algorithm are restricted to *non profit research and non profit educational purposes*(in case of ASIFT) and *research purposes only *(in case of SIFT). This means that the final product as a result of this product will also be bounded by the above licences. It can not go into GDAL's main distribution but can be used as a separate utility of GDAL for non-commercial uses only. Basically the commercial use of the tool won't be allowed without approval from the concerned people. Your views and suggestions are highly appreciated. Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Thu, Jan 30, 2014 at 12:25 PM, Kshitij Kansal kansa...@gmail.com wrote: Hello @Jukka Rahkonen: The OSSIM project (the link you provided) is more of image orthorectification. Although they are doing image co-registration but its as one of the steps of orthorectification(I could only understand this from the manual). Also I am not sure of the techniques they are using for this purposes. (Its written corner point detection but How?) I am new to OSSIM, so not aware of this thing's functionality and accuracy. I am in the process of estimating it. Thank you for pointing this out. Coming to the Frank Warmerdam's blog (http://fwarmerdam.blogspot.fi/ ). Here the author is talking about writing a code for converting the GCP's into RPC's. But the next question comes is where is he getting GCP's from. Now this is the part where I aim to work on and improve. Given two images, if we can automatically extract GCP's from them then we are in a way
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Hi, Even note that you cannot get the code from this projects and merge it to GDAL, but you free to develop you own implementation of this algorithms as path of GDAL. This is a same situation with correlator. Andrew cannot get code from OpenCV and GRASS as incompatible licenses, so the own (simple) implementation was provided. One can change this implementation to be more advanced: support large datasets, more bands, etc. Everybody welcome to do it. Best regards, Dmitry 08.02.2014 2:15, Kshitij Kansal ?: Sir I am providing the links for both the algorithms that I talked. I am new to this licence issues thing so I would be highly grateful if you can clarify doubts and if can proceed on working for this idea. http://www.cs.ubc.ca/~lowe/keypoints/ http://www.cs.ubc.ca/%7Elowe/keypoints/ (SIFT) http://www.ipol.im/pub/art/2011/my-asift/ (ASIFT) [here source code is provided. It contains license ] http://www.cmap.polytechnique.fr/~yu/research/ASIFT/demo.html http://www.cmap.polytechnique.fr/%7Eyu/research/ASIFT/demo.html (Demo Page for ASIFT) The SIFT algorithm in itself is patented. They only provide binaries. I am not sure If we can use those binaries or not. As far as ASIFT is concerned, i think its implementation is only patented. Kindly clarify this. Thanking You With Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Sat, Feb 8, 2014 at 2:23 AM, Even Rouault even.roua...@mines-paris.org mailto:even.roua...@mines-paris.org wrote: Selon Kshitij Kansal kansa...@gmail.com mailto:kansa...@gmail.com: Kshitij, I'm surprised that you mention licenses for algorithms. What are your sources for that? Only *implementations* can be licensed not algorithms themselves. So if you develop your own implementation you are free to select the license you wish. There might be issues linked to potential pattents in some countries but that is acceptable in my opinion as software parents are not valid in all contries so mentionning potential issues with them in the documentation is sufficient . Hello Based on all suggestion ins and comments above, I have come up with one thing. The most important thing that could have been a road block for this project was licence issues which was pointed by Even Rouault. I am interested in implementing the SIFT or ASIFT algorithms for automatic geo-referencing which I proposed in above mails. I am interested in making a separate tool which will be completely based on the GDAL and maintained by GDAL community. I looked into the GDAL-correlator idea which was also implemented as a part of GSoC. That idea uses only *SIMPLE SURF *algorithm for control point detection and is only *limited to small size three band imagery(RGB)*. I am interested in developing something that is fully automated and works on large multi band imagery.But the above two algorithms that I am planning to use come up with the licence that does not allows the free use for commercial purposes. The free use of above algorithm are restricted to *non profit research and non profit educational purposes*(in case of ASIFT) and *research purposes only *(in case of SIFT). This means that the final product as a result of this product will also be bounded by the above licences. It can not go into GDAL's main distribution but can be used as a separate utility of GDAL for non-commercial uses only. Basically the commercial use of the tool won't be allowed without approval from the concerned people. Your views and suggestions are highly appreciated. Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Thu, Jan 30, 2014 at 12:25 PM, Kshitij Kansal kansa...@gmail.com mailto:kansa...@gmail.com wrote: Hello @Jukka Rahkonen: The OSSIM project (the link you provided) is more of image orthorectification. Although they are doing image co-registration but its as one of the steps of orthorectification(I could only understand this from the manual). Also I am not sure of the techniques they are using for this purposes. (Its written corner point detection but How?) I am new to OSSIM, so not aware of this thing's functionality and accuracy. I am in the process of estimating it. Thank you for pointing this out. Coming to the Frank Warmerdam's blog (http://fwarmerdam.blogspot.fi/). Here the author is talking about writing a code for converting the GCP's into RPC's. But the next question comes is where is he getting GCP's from. Now this is the part where I aim to work on and improve. Given two
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Hello Based on all suggestions and comments above, I have come up with one thing. The most important thing that could have been a road block for this project was licence issues which was pointed by Even Rouault. I am interested in implementing the SIFT or ASIFT algorithms for automatic geo-referencing which I proposed in above mails. I am interested in making a separate tool which will be completely based on the GDAL and maintained by GDAL community. I looked into the GDAL-correlator idea which was also implemented as a part of GSoC. That idea uses only *SIMPLE SURF *algorithm for control point detection and is only *limited to small size three band imagery(RGB)*. I am interested in developing something that is fully automated and works on large multi band imagery.But the above two algorithms that I am planning to use come up with the licence that does not allows the free use for commercial purposes. The free use of above algorithm are restricted to *non profit research and non profit educational purposes*(in case of ASIFT) and *research purposes only *(in case of SIFT). This means that the final product as a result of this product will also be bounded by the above licences. It can not go into GDAL's main distribution but can be used as a separate utility of GDAL for non-commercial uses only. Basically the commercial use of the tool won't be allowed without approval from the concerned people. Your views and suggestions are highly appreciated. Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Thu, Jan 30, 2014 at 12:25 PM, Kshitij Kansal kansa...@gmail.com wrote: Hello @Jukka Rahkonen: The OSSIM project (the link you provided) is more of image orthorectification. Although they are doing image co-registration but its as one of the steps of orthorectification(I could only understand this from the manual). Also I am not sure of the techniques they are using for this purposes. (Its written corner point detection but How?) I am new to OSSIM, so not aware of this thing's functionality and accuracy. I am in the process of estimating it. Thank you for pointing this out. Coming to the Frank Warmerdam's blog (http://fwarmerdam.blogspot.fi/). Here the author is talking about writing a code for converting the GCP's into RPC's. But the next question comes is where is he getting GCP's from. Now this is the part where I aim to work on and improve. Given two images, if we can automatically extract GCP's from them then we are in a way speeding up and automating this whole process. Once we have GCP, there are a lot of things that we can do from them like geo-referencing(which I plan on doing), image stitching etc. *Also you talked about a more light weighted system. Can you please elaborate on this?* I could not understand what you actually meant from that. If we look into the last year idea's page ( http://trac.osgeo.org/gdal/wiki/SummerOfCode), there is one idea that is proposed regarding the Raster/Vector geo-referencer on the Web. I want to modify this idea a little bit and want to automate the whole process. As far as the automation is concerned, we can develop GDAL functions for that(which will be completely re-usable) and then developing a Web based geo-referencer would only require calling those functions. If we do this thing,* two objectives will be fulfilled*.* First*, GDAL will get a web based geo-referencer. *Secondly*, communities that use GDAL and have not developed these kind of geo-referencer(Like QGIS) can directly use the functions developed and then build on that. Suggestions and comments are welcomed. Thank you for your propositions. Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Wed, Jan 29, 2014 at 1:27 PM, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote: Kshitij Kansal kansal.k at gmail.com writes: Even, Thank you for pointing out this issue. I will keep this in mind. I will look into that last year project and try to understand the implementation. More suggestions and comments are always welcomed. Hi, Another OSGeo project OSSIM has implemented an automatic image to image rectification. Isn't that a bit alike your plan? http://download.osgeo.org/ossim/docs/OSSIM_Coregistration_UserManual.pdf Frank Warmerdam seems to entertain himself with something related http://fwarmerdam.blogspot.fi/ This article from 2013 may also give some inspiration http://www.academia.edu/4388853/OrientAL_-_Automatic_geo-referencing_and_ortho-rectification_of_archaeological_aerial_photographs All these three aim to very high quality and I am sure that there is also need for a more light-weight system. -Jukka Rahkonen- ___ 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
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
On Fri, Feb 7, 2014 at 11:10 AM, Kshitij Kansal kansa...@gmail.com wrote: This means that the final product as a result of this product will also be bounded by the above licences. It can not go into GDAL's main distribution but can be used as a separate utility of GDAL for non-commercial uses only. Basically the commercial use of the tool won't be allowed without approval from the concerned people. Your views and suggestions are highly appreciated. That's a no go as far as GSOC is concerned. (I assume this is the question.) My recollection is that they will not accept a project that is not released under an approved license. THK -- http://www.keittlab.org/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Selon Kshitij Kansal kansa...@gmail.com: Kshitij, I'm surprised that you mention licenses for algorithms. What are your sources for that? Only *implementations* can be licensed not algorithms themselves. So if you develop your own implementation you are free to select the license you wish. There might be issues linked to potential pattents in some countries but that is acceptable in my opinion as software parents are not valid in all contries so mentionning potential issues with them in the documentation is sufficient . Hello Based on all suggestion ins and comments above, I have come up with one thing. The most important thing that could have been a road block for this project was licence issues which was pointed by Even Rouault. I am interested in implementing the SIFT or ASIFT algorithms for automatic geo-referencing which I proposed in above mails. I am interested in making a separate tool which will be completely based on the GDAL and maintained by GDAL community. I looked into the GDAL-correlator idea which was also implemented as a part of GSoC. That idea uses only *SIMPLE SURF *algorithm for control point detection and is only *limited to small size three band imagery(RGB)*. I am interested in developing something that is fully automated and works on large multi band imagery.But the above two algorithms that I am planning to use come up with the licence that does not allows the free use for commercial purposes. The free use of above algorithm are restricted to *non profit research and non profit educational purposes*(in case of ASIFT) and *research purposes only *(in case of SIFT). This means that the final product as a result of this product will also be bounded by the above licences. It can not go into GDAL's main distribution but can be used as a separate utility of GDAL for non-commercial uses only. Basically the commercial use of the tool won't be allowed without approval from the concerned people. Your views and suggestions are highly appreciated. Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Thu, Jan 30, 2014 at 12:25 PM, Kshitij Kansal kansa...@gmail.com wrote: Hello @Jukka Rahkonen: The OSSIM project (the link you provided) is more of image orthorectification. Although they are doing image co-registration but its as one of the steps of orthorectification(I could only understand this from the manual). Also I am not sure of the techniques they are using for this purposes. (Its written corner point detection but How?) I am new to OSSIM, so not aware of this thing's functionality and accuracy. I am in the process of estimating it. Thank you for pointing this out. Coming to the Frank Warmerdam's blog (http://fwarmerdam.blogspot.fi/). Here the author is talking about writing a code for converting the GCP's into RPC's. But the next question comes is where is he getting GCP's from. Now this is the part where I aim to work on and improve. Given two images, if we can automatically extract GCP's from them then we are in a way speeding up and automating this whole process. Once we have GCP, there are a lot of things that we can do from them like geo-referencing(which I plan on doing), image stitching etc. *Also you talked about a more light weighted system. Can you please elaborate on this?* I could not understand what you actually meant from that. If we look into the last year idea's page ( http://trac.osgeo.org/gdal/wiki/SummerOfCode), there is one idea that is proposed regarding the Raster/Vector geo-referencer on the Web. I want to modify this idea a little bit and want to automate the whole process. As far as the automation is concerned, we can develop GDAL functions for that(which will be completely re-usable) and then developing a Web based geo-referencer would only require calling those functions. If we do this thing,* two objectives will be fulfilled*.* First*, GDAL will get a web based geo-referencer. *Secondly*, communities that use GDAL and have not developed these kind of geo-referencer(Like QGIS) can directly use the functions developed and then build on that. Suggestions and comments are welcomed. Thank you for your propositions. Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Wed, Jan 29, 2014 at 1:27 PM, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote: Kshitij Kansal kansal.k at gmail.com writes: Even, Thank you for pointing out this issue. I will keep this in mind. I will look into that last year project and try to understand the implementation. More suggestions and comments are always welcomed. Hi, Another OSGeo project OSSIM has implemented an automatic image to image rectification. Isn't that a bit alike your plan? http://download.osgeo.org/ossim/docs/OSSIM_Coregistration_UserManual.pdf Frank Warmerdam seems to entertain himself
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Sir I am providing the links for both the algorithms that I talked. I am new to this licence issues thing so I would be highly grateful if you can clarify doubts and if can proceed on working for this idea. http://www.cs.ubc.ca/~lowe/keypoints/ (SIFT) http://www.ipol.im/pub/art/2011/my-asift/ (ASIFT) [here source code is provided. It contains license ] http://www.cmap.polytechnique.fr/~yu/research/ASIFT/demo.html (Demo Page for ASIFT) The SIFT algorithm in itself is patented. They only provide binaries. I am not sure If we can use those binaries or not. As far as ASIFT is concerned, i think its implementation is only patented. Kindly clarify this. Thanking You With Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Sat, Feb 8, 2014 at 2:23 AM, Even Rouault even.roua...@mines-paris.orgwrote: Selon Kshitij Kansal kansa...@gmail.com: Kshitij, I'm surprised that you mention licenses for algorithms. What are your sources for that? Only *implementations* can be licensed not algorithms themselves. So if you develop your own implementation you are free to select the license you wish. There might be issues linked to potential pattents in some countries but that is acceptable in my opinion as software parents are not valid in all contries so mentionning potential issues with them in the documentation is sufficient . Hello Based on all suggestion ins and comments above, I have come up with one thing. The most important thing that could have been a road block for this project was licence issues which was pointed by Even Rouault. I am interested in implementing the SIFT or ASIFT algorithms for automatic geo-referencing which I proposed in above mails. I am interested in making a separate tool which will be completely based on the GDAL and maintained by GDAL community. I looked into the GDAL-correlator idea which was also implemented as a part of GSoC. That idea uses only *SIMPLE SURF *algorithm for control point detection and is only *limited to small size three band imagery(RGB)*. I am interested in developing something that is fully automated and works on large multi band imagery.But the above two algorithms that I am planning to use come up with the licence that does not allows the free use for commercial purposes. The free use of above algorithm are restricted to *non profit research and non profit educational purposes*(in case of ASIFT) and *research purposes only *(in case of SIFT). This means that the final product as a result of this product will also be bounded by the above licences. It can not go into GDAL's main distribution but can be used as a separate utility of GDAL for non-commercial uses only. Basically the commercial use of the tool won't be allowed without approval from the concerned people. Your views and suggestions are highly appreciated. Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Thu, Jan 30, 2014 at 12:25 PM, Kshitij Kansal kansa...@gmail.com wrote: Hello @Jukka Rahkonen: The OSSIM project (the link you provided) is more of image orthorectification. Although they are doing image co-registration but its as one of the steps of orthorectification(I could only understand this from the manual). Also I am not sure of the techniques they are using for this purposes. (Its written corner point detection but How?) I am new to OSSIM, so not aware of this thing's functionality and accuracy. I am in the process of estimating it. Thank you for pointing this out. Coming to the Frank Warmerdam's blog (http://fwarmerdam.blogspot.fi/). Here the author is talking about writing a code for converting the GCP's into RPC's. But the next question comes is where is he getting GCP's from. Now this is the part where I aim to work on and improve. Given two images, if we can automatically extract GCP's from them then we are in a way speeding up and automating this whole process. Once we have GCP, there are a lot of things that we can do from them like geo-referencing(which I plan on doing), image stitching etc. *Also you talked about a more light weighted system. Can you please elaborate on this?* I could not understand what you actually meant from that. If we look into the last year idea's page ( http://trac.osgeo.org/gdal/wiki/SummerOfCode), there is one idea that is proposed regarding the Raster/Vector geo-referencer on the Web. I want to modify this idea a little bit and want to automate the whole process. As far as the automation is concerned, we can develop GDAL functions for that(which will be completely re-usable) and then developing a Web based geo-referencer would only require calling those functions. If we do this thing,* two objectives will be fulfilled*.* First*, GDAL will get a web based geo-referencer. *Secondly*,
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Hello @Jukka Rahkonen: The OSSIM project (the link you provided) is more of image orthorectification. Although they are doing image co-registration but its as one of the steps of orthorectification(I could only understand this from the manual). Also I am not sure of the techniques they are using for this purposes. (Its written corner point detection but How?) I am new to OSSIM, so not aware of this thing's functionality and accuracy. I am in the process of estimating it. Thank you for pointing this out. Coming to the Frank Warmerdam's blog (http://fwarmerdam.blogspot.fi/). Here the author is talking about writing a code for converting the GCP's into RPC's. But the next question comes is where is he getting GCP's from. Now this is the part where I aim to work on and improve. Given two images, if we can automatically extract GCP's from them then we are in a way speeding up and automating this whole process. Once we have GCP, there are a lot of things that we can do from them like geo-referencing(which I plan on doing), image stitching etc. *Also you talked about a more light weighted system. Can you please elaborate on this?* I could not understand what you actually meant from that. If we look into the last year idea's page ( http://trac.osgeo.org/gdal/wiki/SummerOfCode), there is one idea that is proposed regarding the Raster/Vector geo-referencer on the Web. I want to modify this idea a little bit and want to automate the whole process. As far as the automation is concerned, we can develop GDAL functions for that(which will be completely re-usable) and then developing a Web based geo-referencer would only require calling those functions. If we do this thing,* two objectives will be fulfilled*.* First*, GDAL will get a web based geo-referencer. *Secondly*, communities that use GDAL and have not developed these kind of geo-referencer(Like QGIS) can directly use the functions developed and then build on that. Suggestions and comments are welcomed. Thank you for your propositions. Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Wed, Jan 29, 2014 at 1:27 PM, Jukka Rahkonen jukka.rahko...@mmmtike.fiwrote: Kshitij Kansal kansal.k at gmail.com writes: Even, Thank you for pointing out this issue. I will keep this in mind. I will look into that last year project and try to understand the implementation. More suggestions and comments are always welcomed. Hi, Another OSGeo project OSSIM has implemented an automatic image to image rectification. Isn't that a bit alike your plan? http://download.osgeo.org/ossim/docs/OSSIM_Coregistration_UserManual.pdf Frank Warmerdam seems to entertain himself with something related http://fwarmerdam.blogspot.fi/ This article from 2013 may also give some inspiration http://www.academia.edu/4388853/OrientAL_-_Automatic_geo-referencing_and_ortho-rectification_of_archaeological_aerial_photographs All these three aim to very high quality and I am sure that there is also need for a more light-weight system. -Jukka Rahkonen- ___ 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
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Just for your information. There already has been some work, at GSoC '13, to get this type of algorithms in scikit-image, see: http://skimager.blogspot.nl/ Scikit-image is of course restricted to use with Python. But of your final aim is to add this to for example QGIS (Which can handle Python) a lot of work is already done. Having this functionality at the core of GDAL would of course target much more people then only Python users. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-RFC-GDAL-Idea-for-GSoC-2014-tp5100128p5100379.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Hello Thank you for you suggestions. Joaquim I looked into the link regarding Affine-SIFT that you provided. Indeed the results that are shown there are very promising. If we can bring this to one of the core functionality of GDAL then it would not only help in this project but many more digital image/computer vision related projects. Rutger Yes the main aim to propose this idea into GDAL community is to bring this functionality into the core GDAL functionality. I checked with the other communities like QGIS or GRASS or even OPTICKS, but this functionality of automatic geo-referencing is not present and till now no work has been done in this direction. If implemented here, these communities can directly adapt our thing and then build on this. As we can see that we have a lot of algorithms to start with. Some kind of analysis like Estimating the shift between two georeferenced images. This was something Chaitanya was talking about. Also there was something me and Chaitanya discussed about, like matching raster with vector datasets, for example, GPX data could be used to match roads. Once we have this available in our core functionality of GDAL, we can easily use it to make *Raster / Vector Geo-referencer on the Web* which was the original idea proposed by the community in GS0C'13. Any Comments or Suggestions? Suggestions for getting started.. Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Tue, Jan 28, 2014 at 1:44 PM, Rutger kass...@gmail.com wrote: Just for your information. There already has been some work, at GSoC '13, to get this type of algorithms in scikit-image, see: http://skimager.blogspot.nl/ Scikit-image is of course restricted to use with Python. But of your final aim is to add this to for example QGIS (Which can handle Python) a lot of work is already done. Having this functionality at the core of GDAL would of course target much more people then only Python users. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-RFC-GDAL-Idea-for-GSoC-2014-tp5100128p5100379.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ 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
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Le mardi 28 janvier 2014 20:41:15, Kshitij Kansal a écrit : Hello Thank you for you suggestions. Joaquim I looked into the link regarding Affine-SIFT that you provided. Indeed the results that are shown there are very promising. If we can bring this to one of the core functionality of GDAL then it would not only help in this project but many more digital image/computer vision related projects. Rutger Yes the main aim to propose this idea into GDAL community is to bring this functionality into the core GDAL functionality. I checked with the other communities like QGIS or GRASS or even OPTICKS, but this functionality of automatic geo-referencing is not present and till now no work has been done in this direction. If implemented here, these communities can directly adapt our thing and then build on this. As we can see that we have a lot of algorithms to start with. Some kind of analysis like Estimating the shift between two georeferenced images. This was something Chaitanya was talking about. Also there was something me and Chaitanya discussed about, like matching raster with vector datasets, for example, GPX data could be used to match roads. Once we have this available in our core functionality of GDAL, we can easily use it to make *Raster / Vector Geo-referencer on the Web* which was the original idea proposed by the community in GS0C'13. Any Comments or Suggestions? Kshitij, I just wanted to mention, to avoid any potential problem later in the process, that if you adapt existing code from other projects into GDAL, you will need to make sure that it comes with a license compatible with the GDAL X/MIT license (so LGPL or GPL would not be OK), or make sure with copyright holders that it is OK to port it to GDAL under the GDAL X/MIT license. As a result of last year GSoC, we have an implementation of SURF algorithm in GDAL. Not sure how mature it is, but that might be a potential starting point. Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Even, Thank you for pointing out this issue. I will keep this in mind. I will look into that last year project and try to understand the implementation. More suggestions and comments are always welcomed. Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Wed, Jan 29, 2014 at 1:31 AM, Even Rouault even.roua...@mines-paris.orgwrote: Le mardi 28 janvier 2014 20:41:15, Kshitij Kansal a écrit : Hello Thank you for you suggestions. Joaquim I looked into the link regarding Affine-SIFT that you provided. Indeed the results that are shown there are very promising. If we can bring this to one of the core functionality of GDAL then it would not only help in this project but many more digital image/computer vision related projects. Rutger Yes the main aim to propose this idea into GDAL community is to bring this functionality into the core GDAL functionality. I checked with the other communities like QGIS or GRASS or even OPTICKS, but this functionality of automatic geo-referencing is not present and till now no work has been done in this direction. If implemented here, these communities can directly adapt our thing and then build on this. As we can see that we have a lot of algorithms to start with. Some kind of analysis like Estimating the shift between two georeferenced images. This was something Chaitanya was talking about. Also there was something me and Chaitanya discussed about, like matching raster with vector datasets, for example, GPX data could be used to match roads. Once we have this available in our core functionality of GDAL, we can easily use it to make *Raster / Vector Geo-referencer on the Web* which was the original idea proposed by the community in GS0C'13. Any Comments or Suggestions? Kshitij, I just wanted to mention, to avoid any potential problem later in the process, that if you adapt existing code from other projects into GDAL, you will need to make sure that it comes with a license compatible with the GDAL X/MIT license (so LGPL or GPL would not be OK), or make sure with copyright holders that it is OK to port it to GDAL under the GDAL X/MIT license. As a result of last year GSoC, we have an implementation of SURF algorithm in GDAL. Not sure how mature it is, but that might be a potential starting point. Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Kshitij Kansal kansal.k at gmail.com writes: Even, Thank you for pointing out this issue. I will keep this in mind. I will look into that last year project and try to understand the implementation. More suggestions and comments are always welcomed. Hi, Another OSGeo project OSSIM has implemented an automatic image to image rectification. Isn't that a bit alike your plan? http://download.osgeo.org/ossim/docs/OSSIM_Coregistration_UserManual.pdf Frank Warmerdam seems to entertain himself with something related http://fwarmerdam.blogspot.fi/ This article from 2013 may also give some inspiration http://www.academia.edu/4388853/OrientAL_-_Automatic_geo-referencing_and_ortho-rectification_of_archaeological_aerial_photographs All these three aim to very high quality and I am sure that there is also need for a more light-weight system. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Hi all, I talked with Kshitij about this idea at length. I am sure that he can do a good job. He has the programming skills and has academic background in image processing and computer vision. I am willing to co-mentor him. Kshitij, You did not include the extensions we discussed. Estimating the shift between two georeferenced images, matching rasters with vector datasets. On Mon, Jan 27, 2014 at 1:16 PM, Kshitij Kansal kansa...@gmail.com wrote: Hello Everyone I am an undergrad student in my Junior year of study. I have been involved with some research in field of Spatial Temporal Analysis of Images. I have been using the GDAL for various purposes, for quite some time now. I thought that now its time to contribute something to Open Source Community. So I started to think about the GSoC, 2014. As I started browsing the last year's ideas, one idea that I could relate was *Raster / Vector Geo-referencer on the Web*. *Motivation:* The main motivation behind this is that, among the very first things that are required in many remote sensing/geo-spatial related projects are geo-referenced images. Most of the images that we have are generally not referenced and hence we have to go to some tool and MANUALLY reference them with the help of some reference image. This generally takes a lot of time and most of the times errors do creep in. *Original Idea:* What has been proposed in this(as a part of GSoC'13 idea) was that we should provide two image, one reference image and other un-referenced image. Now with the help of this we should be able to geo-reference this unreferenced image by MANUALLY selecting the Control Points. Some thing like this : http://www.youtube.com/watch?feature=player_embeddedv=88gt1gj2dbs *Modified Idea:* Now what I felt was that, this idea can be made more innovative and useful if we can AUTOMATE this whole process of geo-referencing along with providing the option for manual selection. This is where the knowledge of Image Processing can help. There are various algorithms(like SIFT/SURF) which can be used for doing this. We can apply these algorithms and extract the GCP's and then geo-reference the images. Also, this thing has not been implemented in any of the other open source softwares(like GRASS,QGIS). So if we can implement this, other communities can build on these ideas or even adapt it. It would be entirely based on GDAL and completely reusable Furthermore, this idea can be expanded a lot in the sense that we should not not put restrictions to the number of bands in the images. Now what I mean by this is that reference image's bands may not be the same order of unreferenced. It should work with images of any number of bands. Any Comments or Suggestions or Feedback ? Anyone willing to help me in this? Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Well, I actually implemented this idea in Mirone long time ago. First with SIFT and later with the SURF module in OpenCV, but I really never tested much from the the point that some cases work well, others not so much. Anyway, you might be interested to look also into ASIFT. It looks promising http://www.cmap.polytechnique.fr/~yu/research/ASIFT/demo.html Joaquim Hi all, I talked with Kshitij about this idea at length. I am sure that he can do a good job. He has the programming skills and has academic background in image processing and computer vision. I am willing to co-mentor him. Kshitij, You did not include the extensions we discussed. Estimating the shift between two georeferenced images, matching rasters with vector datasets. On Mon, Jan 27, 2014 at 1:16 PM, Kshitij Kansal kansa...@gmail.com mailto:kansa...@gmail.com wrote: Hello Everyone I am an undergrad student in my Junior year of study. I have been involved with some research in field of Spatial Temporal Analysis of Images. I have been using the GDAL for various purposes, for quite some time now. I thought that now its time to contribute something to Open Source Community. So I started to think about the GSoC, 2014. As I started browsing the last year's ideas, one idea that I could relate was *Raster / Vector Geo-referencer on the Web*. *Motivation:* The main motivation behind this is that, among the very first things that are required in many remote sensing/geo-spatial related projects are geo-referenced images. Most of the images that we have are generally not referenced and hence we have to go to some tool and MANUALLY reference them with the help of some reference image. This generally takes a lot of time and most of the times errors do creep in. *Original Idea:* What has been proposed in this(as a part of GSoC'13 idea) was that we should provide two image, one reference image and other un-referenced image. Now with the help of this we should be able to geo-reference this unreferenced image by MANUALLY selecting the Control Points. Some thing like this : http://www.youtube.com/watch?feature=player_embeddedv=88gt1gj2dbs http://www.youtube.com/watch?feature=player_embeddedv=88gt1gj2dbs *Modified Idea:* Now what I felt was that, this idea can be made more innovative and useful if we can AUTOMATE this whole process of geo-referencing along with providing the option for manual selection. This is where the knowledge of Image Processing can help. There are various algorithms(like SIFT/SURF) which can be used for doing this. We can apply these algorithms and extract the GCP's and then geo-reference the images. Also, this thing has not been implemented in any of the other open source softwares(like GRASS,QGIS). So if we can implement this, other communities can build on these ideas or even adapt it. It would be entirely based on GDAL and completely reusable Furthermore, this idea can be expanded a lot in the sense that we should not not put restrictions to the number of bands in the images. Now what I mean by this is that reference image's bands may not be the same order of unreferenced. It should work with images of any number of bands. Any Comments or Suggestions or Feedback ? Anyone willing to help me in this? Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto:gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. +91-9494447584 17.2416N 80.1426E ___ 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] [RFC] [GDAL] Idea for GSoC, 2014
Hello Everyone I am an undergrad student in my Junior year of study. I have been involved with some research in field of Spatial Temporal Analysis of Images. I have been using the GDAL for various purposes, for quite some time now. I thought that now its time to contribute something to Open Source Community. So I started to think about the GSoC, 2014. As I started browsing the last year's ideas, one idea that I could relate was *Raster / Vector Geo-referencer on the Web*. *Motivation:* The main motivation behind this is that, among the very first things that are required in many remote sensing/geo-spatial related projects are geo-referenced images. Most of the images that we have are generally not referenced and hence we have to go to some tool and MANUALLY reference them with the help of some reference image. This generally takes a lot of time and most of the times errors do creep in. *Original Idea:* What has been proposed in this(as a part of GSoC'13 idea) was that we should provide two image, one reference image and other un-referenced image. Now with the help of this we should be able to geo-reference this unreferenced image by MANUALLY selecting the Control Points. Some thing like this : http://www.youtube.com/watch?feature=player_embeddedv=88gt1gj2dbs *Modified Idea:* Now what I felt was that, this idea can be made more innovative and useful if we can AUTOMATE this whole process of geo-referencing along with providing the option for manual selection. This is where the knowledge of Image Processing can help. There are various algorithms(like SIFT/SURF) which can be used for doing this. We can apply these algorithms and extract the GCP's and then geo-reference the images. Also, this thing has not been implemented in any of the other open source softwares(like GRASS,QGIS). So if we can implement this, other communities can build on these ideas or even adapt it. It would be entirely based on GDAL and completely reusable Furthermore, this idea can be expanded a lot in the sense that we should not not put restrictions to the number of bands in the images. Now what I mean by this is that reference image's bands may not be the same order of unreferenced. It should work with images of any number of bands. Any Comments or Suggestions or Feedback ? Anyone willing to help me in this? Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
