WebODM on PC With GPU enabled Version 1.9.18
Load and prepare mesh:
Reading PLY: 57466 verts… 113966 faces… done.
Generating texture views:
NVM: Loading file…
NVM: Number of views: 200
NVM: Number of features: 235962
This dataset tends to create unmatched reconstructions. Besides the matching issue that leaves a hole in the model, there is another issue related to merging reconstructions.
Previously, only the largest reconstruction will be used for following processing, but in newer ODM, it will try to merge all reconstructions into a single one and will cause noise especially when GPS is inaccurate. Trying to delete those misplaced cameras(images) could be helpful.
The EXIF file locations are spot on nadir shots and positions listed in EXIF, indicate straight down, where there are objects I can use to determine thusly … A QUESTION, for WebODM, is there a computational difference using a drone that records an absolute flight elevation as opposed to a flight Height over ground?
I have stayed on this site, simply because I have accurate GPS locations throughout, have surveyed in the area with RTK and this property was surveyed by another surveyor whom I worked with often. Pin locations are marked for aerials, and with NO CONTROL, more often than not, agree within 0.3 feet per hundred for the front and back pins(no more off than a foot in 155’). In ODM3, the locations vary greatly … 3 or more feet off, and with control sometimes 6 or 7 feet off. Same control in #2, and I’m back to about 1/2’ in 155 feet.
The middle 550 feet or so, is very brushy with a few large trees. I am considering clearing a few areas, and placing random TARGETS(not GCP), just targets for WebODM to get some computational footing(?).
Until I can decide I have the stamina to start a new business, I’m not about to play out the few thousand, for a single used RTK. I’m even less inclined to foot a $4000 plus cost of a low end RTK Drone.
So, right now this is a form of therapy … recreation … and sorry to say, after 10 years, re-learning everything … it’s all subtly different.
I HAVE run a project on WebODM2, which looks awfully good … it’s the second or third time I have done so … sometimes with no control, then with control … differences are minimal.
The EXACT same data in WebODM3, present differences that are drastic and in obvious error.
The last ODM2 data, was placed in ODM3 and the results are that 1/3 of the project is very good, but 2/3 of the project are atrocious and, of my runs of photos, it appears that about 100 or so photos have become clustered in a 10’ diameter space(2d view). Seven GCP’s appear to be shown correctly, but not a single photo is shown with the south 2/3 of this project.
In 3d view this group of photos appear to make the southern 2/3 of the project project incoherently on the side of a mountain. While 6 of my control points have minimal error, my south control point shows errors of 220 metersH and 119netersV … but the control point is good.
It seems to me that there a difference in the ODM2 and ODM3, that causes these issues. While ODM2 is rather consistent in results, ODM3 is “additionally”, inconsistent, with it’s differences.
My site is far from ideal, and is probably the cause of the bad results in ODM3.
The big issue I perceived in ODM3 was the better and correct representation of items, such as cars, etc… In those projects that work, or those parts of projects that worked, this is evident, and the reason why I’d like to pursue ODM3 … a specific flag or setting?
INTERESTING Results … importing of “All Assets”, from WebODM2 to WebODM3 …
A project in WebODM2, that looks about as good as it gets, with full coverage of the flown zone, and extremely close to good scaling, suddenly looks terrible in WebODM3 from an import of All Assets from ODM2 …
Photos in ODM2 are shown in the proper locations and drone “Elevation”, not the EXIF height from ground, but seemingly the same elevation given the takeoff height over ground elevation. In ODM3, the locations of these photos are terribly displaced …