Smathermather's Weblog

Remote Sensing, GIS, Ecology, and Oddball Techniques

Posts Tagged ‘ODM’

MSF Canada Drone Day follow-up

Posted by smathermather on July 13, 2015

Dirk’s MSF Canada Drone Day is officially the first blog post I have “re-blogged”. Please read: https://smathermather.wordpress.com/2015/07/13/msf-canada-drone-day/

or better yet here: http://dirkgorissen.com/2015/07/14/msf-canada-drone-day/

I had the pleasure of co-presenting with Dirk and Ivan, and the rest is well covered in Dirk’s post. It came together as an excellent day and I think you would be hard pressed to have had a better introduction to drones.

The day was valuable to me as an emerging practitioner. I learned more about the state of the art in hardware, software, regulations, philosophy, and RC control from this day, and it was inspiring to inhabit the same space with such dedicated practitioners for a short time.

Beyond the value of the workshop to the participants, the outcomes were the following, this quoted from Dirk’s post:

As a first milestone we are looking to pull together a proposal to the Humanitarian Innovation Fund in collaboration with OpenDroneMap and supported by the Missing Maps consortium.

I love the extension of ODM into this space. This is the real value of open source, the opportunity to collaborate across the world, across industries and use cases, and across organizations. Expect to see improvements to ODM in usability, performance, and output qualities from this initiative. More on this later.

Another outcome / learning for me was observing Ivan’s OpenUAV. From his repo:

This is intended to be a repository for design files, instructions, photos, documentation, and everything else needed for people wishing to build a and operate UAV (drone) in a low-income, resource-poor environment. This is not about cutting-edge UAVs, it’s about democratizing the technology and getting it into the hands of more people, particularly in poorer countries and humanitarian settings.

Photo of OpenUAV example

Ivan undersells it. This is a pro quality quad copter on a very nice price diet — a brilliant piece of pragmatic engineering.

This little quad copter will make its way into drone building workshops I’ll be offering in Cleveland and Columbus Ohio and Seoul, South Korea in August and September. More details forthcoming.

If you are in Cleveland, plan to be at FOSS4G Seoul, or Ohio GIS, come build Ivan’s capable quad.

 

(BTW, Ivan says with a couple of 4C 8000mAh batteries, this sucker flies for 50 minutes… .)

Posted in 3D, Bundler, Camera Calibration, FOSS4G, Image Processing, OpenDroneMap, OpenDroneMap, Optics, Photogrammetry, PMVS | Tagged: , , , , , , , , , | Leave a Comment »

OpenAerialMap, OpenImageryNetwork, MapKnitter, OpenTerrain, and OpenDroneMap (cont. 1)

Posted by smathermather on June 7, 2015

Citing my previous post, let’s move on to more specifics on my thoughts regarding the integration of OpenAerialMap, OpenDroneMap, and MapKnitter as projects.

Image from kite over Seneca Golf Course

OpenDroneMap ❤ OpenAerialMap.

OpenAerialMap will become a platform by which drone users can share their imagery under an open license.

So, as the metadata spec for OpenAerialMap and OpenImageryNetwork matures, and as soon as a publicly available place for drone users to push their data comes online, ODM will write appropriate metadata and geotiffs to go into OIN to be indexed by OAM. Probably as an added bonus, ODM should be able to optionally auto-upload outputs from to the appropriate node on the OpenImageryNetwork.

Lincoln Peak Vinyard

OpenDroneMap ❤ MapKnitter.

MapKnitter / ODM integration is pretty straight forward in my mind too. There are ways that MapKnitter complements ODM, and vice versa. ODM does not have a graphical user interface at this time. MapKnitter promises to fill that role in a future OpenDroneMap implementation. MapKnitter has no image blending or auto-matching tools. OpenDroneMap will soon have both.

  • Ways MapKnitter may help OpenDroneMap:
    • MapKnitter’s clever use of Leaflet to handle affine transformation of images is really exciting, and may help with improving final georeferencing for ODM datasets.
    • Regarding the above, one really useful thing for fliers launching balloons, drones, and kites without GPS would be the ability to quickly and easily perform really approximate georeferencing. I would envision a workflow where a user moves an image to its approximate position and size relative to a background aerial. ODM would be able to take advantage of this approximate georeferencing to optimize matching.
  • Ways OpenDroneMap could benefit MapKnitter
    • For large image datasets, matching images can be very tedious. Automatic feature extraction and matching can help. OpenDroneMap could be adapted to serve back match information to Mapknitter to ease this process. This will become increasingly important as MapKnitter raises the ~60 image limit on images that it can process.
    • A near future version of ODM will have image blending / smoothing / radiometric matching. For the server portion of the MapKnitter infrastructure, this feature could be a really useful addition for production of final mosaics.

These projects (plus OpenTerrain…) are really exciting in their own right. Together, they represent amazing opportunities to foster, cultivate, process, and serve a large community of imagery providers, from individuals and small entities capturing specific datasets using kites, drones, and balloons, to satellite imagery providers hosting their own “image buckets” of open imagery data. Exciting times.

Image over Groth Memorial from kite

Posted in 3D, Bundler, Camera Calibration, FOSS4G, Image Processing, OpenDroneMap, Optics, Photogrammetry, PMVS | Tagged: , , , , , , , , , , | Leave a Comment »

OpenAerialMap, OpenImageryNetwork, MapKnitter, OpenTerrain, and OpenDroneMap

Posted by smathermather on May 29, 2015

This tweet:

is the beginning of some fruitful discussion, I suspect. There are some really awesome projects gaining momentum. I’ll give an overview of them as best I am able.

Kite aerial photography image over bridle riding ring.

Kite aerial photography image over bridle riding ring.

Let’s start with the one nearest and dearest to my heart (if you’ve been reading my blog, you can skip this part): OpenDroneMap. OpenDroneMap is an open source toolkit for processing drone, balloon, kite imagery into geographic data. It does this by using fully automated feature-matching between images, which create a 3D point cloud. From that, we can create a 3D surface (mesh), textured mesh, and orthophoto. This guy says it better:

But, it’s just a stand alone, Linux (Ubuntu)-based tool. It requires some geekiness to run, and it does not (at least not yet) act as a platform.  By that I mean, generically, you can’t just upload images to it and get the wonderful output from a service, and we don’t have a place to store and share all this wonderful data that comes from and will be coming from drones and other aerial platforms. This is where (from my selfish perspective) the other projects are so well timed… .

Screenshot of DevelopmentSeed's introductory post for OpenAerialMap

Let’s start with OpenAerialMap. From the Development Seed blog post on it (yes, you should follow the link. Don’t worry, I’ll wait until you return):

OpenAerialMap is a set of tools for searching, sharing, and using open satellite and drone imagery. This initial release includes the core infrastructure to catalog petabytes of open imagery. It also includes an extremely usable API and an elegant web interface to submit, search and download available imagery.

This is a reboot of a couple of previous attempts at solving this problem space, and it’s really exciting to watch passionate and brilliant work take place to make this happen. Also, this is not an easy problem space, and is being really thoughtfully simplified and implemented.

(As a side note, I’m not going to get into the distinction between OpenAerialMap and OpenImageryNetwork — not today anyway)

Preview of Open Terrain tumblr page

Preview of Open Terrain tumblr page

 

Open Terrain is a project for which a portion of its scope is to do for terrain models what OpenAerialMap and OpenImageryNetwork will do for open aerial datasets. The projects are informing each other and growing together, which is awesome collaboration to observe.

Finally, Mapknitter has recently been rebooted too, and it’s now a really elegant tool for taking a few aerial images and knitting them into a usable map (ok, it always was p. cool — now it’s even more elegant). What’s great about MapKnitter is it specifically addresses the problem of georeferencing balloon, kite, or drone images in a simple-to-use interface in the browser.

Snapshot of MapKnitter landing page

So, back to the question:

Bravo, yes. Lets. I have been thinking about, talking to people, discerning the strengths, overlaps, and complementary fittings of these projects as they have emerged. We are headed toward some really great things… . More specific thoughts to come.

Posted in 3D, Bundler, Camera Calibration, FOSS4G, Image Processing, OpenDroneMap, Optics, Photogrammetry, PMVS | Tagged: , , , , , , , , , , | 1 Comment »

OpenDroneMap Video for FOSS4GNA

Posted by smathermather on March 6, 2015

Thanks to some brilliant work by our Interpretive Technology Technician, we now have a little video for FOSS4GNA on OpenDroneMap. Come see my presentation next week in San Francisco, Weds. at 13:30 (1:30PM):

odm_screenshot

Posted in 3D, Bundler, Camera Calibration, FOSS4G, Image Processing, OpenDroneMap, Optics, Photogrammetry, PMVS | Tagged: , , , , , , , | 6 Comments »

OpenDroneMap — GCP file format

Posted by smathermather on March 1, 2015

Introduction:

So much documentation to catch up on for OpenDroneMap. Probably the most important missing element is documenting the ground control point file format. This will be a file name gcp_list.txt to be placed in the root of the image directory that you are processing.

Objective:

The ground control point file associates locations in the input raw images with geographic positions, allowing for the output of an orthophoto and georeferenced mesh. It can augment or replace the need for geographic coordinates in the exif headers of the input images.

Format

I mention this file briefly in a previous post, but let’s get into the weeds a bit on how to create one. The format is a simple text file. The header, or first line, is a descriptor of the coordinate system. This is not a formal thing, so don’t worry about format for this line.

The subsequent lines contain the x, y, and z of the ground control location in your local coordinate system, the pixel and line number of the location in the image, and the imagename itself. A minimum of 3 GCPs is necessary:

x y z pixelx pixely imagename

So, for example, if I mock up a version for the Langley dataset, I get something like this:

WGS84 UTM 10N
544256.7 5320919.9 5 3044 2622 IMG_0525.jpg
544157.7 5320899.2 5 4193 1552 IMG_0585.jpg
544033.4 5320876.0 5 1606 2763 IMG_0690.jpg

Note that my elevations are all the same. I was lazy, and assumed that there’s minimal topography and Langley, and that we are 5 meters above sea level. It is far better to put real values here, derived from an elevation dataset.

More on the how:

So, how to get these numbers? I loaded my raw unprocessed jpegs into QGIS. As I mouse over the image, it gives me coordinates, like “3044 -2622”. These are pixel values. I ignore the sign on the Y value.

For the X and Y values, I just used a Leaflet slippy map with a lat/lon pop-up: http://smathermather.github.io/leaflet-test/index.html. It would be better if I had GPS values from the field (preferably map grade) or survey values, but this quick and dirty adaptation of http://leafletjs.com/examples/quick-start.html will at least get my map in the correct part of the world. I plugged the lat/lon values I get into Montana State’s UTM converter, though this is a slow method if I am doing a lot of points.

Screenshot of coordinate collection process

Screenshot of coordinate collection process

Screenshot of coordinate collection process -- a total of 3 points have now been collected.

Screenshot of coordinate collection process — a total of 3 points have now been collected.

Finally…
Finally, I save my text file as gcp_list.txt, save it in the directory that contains my raw images, and run the run.pl script, and sit back and get some coffee. Output will be a subdirectory with a name similar to reconstruction-with-image-size-2400-results.

Edit:
And now I’ve added this to the wiki: https://github.com/OpenDroneMap/OpenDroneMap/wiki/Running-OpenDroneMap

Posted in 3D, Bundler, Camera Calibration, FOSS4G, Image Processing, OpenDroneMap, Optics, Photogrammetry, PMVS | Tagged: , , , , , , , | Leave a Comment »

OpenDroneMap — Now with animated GIFs

Posted by smathermather on February 20, 2015

Ok. I confess, clickbait. OpenDroneMap won’t make the animated gifs for you. But come on! it can make the 3D models which you can view in Meshlab or where ever, and then create animated gifs. Ok ok. I promised animated gifs. These are from data contributed to our test dataset repo by  Aaron Racicot and Tomasz Nycz respectively.

View of 3D textured surface model of Langley, BC

View of 3D textured surface model of Langley, BC

3D of kite aerial photography dataset

3D view of farm from Kite Aerial Photography (revised description)

 

Posted in 3D, Bundler, Camera Calibration, FOSS4G, Image Processing, OpenDroneMap, Optics, Photogrammetry, PMVS | Tagged: , , , , , , , | 7 Comments »

OpenDroneMap — Orthophotos, textured mesh, ground control points, oh my!

Posted by smathermather on February 7, 2015

Spotscale’s texturing, orthophotos, and ground control have landed on the main branch for OpenDroneMap. No docs written yet, but an orthophoto and properly oriented textured mesh will be autogenerated just by running it on data with GPS ephemeris. Documentation yet to come on using ground control points for balloons, kites, and lower end drones, but expect that early next week.

Snapshot of untextured mesh, Seneca test dataset

 

Snapshot of textured mesh of Seneca test dataset

(edit: for the record, this is my pi post — my 314th post on my blog)

Posted in 3D, Bundler, Camera Calibration, FOSS4G, Image Processing, OpenDroneMap, Optics, Photogrammetry, PMVS | Tagged: , , , , , , , | Leave a Comment »

OpenDroneMap — Orthophotos and GCPs

Posted by smathermather on February 4, 2015

No docs yet for orthophoto generation and the use of GCPs in OpenDroneMap, but for the early adopters, check out this branch of OpenDroneMap:

https://github.com/OpenDroneMap/OpenDroneMap/tree/ortho-gcp

The format of the GCP file is simple. The header line is a description of the coordinate system (nothing formal here). Subsequent lines are the X, Y & Z coordinate in your coordinate system, your associated pixel and line number in the image, and the image name itself:

WGS84 UTM 17N
306285.997948 4545379.373772 218.375076 755 1159 IMG_0541.jpg
306086.87645 4545305.068275 220.971863 1874 1508 IMG_0548.jpg
306286.079002 4545211.102966 222.374451 1650 2381 IMG_0605.jpg
306258.256744 4545357.435387 218.836639 1763 2603 IMG_0513.jpg
306323.770813 4545246.277000 222.837692 543 2326 IMG_0521.jpg

 
For your edification, the schematic of ground control for Michele M. Tobias & Alex Mandel’s Cole Oil Point Reserve dataset.

Image of ground control over Coal Oil Point Reserve dataset

Posted in 3D, Bundler, Camera Calibration, FOSS4G, Image Processing, OpenDroneMap, Optics, Photogrammetry, PMVS | Tagged: , , , , , , , | 1 Comment »

OpenDroneMap — Orthophotos and Textured Mesh (Habitats)

Posted by smathermather on February 4, 2015

ODM shows some promise in mapping out microhabitats as on display with Michele Tobias & Alex Mandel’s dataset of hot air balloon derived images of Coal Oil Point Reserve, Goleta, CA.

Here is one of the raw images:

Raw aerial image of beach from hot air balloon

And here’s a visualization of the small topographic and surface model variation derived from using ODM from the dataset.

Mesh of small scale beach structure

 

edit: I’m really looking forward to trying this out in sedge habitats… .

Posted in 3D, Bundler, Camera Calibration, FOSS4G, Image Processing, OpenDroneMap, Optics, Photogrammetry, PMVS | Tagged: , , , , , , , | Leave a Comment »

OpenDroneMap — Orthophotos and Textured Mesh (testing…)

Posted by smathermather on February 4, 2015

A few new features are about to land on OpenDroneMap. Among those features, we have great work led and implemented by Spotscale for orienting our textured meshes so that Z is up:

Screenshot of georeferenced textured mesh

and auto-exporting an orthophoto when GPS ephemeris is available in our input images:

Screen capture of orthophoto from Seneca test dataset

——-

Next step — testing the input of ground control points in order to output fully referenced and orthorectified imagery. Stay tuned.

Posted in 3D, Bundler, Camera Calibration, FOSS4G, Image Processing, OpenDroneMap, Optics, Photogrammetry, PMVS | Tagged: , , , , , , , | Leave a Comment »