Multispectral imagery Coming out with portions Yellow?

I’ve just purchased webODM and I’m working on processing some data collected with a P4 Multispectral.

The Flight:
The pictures we’re collected with individual pictures for R,G,B,RE, and IR. Flight was conducted with 80/80 overlap at 400’ above tallest point(terrain following is not available on the P4) and terrain was variable with upto ~300’ elevation change maximum. All pictures taken in 1 flight without landing.

The Problem:
I’ve processed it multiple times with changing the parameters slightly each time to see if it changes anything, but I keep coming out with about 3/4 of the ortho covered with a heavy yellow tint. There is a clearly defined line between the yellow section and the SW corner which appears to be processing correctly. It’s almost as if it is mixing up the bands for part of it.

I am also getting some strange swirling near trees, even on ultra-high, maybe this is an inevitability though with the density of canopy cover. According the the report only 34/108 images were used in the reconstruction.

The latest parameters:
Installed on Windows 10 via the WebODM installer
Multispectral +

  • debug: true,
  • feature-quality: ultra,
  • force-gps: true,
  • ignore-gsd: true,
  • orthophoto-compression: NONE,
  • radiometric-calibration: camera+sun,
  • rerun-from: dataset,
  • texturing-data-term: area,
  • texturing-skip-global-seam-leveling: true,
  • texturing-tone-mapping: gamma,
  • use-exif: true,
  • verbose: true

Area: 172,313m2

The Pictures:

The Log and Report:

I’m limited to 2 links right now, but I can also post the ortho in a reply if it helps.

Any help is greatly appreciated!

1 Like

Welcome!

Sorry you’re having trouble with multispectral processing.

I’ll try to take a look later today to help process.

Quick note that many get tripped up on:
If you’re going to process the individual bands (R/G/B/N/I), you can’t mix/match the RGB JPEGs in with them.

1 Like

Thanks for the reply Saijin_Naib!

I chose to fly without using the P4M’s RGB combined sensor. So Images were only captured in the separate 5 bands for this flight to save on storage space. Definitely a good note for the future though, I didn’t know that!

1 Like

Could you please re-upload just this image? The zip failed the CRC check for it:
image

I’m away from my computer for the next few hours, but I’ll upload it right away when I get back to it! Apologies for the error.

1 Like

Not your fault! Could be my internet being a jerk, too.

Once I grab it I’ll give it a go and see if I can work out what’s wrong.

1 Like

Here’s that image that was corrupted in the transfer:
https://www.dropbox.com/s/b1mfmm2gho6mi3d/DJI_1025.TIF?dl=0

1 Like

Are you positive this flight was 400’ AGL?

This seems… tight to the trees.

If we look at subsequent image pairs (Blue/Blue, etc), I’m not seeing the amount of similiarity I’d expect with 80/80 overlap/sidelap.

I’m feeling dumb now that I look at that image. The trees were ~100’ - 150’, but that’s definitely not a 400’ shot. Thanks for looking at that Saijin_Naib.

Settings were at 80/80 overlap, but terrain was highly variable and the flight app was quite restrictive. Probably nothing I can do to make this imagery process any better? Flight area is inaccessible for a while.

1 Like

No, all good.

I’ve sent my Solo up “400ft AGL” after taking the Winter season off at the farms only to go “Shoot, that’s looking high. Wow, yeah… So quiet, huh.” to then realize in horror it was 400m not foot :wink:

I’m trying again, but fundamentally… These are 4MP images really close to the subject with what looks like way low overlap/sidelap for their actual GSD.

oh yeah, been there done that!

Understood, I’ve got a couple other datasets from the same day that I believe I had a take off location for that allowed 400ft AGL for the entire flight plan - I’ll give those a whirl and see what happens.

Thanks so much for the help!

1 Like

Did anyone manage to solve the calibration issue with P4M images?

1 Like

It appears to be due to the lack of overlap, when I ran my other missions the data produced was not tinted yellow, so I’m not sure how this calibration difference came to be it seems to be due to the flight, not the software.

On a side note; When I ran the same low overlap mission using the “Fast Ortho” mode I was able to produce an ortho for the whole area. There were definitely some distortions, and some small holes, but it did produce something - and there was no yellowing to speak of.

1 Like

Welcome!

Like Mr7743 said, I don’t think we normally have terribly much trouble.

Are you having specific issues?

Start your own thread, provide us with your processing parameters and dataset (dronedb.app is what I recommend) and we’ll do our best to help!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.