Not using GPU feature extraction is likely to give a slightly better result, but it will take a bit longer with CPU.
I did see that same group of incorrectly placed camera positions on my first attempt with default settings.
How many features are you finding with those settings?
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
[Pieve di San Lorenzo a Monte - 6/2/2023](javascript:void(0)
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.
3 days to understand the issue is always a good chioce to help the community.
Iām running the pruned dataset⦠Wait some minutes and Iāll be back.
Finger cross!
Is this type of work something you do often? A multichannel GPS (often RTK) would likely help a lot with reducing multipath interference, which likely lead to some of the readings being so off.
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?
Achieving good results all the time can be frustrating. The community may be better able to help if you can post your console output log and quality report.
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 ā¦
Itād be really great if you could provide these data in an Issue on our GitHub so we can investigate further and try to reproduce the behavior youāre experiencing.
You can store the data anywhere you have sufficient space that is publicly accessible, like OneDrive, Google Drive, etc.
I can send you the āAll Assetsā, from #2 and the subsequent āAll Assetsā, from #3.
You might consider asking someone, that has experienced the same issues, using both #2 & #3, that also uses cloud service to repeat my actions(their data), and ask them to send you their data.
Possibly both ⦠there has been postings within this forum about the very same or very similar problems(WebODM2 correctly completing tasks/WebODM3 incorrectly completing the same tasks).
I donāt know of any others that might have saved āAll Assetsā, from WebODM2 and imported said zip file into WebODM3, resulting in errors, similar to errors similar the actual task as run in WebODM3.
Might you want to see the āAll Assetsā, if I can send them?