I've recently obtained Autodesk Recap360. It's basically a software package that stitches images from drones/multiple viewpoints together to make a 3D model. I think it's the slightly more advanced version of 123D Catch.
I've also got a drone, and in June of 2014 I flew a series of missions with it over my home. Since then I've not really known what to do with the large selection of images (overall, about 1000), so they've just sat on my hard drive waiting for something to happen.
Something happened when I was trying to make a bid for a drone for work. I had to price up the software available, and the hardware (...the flying bit). I looked at the usual suspects for drone imagery, Pix4D, Agisoft etc, but a new one popped up, Autodesk's Recap360.
Their system works in the cloud, so you upload your images to their servers, and tell it what to do, and about an hour later you get a lovely email saying it's done.
At the moment, their online viewing and editing tools are out of action, so I've not tried their georeferencing tools online (which is hopefully the easy way...). I went for the hard way.
When you process your data, there is the option for either a quick preview (which I guess is perfect for just making sure it'll all come out okay) or ultra (which allows you to do all the fancy stuff, including download the orthomosaics). Ultra costs credits, which I assume you top up and pay for (because I'm a teacher, I'm using it for education (it'll be used to teach my students about DEMs next year) I get it for free.)
When it's processed, you've got the option to download the products, such as OBJ files (I guess you could use it for making 3D prints of stuff too, which is cool), but more interesting is the .TIF download option.
What you get is 2 TIFs, one orthomosaic and one elevation model.
I use QGIS 2.8.1 as my main GIS software, which can happily open Tiffs. so it made sense to import them into that.
This is where it got a bit harder.
The orthomosaic went in just fine, 3 layers, red green and blue, just fine. They all looked good in the GIS (Apart from being mirrored, and un-georeferenced). Both of these problems were easily rectified by georeferencing it to Google Maps.
It referenced pretty well - with only 4 points, I had pretty good accuracy. I didn't do any serious work on it, just a quick 4 points in the corners, and checked it against where the roads were on an OS map, and it looked reasonable.
There are some oddities, such as the fence bordering on the road, but this is actually because the OS Street View map I'm using is an old one, and we moved the fence between the road and the path.
Apart from that, the fences line up well, etc etc. Not bad for 4 control points!
So far so easy.
Now things got a little trickier.
The Digital Surface Model.
I imported it the same way, it's a Tiff too, but I was greeted with this:
Very kindly, excel can put the formula on the graph too, and this is the formula I could use to calculate all heights from the weird values on the DSM.
y (real height) = 20.352 x the value on the DSM + 231.02. I'm sure there was an easier way of doing this, but it worked.
From this, I could calculate what the actual minimum and maximum values should be, from the -3.7 and +2.8. I thought it might allow me to simply put this formula into the Raster Calculator, and just create a new layer from that, but the result had the same "nan" and the error....
Luckily QGIS has a tool for the job. Enter "Grid Normalisation".
It obviously allows me to normalise the data, and luckily it does it from a known maximum and minimum, which we'd calculated using the formula.
This done, and my DSM was finally showing the correct height values! It was still in the wrong place, and mirrored, but hey! at least it was the right value! (+/- a few meters...)
Now it was just a matter of georeferencing it (which was done against the outline of the orthomosaic, as it is a hell of a job trying to georeference a flat field on a DSM... it is just featureless....).
The resolution is quite a bit lower on the DSM than the Ortho - the ortho is about 11cm, the DSM is 50cm. But, overall, it made a pretty little map, so I'm happy!
This was just from 150 of the photos, so I may try and run it again with more. ReCap360 has an upper limit of 250 photos, so it isn't going to be many more, but I might try and chose some from areas that aren't so well represented or are a little fuzzy.
The orthomosaic also has some odd artefacts around trees, where they look oddly pixelated, I think it is because of the way it is constructed. The images are formed into a 3D model, with flat faces, so if there is a slight lack of detail, the model is incomplete, and when viewed from above, it looks slightly like a model from a Playstation 2 game.
I can live with it though, for now.
I'm not sure what I'm going to use my newly georeferenced orthomosaic for...We shall see... but it's nice to have found a method that can potentially process drone images in an occasionally reliable way...
Now I just need to get the drone flying again
I've also got a drone, and in June of 2014 I flew a series of missions with it over my home. Since then I've not really known what to do with the large selection of images (overall, about 1000), so they've just sat on my hard drive waiting for something to happen.
Something happened when I was trying to make a bid for a drone for work. I had to price up the software available, and the hardware (...the flying bit). I looked at the usual suspects for drone imagery, Pix4D, Agisoft etc, but a new one popped up, Autodesk's Recap360.
Their system works in the cloud, so you upload your images to their servers, and tell it what to do, and about an hour later you get a lovely email saying it's done.
At the moment, their online viewing and editing tools are out of action, so I've not tried their georeferencing tools online (which is hopefully the easy way...). I went for the hard way.
When you process your data, there is the option for either a quick preview (which I guess is perfect for just making sure it'll all come out okay) or ultra (which allows you to do all the fancy stuff, including download the orthomosaics). Ultra costs credits, which I assume you top up and pay for (because I'm a teacher, I'm using it for education (it'll be used to teach my students about DEMs next year) I get it for free.)
When it's processed, you've got the option to download the products, such as OBJ files (I guess you could use it for making 3D prints of stuff too, which is cool), but more interesting is the .TIF download option.
What you get is 2 TIFs, one orthomosaic and one elevation model.
I use QGIS 2.8.1 as my main GIS software, which can happily open Tiffs. so it made sense to import them into that.
This is where it got a bit harder.
The orthomosaic went in just fine, 3 layers, red green and blue, just fine. They all looked good in the GIS (Apart from being mirrored, and un-georeferenced). Both of these problems were easily rectified by georeferencing it to Google Maps.
It referenced pretty well - with only 4 points, I had pretty good accuracy. I didn't do any serious work on it, just a quick 4 points in the corners, and checked it against where the roads were on an OS map, and it looked reasonable.
Apart from that, the fences line up well, etc etc. Not bad for 4 control points!
So far so easy.
Now things got a little trickier.
The Digital Surface Model.
I imported it the same way, it's a Tiff too, but I was greeted with this:
There were no values assigned to it, and when I opened the properties, I ended up with "bad allocation" and no property box. I tried exporting and reimporting it, no joy, still unchanged.
In the end, I thought, "I'll do this manually" and saved it as a .asc file. If you don't know, an .asc, or ASCII file is basically a text file, you can open it in Notepad, and edit it, but when you import it into a GIS, it is an elevation/raster file again. It's basically just a text file full of pixel values.
Because it is a text file, you can edit it easily in Notepad. The problem, I suspected, was the fact that the transparent parts of the image were set to "#INF", rather than -9999 which they are often set to, I guess QGIS doesn't like #INF as a numerical value, and maybe this was the reason it was throwing an exception.
So, find "#INF" and replace with "-9999". Suddenly, QGIS was quite happy opening this new file with -9999 as the transparent colour.
I could now change all the colours in QGIS, and georeference it as I pleased, but.... it ran on a scale from -3.7 to 2.8. So the lowest bit of the map was -3.7m below sea level, and the highest was just 2.8m. This is the North Yorkshire Moors! It should be higher than that by at least 100!
It was also reading -3.7 for the highest place, and 2.8 for the lowest....
I used QGIS's Raster Calculator to do "1 - the DSM layer" to invert it, so now it was the right way, but the scale was still wrong.
If I'd paid more attention in maths, I would know an easier way of doing this, but I didnt... So instead I compared another digital elevation model of the same place, and compared 2 areas: I looked at what my drone DSM said, and what the real one did, and came up with:
DSM value of -2.7083 corresponded with an actual height of 175.889m,
DSM value of 0.913 corresponded with an actual height of 249.6m.
Now I just had to figure out how to scale them both up, and now my brain left me.
So, I had to do it a slightly more cheaty, boring way, I made a graph.
y (real height) = 20.352 x the value on the DSM + 231.02. I'm sure there was an easier way of doing this, but it worked.
From this, I could calculate what the actual minimum and maximum values should be, from the -3.7 and +2.8. I thought it might allow me to simply put this formula into the Raster Calculator, and just create a new layer from that, but the result had the same "nan" and the error....
Luckily QGIS has a tool for the job. Enter "Grid Normalisation".
It obviously allows me to normalise the data, and luckily it does it from a known maximum and minimum, which we'd calculated using the formula.
This done, and my DSM was finally showing the correct height values! It was still in the wrong place, and mirrored, but hey! at least it was the right value! (+/- a few meters...)
Now it was just a matter of georeferencing it (which was done against the outline of the orthomosaic, as it is a hell of a job trying to georeference a flat field on a DSM... it is just featureless....).
The resolution is quite a bit lower on the DSM than the Ortho - the ortho is about 11cm, the DSM is 50cm. But, overall, it made a pretty little map, so I'm happy!
This was just from 150 of the photos, so I may try and run it again with more. ReCap360 has an upper limit of 250 photos, so it isn't going to be many more, but I might try and chose some from areas that aren't so well represented or are a little fuzzy.
The orthomosaic also has some odd artefacts around trees, where they look oddly pixelated, I think it is because of the way it is constructed. The images are formed into a 3D model, with flat faces, so if there is a slight lack of detail, the model is incomplete, and when viewed from above, it looks slightly like a model from a Playstation 2 game.
I can live with it though, for now.
I'm not sure what I'm going to use my newly georeferenced orthomosaic for...We shall see... but it's nice to have found a method that can potentially process drone images in an occasionally reliable way...
Now I just need to get the drone flying again
