Whenever ghosting occurs, the problem is related to band alignment. In multispectral datasets, sensors such as the Sentera 6x, take multiple pictures at once using different cameras, each capable of capturing a different part of the light spectrum. This enables us to have images for various bands such as red, green, blue and near infrared. The images however are not perfectly aligned, due to the relative position of the cameras and slightly different lens distortion.
ODM now includes state-of-the-art automatic band alignment using a hybrid approach of feature-based and Enhanced Correlation Coefficient (ECC) maximization alignment, which is capable of estimating the alignment parameters from a sample computed on a subset of the input images and applied to the entire reconstruction.
After alignment, things start to look much better!
After aligning the bands, we simply make sure that our orthophoto / texturing generation process uses the sections of one band consistently with all the others, and the ghosts are officially… busted!
If you’ve used OpenDroneMap in the past to process multispectral datasets and you’ve been less-than-enthusiast about the results… it’s time to give it another shot!
Chapter 2. Speed
We’ve also gotten a lot faster at processing these datasets too, courtesy of the awesome team at Mapillary which introduced more efficient multi-threading and a change in how we process multispectral datasets, which now require ~1/3 of the time compared to before. That’s a lot faster!
ODM is now also capable of generating Entwine Point Cloud (EPT) point clouds more quickly and with less memory usage, thanks to the awesome team at Hobu and their new Untwine software.
Chapter 3. AGPL License Switch
Starting from ODM 2.3.0, NodeODM 2.1.0 and WebODM 1.6.0, all three projects join the family of free software projects (which already included ClusterODM) that use the AGPL license.
This move is designed to continue guaranteeing the software freedom of our users in a world of ever-increasing cloud services. Despite some questionable claims of the otherwise, by certain large organizations, AGPL is an excellent license for an open source project such as OpenDroneMap (as this humorous blog post by Drew DeVault explains). This choice will continue to help OpenDroneMap be as open and inclusive as it possibly can.
Today we’d like to share an impressive open source UAV hardware and software project, possible thanks to the effort of Ryan Brazeal and supporters.
When we think of open source UAV hardware projects we usually think of small, classroom friendly, tiny drones. Well, this one is not a toy, but will give a run for the money to the most sophisticated and professional rigs.
OpenMMS “presents a single source of information that lists every nut, bolt, OEM sensor, and manufacturing step required to build a modern, tightly-integrated MMS [Mobile Mapping System] sensor. The project also includes a robust suite of novel open-source software applications that rigorously process the collected data and generate industry-standard geospatial deliverables”.
Now for the kicker: “The complete OpenMMS solution provides many of the same features and achieves the same (or better) accuracy specifications as comparable commercial systems. The hardware combines a lidar sensor, global navigation satellite system sensors, an inertial sensor, cameras, and computers, to create a tightly-integrated digital mapping tool. The software is easy to use, fast, supports multiple OS, and, when possible, leverages multi-core (CPU) and graphics card (GPU) processing.”.
While OpenMMS is an independent project, here at OpenDroneMap we’re fully committed to support other open source projects in UAV mapping. We have opened a community channel on our forum for OpenMMS that will provide a venue for users to talk and share ideas about the project.
We look forward to see what the OpenMMS team will bring up next.
Today we’re excited to announce a new major release of ODM! What have we been working on? Well a lot of things. The two most important ones are the ones we hope you won’t notice, because they don’t affect functionality, but have been part of necessary “infrastructure” updates to make sure that ODM continues to work in the future. Namely:
We’ve upgraded the codebase from Python 2 to Python 3. Python 2 has been deprecated and will not receive updates past 2020. With Python 3 support, ODM can continue moving forward with the rest of the Python ecosystem.
We’ve upgraded the base OS target from Ubuntu Linux 16.04 to 18.04. 18.04 will continue to receive extended security maintenance updates until 2028 and compatibility with 18.04 has been frequently requested from our community.
If you’re using docker, these changes are (should be) transparent. If you’re running ODM natively, you will need to upgrade your base system to 18.04 before updating ODM (or continue using a 1.x release of ODM until you decide to upgrade).
Aside from these important under-the-hood upgrades, we couldn’t make an important release such as a 2.0 release without adding something new and shiny!
Image Geolocation Files allow you to specify/override the GPS location of your images without having to fiddle with tools such as exiftool. This is different than using Ground Control Point files. With these you simply specify the location of the camera centers instead of the location of points on the ground.
Image Masks allow you to mask out areas that you don’t want to include in your reconstruction. This is useful in many scenarios. For example, during cell tower inspections, photos typically include parts of the sky, which end up creating strange artifacts and negatively affect the reconstruction. By using masks, one can delineate areas to exclude from a reconstruction, thus obtaining a clean and more accurate result.
A new option, –feature-quality automatically adjusts the image sizes for feature extraction based on predetermined ratios instead of relying on the user input or making assumptions about the image size.
Static tiles that were previously computed in NodeODM for use in viewers such as Leaflet or OpenLayers can now be generated via the –tiles option directly in ODM.
Aside from the speed improvements of having updated Python, PDAL, numpy and many other libraries, we’ve specifically improved memory usage in split-merge to handle even larger DEMs, have improved DEMs compression and improved speed/network stability in ClusterODM/NodeODM.
We’ve fixed numerous bugs and increased overall stability. See the related PRs for geeky details (#1156 and #124). We also cleaned up the ODM repository from old, large binary objects that were inflating the git repository. A git clone previously took 1.1GB of downloads, now it takes only 12MB. If you forked ODM, read this announcement as it affects you.
Give ODM 2.0 a try! If you find any issues, please report them on GitHub.
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?”.
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.
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
Not exactly a trivial endeavor, but the result is quite seamless:
Run the setup.
That’s it, there’s no other steps. Just run the software.
Ok, admittedly this requires that you have a processing node running NodeODM somewhereelse, 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:
A web server
A message broker service
Multiple worker/scheduler processes
A database (with PostGIS)
A single Python environment
An installation of GRASS
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.
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.
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).
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!
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.
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?)
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.
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.
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.
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.
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!
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).
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.
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.
During this past summer, the OpenDroneMap team has been active on a number of fronts.
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:
Brown (like perspective, but capable of handling more complex distortion models)
To use a particular camera model simply pass –camera-lens <type> (lower case).
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.
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.
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
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.