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.
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.
The latest version of WebODM now has a “Tile in Cesium ion” button which will tile and host massive 3D datasets in the cloud.
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!
With the 0.9 release of WebODM we are introducing the ability to preview and export contours directly from map view. This has been a much requested feature and we decided to take on the work to implement it.
Behind the curtains we used the GRASS GIS engine which already powers the volume measurement plugin to do the contours calculation, with some help from GDAL/OGR. The beauty of using a familiar language to power these computations is that it’s really easy (if you are familiar with GRASS) to understand how the information is calculated. No mistery. It’s all here.