search

OpenDroneMap / ODM

A command line toolkit to generate maps, point clouds, 3D models and DEMs from drone, balloon or kite images. 📷
https://opendronemap.org
GNU Affero General Public License v3.0
4.81k stars 1.09k forks source link

Issues with Multispectral Imagery using Micasense Altum #1241

Closed adamleemiller closed 3 years ago

adamleemiller commented 3 years ago

How did you install OpenDroneMap? (Docker, natively, ...)?

Natively on Ubuntu using an AWS instance as well as a Dedicated Server.

What's your browser and operating system? (Copy/paste the output of https://www.whatismybrowser.com/)

Firefox on macOS Big Sur

What is the problem?

We have some issues with multispectral when it comes to imagery from the Micasense Altum sensors. The main issue we have been seeing is that it does not seem as though it is labeling the bands correctly when it exports them. What we see is:

Blue Green Red Gray-0 Gray-0 Gray-0 Alpha

However, when we stitch the same imagery using Pix4D, we get this:

Blue Green Red Red edge NIR Thermal IR Alpha

Could this be an issue with Pix4d trying to read the file? What are the stitching settings you would recommend for the Micasense Altum? For reference, we are using the sample set available on the Micasense website to tune our ODM settings. We have tried stitching the imagery with no options set and then we have tried with minimal options set but there doesn't seem to be much of a difference.

We're also seeing another issue with RGB. When we upload imagery to be stitched that was captured by a DJI drone, it takes significantly longer to stitch compared to imagery coming from a higher megapixel Sony sensor. Even though the map is smaller, both in acres covered and GSD, it takes much longer on the same settings. The Sony image sets (399 images with 60MP per image) are .5 in/px GSD and 4.5GB in size and they take about 2.5 hours to stitch. The DJI image sets (1179 images at 20MP per image) are .75in/px and 3.8GB in size and take 20.5 hours to stitch. The only settings we adjusted are "Fast Orthophoto: True" and the GSD for the Orthophoto.

What should be the expected behavior? If this is a feature request, please describe in detail the changes you think should be made to the code, citing files and lines where changes should be made, if possible.

We expected to be able to load the stitched imagery into something like Pix4d which would allow us to see the individual layers essentially one layer per sensor from the Altum sensor.

How can we reproduce this? (What steps did you do to trigger the problem? What parameters are you using for processing? If possible please include a copy of your dataset uploaded on Google Drive or Dropbox. Be detailed)

We're ultimately using ClusterODM + NodeODM + ODM to stitch the image sets. We can try using strictly ODM but I am also wondering if it might be my installation itself though we have tried Docker and are still seeing the same issues as previously explained.

pierotofy commented 3 years ago

The band order is probably correct; we're just not writing the proper description of the band?

pierotofy commented 3 years ago

Could you share the output image from Pix4D for reference?

adamleemiller commented 3 years ago

Thank you for getting back to us quickly. I am working on getting the images from one of our testers in the meantime, we used the Altum image set that is available from the Micasense website: https://share.hsforms.com/1BO4oLyYbS_qz3QznxtTiBA3vejo - Ultimately, if it were just the names that were incorrect, I would think we would still be able to view the layers however, that is not the case. I will get back to you when I have the stitched images.

and-viceversa commented 3 years ago

This might need to be a separate issue, but I'd like to +1 anything to do with MicaSense Altum integration.

I've experienced the same band labeling issue with ODM, but the bands appear to be in the order you'd expect. We process Altum imagery with Agisoft Metashape (switching to ODM!), and band order seems to be Metashape == ODM. Guessing it's also true for Pix4D.

One way to get around the long Altum processing time in a photogrammetry engine is to pre-process the data yourself using the MicaSense imageprocessing library. The output is both band-stack reflectance TIFFs and True Color RGB .jpgs. This is preferable, because currently ODM does not allow you to take the MicaSense reflectance panel calibration image into account as far as I can tell. If it does, I haven't seen the docs for it.

I've had success processing the true color jpgs in WebODM. However, processing the band-stack tiffs throws an error. Plan on writing this up soon.

pierotofy commented 3 years ago

Band descriptions should be fixed with https://github.com/OpenDroneMap/ODM/commit/2032d355802fe8ba038d26505841f98ae16aa5e8

Support for this camera should also be much better with the latest release (2.4.7). Thermal bands should be able to be processed now.

I'm going to close this since it should be fixed. If not, please re-open. :pray: