added dl-annotator, status update on birdcall competition

[radekosmulski]

I created a new repository with an initial version of dl-annotator. Not sure if that's the best name - maybe someone would have a better idea on what to call it?

So many thoughts on this... The birdcall competition is a domain adaptation problem, but I think performance can be improved through cleaner train data (right now the labels are very, very noisy). I wanted to add the annotations on a couple of files myself to see how it would work out (and also in preparation for the upcoming work, to facilitate collaboration with researchers starting with the annotation process wanted to go through the whole ordeal myself).

But seems that Raven is not really designed for this purpose. It allows you to create pixel perfect annotations (where you can run measurements on what's inside of the bounding box you create), but the process is tedious. Maybe there is some way to use Raven like I wanted to, but upon reading the manual I couldn't find it... I don't think it exists.

Here is the workflow I envisioned -> I open an audio file, I play it and when I hear the sound of interest, I press the space bar to create an annotation. For deep learning, for many applications, if I can get the label to be close to the sound, that is way more than enough, it doesn't have to be perfect. I do however want a lot of labels - this workflow should be way more enjoyable than drawing those bounding boxes and should also allow to label data at scale.

Since AFAICT such a tool didn't exist, I hacked an early version of it together. Another set of related thoughts - we probably will need some tool building capability beyond voila anyhow, for some of the things we have tossed around. Why electron? I suppose it works really well and the apps can be user friendly and beautiful. As a tool for creating cross-platform apps, it is probably very decent. I have yet to come across a person who says they had a good time with PyQt and the apps don't look very nice. I got a book last week on electron, read a bit of it and a little bit on javascript (now I know what are arrow functions for instance or that something like promises exist 😄) but if we will require more Python integration we can always switch. As in - I think there is still value in exploring PyQt when an opportunity arises. Plus people are hacking together (and packaging for distribution) electron apps with a Python backend. Also, we have at least one team member whom I observed do magic with electron and I also believe another of our team members is also way better than I am when it comes to frontend based on my observation of him deciphering how jupyter notebooks work. I am not sure if our newest team member has experience with javascript but not sure how important it is at this point, whether we need to standardize on a platform for building applications already or whether we should spend some time in exploratory modus operandi (this is not the core of our work but rather a nice addition that can speed us and others along the way).

But these are only thoughts, nothing set in stone. This is a tiny application that has immediate use, whatever we use for building whatever we need next is an open question worth exploring (and probably relies heavily on the capabilities we will require).

With regards to the birdcall competition - the progress is slow. Lot's of code I am not even checking it in because it is so messy and I want the repo to be at least somewhat presentable. On a high level, the two things I am working towards are:

• training multiple generations of neural nets, when the child will ideally benefit from the work done by the ancestor
• training on cleaner data that I annotate using the app I created, to see what results this brings and to

I am also thinking about test driving some of the fabulous functionality from the representation toolbox but will want to refactor how I go about creating examples from audio before I head in that direction (to have results we can compare against).