generated from fastai/fastpages
-
Notifications
You must be signed in to change notification settings - Fork 0
/
feed.xml
executable file
·1 lines (1 loc) · 8.57 KB
/
feed.xml
1
<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.1.1">Jekyll</generator><link href="https://jcpayne.github.io/aerial-survey-blog/feed.xml" rel="self" type="application/atom+xml" /><link href="https://jcpayne.github.io/aerial-survey-blog/" rel="alternate" type="text/html" /><updated>2021-08-11T18:54:52-05:00</updated><id>https://jcpayne.github.io/aerial-survey-blog/feed.xml</id><title type="html">AI for aerial surveys</title><subtitle>A project to develop an AI pipeline for aerial surveys</subtitle><entry><title type="html">AI for aerial surveys in the real world</title><link href="https://jcpayne.github.io/aerial-survey-blog/2021/07/31/AI-for-aerial-surveys-in-the-real-world.html" rel="alternate" type="text/html" title="AI for aerial surveys in the real world" /><published>2021-07-31T00:00:00-05:00</published><updated>2021-07-31T00:00:00-05:00</updated><id>https://jcpayne.github.io/aerial-survey-blog/2021/07/31/AI-for-aerial-surveys-in-the-real-world</id><author><name>John Payne</name></author><summary type="html">By John Payne</summary></entry><entry><title type="html">Current status</title><link href="https://jcpayne.github.io/aerial-survey-blog/2021/07/30/current-status.html" rel="alternate" type="text/html" title="Current status" /><published>2021-07-30T00:00:00-05:00</published><updated>2021-07-30T00:00:00-05:00</updated><id>https://jcpayne.github.io/aerial-survey-blog/2021/07/30/current-status</id><author><name>John Payne</name></author><summary type="html">Current status: ready for large batches After months and months of work, the project is finally at the point where we can run large batches of images through the pipeline. We have two working models: a heavy bounding-box model (TridentNet), and a much lighter and faster multi-label classification model (ResNet50 from fastai). Both can be used as is; they both have high enough accuracy (&gt;90% for the most important categories) and low enough false-positive rates (&lt;5%) to be useful. The classification model reduces the workload for the bounding box model by 95%. The multi-label classification model reduces the number of tiles that the big Detectron2 bounding-box model needs to check by almost 95% (&gt;98% reduction if you’re willing to ignore ‘uncertain’ tiles), and it is fast enough to be used in production. Both of those points are very good news, and it means we could even afford to throw in a random sample of ‘empty’ tiles for the big bounding-box model to double-check. It may not reduce the workload for humans as much. Only 4.8% of the total tiles are classified as ‘uncertain’, meaning that the model doesn’t classify them as anything, not even ‘empty’. Unfortunately, despite their modest numbers, those ‘uncertain’ tiles are scattered very evenly across files, with the result that about 1/3 of the images are empty, 1/3 contain objects, and 1/3 are a mix of ‘empty’ and ‘uncertain’ tiles. That means that effectively, the multilabel classification model only gives us a 1/3 reduction in the number of full-size images that we need to check. Depending on how we design the pipeline and what we decide to double-check, that may mean that the workload for humans is not reduced as much as the workload for the Detectron2 model. Our primary need at the moment is to find more training images. We will need to use the models to help with that process by churning through big piles of new images. We need to develop an environment for human-in-the-loop work. We have been exploring AIDE and Howard has also begun to work with the team at WildMe. Keeping track of edits to annotations is a very complicated problem. We need to improve the existing code. It needs to be made more modular, more stable, and to have some of the functions packaged properly, to make them easier to use by other people. -We need a more stable and solid pipeline. I have used the word ‘pipeline’ rather usely throughout this blog, but in reality we would like to move towards an automated Azure pipeline that makes it easier to pass data from one step to the next.</summary></entry><entry><title type="html">Creating a classification model</title><link href="https://jcpayne.github.io/aerial-survey-blog/2021/06/30/classification-model.html" rel="alternate" type="text/html" title="Creating a classification model" /><published>2021-06-30T00:00:00-05:00</published><updated>2021-06-30T00:00:00-05:00</updated><id>https://jcpayne.github.io/aerial-survey-blog/2021/06/30/classification-model</id><author><name>John Payne</name></author><summary type="html">Image credit: Tarique Sani (https://www.flickr.com/photos/tariquesani/6834426351/)</summary></entry><entry><title type="html">Slow inference and a new application</title><link href="https://jcpayne.github.io/aerial-survey-blog/2021/03/26/slow-inference-and-kazakhstan.html" rel="alternate" type="text/html" title="Slow inference and a new application" /><published>2021-03-26T00:00:00-05:00</published><updated>2021-03-26T00:00:00-05:00</updated><id>https://jcpayne.github.io/aerial-survey-blog/2021/03/26/slow-inference-and-kazakhstan</id><author><name>John Payne</name></author><summary type="html">Slow inference causes a traffic jam I was getting excited that we were ready to do inference and to finally deploy the model. I took a deep dive into Azure DevOps, Kubernetes clusters and web endpoints, and got as far as running the model in a container (which required ‘registering’ the model, among other steps). I was discouraged to find that it ran far too slowly, and upgrading the container with a GPU proved too difficult and expensive. So I abandoned that approach and decided to stick with working on VMs for now.</summary></entry><entry><title type="html">Training the model and sharing results</title><link href="https://jcpayne.github.io/aerial-survey-blog/2021/02/11/training-and-sharing-results.html" rel="alternate" type="text/html" title="Training the model and sharing results" /><published>2021-02-11T00:00:00-06:00</published><updated>2021-02-11T00:00:00-06:00</updated><id>https://jcpayne.github.io/aerial-survey-blog/2021/02/11/training-and-sharing-results</id><author><name>John Payne</name></author><summary type="html">Training the model Once the training and validation sets were created, the model customization was working, and I had learned how to use AML, I trained the model fairly hard on an AML cluster with 4 GPUs. The process did not go smoothly. Fixing learning rate problems The model didn’t improve much at first, and I realized that the learning rate was probably wrong. However, I didn’t have a good way to visualize results because the Detectron2 logger is self-contained and didn’t communicate with the AML cluster. To use AML’s visualizations properly, it would be necessary to intercept the Detectron2 messages on their way to its logger and share them with AML. I have since figured out how to do that, but at the time, I just wrote a bit of code to visualize both the output and the learning rate schedule once the run was finished. I then experimented quite actively with learning rate schedules. I found that I had misinterpreted some of Detectron2’s learning rate schedule parameters and the initial learning rate was too high. I eventually figured out where to aim (although it was a moving target, because the best rate dropped as the model improved), and training finally started going well. Dropping the ‘boma’ class and re-training In the US, a corral for livestock is usually made with fence posts and wire, but in subSaharan Africa, corrals are often made by piling up brush in a rough circle or rectangle. In Tanzania, those brush corrals are called ‘bomas’. Howard wanted to be able to identify bomas, and they were included in our object list. As the training proceeded, the model accuracy got up to 80-90% for most of the important classes, but there were still an unacceptable number of false-positives. Looking at the output, we quickly realized that most of the problem was in the ‘boma’ class. The model obviously recognized straight edges, but sometimes got the scale very wrong because at smaller scales, everything looks like a boma. We didn’t have a very big sample size of labeled bomas, and we decided that it was better to leave the class for another time. So we dropped it and retrained, starting by training the ROI heads with the rest of the model layers frozen. That fixed the false-positive problem and the accuracy got quite good. It’s currently above 95% for the common categories, with only 5 - 7% false-positives. The 05_aml_pipeline.ipynb notebook describes the training.</summary></entry></feed>