Posts by: pierotofy

A new era of open source funding? How we raised $5,099 for core work.

 

As part of our mission to bring awesome drone software, we focus intensively on sustainability (a.k.a. how to pay for development, bug fixes, new features, hosting, etc. for the benefit of all).

Open-source is a tricky type of software to fund. I will not cover the details, as other people have already done a great job of summarizing the problem.

I have a keen interest in finding solutions to the open-source funding problem. In particular, how do you give more voice and decision-making power to the community? How can a community better steer the direction of the project? What features are worth implementing right away? What has value? What is noise?

When I stumbled on the idea of quadratic payments I knew that something interesting was up. The core ideas that came out of the quadratic payments paper as applied to open-source are that:

  • It’s not economically advantageous for people to directly fund open-source software. A system could make it advantageous by combining each pledge with additional funds from a sponsor pool. The additional funds optimally compensate for the value a pledge benefits other users. Example: if Bob makes a contribution ($25) for something that could be valuable to Alice, Bob needs to be compensated for the additional benefit that Alice gets ($25). So Bob’s pledge needs to be worth $50. More pledges lead to more overall value for everyone involved, making it economically advantageous for both Bob and Alice to pledge.
  • Pledging money toward the implementation of a feature/bug is not just a mean of payment, it’s also a vote of preference. It helps answer the question of “what’s important to me as a user?”.

So a month ago we built a platform to collect pledges from users and opened three funds with different funding goals. As excitement built-up, we successfully met the funding goal for one of the three funds with $5,099 worth of pledges.

Where does the “sponsor pool” money come from? It’s from one of the organizations that currently develops and benefits commercially from OpenDroneMap software. While ~90% of the funds come directly from this sponsor pool, the remaining 10% is community driven.

If you think this is not a lot, you might be missing the most important value of the funding process: the voting aspect of it.

As maintainers of FOSS we receive hundreds of feature requests. Time is limited however, so how do you prioritize? Thumbs up on GitHub / forum polling is a “one-person one vote” system, which is not ideal. If you let a single organization sponsor the development of a feature, you get a “one-dollar one-vote” system, which gives too much power to the single organization.

Quadratic voting is a fairer system. After the funding period has ended, we know what the community values and we know what to prioritize.

Oh, and we raised some funds in the process, too! Win-win?

We hope this model can be studied, improved and replicated in other FOSS communities. It could be the start of a new era of sustainable funding.

https://github.com/uav4geo/quadratik

Introducing the UAV Mapping Arena

 

With the help of several members of the community, today we have launched a simple tool to visually compare outputs processed with several drone mapping packages (including ODM, of course): https://opendronemap.github.io/UAVArena/

We are pleased with how far ODM has come over the years and hopefully this tool will continue to help track our progress, at least as a measure of “visual appeal” (up next, accuracy comparisons?).

WebODM Now Available As a Native Windows Application

 

Long time ago, when WebODM was still in its infancy, Windows was still my (Piero’s) primary development platform. As such, the very first versions of WebODM used to run natively on Windows, without docker. But as time went on, with docker entering the development/release process, Windows compatibility was placed aside and focus was shifted on getting docker to work less painfully on Windows (spoiler, it’s still painful).

Despite knowing that in theory WebODM could work natively on Windows , I don’t think anyone attempted to prove it. We’ve added a lot of stuff to WebODM since its old Windows-first days. Dynamic tiling, GRASS engine, background worker processes, message brokers, plugin systems, Python environments… none of which take Windows as a first-class citizen.

Curiosity… would it still work?

Well, I’m happy to report that, after some tweaks, the answer is

Thank you Keebler Elves! | nightshade

Not exactly a trivial endeavor, but the result is quite seamless:

  1. Run the setup.
  2. That’s it, there’s no other steps. Just run the software.
image
image

Ok, admittedly this requires that you have a processing node running NodeODM somewhere else, as we still haven’t managed to compile/run the full processing pipeline natively on Windows, this is just the user interface, but it’s a really important step toward full native support for Windows (which we have long-term plans for).

If you are used to the docker experience of installing WebODM, you might be seriously impressed by the simplicity of this new option.

The engineering feat is also quiet impressive, because getting WebODM to run natively requires:

  1. A web server
  2. A message broker service
  3. Multiple worker/scheduler processes
  4. A database (with PostGIS)
  5. A single Python environment
  6. An installation of GRASS
  7. Lots of smaller Python/Node.JS dependencies to work correctly

In particular, issues of compatibility had to be solved between GRASS’s Python environment and WebODM’s virtual environment, as the two can run in the same process space, but Windows does not like that at all. Piggy-backing GRASS’s Python environment to run all of WebODM’s other functions turned out to be a good solution and removed the need for multiple Python environments.

The application setups all of these requirements (with careful consideration for security as well, where strong passwords need to be set to protect from untrusted local users), launches the necessary services in the proper order and wraps the application using Electron. Voila’!

The windows setup is freely available from https://webodm.net. This is a first release, so a few issues are expected. If you find them, please report them.

Drone mapping for the rest of us

 

One of our community members, Zach Ryall, has covered OpenDroneMap in a recent article for AOPA (Aircraft Owners and Pilots Association).

Maps and mosaics are among the most powerful products a drone camera can produce, but producers of polished, user-friendly software made for professionals aren’t giving freebies anymore. Open-source software offers hobbyists and soloists an affordable alternative.

You can read the full article here: https://www.aopa.org/news-and-media/all-news/2020/february/28/drone-mapping-for-the-rest-of-us#

Small correction on the attribution of credits from the article: OpenDroneMap was founded by Stephen Mather and not me (I’d like to get this record straight). If it wasn’t for Steve’s commitment and vision for the project, we wouldn’t be reading this post (or this article, or anything OpenDroneMap related for the matter).

ODM 0.9.8 Adds Multispectral, 16bit TIFFs Support and Moar!

 

WebODM introduced support for plant health algorithms about a month ago. It was no secret that we concurrently started work to support TIFFs file inputs and multispectral cameras, both features that have been highly requested.

Today we are excited to announce the release of ODM 0.9.8!

TIFF Support

Up until now ODM was able to process only JPG files. With this release we added support for processing TIFF files, both 8bit and 16bit. TIFF is a popular format especially with multispectral and thermal cameras.

Mapir Camera 16bit TIFFs processed in ODM

Multispectral Support (Experimental)

We have added the ability to process multispectral images (for example those captured with a Parrot Sequoia, MicaSense Altum or RedEdge). We have obtained some promising preliminary results. When provided with N camera bands, ODM will generate an N band orthophoto (in the proper bit resolution, up to 16).

We have not added support for spectral calibration targets, which we plan to add in the near future and we’re currently looking to add support for more cameras. The task of identifying different bands is different for each camera vendor and we’ll need to add support for more cameras with time. We hope the community will start to process some datasets and help us improve multispectral support (share your datasets?)

MicaSense RedEdge 5 Bands processed in ODM

We recommend to pass the –texturing-skip-global-seam-leveling option when processing thermal/multispectral datasets. Global seam leveling will attempt to normalize the values distribution across orthophotos, which works well for making pretty RGB images, but will affect measured values in thermal/multispectral settings.

Split-merge Improvements

We rewrote from scratch the orthophoto cutline blending algorithm to merge orthophotos, a bottleneck that was causing processing to take longer than necessary in the last stage of the pipeline. The new algorithm is faster and much more memory efficient. We also sped up by a factor of 30x the time it takes to merge point clouds from submodels, as well as reducing memory usage drastically.

OpenSfM/MVE Updates

We brought the latest version of OpenSfM in this update, which delivers up to 1.6x faster image matching than before.

MVE has also been (finally) modified to report progress on the status of computations. You’ll finally know if the program is “stuck” or not.

Improved Brown-Conrady Camera Model

We made modifications to the camera model used to compute camera poses and points. Up until now the default in ODM has been to use a simplified perspective camera model. The community has been testing the usage of the brown-conrady model for a while, with great results. The original brown-conrady model however uses two parameters for specifying focal length, which are unfortunately not accurately supported by the texturing and dense reconstruction stages of the pipeline (a single focal length is used by those stages). We’ve approximated the brown-conrady computation by averaging the two focal lengths, but could we do better? Yes!

We modified the brown-conrady model to use a single focal length, bringing the model to full support for all stages of the pipeline and set it as the default camera model. We expect this will improve the quality of results for all outputs. Preliminary tests confirm this.

EPrfdJAW4AAKQZW
Credits: Klas Karlsson

Easier To Contribute to ODM

If you are on Linux, it’s now easier than ever to make a change to ODM. A new script setups a development environment for you inside a docker container.

And One More Thing: NodeODM Changes

NodeODM now exposes a task list API endpoint. This is a feature that has been requested a lot and allows people to view the tasks running on a particular node. If you send a task to NodeODM via WebODM (or CloudODM or PyODM, or any other client), if you open the NodeODM interface you will be able to monitor and manage the task. This is also implemented in ClusterODM.

We have also replaced the .zip compression method in NodeODM to be faster, more memory efficient.

What do you think of the new changes? Try them out and report any bug.

OpenDroneMap Update: Cloud Optimized GeoTIFFs, Plant Health, Histograms and More!

 

WebODM 1.2.0 has been released today. This is a major release update that brings some shiny new features to the platform, most importantly a large effort to write a dynamic tiling system (powered in large part by rio-cogeo and rio-tiler, thank you Vincent Sarago for the great software!) They include:

Cloud Optimized GeoTIFF support

COGs are “regular GeoTIFF files, aimed at being hosted on a HTTP file server, with an internal organization that enables more efficient workflows on the cloud.”. Sounds like a perfect match for WebODM. This feature in fact has been on the TODO list since mid-2018.

But what are “efficient workflows”? In WebODM’s case, the primary goal of using COGs is dynamic tiling; once we store our maps and elevation models using COGs, we can display (and manipulate) them in real time before serving them to end users. Which means no more static tiles and a lot of cool new features, such as plant health algorithms, dynamic hillshading, histograms, levels and color maps!

Plant Health

This feature has been asked over and over by our community members (we hear you!). We finally added support for Plant Health algorithms. The current list of algorithms is probably not comprehensive, but we made sure to set it up in a straightforward manner to allow for contributions even from non-developers. We look forward for feedback from the community for the addition of more algorithms.

People can apply the plant health algorithms to JPG images that were captured with a spectral filter. We are working to add full support for .TIFF inputs (both 8bit and 16bit) and for multi-camera captures, which will land in ODM within the next few months.

Histograms, Hillshading and Color Maps

Thanks to dynamic tiling we can now visualize rasters statistics with histograms (showing the distribution of values). We can also change colors and enable hillshading on-demand.

We can also stretch the color distribution to visualize better looking orthophotos (this feature is called levels in programs such as GIMP that do image editing).

Left: default orthophoto. Right: Histogram levels adjusted to stretch color distribution.

We are just scratching the surface of what we can do with dynamic tiles. Another cool thing we can do is choose a discrete color map (Pastel) and apply it to an elevation model.

Which highlights areas of similar elevation.

New Icons

We’ve updated the look of WebODM to use the newer version of Font Awesome! If you find missing icons, please let us know, it was a tricky upgrade to perform and we might have missed a few.

Take a moment to share this post with your followers on social media and update your copy of WebODM. As usual report any issues on GitHub.

Toward ODM 1.0 and Beyond

 

During this past summer, the OpenDroneMap team has been active on a number of fronts.

Split-Merge Improvements

While this feature has been announced months ago, we’ve been working on a number of improvements to make it more stable and fast. The distributed split-merge workflow in particular is non-trivial and has required a number of fixes to improve its reliability over time. The LocalRemoteExecutor (LRE) module is perhaps one of the most interesting modules in the codebase, allowing submodels to be processed with a mix of local and remote processing, working in sync with ClusterODM (which is now more fault tolerant).

Ground Control Points

GCPs kept confusing our users with respect to supported coordinate reference systems (CRS). The system only handled well UTM CRSes, but the software happily accepted others, some which worked, some which didn’t.

If you are a frequent user on our forum you might have noticed a significant decrease (disappearance?) of questions related to GCPs. That’s because without fanfare, we’ve improved significantly GCP support in July (see PR #997). You can now use whatever CRS you please and ODM will handle the rest.

Major Speed Improvements

Our friends at Mapillary have also been working throughout the summer and brought some really neat new features to OpenSfM. Among some of these, there’s Bag of Words (BoW) matching, which significantly boosts reconstructions lacking georeferencing information. Datasets captured with a handheld camera are now much faster to process. You will also notice speed-ups for processing normal drone datasets (unrelated to BoW matching).

Camera Calibration Transfer and Models

Up until recently, you might have had some difficulty processing datasets captured with fisheye cameras such as the ones found in GoPros or Parrot Bebop drones.

ODM now comes with support for 4 different camera models:

  • Perspective (default)
  • Brown (like perspective, but capable of handling more complex distortion models)
  • Fisheye
  • Equirectangular (spherical)

To use a particular camera model simply pass –camera-lens <type> (lower case).

image
Bebop dataset before latest changes. Problem?
image
Processed by passing –camera-lens fisheye. Better!

It’s also possible to transfer a camera calibration model computed from one dataset to process another. This is useful to process a dataset that was captured in less-than-ideal conditions (for which good camera calibration parameters cannot be computed), but for which a good dataset captured with the same camera exists.

A cameras.json file is now created and placed in the root folder of each project and that file can be reused to process another dataset via –cameras /path/to/cameras.json.

Automated Docker Builds

Since ODM takes a while to compile, we haven’t been able to leverage Docker Hub’s ability for automatic builds (due to system timeouts). So up until a few days ago we have been building and publishing docker images manually. But no more! Starting from last week, a dedicated build server checks for changes on the ODM and WebODM repositories and automatically builds, tags and pushes the latest changes in master to Docker Hub.

ODM Book

Last but not least, the first edition of OpenDroneMap: The Missing Guide has been published. Spanish and Portuguese translations are also on the way. This has been a very time consuming task, but one which we hope will help more people get the most out of OpenDroneMap.

Future Plans

The community has already provided tremendous feedback. We know what needs to be done and we will continue to listen to our users. Among some of the most requested features:

  • Better GCP interface / workflows
  • Quality/Accuracy reports
  • Override mechanism for EXIF coordinates (PPK)
  • Multiband (TIFF) image support
  • NDVI, VARI index support (and others)
  • WebODM interface/workflow improvements

If your organization uses OpenDroneMap and is in a position to help (financially or by dedicating a developer to a task), get in touch on the forum.

Share Massive Drone Captures Directly from WebODM with Cesium ion

 

Reposted from the Cesium blog.

We’re excited to announce that the latest version of WebODM (OpenDroneMap) now ships with support for 3D tiling with Cesium ion.

WebODM allows users to generate point clouds, 3D models, and terrain from aerial images. With this new Cesium ion integration, users can also fuse the data they’ve collected with other geospatial datasets, such as the Cesium World Terrain, all placed in an accurate global context.

This photogrammetry mesh of Malalison Island, Philippines, was tiled on Cesium ion and fused with the global Cesium World Terrain. See a live demo in your browser. Source data captured by the American Red Cross and processed with OpenDroneMap.

It’s also possible to layer multiple versions of data, which is useful if, for example, you’re monitoring an area by comparing scans from different points in time.

Even though such high resolution 3D data often comes in gigabytes, our new integration makes it easy to tile that data into 3D Tiles and host it with the Cesium ion platform directly from the WebODM dashboard.

Cesium ion plugin in WebODM

The latest version of WebODM now has a “Tile in Cesium ion” button which will tile and host massive 3D datasets in the cloud.

MicMac Support Lands in WebODM

 

Continuing our recent announcement about MicMac integration, today we are pleased to announce that support for NodeMICMAC in WebODM is now available!

We have started making changes to the NodeODM API to accommodate a more engine agnostic definition, which will continue in the future to improve the synergy between projects.

Existing WebODM users (using docker) can get up and running with MicMac by simply typing:

./webodm.sh update
./webodm.sh restart --with-micmac

Kudos to the DroneMapper team for the development of NodeMICMAC that has made this feat possible.

We look forward to hear the community feedback.

Stitching Historical Aerial Images From 1940 Using OpenDroneMap

 

During the recent OSGeo Code Sprint hosted at the University of Minnesota, we had the opportunity to learn more about the university’s effort to preserve some historical archives of aerial imagery.

We put our eyes on an old 1940 dataset of Hennepin County, Minnesota. The images are overlapping by about 20-30%. There’s also paper tears in many of the scans. We had never tried this before. Would it be good enough for ODM to process? We had to find out.

We quickly put together a script to download some of the images from the University’s online archive, add EXIF tags to the images and send them to ODM using the –fast-orthophoto option, which works well for high altitude flights and datasets with little overlap. We didn’t know what to expect. But a few hours later, when we saw the results, we knew it had worked!

Code available at: https://github.com/pierotofy/historical_aerial_downloader

GeoTIFF: https://drive.google.com/open?id=18UhkAR5jggOtgNvBzadEz-P-bymu14_m

Images credits to the University of Minnesota.