I have four orthos produced from the same 119 test images flown with >80% overlap at tree canopy with same yaml.settings. Images were take Oct/16 mid-day, so sun was at lower angle creating strong shadows. 3 orthos were produced on same amd64 workstation with 32 vcores. J3455 was produced on 4 core Atom SBC
Each shows wildly differing results to the point of being unusable to observe tree health and location. Some trees simply disappear, others are quite tilted in one ortho straight in next, there are some mirages, trees do not align with ground observations even though natural ground points line up +/- 5 meters.
PNG ortho images will not upload to this posting
Any thoughts on how to improve the output and get some consistency would be welcome
I don’t think you will be able to achieve 100% deterministic results across separate machines (or even across separate runs). I’m pretty sure certain calculations (especially in the texturing module) contain some elements of randomness.
All but one ortho is produced on same workstation. Trees appear in one ortho, completely absent in another (0% deterministic?). Nothing is lining up with the field transects, allowing for GPS error. We have located & classified trees for health - green healthy, green attacked, red, gray, dead. Gray/red trees (easy markers) move all over the ortho by 20 - 30+ meters or even just disappear. In one ortho have a full tree crown right in a skid trail.
Tried 25d_mesh, but just produces random art images, don’t even look like trees. PMVS produces an ortho but has much lower detail/resolution and tree location is questionable, with trees appearing when don’t show in another view. Used both together, but still very distorted tree images.
Current settings are: #resize_to: 2400
resize_to: 2000 #start_with: ‘resize’ #end_with: ‘odm_orthophoto’ #rerun_all: False #zip_results: False #verbose: False
verbose: True #time: False
time: True #min_num_features: 4000 #default
min_num_features: 15000 #matcher_threshold: 2.0 # zombie code, does nothing #matcher_ratio: 0.6 #matcher_neighbors: 8
matcher_neighbors: 12 #matcher_distance: 0
matcher_distance: 250 #use_pmvs: False # The cmvs/pmvs settings only matter if ‘Enabled’ is set to True #cmvs_maximages: 500 #pmvs_level: 1 #pmvs_csize: 2 #pmvs_threshold: 0.7 #pmvs_wsize: 7 #pmvs_min_images: 3 #pmvs_num_cores: 4 # by default this is set to $(nproc) #mesh_size: 100000
mesh_size: 30000 #mesh_octree_depth: 9 #default - when pulls images off
mesh_octree_depth: 5 #mesh_samples: 1.0 #mesh_solver_divide: 9
mesh_remove_outliers: 3 #texturing_data_term: ‘gmi’ #texturing_outlier_removal_type: ‘gauss_clamping’ #texturing_skip_visibility_test: False #texturing_skip_global_seam_leveling: False #texturing_skip_local_seam_leveling: False #texturing_skip_hole_filling: False #texturing_keep_unseen_faces: False #default #texturing_keep_unseen_faces: True #? adds shelf to mesh around textured section #texturing_tone_mapping: ‘none’ #gcp: !!null # YAML tag for None #use_exif: False # Set to True if you have a GCP file (it auto-detects) and want to use EXIF
use_exif: True #dtm: False # Use this tag to build a DTM (Digital Terrain Model #dsm: False # Use this tag to build a DSM (Digital Surface Model #dem-gapfill-steps: 4 #dem-resolution: 0.1 #dem-maxangle:20 #dem-maxsd: 2.5 #dem-approximate: False #dem-decimation: 1
dem-terrain-type: ComplexForest #orthophoto_resolution: 20.0 # default Pixels/meter 20.0px/m = 5.0cm/px
orthophoto_resolution: 30.0 #orthophoto_target_srs: !!null # Currently does nothing #orthophoto_no_tiled: False
orthophoto_no_tiled: True #orthophoto_compression: DEFLATE # Options are [JPEG, LZW, PACKBITS, DEFLATE, LZMA, NONE] Don’t change unless you know what you are doing
Not sure what other parameters I should tweak to improve the forest orthos?
Will push test images and produced orthos to a shared drive and post.
Neither the SfM portion nor the texturing are deterministic, but the aforementioned orthophoto improvements should improve results overall, hopefully resulting in some convergence.
Are you saying that there is no determinism in the formation of the produced ortho and point cloud? While I don’t expect 100%, how could an engineer or forester utilize ODM if results are non-deterministic?
Results just become pretty pictures if there is no repeatability. How can a forester have any confidence in their log yard volumes if the results are all over the map? A researcher in tree location and condition? A civil engineer in their tailings pile volume?
I can adjust for locational shifts in the whole tree stand, but not for random tree locations that do not align with plotted ground observations.
Is this a product of the software engineering? How do we tight this up? Or is it the nature of SfM?
I am producing a fresh set of orthos with my settings to test the repeatability.
Tuned my test images to be all rotated north, which has yielded an ortho with seemingly better alignment to the ground observations. Will compare the next set of runs orthos.
Three runs, zoomed to a survey transect with plotted trees. GPS location to base of tree.
Red track is flight path
Cameras are where image was taken
Dotted purple line is the plotted transect
White line on the ground is actual transect line - ~3 meter error according to GPS
Green dots are live healthy trees
Light green dots are attacked but still alive trees
Red dots are red dead trees
White dots are gray dead trees
Interesting, when build orthos from a 10 image subset that covers the transect plot area, objects, aka trees, in ortho are more consistently placed across the three generated images. Still some tree tilt from which image tree was pulled from and location shifting likely due to GPS error. ODM builds the orthos et al in ~5 min vs 53 min for 119 images.
Only the transect start and end were GPS, rest were all directly measured down/off transect line. So any GPS error should shift all points together. All trees inside the plot box where measured and classified, aka should have a corresponding dot if existed in ground survey.
With 25d_mesh & pmvs → still have distorted tree crowns showing as whirls, but not so abstract. Only effects a few of the more outlier trees compared to 25d_mesh use on whole set of images
PMVS only on 10 image subset - yields the most stable orthos across 3 runs; still minor tree shift and a couple of questionable tree placements, noticeable missing tree in one ortho to the right; overall seeing a usable result once plots are realigned for GPS error
Processing time is also much quicker: 05:00 minutes vs 02:50, over 40% faster to produce full ODM run
My guess is that these inconsistencies are the result of not having a good mesh. Lower mesh values (5 is what you have these set to) are a useful trick to getting good orthos under certain circumstances, but in use cases like this are likely to cause a variety of texturing inconsistencies.
How tall are your trees, and what height did you fly at? (My hunch is the only solution is to wait for @pierotofy’s aforementioned fixes, but these details will help make that determination).
PMVS of sub-set images is still the most repeatable. With MVS, still have trees appearing/disappearing, tree shifts in location. Also a bit of mirage is showing. Crisper detail, but other problems make this choice not viable. PMVS is also much quicker: 02:59 vs 05:13
