Mesh and Orthophoto anomalies

[rion-saeon]

Hi all,

my orthophotos contain strangely-COLOURed patches (there were some overcast conditions though) and TOPOGRAPHY in river datasets I ran through the latest ODM Master branch. I am inclined to say that the previous ODM version did a better job. Maybe there are some para's I can set to improve results? Also, the trees did not even appear in 3D like before?

Meshlab snapshot below:

[dakotabenjamin]

Try adding the parameter --mvs_texturing-skipGlobalSeamLeveling. This is a documented problem with MVS Texturing that has not been addressed. If you don't mind, could you post that image in the thread linked above as added documentation of the issue?

[dakotabenjamin]

@rionlerm nmoerhle says in their comment that

The issues of the other datasets look different to me, I belief that alignment (and thus the adjustment of non corresponding colors) is more of an issue there.

This could be attributed to three things IMO:

1. The images you are using are not calibrated. Have you tried that?
2. Your point cloud is not as accurate as it could be. Try --use-opensfm-pointcloud
3. The mesh being generated is not as accurate as it could be. This needs work on our end.

[rion-saeon]

Hi @dakotabenjamin ,I have been following some of the wrong colour testing you guys did.

1. Calibrated colour-wise or location-wise?
2. Tried --use-opensfm-pointcloud but, memory issues on my 4 cpu 12 GIG RAM PC even with 77 photos? I will try it again on this dataset though.

Must mention the --mvs_texturing-skipGlobalSeamLeveling solved some colour issues!

[dakotabenjamin]

Calibrating the camera to remove image distortion. This can cause alignment issues. I have a simple script here but there are other ways (Agisoft, for example, has an undistort function).

Try running --use-opensfm-pointcloud with only 1 core: --opensfm-processes 1

[rion-saeon]

Thanks for the responses @dakotabenjamin ,

I am going to attempt the script with checkerboard for undistorting my images and post here with --use-opensfm-pointcloud results.

Regards,
Rion

[rion-saeon]

Hi @dakotabenjamin ,

it seems like using the UAV's camera with broken cloud/sunlight conditions and nadir photos, produce very weird results as mentioned in the top of this issue however,

I reran the script with only --mvs_texturing-skipGlobalSeamLevelling and the results are very good in my eyes at 100 meters ATL!

I found that with my Intel i7 Quad Core processor and 12Gig Ram the --use-opensfm-pointcloud command could not process the 400 photos. Without the latter it could however, producing the following lovely results on a constant overcast day.

Click/Zoom into these screenshots for better detail!

True colour

false Normalised Difference Vegetation Index (NDVI)

[dakotabenjamin]

Did you try reducing the number of processes as well for --use-opensfm-pointcloud? I'd like to know because if there are issues then I do not want to completely switch over to that new algorithm just yet.

[LucasMM86]

@rionlerm let me ask you something, the "false NDVI" is done with the RGB camera or do you use a multispectral camera for a "real" NDVI?

[rion-saeon]

@dakotabenjamin I tried: --opensfm-processes 1 but, ODM didn't recognise the argument.

@LucasMM86 you are correct: false NDVI is from the RGB camera. A "real" NDVI uses the Near-infrared (NIR) sensor/band on a multispectral camera. By the way, this company produces add-on multispectral cameras for popular drones: https://sentera.com/dji-ndvi-upgrade/

What you might have noticed is that in this false NDVI image the red soils showed lower values than the more whiter soils even though they are both regarded as bare soil (we dont' care about soil colour). So a camera with a NIR sensor will produce a NDVI image where all bare soil (disregarding visible RGB colour) have similar low values (around 0), water even lower (<0 mostly) and green, healthy vegetation the highest index values (>0) in a true NDVI image.

So true NDVI is specifically used in e.g. agriculture to identify 'invisible' plant stress with lower values even though the RGB photos will produce visible green across the board and cannot discriminate between healthy and unhealthy vegetation.

In this case I am satisfied that the highest index values in this false NDVI (darkest blue) identified well with an exotic/alien plant we attempt to map after Dec. 2016-Jan. 2017 rains caused them to sprout in a wildlife area. They can be seen in the true colour image growing along the drainage line/dry riverbed leading down to the dam

[rion-saeon]

Problem persistence even with @smathermather's ODM integration?

I passed no runtime parameters such as skipGlobalSeamLevelling

[dakotabenjamin]

What version of ODM are you using?

[rion-saeon]

@dakotabenjamin I just noticed the Install Instructions have been amended and beta 0.2 implemented.

How do I register for updates on these new releases?

[dakotabenjamin]

I'm wondering if it is due to the odd shape of the output. You may need to disable global seam leveling.

[dakotabenjamin]

We usually inform users on the gitter and email list (which tbh hasn't been used much lately) opendronemap-users@lists.osgeo.org

[dakotabenjamin]

This is an old issue, so I will close for now. Please reopen if issues persist.

[dakotabenjamin]

This issue was moved to http://community.opendronemap.org/t/mesh-and-orthophoto-anomalies/401