Casi particolari: vegetazione, acqua, edifici e rolling shutter

I preset di WebODM funzionano bene su terreni con buona texture, volo nadir regolare e camera con otturatore meccanico. Appena esci da quel caso (un bosco, un lago, un campanile, un video di una GoPro) i default producono buchi, deformazioni o ricostruzioni fallite. Questa guida raccoglie i casi difficili più comuni e, per ciascuno, le scelte che fanno la differenza. La regola generale vale sempre: molti problemi si risolvono meglio in fase di volo che in fase di elaborazione.

1. Vegetazione#

Perché è difficile. Le foglie si muovono tra uno scatto e l'altro, hanno texture ripetitiva e producono poche corrispondenze affidabili. Il risultato tipico: poche feature, immagini non ricostruite, nuvola rumorosa e DTM impossibile perché il terreno non si vede.

In volo. Aumenta la sovrapposizione (80/70 o più), vola più alto con GSD comunque adeguato (più contesto per immagine), evita vento e ore con ombre lunghe. Per il DTM sotto bosco la fotogrammetria ha un limite fisico: dove il suolo non compare in nessuna foto, non c'è nulla da ricostruire.

Opzioni.

Il preset "Forest" di WebODM parte da scelte simili. Ricorda che il DTM sotto vegetazione fitta è una stima: dichiaralo nella relazione (vedi accuratezza e validazione).

2. Acqua#

Perché è difficile. L'acqua non ha texture stabile: riflette il cielo, si muove, cambia tra uno scatto e l'altro. Il motore non trova corrispondenze e la nuvola resta vuota o piena di punti casuali. Nell'ortofoto compaiono buchi o macchie; nel DSM picchi e crateri.

In volo. Non puoi cambiare l'acqua, ma puoi limitare il danno: assicurati che ogni foto contenga almeno una porzione di terra o di strutture fisse; evita che intere strisciate siano solo acqua; volare con cielo coperto riduce i riflessi.

Opzioni e strategie.

• Mascherare l'area con --boundary: disegna in QGIS un poligono GeoJSON che escluda lo specchio d'acqua e caricalo; l'elaborazione ignora ciò che sta fuori e i buchi spariscono perché quella zona non esiste nel prodotto. --auto-boundary calcola un confine automatico intorno alle posizioni delle camere, utile lungo coste e fiumi.
• Accettare i buchi e riempirli nel DEM con --dem-gapfill-steps alto: l'acqua è piatta e l'interpolazione tra le rive è plausibile. Nell'ortofoto i buchi restano trasparenti.
• Nuvola: --pc-filter più basso rimuove i punti spuri; in alternativa pulisci la nuvola in CloudCompare.

Non provare a "risolvere" l'acqua alzando la qualità: non c'è informazione da estrarre. Per piscine e canali stretti basta l'interpolazione; per laghi e mare, la maschera.

3. Superfici uniformi: neve, sabbia, tetti, asfalto nuovo#

Perché è difficile. Come l'acqua, ma ferma: poche feature distinguibili, corrispondenze ambigue (un punto di neve assomiglia a tutti gli altri). Il rischio è una ricostruzione con poche immagini o un modello deformato.

In volo. Sovrapposizione alta (80/75), foto oblique aggiuntive che inquadrino elementi fissi, target a terra numerosi e ben visibili (sulla neve: target neri). Su tetti industriali uniformi, includi nel volo i bordi dell'edificio e il terreno intorno.

Opzioni.

Se il motore ricostruisce solo una parte delle immagini, verifica quali nel report (sezione features/matching) e valuta un volo integrativo.

4. Edifici e facciate#

Perché è difficile. Con sole foto nadir le facciate non sono visibili, i bordi verticali risultano "tirati" nell'ortofoto e la mesh dei muri è povera. Cortili e sottotetti restano in ombra.

In volo. Aggiungi foto oblique (camera a 45° circa) in una o più orbite intorno all'edificio, oppure una doppia griglia con camera inclinata. Mantieni una sovrapposizione elevata tra oblique e nadir. Per facciate alte, orbite a quote diverse.

Opzioni.

Il preset "Buildings" di WebODM è un buon punto di partenza. Vedi anche la guida al modello 3D.

5. Rolling shutter#

Perché è difficile. Molti droni consumer hanno un otturatore elettronico a tendina (rolling shutter): il sensore viene letto riga per riga in alcuni millisecondi e, se il drone si muove, l'immagine è leggermente distorta. A bassa precisione non si nota; con GCP centimetrici diventa il primo limite e produce errori sistematici, specie in quota.

In volo. Riduci la velocità, vola più alto, scatta con tempi rapidi, evita il vento. La soluzione definitiva è una camera con otturatore meccanico o globale.

Opzioni.

• --rolling-shutter: attiva la correzione, stimata dal tempo di lettura del sensore e dalla velocità del drone.
• --rolling-shutter-readout <ms>: tempo di lettura in millisecondi. Con 0 (default) il motore usa il proprio database per la camera rilevata dall'EXIF; se la camera non è nel database, la console lo segnala e devi indicare il valore a mano, cercandolo nella documentazione ufficiale o misurandolo.

Verifica con check point prima e dopo: in alcuni dataset l'effetto è minimo e la correzione può introdurre rumore.

6. Camere fisheye e 360°#

Perché è difficile. Il modello di camera predefinito (prospettico con distorsione radiale) non descrive un'ottica fisheye o una camera sferica. Con il modello sbagliato la calibrazione non converge e il modello si deforma.

Opzioni.

auto legge l'EXIF e sceglie il modello; se l'EXIF è povero o la camera è insolita, impostalo a mano. Le camere 360° producono nuvole meno dense e ortofoto meno utili: vanno bene per interni, strade e documentazione rapida, non per rilievi di precisione. Le immagini fisheye vanno lasciate non corrette dalla camera, perché sia il motore a modellare la distorsione.

7. Fotogrammi da video#

Perché è difficile. Il video è comodo ma povero: fotogrammi compressi, rolling shutter quasi sempre, nessuna posizione GPS per fotogramma, risoluzione spesso inferiore alle foto, motion blur. WebODM lo accetta e ne estrae fotogrammi, con questi limiti.

Opzioni.

• --video-limit <n> (default 500): numero massimo di fotogrammi estratti per video. Troppo alto e ottieni fotogrammi quasi identici che rallentano senza aggiungere informazione; troppo basso e perdi sovrapposizione.
• --video-resolution <px> (default 4.000): lato lungo massimo dei fotogrammi.
• --matcher-order: senza GPS, indica al motore di cercare corrispondenze tra fotogrammi vicini nella sequenza (per esempio 10–20).
• --rolling-shutter: quasi sempre utile.

Senza GPS il modello non è georeferenziato: scala e posizione le danno solo i GCP, difficili da cliccare nei fotogrammi. Usa il video per documentazione e modelli dimostrativi; per un rilievo scatta foto.

8. Sfondo e cielo: --bg-removal e --sky-removal#

Due opzioni sperimentali che generano maschere automatiche prima dell'estrazione delle feature. --sky-removal esclude il cielo, utile in voli obliqui o a bassa quota dove le nuvole in movimento generano feature dannose. --bg-removal prova a isolare un oggetto dallo sfondo, per oggetti fotografati girandogli intorno (statue, veicoli, reperti).

Entrambe possono sbagliare: controlla le maschere prodotte nella cartella del progetto e i risultati. Per lavori di rilievo, la scelta più affidabile resta escludere il cielo con l'inquadratura. Per lo stato di queste funzioni in ODX consulta docs.webodm.org/options-flags.

9. Tabella riassuntiva#

Come verificare

Il report di qualità dice subito se la strategia ha funzionato: nella sezione features/matching controlla che quasi tutte le immagini siano state ricostruite e che il numero di feature per immagine sia salito rispetto all'elaborazione con i default; nella mappa di sovrapposizione controlla che le zone difficili (acqua esclusa a parte) siano coperte. Poi apri il prodotto: nell'ortofoto di un edificio con --use-3dmesh i bordi dei tetti devono essere netti; nel DTM sotto vegetazione la superficie deve essere continua, senza "colline" dove ci sono alberi; con --rolling-shutter i residui dei GCP in quota devono scendere rispetto alla stessa elaborazione senza correzione. Se un valore non migliora, torna al default: non tutte le opzioni aiutano su tutti i dataset.

Problemi frequenti#

"Not enough features" o poche immagini ricostruite. Vegetazione o superfici uniformi: alza --feature-quality e --min-num-features; se non basta, il volo va integrato con più sovrapposizione o foto oblique.

Buchi nell'ortofoto sull'acqua anche con gapfill. Il gapfill agisce sul DEM, non sull'ortofoto: i pixel senza dati restano trasparenti. Usa --boundary per escludere l'area o accetta la trasparenza.

Facciate "spalmate" nell'ortofoto. Manca --use-3dmesh, oppure mancano le foto oblique: senza immagini che vedono le facciate, la mesh non può ricostruirle.

Il DTM segue la vegetazione. --smrf-threshold troppo basso e --smrf-window troppo piccola rispetto agli alberi. Alza entrambi e confronta. Vedi la guida a DSM e DTM.

Con --rolling-shutter il risultato è peggiorato. Tempo di lettura sbagliato per la tua camera, o dataset in cui l'effetto era già trascurabile. Verifica --rolling-shutter-readout o disattiva la correzione.

Per una diagnosi dei sintomi più generali (bowl effect, bordi deformati, texture sfocate) vedi risultati scadenti.

Prossimi passi#

• Riferimento completo delle opzioni: default e significato di ogni opzione citata.
• Risultati scadenti: buchi e deformazioni: dal sintomo alla correzione.
• Acquisire le immagini: pianificare il volo che evita la maggior parte di questi problemi.

Fonti

• Riferimento delle opzioni ODM (--camera-lens, --rolling-shutter, --boundary, --video-limit, --sky-removal, --bg-removal e altre): https://docs.opendronemap.org/arguments/(link esterno)
• Documentazione OpenDroneMap: https://docs.opendronemap.org/(link esterno)
• Opzioni e flag di ODX: https://docs.webodm.org/options-flags(link esterno)
• Documentazione WebODM: https://docs.webodm.org/(link esterno)