[OSM-dev] [GSoC] Video based speed limit detector

Keshan Sodimana | කේෂාන් සෝදිමාන kesh.jboy at gmail.com
Thu Mar 31 17:14:07 BST 2011


2011/3/31 Kai Krueger <kakrueger at gmail.com>

>  Hi,
>
> I had a short look at the proposal. Looking at some of the sample project
> proposals on the GSoC page, it looks comparable in detail.
>

first of all Thank you for the response..


> Some thoughts of things you could consider mentioning in the proposal.
>
> - You might want to mention a thing about data collection. For one you will
> need some sample video to play around with and test how well things work.
> More importantly though, you will likely need data to train the detection
> and recognition algorithms on. As you will likely use some form of
> supervised learning algorithm for those, you will need a training set of
> labeled examples, which you will need to create. I'd hope that the community
> will help collecting some raw video material that can be used, but it will
> then need to be labeled. Alternatively, or in addition, there might be some
> standard training sets for street signs and speed limits, given that there
> appears to be a reasonable set of research literature on the topic.
>
> - It might be good to mention if once you have some basics going, if you
> want to take to project either more in the direction of building something
> that is fully integrated into the OSM editing ecosystem, or if you would
> rather take it more in the research direction of improving the quality of
> the detection algorithm, for example using more rich queues that the video
> gives you over the single image processing.
>

I would like to fully integrate this to OSM and also develop and improve the
quality of the algorithms in a different components but latter will be done
after GSoC. within this time frame i will totally focus in integrating this
system to OSM ecosystem.


>
> In that respect, it might be good to be slightly more specific on the
> deliverables, although you want to make sure that you don't over promise and
> leave enough freedom for inevitable changes along the line.
>

Since this is a quite a big project and can be extended further i am trying
to stick with few goals that means the main and the core idea.i mentioned
them in the proposal but i will extend this project even after GSoC to
accomplish other tasks such as improving the quality of the algorithms
extending the system to identify other signals.


>
> - You could also add a section to the end with a more speculative part of
> various possibilities of how the project could be extended in the future.
> Even though you are likely not going to be able to implement (all of) it, it
> might show that you have a good understanding of the topics involved and
> enough ideas to independently adapt if some of the things don't work out.
>

i will surely update my proposal within this weekend.


>
> You might also want to put the project related parts of the application on
> a public facing page to give more people a possibility to give suggestions
> and comments.
>
> But those are just some thoughts and it should be a good fun project to
> work on.
>
> Kai
>
>
>
> On 03/28/2011 09:08 PM, Keshan Sodimana | කේෂාන් සෝදිමාන wrote:
>
> Hi all,
> As i mentioned above. i drafted a project proposal and submitted it to the
> GSoC site. so it would be great if any potential mentor can review my
> proposal.feedbacks are welcome. here's the link to my proposal :
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/keshansanjaya/1#
> (i didn't make this proposal publicly visible)
>
>  Thanks !!!
> - Keshan
>
> On Tue, Mar 22, 2011 at 11:49 PM, Stefan de Konink <stefan at konink.de>wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> Op 22-03-11 08:33, Kai Krueger schreef:
>> > I'll possibly be able to mentor such a project, although I know little
>> about
>> > the code of any of the editors, so I'd be less able to help on that side
>> of
>> > things.
>>
>>  Since I was the mentor of the last project, there is a great number of
>> test material available to even build a recognizer. Video segmentation
>> is step two, not the first step.
>
>   Yes, the first step approach (and potentially even sufficient step)
> would be to treat each video frame as an independent still image.
>
> Do you still have the material and write up for last years project, as that
> project is clearly very relevant to this one and thus should be a good
> source of inspiration.
>
>
>   If someone isn't able to even find a
>> sign on a still image, it is even harder to do it on motion pictures.
>>
>   Depending on what you mean by "harder", not necessarily. Video gives you
> a lot of redundancy that you don't have in a still image. And so you can
> potentially accept a much higher false positive rate on the individual
> frames, as you combine the various predictions on the frames to reach a
> higher confidence, and thus you potentially can get away with a weaker
> detector.
>
>
>> For Dutch signs, and most likely many international ones on Wikipedia
>> SVG images do exist showing signs in the highest details possible. So
>> first things first:
>>
>>  - sign is present (x,y,w,h)
>>  - classify sign
>>  - segment video
>>  - enhance recognitionrate on multiple images
>>  - pinpoint the location of the sign in 3D
>>
>>
>> Stefan
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.16 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEAREKAAYFAk2I6C8ACgkQYH1+F2Rqwn3u/wCggw+qJzPbUuR60IzOclFlz3f8
>> i7gAnRm2+D2cBPWT3+Fd2hKIKdKghJqS
>> =reZv
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> dev mailing list
>> dev at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20110331/5beaadd5/attachment.html>


More information about the dev mailing list