My latest project, pleased with the results
4 Likes
Just realised I never included the settings:
| Created on: | 02/10/2022, 16:24:26 |
|---|---|
| Processing Node: | node-odm-1 (auto) |
| Options: | auto-boundary: true, dem-resolution: 2.0, dsm: true, feature-quality: ultra, orthophoto-resolution: 2.0, pc-quality: ultra, rolling-shutter: true, rolling-shutter-readout: 26 |
| Average GSD: | 11.06 cm |
| Area: | 347,526.24 m² |
| Reconstructed Points: | 51,661,322 |
Also here is a link to the ortho on maphub
1 Like
How high were you flying to get 11cm GSD?
I’m thinking that with that GSD and a fairly fast readout time, the rolling shutter correction may not have made much difference, other than increasing processing time.
I just see a blank page on your maphub.online link
Hi Gordon, was flying at 285 feet AGL, is that GSD good or bad, that took 1:49:01 to process, as usual any help or advise much appreciated.
Strange on the maphub, shows ok here
1 Like
With ultra settings from that height, typically with many drones it would be more like 2-3cm, unless you used a camera with particularly large detector pixels?
With my M2P, I’d have to fly at 490m/1600’ for a GSD of 11cm.
Tried it in Firefox, where it loads, seems it only fails in Chrome. I think I had this problem once before.
Yeah strange how different browsers run things differently, it’s like your washout video won’t show in Firefox based browsers, but it’s fine on edge.
On the subject of GSD, from what I’ve read I’m guessing a lower number gives better definition, so how could I bring that GSD down, I’m flying a mini 2, mission was flown at 285 feet AGL, 75 front 70 side, max speed 20 mph, -70 gimbal
That is strange, since you should be seeing a GSD of just over 3cm. We need to figure out why the discrepancy!
On the original images, does it look like the pixels are about 3cm across, or 11cm? I don’t know what shutter speed you were using, but is there any motion blur?
Flight speed 9m/s means about 24cm of rolling shutter distortion in your images, or a negligible 2 pixels at the apparent 11cm GSD, and still <8 pixels at 3cm GSD.
Do you need super accurate geolocation for this task?
Can you re-run without rolling shutter corrections? It will complete in a lot less time.
That’s weird, I just tried it in FF on my computer, and it runs perfectly well.
1 Like
Ok rerun with no Rolling shutter & these are the numbers:
| Created on: | 05/10/2022, 17:43:47 |
|---|---|
| Processing Node: | node-odm-1 (auto) |
| Options: | auto-boundary: true, dem-resolution: 2.0, dsm: true, feature-quality: ultra, orthophoto-resolution: 2.0, pc-quality: ultra |
| Average GSD: | 11.08 cm |
| Area: | 347,329.48 m² |
| Reconstructed Points: | 52,636,249 |
Took 1:34:09
Dataset is available here
Cheers for your help as ever Gordon
2 Likes
Hi Martin, the images (finally downloaded after 5 attempts due to poor internet here), certainly appear to have a GSD of around 3cm, are sharp and well focused, so it must be something in the processing.
I’ll have a go at them in a day or 2 once the currently running task completes.
2 Likes
Thanks Gordon, appreciatedđź‘Ť
This looks about right-
Buxton Road
472 images 03:26:14
|Options:|auto-boundary: true, dem-resolution: 4, gps-accuracy: 8 , mesh-octree-depth: 13, mesh-size: 500000, min-num-features: 12000, orthophoto-resolution: 3, pc-geometric: true, pc-quality: high, resize-to: -1, use-3dmesh: true|
|Average GSD:|2.75 cm|
|Area:|347,341.42 m²|
|Reconstructed Points:|50,035,809|
3D textured model
1 Like
Thanks Gordon, I’ll give it a go my end using those settings and save them for future use👍
3 Likes
After Nearly 16.5 hours i cancelled it, memory usage was right on the roof with task manager showing 15.8 out of 16 in use and had been stuck as per screenshot for over 8 hours minimum
This was the last section of the log:
[INFO] Finished odm_filterpoints stage
[INFO] Running odm_meshing stage
[INFO] Writing ODM Mesh file in: C:\WebODM\resources\app\apps\NodeODM\data\bfcdab40-d1e9-4032-a482-b79d5002c6df\odm_meshing\odm_mesh.ply
[INFO] running “C:\WebODM\resources\app\apps\ODM\SuperBuild\install\bin\PoissonRecon” --in “C:\WebODM\resources\app\apps\NodeODM\data\bfcdab40-d1e9-4032-a482-b79d5002c6df\odm_filterpoints\point_cloud.ply” --out “C:\WebODM\resources\app\apps\NodeODM\data\bfcdab40-d1e9-4032-a482-b79d5002c6df\odm_meshing\odm_mesh.dirty.ply” --depth 13 --pointWeight 4.0 --samplesPerNode 1.0 --threads 11 --bType 2 --linearFit
[WARNING] D:\a\ODM\ODM\SuperBuild\src\PoissonRecon\Src\FEMTree.IsoSurface.specialized.inl (Line 1896)
IsoSurfaceExtractor<3,float,struct VectorTypeUnion<float,struct Point<float,3>,struct Point > >::Extract
bad average roots: 30
[INFO] running “C:\WebODM\resources\app\apps\ODM\SuperBuild\install\bin\OpenMVS\ReconstructMesh” -i “C:\WebODM\resources\app\apps\NodeODM\data\bfcdab40-d1e9-4032-a482-b79d5002c6df\odm_meshing\odm_mesh.dirty.ply” -o “C:\WebODM\resources\app\apps\NodeODM\data\bfcdab40-d1e9-4032-a482-b79d5002c6df\odm_meshing\odm_mesh.ply” --remove-spikes 0 --remove-spurious 20 --smooth 0 --target-face-num 1000000 -v 0
Will try it on my pc at home, when i get home in a couple of days time, this was on my laptop:
Windows 10 Laptop
Cosmos Series: 15.6" Matte Full HD, i7 Six Core Processor 10750H (2.6GHz, 5GHz Turbo),16GB Corsair 2666MHz, GTX 1650 Ti
1 Like
16GB RAM might be pushing your luck a bit! Let us know how you go on the pc.
1 Like
Will do, I’ve upped the virtual memory on the laptop, giving it another try, will see what happens
1 Like
Yes no doubt it was using the pagefile as memory for processing. on my linux ODM machine with 64 GB of ram I have seen more than 100GB of swap file space being used beyond the 64GB of ram.
1 Like