Come organizzare un archivio fotografico di fototrappole: cartelle, metadati e tag di specie

Ecco la verità scomoda che nessuno avverte quando si acquistano le prime dozzine di fototrappole: la parte difficile del fototrappolaggio non è il trappolaggio. È tutto ciò che accade dopo che le schede SD sono tornate a casa. Un singolo progetto accumula abitualmente da migliaia di immagini per scheda fino a centinaia di migliaia, persino milioni, di file. E nel momento in cui quel mucchio esiste, comincia a ticchettare un orologio — perché un archivio che non si può cercare, di cui non ci si può fidare e che non si può consegnare a nessun altro è, ai fini della ricerca, a malapena un archivio.

Chi studia tutto questo per mestiere lo dice senza giri di parole. In tutta la letteratura, il risultato ricorrente è che la gestione dei dati, più della loro raccolta, è il fattore limitante nel completamento degli studi con fototrappole. Le fototrappole sono diventate economiche e affidabili; il muro dell'archiviazione-e-catalogazione non si è mosso. La catalogazione resta indietro rispetto all'acquisizione, e «una grande quantità di dati rimane inutilizzata e in ultima analisi perduta per la scienza e la gestione della conservazione». Una rassegna ha rilevato che i confronti tra siti e le meta-analisi sono quasi del tutto assenti dalla letteratura — non perché i dati non esistano, ma perché ognuno li ha organizzati in modo diverso, a modo proprio e in privato, e nessuno riesce a combinarli.

Questo articolo riguarda il passaggio precedente all'analisi: come impostare, denominare, catalogare, salvare e infine condividere un archivio fotografico di fototrappole in modo che sopravviva al progetto, sopravviva al ricambio del personale e resti utile a chi lo cura e a chiunque vi collabori. Non riguarda dove collocare le fototrappole, né riguarda la trasformazione delle marche temporali in curve di attività — quelli sono lavori a sé. Conviene pensare a quanto segue come all'impianto idraulico. Non è affascinante, è il punto in cui la maggior parte dei progetti perde silenziosamente valore, e farlo bene è quasi interamente una questione di decisioni che si prendono nella prima ora, non nell'ultima.

Perché questo è il collo di bottiglia, e perché «lo sistemo dopo» fallisce

Aiuta capire perché questo passaggio inghiotte i progetti, perché le ragioni indicano da che cosa difendersi.

La prima ragione è il volume grezzo che si scontra con il lavoro manuale. Recuperare, archiviare, organizzare e — cosa più penosa di tutte — identificare il contenuto di ciascuna immagine si fa ancora in gran parte a mano, e la classificazione delle immagini è costantemente giudicata la sfida più grande in assoluto del fototrappolaggio. Il lavoro è «laborioso, dispendioso in termini di tempo, soggetto a errore e costoso». Quando la manodopera non riesce a tenere il passo, l'arretrato cresce, e un arretrato di immagini non catalogate è funzionalmente un arretrato di dati perduti.

La seconda ragione è che la gestione manuale genera errori, e gli errori in un archivio sono corrosivi in un modo in cui non lo sono in un singolo foglio di calcolo. C'è un numero concreto e bellissimo per questo, tratto da uno studio comportamentale in Namibia che ha gestito all'incirca 1,2 milioni di fotografie da 26 fototrappole in tre anni: prima che il gruppo automatizzasse la gestione dei file, gli errori umani — cartelle etichettate male, copie finite nel posto sbagliato — rappresentavano il 15,5% delle interruzioni dei dati; dopo aver lasciato che fosse il software a gestire gli scaricamenti, quella quota è scesa al 6,2%. Stesse persone, stesse fototrappole. La differenza era la struttura.

La terza ragione è quella che costa di più al settore: la frammentazione. Poiché la maggior parte dei progetti si è preoccupata soltanto della propria specie bersaglio e ha costruito il proprio sistema improvvisato, il risultato è ciò che un articolo molto citato chiama «dark data» — dati non disponibili ad altri ricercatori o al pubblico, chiusi in un formato specifico di un programma e archiviati sul disco locale di qualcuno. Le fototrappole sono indiscriminate; fotografano tutto ciò che fa scattare il sensore. Se si cataloga solo il cervo e si scarta il resto, si sono buttati via dati per cui un altro gruppo — che studia le volpi, o le persone, o le interazioni tra loro — avrebbe dato l'anima. Il rimedio è catalogare tutto, in modo coerente, la prima volta.

Dunque «lo sistemo dopo» fallisce per una ragione semplice: dopo è quando il volume è massimo, il ricordo di quale fototrappola stesse dove è più sbiadito e il costo di ogni errore è moltiplicato per l'intera collezione. La disciplina va anticipata. La buona notizia è che la versione anticipata non è molto lavoro — è per lo più una manciata di convenzioni, applicate dal primo giorno. Le fototrappole sono diventate economiche e affidabili; il muro dell'archiviazione-e-catalogazione non si è mosso, e l'unico modo per scavalcarlo è costruire le abitudini prima che il mucchio esista.

Le fototrappole sono diventate economiche e affidabili; il muro dell'archiviazione-e-catalogazione non si è mosso.

Struttura delle cartelle: organizzare per dispiegamento, copiare dalla scheda così com'è

Si parte dalle cartelle, perché tutto il resto dipende da esse.

C'è un accordo sorprendente nel settore sul principio fondamentale, anche se gli strumenti differiscono: organizzare i file multimediali in una directory per ciascun dispiegamento — un dispiegamento essendo una singola collocazione di una fototrappola in un punto per un tratto di tempo — e non rinominare i file man mano che escono dalla scheda. La guida alle buone pratiche di GBIF lo enuncia quasi come un comandamento: «Evitate di rinominare i file multimediali. Organizzate piuttosto i file multimediali in una directory per ciascun dispiegamento».

Perché tanta fermezza sul non rinominare? A causa di come funziona in realtà l'univocità dei nomi dei file. La maggior parte delle fototrappole denomina i file con un breve contatore sequenziale (`IMG_0001.JPG`, `PICT0001.JPG`), e quei nomi sono garantiti univoci soltanto all'interno di una scheda. Riversando le immagini di tre fototrappole in una sola cartella ci si scontra subito con tre file `IMG_0001.JPG`. Tenere ciascun dispiegamento nella propria directory aggira l'intero problema, e significa che si può copiare il contenuto di una scheda esattamente com'è — nessuna trasformazione, nessuna occasione per introdurre un errore. Gli autori di Aardwolf hanno costruito il loro intero schema a tre livelli (progetto → fototrappola → cartella dell'operazione di scaricamento) attorno a questa intuizione: «questa struttura fisica garantisce inoltre che la copia delle directory da una scheda di memoria di una fototrappola possa essere fatta così com'è».

Il toolkit R camtrapR formalizza uno schema strettamente correlato. Per un rilevamento con una fototrappola per stazione, si ottiene `rawImages/stationA`, `rawImages/stationB` e così via; con più di una fototrappola per stazione, si aggiunge un livello: `rawImages/stationA/camera1`, `rawImages/stationA/camera2`. E arriva con un avvertimento che varrebbe la pena tatuare in un punto ben visibile: «Se hai più di 1 fototrappola per stazione ma non separi le immagini delle diverse fototrappole in questa fase, non potrai più farlo in un momento successivo». Se si fondono ora, la provenienza è persa per sempre. È il tema ricorrente dell'intero argomento — alcune informazioni si possono conservare soltanto al momento dell'acquisizione, mai ricostruire.

Due altre abitudini completano il quadro. Primo, si tengono le immagini grezze come backup intatto e si lavora su una copia — la funzione di rinomina di camtrapR copia deliberatamente le immagini in una nuova posizione così che gli originali non siano mai a rischio. Secondo, non si conserva nient'altro che immagini all'interno delle proprie directory di immagini; file estranei possono interferire con gli strumenti che scandiscono quelle cartelle.

Quanto in profondità dovrebbe spingersi la gerarchia? Conviene prendere in prestito la regola pratica dal mondo della gestione dei dati di ricerca, che ci ha riflettuto più a lungo dei fototrappolatori: si limitano le cartelle a tre o quattro livelli di profondità e si cerca di non avere più di una decina di elementi in una singola lista, tenendo dati e documentazione in rami separati. Un progetto con fototrappole ci arriva naturalmente — progetto, poi sito o dispiegamento, poi scheda — senza che nessuno debba forzarlo.

Alcune informazioni si possono conservare soltanto al momento dell'acquisizione, mai ricostruire.

Convenzioni di denominazione: la data in testa, mai la specie

Se proprio si rinominano i file — e ci sono ragioni legittime per farlo, soprattutto per renderli autodescrittivi una volta che lasciano la sicurezza della loro cartella — c'è un modo giusto e diversi modi sbagliati.

La regola più importante in assoluto è far coincidere l'ordine alfabetico con l'ordine cronologico. Il trucco pulito è iniziare il nome con la data, `YYYYMMDD`, oppure con la data e l'ora, `YYYYMMDD_HHMMSS`. La guida GBIF fornisce direttamente gli esempi elaborati: `20200709_093352.JPG` va bene, perché si ordina correttamente; `09072020_093352.JPG` va male, perché la denominazione con il giorno in testa scompiglia l'ordine cronologico nel momento in cui si hanno dati di più di un mese. Non è pedanteria — metà degli strumenti che si useranno assume che l'ordine dei file rifletta l'ordine temporale, e una fototrappola che denomina i file `1.jpg, 2.jpg … 10.jpg` verrà letta dal computer come `1, 10, 2 …`, infrangendo silenziosamente quell'assunzione.

Le guide generiche all'archiviazione dei dati concordano e aggiungono i dettagli di ordine pratico: si usano le date in forma ISO `YYYY-MM-DD`, si separano gli elementi con trattini o trattini bassi, si evitano spazi e caratteri speciali come `&`, `?` o `!`, si mantengono i nomi significativi ma brevi, si riserva l'estensione di tre lettere al formato del file e si include un indicatore di versione dove conta. Lo schema di denominazione di camtrapR è un'istanza concreta di tutto questo: rinomina in `StationID__Date__Time(X).JPG`, dove il `(X)` disambigua le immagini scattate nello stesso minuto, e riserva i doppi trattini bassi come delimitatori di campo — quindi gli identificatori di stazione e di fototrappola non devono a loro volta contenere trattini bassi.

C'è qui una regola che i fototrappolatori violano di continuo, e merita una riga tutta sua: non conservare informazioni di classificazione nel nome del file. È allettante rinominare una foto `..._Ardea_alba_1_Anas_platyrhynchos_male_female.jpg` per ritrovarla più tardi. Non va fatto. La guida GBIF segnala esattamente questo come cattiva pratica. La ragione è che un'identificazione non è un fatto relativo al file; è un'interpretazione, e le interpretazioni vengono riviste. Si incorpora «volpe rossa» in mille nomi di file e poi si scopre che metà erano di un'altra specie: ci si ritrova con mille operazioni di rinomina e una traccia di controllo compromessa. I tag appartengono ai metadati, dove possono essere corretti senza toccare l'identità del file — che è esattamente dove siamo diretti. (camtrapR può aggiungere in coda un nome di specie al nome del file come comodità per la consultazione, ma va notato che legge quell'ID di specie in primo luogo dalla struttura delle cartelle o dai tag dei metadati; l'identificazione risiede altrove, e il nome del file ne è soltanto una copia.)

Quando serve davvero rinominare in blocco, non lo si fa a mano. Esistono strumenti dedicati di rinomina batch per ogni piattaforma, e l'utilità per metadati ExifTool può rinominare i file a partire dai loro stessi metadati — estraendo la data di acquisizione direttamente da ciascuna immagine per costruire il nuovo nome — oltre a modifiche batch dei metadati, geotagging e correzione di data e ora.

Tagging e annotazione: concordare lo schema prima di toccare un'immagine

Ora la parte che tutti pensano sia «il lavoro»: scorrere le immagini e registrare che cosa contengono. Questo passaggio si chiama tagging — esaminare ciascuna immagine e codificarne gli attributi di interesse come dati — ed è dove accadono gli errori più grandi, più costosi e più evitabili.

La lezione più profonda qui viene da un articolo che distilla otto anni di sviluppo dello strumento di analisi delle immagini Timelapse, e non è un consiglio sul software. Riguarda una decisione che si prende prima del software: specificare e adottare uno schema di dati comune. Prima che chiunque cataloghi qualcosa, il responsabile del progetto dovrebbe decidere esattamente quali dati verranno registrati dalle immagini, definirli come uno schema standardizzato e leggibile dalla macchina — i campi, i loro nomi, i loro tipi di dato, i loro valori ammessi — e poi far sì che il software lo imponga. La ragione è il problema dei molti catalogatori. Un progetto reale ha più persone (spesso volontari inclusi) che lavorano ciascuna su una fetta delle immagini, e «senza coerenza dei dati — se ogni analista specificasse in modo idiosincratico quali dati codificare dalle immagini, in quale formato e con quale nome — sarebbe estremamente difficile dare un senso ai dati tra i diversi analisti». Si concorda prima lo schema, oppure si passa il resto del progetto a riconciliare dieci dialetti dello stesso dataset.

Un modello concreto e citabile per quello schema è lo schema a quattro tabelle su cui convergono i progetti organizzati, ben illustrato in un esempio didattico costruito attorno a un dataset canadese: una tabella di progetto (obiettivi, disegno, chi è responsabile), una tabella di immagini/osservazioni (specie, conteggio, età/sesso, comportamento, marca temporale, per immagine), una tabella di dispiegamento (posizione, inizio e fine, fototrappola, altezza, orientamento) e un inventario delle fototrappole (marca, modello, numero di serie). Ogni collocazione unica di fototrappola riceve il proprio record di dispiegamento. È lo stesso scheletro che usano gli standard formali — di cui tra poco — e anche se non si pubblica mai, disporre i dati in questo modo fin dall'inizio significa tenere le cose giuste nei posti giusti.

Oltre allo schema, l'articolo sugli otto anni di Timelapse è un catalogo di schemi di efficienza conquistati a caro prezzo, e vale la pena conoscerli perché separano un flusso di lavoro che dura una stagione da uno che dura un anno. Lo stesso gruppo ha misurato miglioramenti dei tempi di circa il 200% rispetto agli analisti che usavano un semplice foglio di calcolo. Alcuni degli schemi che contano di più:

• Ridurre al minimo la digitazione. Digitare è lento e soggetto a errore; lo si sostituisce con la selezione ovunque possibile — menu a tendina per le specie, caselle di spunta per i flag, completamento automatico che propone le voci precedenti.
• Contare cliccando, e marcare ciò che si è contato. Quando un'immagine contiene un branco, contare male è facile — si perde il segno, si conta due volte, se ne salta uno. Lasciare che il catalogatore clicchi ogni animale per incrementare un contatore e lasci un marcatore visibile risolve tutte e tre le modalità di errore in una volta e consente a una seconda persona di verificare il conteggio in seguito.
• Compilare automaticamente tutto ciò che il computer già conosce. Nome del file, cartella e data/ora di acquisizione dovrebbero essere popolati automaticamente, mai ridigitati. Molte fototrappole incorporano anche degli extra — temperatura ambiente, a volte GPS — che si possono estrarre direttamente dai metadati dell'immagine nei propri campi di dati.
• Raggruppare le raffiche in episodi. Uno scatto per movimento spesso fa partire una raffica, e un singolo animale che si attarda produce molti fotogrammi quasi identici. Raggruppare le immagini scattate in un breve intervallo in un unico «episodio» consente al catalogatore di registrare l'evento una volta sola invece di gonfiare i conteggi — lo strumento può marcare il primo fotogramma di ciascun episodio e numerare gli altri.
• Propagare i valori ripetitivi. Lungo una serie di immagini simili, i dati sono spesso identici; i comandi di copia-in-avanti, riempimento-a-ritroso e copia-su-tutto trasformano cento voci identiche in una.

Non sono lussi. Cattive scelte di strumenti significano «immissione dati tediosa... soggetta a errore (il che compromette la validità dei dati raccolti)... e — a lungo andare — molto costosa in termini di tempo degli analisti». Per inciso, questo è il modo più onesto di pensare al software in generale per questo compito: la rassegna del settore stesso dei programmi disponibili ha rilevato che nessuno strumento si è affermato come favorito netto, e un importante rapporto sulle buone pratiche è giunto pressoché alla stessa conclusione — molti grandi progetti «hanno finito per progettare da zero i propri sistemi», e potrebbe essere necessario provarne diversi prima che uno si adatti al proprio flusso di lavoro. Non c'è una risposta giusta universale; c'è la disciplina dello schema, e c'è l'adattare lo strumento a come le persone lavorano davvero.

Si concorda prima lo schema, oppure si passa il resto del progetto a riconciliare dieci dialetti dello stesso dataset.

Dove risiedono i tag: EXIF, IPTC, XMP e file sidecar

Dunque si è assegnato un tag di specie a un'immagine. Dove va fisicamente quel tag — e sarà ancora lì quando si copierà la cartella sulla macchina di un collega tra un anno?

È qui che conviene comprendere i tre standard di metadati che vivono dentro (e accanto a) un file immagine, perché svolgono compiti diversi:

• EXIF è ciò che la fototrappola scrive al momento dell'acquisizione — data e ora, più impostazioni come tempo di scatto, esposizione, ISO e stato del flash. In generale non lo si modifica; lo si legge. Il campo di data e ora (`DateTimeOriginal`) è il gioiello della corona qui, e torneremo sul perché.
• IPTC è per il testo che si aggiunge da sé dopo l'acquisizione — autore, copyright, didascalie e, cosa cruciale, le parole chiave. Il suo limite è che i campi di testo hanno lunghezza limitata.
• XMP è l'evoluzione moderna di IPTC. «Rimuove le limitazioni sulla dimensione del testo» e supporta più lingue, motivo per cui la strumentazione in genere raccomanda di dare a XMP la priorità massima per tag e didascalie.

Il punto che rende tutti e tre rilevanti per un archivio: parole chiave e tag possono essere scritti direttamente nei metadati stessi dell'immagine, attraverso i campi IPTC e XMP. Ciò significa che un tag di specie — «volpe rossa», o un intero soggetto gerarchico come Mammalia > Carnivora > Vulpes > Vulpes vulpes — può essere conservato dentro la foto, così che viaggi con il file. Come la documentazione di uno strumento di metadati afferma senza mezzi termini: «Conservare i metadati direttamente nei file immagine consente di preservare questa informazione quando si spostano o si inviano i file immagine a sistemi diversi». È tutta la partita. Un tag in un database separato che viene lasciato indietro in una copia è un tag perduto; un tag incorporato nel file è un tag che sopravvive al viaggio.

C'è una sottigliezza che vale la pena conoscere, soprattutto se si riprende qualcosa in RAW o in video. Non sempre si possono riscrivere i metadati nel file originale — i formati RAW sono spesso di sola lettura, e il tagging del video è mal standardizzato. La risposta è un file sidecar: un piccolo file compagno (denominato `filename.ext.xmp`) che conserva i metadati accanto all'immagine, usato da solo o in aggiunta alla scrittura all'interno del file. Quindi la scelta pratica è configurabile — scrivere i tag nell'immagine, in un sidecar o in entrambi — e l'impostazione giusta dipende dai tipi di file.

Un ibrido pragmatico e molto usato è conservare i tag in due posti contemporaneamente: incorporati nell'immagine (o nel suo sidecar) così da essere trasportabili, e anche in un database esterno per una ricerca rapida — trattando il database come una cache e i file come «l'unica fonte di verità». In questo modo si ottiene velocità nell'interrogazione e durabilità nello spostamento.

Sotto quasi tutto questo sta un piccolo strumento, poco affascinante e indispensabile: ExifTool, l'utilità gratuita e indipendente dalla piattaforma di Phil Harvey per leggere, scrivere e modificare i metadati in centinaia di formati, inclusi EXIF, IPTC e XMP. È il motore su cui si appoggiano i toolkit di ricerca — camtrapR, per esempio, ne dipende per ogni operazione sui metadati e senza di esso non farebbe granché. Può darsi che lo si invochi raramente in modo diretto, ma quasi certamente sta facendo il lavoro dietro qualunque cosa si usi.

Una nota onesta su come il flusso di lavoro del tag-di-specie-nei-metadati venga effettivamente cablato nella pratica, perché gli strumenti si dividono il lavoro in un modo che sorprende. È tipicamente un'applicazione generica di gestione fotografica a scrivere in primo luogo la parola chiave di specie nei metadati dell'immagine (tramite i suoi campi di parola chiave/soggetto), e il toolkit R poi rilegge quei tag incorporati — camtrapR può estrarre un ID di specie dal tag di metadati `HierarchicalSubject` scritto da un'app di tagging — per assemblare le sue tabelle di record. L'identificazione ha origine nello strumento di tagging; il campo dei metadati è il modo in cui viene conservata e trasmessa.

Un tag in un database che viene lasciato indietro in una copia è un tag perduto; un tag incorporato nel file è un tag che sopravvive al viaggio.

La marca temporale merita una paranoia speciale

Tra tutti i dati allegati a un'immagine, un campo è unicamente irrecuperabile, e vale la pena estrarlo dalla discussione sui metadati per sottolinearlo a sé stante.

La guida GBIF è inequivocabile: la data e l'ora in cui una foto è stata scattata «sono l'aspetto più importante dei suoi metadati... e non possono essere derivate in seguito» — a differenza, per esempio, della posizione della fototrappola, che si può sempre recuperare a posteriori. Se si sbaglia la marca temporale, non c'è una seconda fonte da cui correggerla. Il gruppo di Timelapse, dopo otto anni passati a osservare questo andare storto, ha catalogato le quattro classiche modalità di guasto: una fototrappola il cui orologio semplicemente non è mai stato impostato correttamente (tutto sfasato di una quantità fissa); una fototrappola che non gestisce il cambio all'ora legale (una porzione di immagini sfasata di un'ora); un orologio che va lentamente avanti o indietro nel corso di un dispiegamento; e una fototrappola che registra le date in modo ambiguo, come `02/10/2019`, che potrebbe essere febbraio o ottobre a seconda della convenzione.

Due abitudini a monte prevengono la maggior parte di tutto ciò, ed entrambe sono per progetto neutrali rispetto alla località. Primo, si imposta l'orologio della fototrappola sul Tempo Coordinato Universale (UTC) o sull'ora solare invernale locale, e si disabilita il passaggio automatico all'ora legale — poi si registra separatamente il fuso orario del dispiegamento. La ragione per cui questo batte l'impostazione sull'ora locale è che il cambio all'ora legale è il sabotatore silenzioso: mette una cucitura nascosta di un'ora attraverso metà dei record, e un orologio fissato su UTC o sull'ora invernale semplicemente non ha alcuna cucitura in cui inciampare. Secondo, quando si esportano o si denominano i file, si scrivono le ore in un ordine non ambiguo — la data in testa, `YYYY-MM-DD` o la marca temporale ISO completa — così che nessuno a valle debba indovinare se `02/10` sia febbraio o ottobre.

Se dopo il fatto si scopre che l'orologio di un dispiegamento era sbagliato di una quantità nota, è recuperabile in blocco — la strumentazione può spostare le marche temporali di ogni immagine in una cartella di uno scarto fisso, che è il modo giusto per gestire, per esempio, il difetto di firmware che un grande produttore ha rilasciato e che ha scompaginato l'anno sulle sue fototrappole allo scoccare del 2015/2016. Si salvano prima le immagini, poi si corregge. Il punto più profondo resta: un errore d'orologio colto all'acquisizione è una seccatura di cinque minuti; lo stesso errore colto mai è una finzione permanente nel dataset.

Eliminare i vuoti: il pre-filtro con IA

Ecco la parte del flusso di lavoro in cui il problema del volume e la strumentazione moderna finalmente si incontrano a proprio favore.

Le fototrappole scattano per calore e movimento, il che significa che scattano per rami mossi dal vento, erba ondeggiante, pioggia, sole che si sposta e aria calda con la stessa prontezza con cui scattano per gli animali. Il risultato è che una grande maggioranza dei fotogrammi in un dispiegamento tipico non contiene alcun animale — sono vuoti. (Si vedrà circolare nel settore una cifra specifica del «70–95% vuoti»; la si tratti come folclore a meno che i propri stessi dati non dicano altrimenti, perché non è ancorata a una singola fonte solida. Ciò che è ben stabilito è la realtà qualitativa: i fotogrammi vuoti di solito surclassano quelli utili, e passarli in rassegna a mano è il grande divoratore di tempo dell'intera impresa.) Farsi strada tra di essi manualmente è esattamente il lavoro «noioso» che inghiotte le ore degli analisti.

Lo strumento standard per tagliar corto è un modello rilevatore — il più noto è MegaDetector, il modello open-source dell'AI for Good Lab di Microsoft. Fa un solo lavoro e lo fa in modo ampio: «rileva animali, persone e veicoli nelle immagini di fototrappola e filtra via le immagini vuote, riducendo la revisione manuale su grandi dataset». Addestrato su diversi milioni di immagini di molti ecosistemi, è stato adottato da ben oltre un centinaio di organizzazioni in tutto il mondo, da agenzie faunistiche nazionali a laboratori universitari in più continenti. In modo cruciale, se ne comprende la portata: MegaDetector trova gli animali; non li identifica a livello di specie. È un primo passaggio grezzo ma implacabile — animale / persona / veicolo / niente — che consente di mettere da parte i fotogrammi vuoti e di riservare l'attenzione vera ai fotogrammi che contengono davvero qualcosa. Le coordinate e la confidenza del rilevatore confluiscono poi in uno strumento di tagging, che traccia un riquadro attorno a ciascun rilevamento e consente di accettarlo, rifiutarlo o etichettarlo per specie.

Una nota su ciò che questo fa guadagnare e ciò che non fa guadagnare. Un rilevatore elimina i vuoti; non fa l'identificazione di specie, e anche quando è abbinato a un classificatore di specie, l'accuratezza della visione artificiale resta comunque al di sotto di quella di un esperto umano — quindi la raccomandazione duratura nel settore è il pre-filtro assistito dall'IA più la verifica umana, non l'automazione cieca. Usato in questo modo, cambia l'aritmetica di un progetto: invece di una persona che apre ognuna delle poche centinaia di migliaia di immagini, apre la frazione che un rilevatore segnala come non vuota, e verifica a partire da lì.

Un rilevatore elimina i vuoti; non fa l'identificazione di specie — va abbinato a un essere umano, non a una fede cieca.

Backup e archiviazione: si dà per scontato che un disco morirà, perché lo farà

Un archivio è durevole soltanto quanto il suo peggiore singolo punto di guasto, e nel fototrappolaggio quel punto è di solito un disco rigido appoggiato su una scrivania.

Il volume che rende tutto il resto difficile rende non banale anche il backup: «non è banale archiviare, salvare e gestire in sicurezza i file multimediali» a questa scala. L'indicazione standard è usare servizi cloud o archiviazione istituzionale ben gestita, accettando che questo comporta un costo reale, e — dove possibile — usare un sistema di archiviazione capace di servire i file su indirizzi web stabili, così che un dataset pubblicato possa riferirsi direttamente alle immagini anziché spedire copie di tutto. Le guide generiche alla gestione dei dati rafforzano la disciplina ovvia che i fototrappolatori saltano a proprio rischio: backup deliberato, non solo «è sul mio portatile».

Due scelte progettuali della strumentazione vale la pena rubarle anche se non si toccano mai gli strumenti stessi. La prima è il modello file-come-fonte-di-verità già menzionato: si tengono i dati autorevoli nei file immagine (e nei loro sidecar), e si tratta qualsiasi database come una cache ricostruibile. Se il database si corrompe, lo si rigenera dai file; non si perdono mai le osservazioni effettive. La seconda è separare l'organizzazione logica dalla posizione fisica — lasciando che i dati di un progetto si distribuiscano su più dischi o su una condivisione di rete pur presentandosi come una singola gerarchia pulita — che è esattamente il modo in cui un sistema minimalista ha scalato fino a oltre un milione di foto su hardware comune.

Il filo conduttore è smettere di fidarsi di qualsiasi singolo dispositivo. I dischi si guastano, le schede si corrompono, e il crudo conteggio dei guasti fisici dello studio in Namibia — danni da pioggia, batterie esaurite, guasti delle schede, distruzione da parte della fauna — è un promemoria del fatto che il campo è ostile ai dati raccolti molto prima che raggiungano un computer. La ridondanza non è opzionale; è il prezzo per tenere in vita un archivio pluriennale.

Standard di dati: parlare una lingua che gli altri possono leggere

Tutto quanto sopra rende l'archivio utilizzabile a chi lo cura. Gli standard sono ciò che lo rende utilizzabile a tutti gli altri — e, sempre di più, al proprio stesso io futuro e ai modelli di apprendimento automatico che si potrebbero addestrare in seguito.

Due standard dominano, e si incastrano ordinatamente.

Camtrap DP (il Camera Trap Data Package) è quello costruito appositamente. È un formato di scambio sviluppato dalla comunità, gestito sotto l'organismo Biodiversity Information Standards (TDWG), che struttura un intero progetto in tre tabelle collegate — Deployments, Media e Observations — più un file di metadati che descrive il pacchetto. È stato progettato proprio perché, sebbene elaborare i «Big Data» delle fototrappole fosse diventato trattabile, «l'armonizzazione e lo scambio dei dati restano limitati, ostacolandone il pieno potenziale». Supporta l'intera gamma dei modi in cui le persone lavorano davvero — classificazione umana e con IA, basata su immagini e basata su eventi — e si costruisce su una specifica aperta di impacchettamento dati preesistente così che un software standard possa validarlo automaticamente. È, in effetti, il moderno successore di un precedente standard di metadati per fototrappole che ha definito per primo l'ormai onnipresente gerarchia a quattro livelli Progetto → Dispiegamento → Sequenza di immagini → Immagine e la convenzione di raggruppare in un'unica sequenza le immagini scattate entro 60 secondi.

Darwin Core è lo standard più ampio sulla biodiversità in cui possono anche confluire i dati delle fototrappole. È «un insieme di termini dalla semantica chiaramente definita che possono essere compresi dalle persone o interpretati dalle macchine», ratificato come standard nel 2009 e usato per condividere centinaia di milioni di record di biodiversità tra centinaia di organizzazioni e decine di Paesi. I suoi termini sono organizzati in classi che coprono cose come evento, posizione, occorrenza e taxon; un'osservazione da fototrappola si mappa sulla classe Occurrence. Poiché è deliberatamente semplice e indipendente dalla tecnologia, gli stessi dati si possono esprimere come CSV, XML, JSON o altre codifiche.

Come si sceglie? L'indicazione pratica è chiara: per i dati di fototrappole in particolare, Camtrap DP è da preferire perché «è specificamente progettato per questo tipo di dati e può conservare più informazioni di un Darwin Core Archive», mentre un Darwin Core Archive è la strada quando si vuole entrare nel più ampio mondo dei dati sulla biodiversità. E i due non sono rivali — esiste un pacchetto R il cui intero compito è leggere un Camtrap DP e convertirlo in Darwin Core (e in EML), che è esattamente il ponte che un repository pubblico usa per acquisire i pacchetti di fototrappole. Si può lavorare nel formato nativo per fototrappole e ciononostante pubblicare in quello generale.

Un'impostazione che questa intera discussione sugli standard rende neutrale rispetto alla località e che vale la pena interiorizzare: si conserva il nome scientifico, anche se alle persone si mostra sempre e solo quello comune. I nomi comuni derivano tra regioni e lingue e talvolta indicano animali del tutto diversi — «elk» indica una specie in Nord America e una diversa in Europa — mentre il nome scientifico è globalmente coerente e non ambiguo. Si tiene un'unica tabella di riferimento delle specie che ci si attende, tratta da una tassonomia autorevole, e si conserva il nome scientifico come àncora. È una piccola abitudine che salva una collaborazione internazionale da una categoria di confusione genuinamente difficile da districare a posteriori.

Condivisione e archiviazione: trasformare una cartella privata in un bene pubblico

L'ultimo passaggio — e quello che distingue un archivio di ricerca da una scatola personale — è pubblicare i dati da qualche parte dove altri possano trovarli e riutilizzarli.

La destinazione, nel mondo della ricerca, è tipicamente un repository pubblico di biodiversità raggiunto attraverso una pipeline di pubblicazione standard; la Global Biodiversity Information Facility (GBIF) è quella principale, e vi si pubblica standardizzando prima i propri dati in Camtrap DP o Darwin Core. L'obiettivo guida ha un nome — dati FAIR: reperibili (findable), accessibili, interoperabili, riutilizzabili — e la ricetta è concreta: si depositano i dati in un repository che assegni loro un identificatore univoco stabile, si allegano metadati ricchi così che altri possano giudicare se fanno al caso loro, si aggiunge una licenza aperta così che sia loro consentito usarli, e si standardizza il formato così che si combinino davvero con altri dataset. La raccomandazione forte è pubblicare un dataset per progetto, il che mantiene descrivibili in un unico luogo coerente l'ambito, i metodi e i collaboratori.

Prima che qualcosa diventi pubblico, contano due passaggi di preparazione. Primo, identificatori stabili e univoci per i record — idealmente quelli che il sistema di gestione ha già assegnato, usati così come sono anziché ritoccati, dato che aggiungere pezzi a un identificatore lo rende soltanto fragile. Secondo, gestire le informazioni sensibili generalizzando, non cancellando. I dati delle fototrappole portano con sé tre tipi di sensibilità: le posizioni di specie rare o minacciate (che possono attirare i bracconieri), le posizioni delle proprie fototrappole (furto e vandalismo) e i dati personali — i nomi dei partecipanti, e qualsiasi immagine di persone identificabili, che ricadono sotto normative sulla privacy come il GDPR. L'approccio raccomandato è sfocare le coordinate di una specie sensibile anziché trattenere del tutto il record, tenere private le immagini di persone e documentare qualunque generalizzazione applicata così che gli utenti sappiano che cosa stanno guardando. Il mondo della citizen science pratica da tempo versioni di tutto ciò: mascherare la posizione delle specie minacciate ed estinguende così che i punti dati pubblici si risolvano soltanto al centro di un progetto, e offrire embarghi sui dati così che un gruppo abbia la prima occasione di pubblicare prima che i dati si aprano.

Vale la pena dire chiaramente perché ci si dovrebbe prendere la briga di condividere, perché è facile trattare la pubblicazione come un fardello burocratico. L'intera ragione per cui il problema dei «dark data» conta è che i dati di fototrappole condivisi in un formato coerente sono riutilizzabili ben oltre il loro scopo originario — per la modellazione della distribuzione delle specie, per il monitoraggio della biodiversità, persino come dati di addestramento per la prossima generazione di modelli di rilevamento. I dati raccolti per rispondere a una domanda possono, se opportunamente archiviati e condivisi, aiutare a rispondere a una dozzina di domande che non ci si era mai posti. È l'intero argomento per fare tutto questo con cura: un archivio organizzato, standardizzato e pubblicato apertamente non si limita a sopravvivere al progetto — lo supera.

I dati raccolti per rispondere a una domanda possono, se opportunamente archiviati, aiutare a rispondere a una dozzina di domande che non ci si era mai posti.

Un flusso di lavoro minimo, dall'inizio alla fine

Se si vuole il tutto come un'unica sequenza, ecco la spina dorsale che le fonti descrivono collettivamente — si adattano gli strumenti, si mantiene l'ordine:

1. Si acquisisce per dispiegamento. Si copia ciascuna scheda nella propria cartella per dispiegamento, non rinominata; si tiene la copia grezza intatta come backup.
2. Si sistema prima l'orologio. Si verificano le marche temporali; se l'orologio di un dispiegamento era sfasato di una quantità nota, le si spostano in blocco ora, prima che qualsiasi cosa legga quelle ore.
3. Si decide lo schema. Si definiscono i campi di dati e i valori ammessi in anticipo e si fa in modo che il software li imponga a ogni catalogatore.
4. Si pre-filtrano i vuoti. Si esegue un rilevatore per mettere da parte i fotogrammi vuoti così che l'attenzione umana vada soltanto alle immagini con qualcosa dentro.
5. Si cataloga in modo efficiente, nei metadati. Si identifica e si annota usando la selezione al posto della digitazione e il raggruppamento in episodi al posto del fotogramma-per-fotogramma, e si conservano i tag negli EXIF/IPTC/XMP stessi dell'immagine (o in un sidecar) così che viaggino.
6. Si salva in modo ridondante. Archiviazione cloud o istituzionale, più la disciplina per cui i file — non un singolo database — sono la fonte di verità.
7. Si standardizza e si condivide. Si esporta in Camtrap DP (o Darwin Core), si generalizza qualsiasi cosa sensibile, e si pubblica un dataset per progetto in un repository pubblico.

Nessuno di questi passaggi è difficile. Diversi di essi sono impossibili da fare dopo. Quell'asimmetria è l'intera ragione per prendere sul serio il passaggio noioso: l'archivio che si potrà consegnare a uno sconosciuto tra cinque anni si costruisce, o si perde, nella prima ora dopo che le schede sono tornate a casa.

Domande frequenti