Fotogrammetria da Drone

Il collo di bottiglia dei tuoi rilievi non vola: sta sulla scrivania.


Venerdì sera. Il rilievo è andato bene: seimila scatti in due giornate di volo, tutto nitido, tutto georeferenziato. Carichi le immagini, lanci l’allineamento, poi le mappe di profondità. E da quel momento la fotogrammetria da drone smette di essere topografia e diventa un’attesa: la barra di avanzamento, il rumore delle ventole, la speranza che stavolta arrivi in fondo senza crash. Il modello è in cottura, e tu sei ostaggio della macchina.

C’è un paradosso in tutto questo: non siamo mai stati così bravi ad acquisire. Sensori full-frame ad alta risoluzione, RTK, precisione centimetrica anche senza punti di controllo a terra. Ma tutti quei dati convergono in un unico punto — la stazione di elaborazione — ed è lì, non in volo, che i progetti rallentano. Non è il tuo metodo e non è il software: sono i dataset, cresciuti più in fretta delle macchine chiamate a elaborarli.

In questo approfondimento guardiamo dentro la pipeline fotogrammetrica — allineamento, nuvola densa, mesh, ortofoto — per capire quale componente lavora davvero in ogni fase, e perché «un computer potente» in astratto non esiste. 

I dataset che i droni producono oggi


Prendi una fotocamera di riferimento del rilievo professionale come la DJI Zenmuse P1: sensore full-frame da 45 megapixel, otturatore meccanico globale, uno scatto ogni 0,7 secondi, fino a 3 km² coperti in un solo volo, con una precisione dichiarata di 3 cm in orizzontale e 5 in verticale anche senza punti di controllo a terra. È uno strumento straordinario. Ed è anche una fabbrica di dati.

Con le sovrapposizioni tipiche di un piano di volo fotogrammetrico — attorno all’80% frontale e al 60-70% laterale — anche un rilievo di poche decine di ettari produce migliaia di fotogrammi. Ogni scatto da 45 megapixel pesa nell’ordine dei 15-20 MB in JPEG e può superare gli 80 in RAW. E il conto non finisce lì: durante l’elaborazione, tra cache di ricostruzione, mappe di profondità intermedie e file temporanei, lo spazio occupato sul disco supera spesso quello delle immagini di origine.

C’è anche un aspetto economico che raramente viene messo a fuoco. Molti studi hanno appena investito decine di migliaia di euro in un drone nuovo o in un sensore migliore, proprio per acquisire più dati e più in fretta. Ogni salto di qualità in volo, però, si traduce in dataset due o tre volte più pesanti da elaborare: se la stazione a terra resta la stessa, l’investimento sull’acquisizione finisce in coda dietro al computer.

Ecco il punto che spiega quasi tutto: la macchina comprata tre anni fa non è invecchiata male. È stata dimensionata per dataset che nel frattempo sono raddoppiati o triplicati. Il drone è andato avanti; la scrivania è rimasta ferma.

Una pipeline, cinque carichi diversi


Nei software di fotogrammetria — Agisoft Metashape, RealityCapture, PIX4Dmatic — la parola «elaborazione» è al singolare, ma dentro ci sono almeno cinque lavori diversi. E ogni lavoro chiede una cosa diversa alla macchina. È la ragione per cui la domanda «quanto ci mette in high quality?» non ha una risposta unica: dipende da quale fase stai attraversando, e da quale componente sta reggendo il peso in quel momento.

L’allineamento vive soprattutto di processore: la rilevazione dei punti caratteristici dipende dalla velocità dei singoli core, mentre l’accoppiamento tra le immagini è accelerato dalla scheda video. Le mappe di profondità sono il territorio della GPU: è la fase più intensiva per la scheda video, e senza un’unità adeguata diventa molte volte più lenta — con la VRAM a decidere quanto grande può essere il blocco di dati elaborato senza frazionamenti.

Poi la scena cambia di nuovo. La nuvola densa — la dense cloud, come la chiama chi elabora ogni giorno — e soprattutto la mesh spostano il peso sulla memoria di sistema: nelle misurazioni pubblicate da Agisoft, il calcolo delle mappe di profondità di un rilievo aereo nadirale ha toccato picchi di oltre 20 GB di RAM; e in un rilievo a corto raggio della stessa serie di test, la generazione della texture eseguita su CPU ha superato i 33 GB — contro gli 11 della stessa operazione delegata alla GPU. Infine DEM e ortofoto tornano a essere un lavoro da processore multicore e da disco: l’ortorettifica legge e riscrive raster enormi, e il consumo di memoria cresce con il numero di thread attivi. Fare l’orto, in altre parole, stressa componenti che fino a un’ora prima erano quasi a riposo.

FaseChi lavora davveroSe manca il margine
AllineamentoCPU (frequenza) + GPU per l’accoppiamentoOre di attesa prima ancora della nuvola
Mappe di profonditàGPU e VRAMLa fase più lunga si allunga ancora
Nuvola densaRAM + CPU multicoreRallentamenti e swap sui dataset grandi
MeshRAM (picchi transitori)Out of memory dopo ore di calcolo
TextureGPU per il blending (o CPU + molta RAM)Consumi di memoria che crescono con i thread
DEM e ortofotoCPU multicore + discoScritture continue su raster di grandi dimensioni

Questa mappa spiega un’esperienza che chi elabora conosce bene: il progetto non si ferma dove te lo aspetti. La fase più temuta passa senza problemi, e il crollo arriva dopo, in un passaggio che sulla carta sembrava tranquillo. Per questo la diagnosi di un collo di bottiglia si fa per fase, non per macchina: la stessa workstation può essere sovradimensionata per le mappe di profondità e sottodimensionata per la mesh dello stesso identico progetto.

Out of memory alla ventesima ora: cosa è successo davvero

Quando la mesh nasce dalla nuvola densa, il software ricostruisce prima la superficie alla massima risoluzione consentita dai punti — una geometria transitoria enormemente più pesante del modello finale — e solo alla fine la decima al numero di poligoni che hai richiesto. Il picco di memoria avviene lì, ed è slegato dal limite di poligoni che hai impostato.

Se la RAM fisica non basta per quel picco, la macchina va in swap sul disco e i tempi si dilatano in modo drastico — oppure il processo si interrompe. Non hai sbagliato impostazioni: la macchina non aveva il margine per quel passaggio. È il primo punto che verifichiamo quando un cliente ci descrive elaborazioni che crollano a notte fonda.

Tre software, tre macchine diverse


Agisoft Metashape segue una filosofia rigorosa e affamata di memoria: la dimensione massima del progetto che puoi elaborare è, di fatto, scritta nei banchi di RAM. Se il dataset supera la memoria fisica, il calcolo rallenta drasticamente o non arriva in fondo. La GPU accelera le mappe di profondità e la ricostruzione della mesh, ma è la RAM a fissare il perimetro di ciò che è possibile.

RealityCapture — oggi RealityScan, dopo il passaggio a Epic Games — sceglie l’approccio opposto: algoritmi out-of-core che caricano in memoria solo i dati della fase attiva, al punto che gli sviluppatori dichiarano 16 GB tecnicamente sufficienti per migliaia di immagini. Il carico però non sparisce: si sposta sul disco di cache e sul processore. E nelle versioni recenti i test indipendenti mostrano che il numero di core è tornato a pesare parecchio sui progetti grandi.

PIX4Dmatic vive invece di CPU e memoria: nei test indipendenti più recenti un dataset impegnativo arriva a occupare circa 80 GB di RAM, mentre il salto da una scheda video di fascia media a una top cambia relativamente poco — e la scheda utilizzata è comunque una sola. Dettaglio che dice molto: in quegli stessi test, alcuni processori da workstation tradizionale, eccellenti in altri ambiti, qui risultano sorprendentemente lenti.

E la pipeline non finisce con l’export: la nuvola va aperta, sezionata, misurata, consegnata — in CloudCompare, nel GIS — e lì tornano protagonisti la RAM e la scheda video in visualizzazione. Quando la macchina non riesce ad aprire la nuvola intera, la tentazione è una sola: decimarla. Ma decimare la nuvola significa consegnare meno di quanto il rilievo conteneva — una perdita che il committente non vede nel file, e che tu conosci benissimo.

Tre software, tre profili hardware quasi opposti, più il lavoro quotidiano sulla nuvola. È il motivo per cui «un PC con tanta RAM e una buona scheda» a volte funziona e a volte no: dipende da quale fotogrammetria fai, con quale software, su quali volumi. Ed è lo stesso principio con cui progettiamo le nostre workstation professionali: prima il flusso di lavoro, poi i componenti.

Perché il PC da gaming trova il suo limite


A questo punto arriva l’obiezione classica: il collaboratore con il PC da gioco e la scheda video top di gamma elabora benissimo. È vero, e c’è anche un colpo di scena: la scheda non è il problema. Nei benchmark indipendenti le GeForce consumer equivalgono o superano le più costose schede professionali proprio in fotogrammetria, perché questi motori di calcolo lavorano in singola precisione. E la seconda scheda? Aggiunge tipicamente il 5-13% in RealityCapture e il 5-10% in Metashape, mentre PIX4Dmatic ne usa una sola: quasi sempre è preferibile un’unica GPU di fascia alta.

Vale anche per il processore: più core non significa automaticamente più velocità. I motori fotogrammetrici sfruttano bene un numero moderato di core ad alta frequenza, e oltre una certa soglia i benchmark indipendenti mostrano rendimenti decrescenti — al punto che alcuni processori con decine di core risultano più lenti di ottimi chip desktop. La scelta della CPU è un equilibrio tra frequenza, numero di core e piattaforma, non una gara a chi ne ha di più.

Il limite vero è la piattaforma intorno alla scheda. I processori desktop lavorano su due canali di memoria e danno il meglio con due moduli: quando i dataset ti spingono oltre — quattro banchi per arrivare a 128 o 192 GB — le DDR5 vengono tipicamente declassate in frequenza per restare stabili, e la banda che alimenta il processore cala proprio dove servirebbe di più. E su calcoli che girano ininterrottamente per 24 o 48 ore, la memoria senza correzione d’errore lascia il risultato esposto: un singolo errore può interrompere un’elaborazione di due giorni.

Le piattaforme professionali nate per questi carichi lavorano invece su otto canali di memoria registrata con correzione d’errore (ECC), salgono a centinaia di GB senza compromessi di stabilità e alimentano schede e dischi veloci senza contendersi le risorse. La differenza non si legge nella scheda tecnica esposta a scaffale: si vede alla ventesima ora di calcolo, quando la macchina generica ha già mollato e quella progettata sta ancora lavorando.

128 GB montati, e la macchina è diventata instabile

Hai aggiunto due moduli per reggere i dataset nuovi, e sono comparsi blocchi e schermate blu durante le elaborazioni lunghe. Non è un difetto dei moduli, né un errore di montaggio: con quattro banchi popolati, le piattaforme consumer riducono la frequenza della memoria per mantenere l’integrità del segnale, e la stabilità sotto carico prolungato resta comunque al limite. È un vincolo strutturale della piattaforma — ed è una delle prime cose che controlliamo quando uno studio ci racconta di elaborazioni diventate imprevedibili dopo un upgrade.

Lo storage non è un dettaglio


Durante l’elaborazione il software legge e scrive di continuo: cache di ricostruzione, mappe di profondità intermedie, tasselli dei raster. Pix4D arriva a dichiarare che nella fase di DSM e ortofoto è la velocità del disco a definire quella di elaborazione, ed Epic raccomanda esplicitamente unità NVMe veloci per la creazione del modello e delle texture. Non è teoria: è la ragione per cui certe fasi sembrano ferme mentre il disco lavora al massimo.

Per questo il disco non lo trattiamo come un accessorio, ma come un componente di progetto. Sistema operativo e software su un’unità dedicata; progetti attivi e cache su un SSD NVMe dedicato di ultima generazione — PCIe 5.0 sulle piattaforme attuali — così le scritture dell’elaborazione non si contendono il canale con tutto il resto; archivio dei rilievi consegnati su storage capiente separato. Tre ruoli, tre unità: è una delle scelte che più cambiano la giornata di chi elabora ogni settimana.

L’elaborazione che si inchioda quando scrive la cache

La percentuale resta ferma per minuti, il software sembra bloccato, poi riparte. Spesso non è il programma: è l’unico disco che fa contemporaneamente da sistema, da archivio progetti e da cache, con tutte le scritture in coda sullo stesso canale. Separare i ruoli su unità dedicate è uno degli interventi con il miglior rapporto tra costo e ore di lavoro recuperate.

Cloud o locale?


Le piattaforme di elaborazione in cloud esistono e per alcuni flussi hanno senso, ad esempio per assorbire un picco improvviso di lavoro. Prima di spostarci sopra l’attività di uno studio, però, vanno messi sul tavolo tre elementi: il tempo di caricamento di centinaia di GB di immagini per ogni progetto, su linee pensate più per scaricare che per caricare; il costo ricorrente, che cresce con i volumi invece di ammortizzarsi; e il controllo del dato, che diventa decisivo quando lavori per enti pubblici o su commesse con vincoli di riservatezza. C’è poi un quarto elemento, meno visibile: la coda. In cloud l’elaborazione parte quando parte; in locale parte quando serve a te. Per chi elabora ogni settimana, la stazione locale resta il centro di gravità del flusso.

La macchina giusta per i tuoi rilievi


Quando un nostro esperto parla con uno studio che fa fotogrammetria da drone, le domande sono sempre le stesse. Quante immagini ha il tuo progetto tipico, e a quale risoluzione? Quale software usi, e quale fase ti tiene sveglio la notte? Consegni ortofoto su grandi estensioni o modelli 3D densi? Elabori un progetto alla volta, o vorresti far girare una coda mentre lavori sul precedente? Ogni risposta sposta l’equilibrio tra processore, scheda video, memoria e dischi.

C’è un ultimo punto, ed è quello che conta davvero in bilancio: la velocità di elaborazione non è comfort, è capacità produttiva. Significa presentarsi alle gare con tempi di consegna competitivi, dire di sì al lavoro urgente senza esitare, far girare l’elaborazione di un progetto mentre lo studio lavora sul successivo. La macchina giusta non si limita a farti aspettare di meno: ti permette di accettare lavori che oggi devi rifiutare.

È anche il motivo per cui le macchine preconfigurate, per quanto blasonate, faticano su questi carichi: sono progettate per andare discretamente ovunque, non per il picco di RAM della tua mesh o per la cache del tuo software. Ne abbiamo parlato in i quattro limiti delle workstation di marca. La fotogrammetria da drone non chiede una macchina potente in astratto: chiede la macchina giusta per i tuoi dataset e i tuoi tempi di consegna. E quella si progetta, non si sceglie a scaffale.

Hai bisogno di una workstation per i tuoi rilievi fotogrammetrici?

Raccontaci il software che usi, la dimensione dei tuoi dataset e le scadenze con cui consegni: un nostro esperto progetterà la workstation giusta per il tuo lavoro.

Parla con un esperto

Continua a leggere: Rilievo 3D: come scegliere la workstation giusta

Scorri