Shooting large body of water problem

bring the drone up to 400ft (max legal limit) and shoot a grid for the missing area, making sure that each shot has at least a bit of a view of the land. Remove any shot that only has water (it will only throw off the reconstruction).

in absence of the possibility to take more shots, you could try --sfm-algorithm triangulation or --sfm-algorithm planar but I wouldn't count on it

Cheers, I'll give those a try👍

If you have good OPK angles, SfM triangulation could inadvertently work.

This was the result using --sfm-algorithm planar

And this was the result with --sfm-algorithm triangulation

It was worth a shot; I need to find some time to do more testing with OPK data which could help these cases like Yann was saying

If you can share these images, consider contributing to https://webodm.org/datasets this would be a good dataset to test

yeah can do

Here's a link, hope this will do https://www.dropbox.com/scl/fi/y9viqa6p1l1u8n3et80jk/26-04-13-Knypersley-Main-Pool-1.zip?rlkey=8in2k70kibnpr9bdcn54lybb2&dl=0

Awesome, can you also edit https://github.com/WebODM/Website/edit/master/data/datasets.json by adding a new entry with this link? I can help if needed

yeah i think I'll need help

can you tell me:

"name": name of dataset
"images": how many images
"size_mb": total size
"gcp": does it have GCPs?
"rtk": does it use RTK?
"notes": any other note? (water...?)

Name: Knypersley Main Pool 1 Images 100 size 408MB, no GCP, No RTK, Notes flown over water

Perfect, just updated the website

Always willing to help where I can

Can confirm that the Mini 2 has some weird Yaw/Pitch/Roll data in the EXIF : Gimbal is full or zeros, so I'm using Flight YPR angles, which aren't great, so triangulation won't do magic with such bad initialisation

When I started adding OPK support in ODM, I quickly realized that manufacturers never settled on any sort of convention or standard when storing YPR data. Even between the same camera models, but different firmware versions, you'll see completely different conventions; swapped axes, Flight vs. Camera vs. Gimbal data. It was a nightmare. I think the only way to make it reliable is to start a database that normalizes the data

I'm double checking the YPR, so wouild be good to have another Mini 2 dataset @Martin Reading (CRYO-GEN) if you have any by chance

Exactly, actually added this fix as a map [model make] -> (func(EXIF) -> YPR).

Then, started wondering if you could have a database of correction functions, so it would be an actual Python code file.

Correction functions would be the way to go

I'll sort another set when I get home, I guess any will do doesn't need to be over water, and let me know if I can supply any other data

Yes, any other dataset will be good

OK @YanNoun I'll post a link in here once I've sorted one 👍

Hi @YanNoun , here's another dataset as promised https://www.dropbox.com/scl/fi/b6k62d3rvw4jaosql8krj/26-04-08-Football-Pitch-to-roundabout-RH-side.zip?rlkey=1xlj5k4ynrorzms9xdp61uqw0&dl=0

Many thanks @Martin Reading (CRYO-GEN) I've been looking at several Mini 2 datasets and they all exhibits the same issue (Gimball angle to zero, so we read from Flight angle instead). I don't know if DJI did this on purpose to force people not to use Mini's to do mapping.

Nevertheless, using incremental reconstruction, it works fine with bigger overlaps (see screenhots). The Knypersley is challenging because of the weak overlap + water (and OPK angle can't save us), but that's the kind of data we need.

Knypersley | Some other Mini 2 dataset | Football Pitch

@YanNoun ,any data I can help with just let me know, I've just looked at the settings for Knypersley and front and side overlap is set at 70%, I normally use 80%,so may try that early next week when the weather here improves

I definitely need to add some overlap estimation in the quality report