Een foto-archief van wildcamera's ordenen: mappen, metadata en soorttags

Hier volgt de ongemakkelijke waarheid waar niemand voor waarschuwt bij de aankoop van dat eerste dozijn camera's: het lastige aan cameravallen is niet het vangen. Het is alles wat gebeurt nadat de SD-kaarten thuiskomen. Eén enkel project stapelt routineus van duizenden beelden per kaart op tot honderdduizenden, zelfs miljoenen bestanden. En op het moment dat die stapel bestaat, begint een klok te tikken — want een archief dat niet doorzoekbaar is, niet te vertrouwen is en aan niemand anders over te dragen valt, is voor onderzoeksdoeleinden nauwelijks een archief.

De mensen die dit beroepsmatig bestuderen, verwoorden het botweg. Door de hele literatuur heen luidt de terugkerende bevinding dat databeheer, en niet gegevensverzameling, de beperkende factor is bij het afronden van cameravalstudies. Camera's werden goedkoop en betrouwbaar; de opslag-en-tagmuur bewoog niet mee. Het catalogiseren loopt achter op het verwerven, en “een grote hoeveelheid gegevens blijft ongebruikt en gaat uiteindelijk verloren voor wetenschap en natuurbeheer”. Eén overzicht vond dat vergelijkingen tussen locaties en meta-analyses vrijwel volledig ontbreken in de literatuur — niet omdat de gegevens niet bestaan, maar omdat iedereen ze anders ordende, op de eigen private manier, en niemand ze kan combineren.

Dit artikel gaat over de stap vóór de analyse: hoe een foto-archief van wildcamera's wordt opgezet, benoemd, getagd, geback-upt en uiteindelijk gedeeld, zodat het het project overleeft, personeelsverloop overleeft en bruikbaar blijft voor jezelf en voor iedereen met wie wordt samengewerkt. Het gaat niet over waar de camera's komen te staan, en het gaat niet over het omzetten van tijdstempels in activiteitscurven — dat zijn hun eigen taken. Zie wat volgt als het leidingwerk. Het is roemloos, het is de plek waar de meeste projecten stilletjes waarde lekken, en het goed doen is bijna volledig een kwestie van beslissingen in het eerste uur, niet het laatste.

Waarom dit het knelpunt is, en waarom “ik sorteer het later wel” faalt

Het helpt te begrijpen waarom deze stap projecten verzwelgt, want de redenen vertellen waartegen verdedigd moet worden.

De eerste reden is ruwe hoeveelheid die botst op handwerk. Het ophalen, opslaan, ordenen en — het pijnlijkst — identificeren van de inhoud van elk beeld gebeurt nog grotendeels met de hand, en beeldclassificatie wordt stelselmatig aangewezen als de grootste uitdaging bij cameravallen. Het werk is “bewerkelijk, tijdrovend, foutgevoelig en duur”. Wanneer het handwerk het tempo niet kan bijhouden, groeit de achterstand, en een achterstand van ongecatalogiseerde beelden is feitelijk een achterstand van verloren gegevens.

De tweede reden is dat handmatige verwerking fouten kweekt, en fouten in een archief zijn aantastend op een manier die ze in één enkel rekenblad niet zijn. Er bestaat een prachtig, concreet getal hiervoor uit een gedragsstudie in Namibië die ruwweg 1,2 miljoen foto's van 26 camera's over drie jaar beheerde: voordat het team de bestandsverwerking automatiseerde, waren menselijke fouten — verkeerd gelabelde mappen, kopieën naar de verkeerde plek gestuurd — goed voor 15,5% van hun data-uitval; nadat ze software de downloads lieten beheren, daalde dat tot 6,2%. Dezelfde mensen, dezelfde camera's. Het verschil was structuur.

De derde reden is die welke het vakgebied het meest kost: versnippering. Omdat de meeste projecten alleen ooit gaven om hun eigen doelsoort en hun eigen ad-hocsysteem bouwden, is het resultaat wat één veelgeciteerd artikel “donkere data” noemt — gegevens die niet beschikbaar zijn voor andere onderzoekers of het publiek, opgesloten in een programmaspecifiek formaat en opgeslagen op iemands lokale schijf. Cameravallen zijn onbevooroordeeld; ze fotograferen alles wat de sensor in werking stelt. Wie alleen de reeën catalogiseert en de rest weggooit, heeft gegevens weggegooid waarvoor een ander team — dat de vossen bestudeert, of de mensen, of de interacties daartussen — een moord zou hebben gedaan. De oplossing is alles te catalogiseren, consequent, de eerste keer.

Dus “ik sorteer het later wel” faalt om een eenvoudige reden: later is wanneer de hoeveelheid het grootst is, de herinnering aan welke camera waar stond het vaagst, en de kosten van elke fout vermenigvuldigd zijn over de hele verzameling. De discipline moet naar voren worden gehaald. Het goede nieuws is dat de naar-voren-gehaalde versie niet veel werk is — het zijn vooral een handvol conventies, toegepast vanaf dag één. Camera's werden goedkoop en betrouwbaar; de opslag-en-tagmuur bewoog niet mee, en de enige weg eroverheen is de gewoonten inbouwen voordat de stapel bestaat.

Camera's werden goedkoop en betrouwbaar; de opslag-en-tagmuur bewoog niet mee.

Mapstructuur: orden per uitrol, kopieer ongewijzigd van de kaart af

Begin met de mappen, want al het andere hangt eraan.

Er is opvallende overeenstemming in het vakgebied over het kernbeginsel, ook al verschillen de gereedschappen: orden media in één map per uitrol — waarbij een uitrol één plaatsing van een camera op één plek voor één tijdsbestek is — en hernoem de bestanden niet zoals ze van de kaart komen. De best-practicesgids van GBIF stelt het bijna als een gebod: “Vermijd het hernoemen van mediabestandsnamen. Orden mediabestanden liever in één map per uitrol”.

Waarom zo stellig over niet hernoemen? Vanwege hoe uniciteit van bestandsnamen werkelijk werkt. De meeste camera's benoemen bestanden met een korte oplopende teller (`IMG_0001.JPG`, `PICT0001.JPG`), en die namen zijn alleen gegarandeerd uniek binnen één kaart. Trek beelden van drie camera's in één map en er botsen meteen drie `IMG_0001.JPG`-bestanden. Elke uitrol in zijn eigen map houden omzeilt het hele probleem, en het betekent dat de inhoud van een kaart precies zo kan worden overgekopieerd als hij is — geen transformatie, geen gelegenheid om een fout te introduceren. De auteurs van Aardwolf bouwden hun hele driedelige schema (project → camera → download-operatiemap) rond dit inzicht: “deze fysieke structuur zorgt er ook voor dat mappen van een opslagkaart van een cameraval ongewijzigd kunnen worden gekopieerd”.

De R-toolkit camtrapR formaliseert een nauw verwante indeling. Voor een onderzoek met één camera per station ontstaat `rawImages/stationA`, `rawImages/stationB`, enzovoort; met meer dan één camera per station komt er een niveau bij: `rawImages/stationA/camera1`, `rawImages/stationA/camera2`. En hij komt met een waarschuwing die het waard is ergens zichtbaar te tatoeëren: “Heb je meer dan 1 camera per station maar scheid je de beelden van verschillende camera's op dit moment niet, dan kun je dat later niet meer doen”. Voeg ze nu samen en de herkomst is voorgoed weg. Dit is het terugkerende thema van het hele onderwerp — sommige informatie kan alleen op het moment van inlezen worden bewaard, nooit gereconstrueerd.

Twee gewoonten maken dit compleet. Ten eerste: bewaar de ruwe beelden als een onaangeroerde back-up en werk op een kopie — de hernoemfunctie van camtrapR kopieert beelden opzettelijk naar een nieuwe locatie zodat de originelen nooit in gevaar komen. Ten tweede: bewaar niets anders dan beelden in de beeldmappen; verdwaalde bestanden kunnen de gereedschappen storen die die mappen doorzoeken.

Hoe diep moet de hiërarchie gaan? Leen de vuistregel uit de wereld van onderzoeksdatabeheer, die hier langer over heeft nagedacht dan cameravallers: beperk mappen tot drie of vier niveaus diep, en probeer niet meer dan ongeveer tien items in één lijst te hebben, waarbij gegevens en documentatie in gescheiden takken worden gehouden. Een cameravalproject belandt hier vanzelf — project, dan locatie of uitrol, dan kaart — zonder dat iemand het hoeft te forceren.

Sommige informatie kan alleen op het moment van inlezen worden bewaard, nooit gereconstrueerd.

Naamgevingsconventies: begin met de datum, nooit met de soort

Wanneer bestanden wel worden hernoemd — en daar zijn legitieme redenen voor, vooral om ze zelfbeschrijvend te maken zodra ze de veiligheid van hun map verlaten — is er één juiste manier en zijn er meerdere verkeerde.

De verreweg belangrijkste regel is alfabetische volgorde te laten samenvallen met chronologische volgorde. De schone truc is de naam te beginnen met de datum, `YYYYMMDD`, of de datum en tijd, `YYYYMMDD_HHMMSS`. De GBIF-gids geeft de uitgewerkte voorbeelden rechtstreeks: `20200709_093352.JPG` is goed, omdat het correct sorteert; `09072020_093352.JPG` is slecht, omdat dag-eerst naamgeving de chronologische volgorde door de war stuurt zodra er meer dan één maand aan gegevens is. Dit is geen muggenzifterij — de helft van alle gebruikelijke gereedschappen gaat ervan uit dat de bestandsvolgorde de tijdsvolgorde weerspiegelt, en een camera die bestanden `1.jpg, 2.jpg … 10.jpg` noemt wordt door de computer gelezen als `1, 10, 2 …`, wat die aanname stilletjes breekt.

De algemene gidsen voor gegevensarchivering zijn het eens en voegen de huishoudelijke details toe: gebruik data in ISO-vorm `YYYY-MM-DD`, scheid elementen met koppeltekens of underscores, vermijd spaties en speciale tekens als `&`, `?` of `!`, houd namen betekenisvol maar kort, reserveer de drieletterige extensie voor het bestandsformaat, en neem een versieaanduiding op waar dat ertoe doet. Het eigen naamgevingsschema van camtrapR is hiervan een concreet geval: het hernoemt naar `StationID__Date__Time(X).JPG`, waarbij de `(X)` beelden onderscheidt die in dezelfde minuut zijn genomen, en het reserveert dubbele underscores als veldscheidingstekens — dus de station- en camera-ID's mogen zelf geen underscores bevatten.

Er is hier één regel die cameravallers voortdurend schenden, en die verdient een eigen regel: bewaar geen classificatie-informatie in de bestandsnaam. Het is verleidelijk een foto te hernoemen naar `..._Ardea_alba_1_Anas_platyrhynchos_male_female.jpg` om hem later terug te vinden. Doe het niet. De GBIF-gids markeert precies dit als slechte praktijk. De reden is dat een identificatie geen feit over het bestand is; het is een interpretatie, en interpretaties worden herzien. Bak “boommarter” in duizend bestandsnamen en ontdek dan dat de helft steenmarter was, en er staan nu duizend hernoemoperaties en een gebroken controlespoor. Tags horen in de metadata, waar ze kunnen worden gecorrigeerd zonder de identiteit van het bestand aan te raken — precies waar we hierna heen gaan. (camtrapR kan een soortnaam aan een bestandsnaam toevoegen als hulpmiddel voor het bladeren, maar merk op dat het die soort-ID in de eerste plaats uit de mapstructuur of de metadatatags leest; de identificatie leeft elders, en de bestandsnaam is er slechts een kopie van.)

Hernoemen in bulk gebeurt niet met de hand. Toegewijde batch-hernoemgereedschappen bestaan voor elk platform, en het metadatahulpmiddel ExifTool kan bestanden hernoemen vanuit hun eigen metadata — waarbij het de opnamedatum rechtstreeks uit elk beeld haalt om de nieuwe naam op te bouwen — samen met batch-metadatabewerkingen, geotagging en datum-/tijdcorrectie.

Taggen en annoteren: spreek het schema af voordat je een beeld aanraakt

Nu het deel dat iedereen ziet als “het werk”: beelden doorlopen en vastleggen wat erop staat. Deze stap heet taggen — elk beeld onderzoeken en de kenmerken van belang coderen als gegevens — en het is waar de grootste, duurste en best te voorkomen fouten gebeuren.

De diepste les hier komt uit een artikel dat acht jaar bouwen aan het beeldanalysehulpmiddel Timelapse destilleert, en het is geen tip over software. Het gaat over een beslissing die aan de software voorafgaat: specificeer en gebruik een gemeenschappelijk dataschema. Voordat iemand ook maar iets tagt, zou de projectleider precies moeten bepalen welke gegevens uit de beelden worden vastgelegd, ze definiëren als een gestandaardiseerd, machineleesbaar schema — de velden, hun namen, hun datatypen, hun toegestane waarden — en de software het dan laten afdwingen. De reden is het probleem van meerdere taggers. Een echt project heeft meerdere mensen (vaak inclusief vrijwilligers) die elk een deel van de beelden doorwerken, en “zonder dataconsistentie — als elke analist idiosyncratisch bepaalde welke gegevens uit beelden gecodeerd zouden worden, in welk formaat en onder welke naam — zou het uitermate moeilijk zijn de gegevens over analisten heen te begrijpen”. Spreek het schema eerst af, of besteed de rest van het project aan het verzoenen van tien dialecten van dezelfde dataset.

Een concreet, citeerbaar sjabloon voor dat schema is de vier-tabellenindeling waarnaar geordende projecten convergeren, mooi vastgelegd in een lesvoorbeeld rond een Canadese dataset: een projecttabel (doelstellingen, opzet, wie de leiding heeft), een beeld-/waarnemingstabel (soort, aantal, leeftijd/geslacht, gedrag, tijdstempel, per beeld), een uitroltabel (locatie, begin en einde, camera, hoogte, oriëntatie), en een camera-inventaris (merk, model, serienummer). Elke unieke cameraplaatsing krijgt zijn eigen uitrolrecord. Dit is hetzelfde skelet dat de formele standaarden gebruiken — daarover zo meer — en zelfs zonder ooit te publiceren betekent de gegevens vanaf het begin zo indelen dat de juiste dingen op de juiste plaats worden bewaard.

Naast het schema is het artikel over acht jaar Timelapse een catalogus van moeizaam verworven efficiëntiepatronen, en die zijn het waard te kennen omdat ze een werkstroom die een seizoen kost scheiden van een die een jaar kost. Hetzelfde team mat ruwweg 200% tijdsverbetering ten opzichte van analisten die een gewoon rekenblad gebruikten. Enkele van de patronen die het meest ertoe doen:

• Minimaliseer het typen. Typen is traag en foutgevoelig; vervang het waar mogelijk door selectie — keuzelijsten voor soorten, selectievakjes voor markeringen, autoaanvulling die eerdere invoer aanbiedt.
• Tel door te klikken, en markeer wat je hebt geteld. Wanneer een beeld een kudde bevat, is verkeerd tellen makkelijk — je plek kwijtraken, dubbel tellen, er een overslaan. De tagger elk dier laten aanklikken om een teller op te hogen én een zichtbare markering te plaatsen verhelpt alle drie de foutmodi tegelijk en laat een tweede persoon de telling later verifiëren.
• Vul automatisch in wat de computer al weet. Bestandsnaam, map en opnamedatum/-tijd zouden automatisch moeten worden gevuld, nooit opnieuw getypt. Veel camera's verankeren ook extra's — omgevingstemperatuur, soms GPS — die rechtstreeks uit de beeldmetadata in de datavelden kunnen worden getrokken.
• Groepeer reeksen tot episoden. Een bewegingstrigger vuurt vaak een reeks af, en één dier dat blijft hangen levert veel bijna identieke beelden op. Beelden die binnen een kort interval zijn genomen groeperen tot één “episode” laat de tagger de gebeurtenis eenmaal vastleggen in plaats van de tellingen op te blazen — het gereedschap kan het eerste beeld van elke episode markeren en de rest nummeren.
• Verspreid herhalende waarden. Over een reeks vergelijkbare beelden zijn de gegevens vaak identiek; kopieer-vooruit, vul-terug en kopieer-naar-alles-knoppen maken van honderd identieke invoeringen er één.

Dit zijn geen luxes. Slechte gereedschapskeuzes betekenen “vervelende gegevensinvoer... foutgevoelig (wat de geldigheid van de verzamelde gegevens aantast)... en — op de lange termijn — zeer duur in termen van analistentijd”. Terzijde, dit is de meest eerlijke manier om over software in het algemeen voor deze taak te denken: het eigen overzicht van het vakgebied van beschikbare programma's vond dat geen enkel hulpmiddel als duidelijke favoriet naar voren is gekomen, en een groot best-practicesrapport concludeerde vrijwel hetzelfde — veel grote projecten “zijn uiteindelijk hun eigen systemen vanaf nul gaan ontwerpen”, en wellicht moeten er meerdere worden getest voordat er één bij de werkstroom past. Er is geen universeel juist antwoord; er is de schemadiscipline, en er is het afstemmen van het gereedschap op hoe de mensen werkelijk werken.

Spreek het schema eerst af, of besteed de rest van het project aan het verzoenen van tien dialecten van dezelfde dataset.

Waar de tags leven: EXIF, IPTC, XMP en sidecar-bestanden

Stel, een soort is aan een beeld getagd. Waar gaat die tag fysiek heen — en zit hij er nog wanneer de map over een jaar naar de machine van een collega wordt gekopieerd?

Hier loont het te begrijpen dat er drie metadatastandaarden in (en naast) een beeldbestand leven, want ze doen verschillend werk:

• EXIF is wat de camera schrijft op het moment van opname — datum en tijd, plus instellingen als sluitertijd, belichting, ISO en flitsstatus. Doorgaans wordt het niet bewerkt maar gelezen. Het datum-en-tijdveld (`DateTimeOriginal`) is hier het kroonjuweel, en we komen terug op waarom.
• IPTC is voor tekst na de opname die handmatig wordt toegevoegd — auteur, copyright, bijschriften, en cruciaal trefwoorden. De keerzijde is dat de tekstvelden een lengtebeperking hebben.
• XMP is de moderne evolutie van IPTC. Het “verwijdert de beperkingen van de tekstgrootte” en ondersteunt meerdere talen, en daarom raadt het gereedschap doorgaans aan XMP de hoogste prioriteit te geven voor tags en bijschriften.

Het punt dat alle drie belangrijk maakt voor een archief: trefwoorden en tags kunnen rechtstreeks in de eigen metadata van het beeld worden geschreven, via de IPTC- en XMP-velden. Dat betekent dat een soorttag — “rode vos”, of een heel hiërarchisch onderwerp als Mammalia > Carnivora > Vulpes > Vulpes vulpes — binnen de foto kan worden opgeslagen, zodat hij met het bestand meereist. Zoals de documentatie van één metadatahulpmiddel het ronduit stelt: “Metadata rechtstreeks in beeldbestanden opslaan maakt het mogelijk deze informatie te behouden bij het verplaatsen of verzenden van beeldbestanden naar andere systemen”. Dat is het hele spel. Een tag in een aparte database die bij een kopie achterblijft is een verloren tag; een tag verankerd in het bestand overleeft de reis.

Er is een subtiliteit die het waard is te kennen, vooral bij RAW of video. Metadata terugschrijven in het oorspronkelijke bestand lukt niet altijd — RAW-formaten zijn vaak alleen-lezen, en videotaggen is slecht gestandaardiseerd. Het antwoord is een sidecar-bestand: een klein begeleidend bestand (genoemd `bestandsnaam.ext.xmp`) dat de metadata naast het beeld bewaart, gebruikt op zichzelf of als aanvulling op het schrijven binnen het bestand. De praktische keuze is dus instelbaar — tags in het beeld schrijven, in een sidecar, of beide — en de juiste instelling hangt af van de bestandstypen.

Een pragmatische, veelgebruikte hybride is tags op twee plekken tegelijk op te slaan: verankerd in het beeld (of zijn sidecar) zodat ze overdraagbaar zijn, en ook in een externe database voor snel zoeken — waarbij de database als cache wordt behandeld en de bestanden als “de enige bron van waarheid”. Zo ontstaat snelheid bij het bevragen en duurzaamheid bij het verplaatsen.

Onder vrijwel dit alles ligt één klein, roemloos, onmisbaar hulpmiddel: ExifTool, Phil Harveys gratis, platformonafhankelijke hulpprogramma voor het lezen, schrijven en bewerken van metadata over honderden formaten heen, inclusief EXIF, IPTC en XMP. Het is de motor waar de onderzoekstoolkits op leunen — camtrapR bijvoorbeeld hangt er voor elke metadatabewerking van af en doet zonder hem weinig. Het wordt zelden rechtstreeks aangeroepen, maar het doet vrijwel zeker het werk achter wat er ook wordt gebruikt.

Eén eerlijke kanttekening bij hoe de soort-tag-in-metadata-werkstroom in de praktijk werkelijk aan elkaar wordt geknoopt, want de gereedschappen verdelen het werk op een manier die mensen verrast. Een algemene fotobeheertoepassing schrijft doorgaans het soorttrefwoord in de eerste plaats in de beeldmetadata (via zijn trefwoord-/onderwerpvelden), en de R-toolkit leest die verankerde tags er vervolgens weer uit — camtrapR kan een soort-ID uit de metadatatag `HierarchicalSubject` trekken die een tag-toepassing schreef — om zijn recordtabellen samen te stellen. De identificatie ontstaat in het taghulpmiddel; het metadataveld is hoe ze wordt opgeslagen en doorgegeven.

Een tag in een database die bij een kopie achterblijft is een verloren tag; een tag verankerd in het bestand overleeft de reis.

De tijdstempel verdient bijzondere paranoia

Van alle gegevens die aan een beeld hangen, is één veld uniek onherstelbaar, en het is het waard uit de metadatabespreking te lichten om het op zichzelf te benadrukken.

De GBIF-gids is ondubbelzinnig: de datum en tijd waarop een foto is genomen “is het belangrijkste aspect van de metadata... en kan later niet worden afgeleid” — in tegenstelling tot bijvoorbeeld de locatie van de camera, die altijd achteraf valt op te zoeken. Bij een verkeerde tijdstempel is er geen tweede bron om hem uit te herstellen. Het Timelapse-team catalogiseerde, na acht jaar dit fout te hebben zien gaan, de vier klassieke faalmodi: een camera waarvan de klok simpelweg nooit goed is ingesteld (alles verschoven met een vast bedrag); een camera die de zomertijdovergang niet aankan (een deel van de beelden verschoven met een uur); een klok die langzaam voor- of achterloopt gedurende een uitrol; en een camera die data dubbelzinnig registreert, zoals `02/10/2019`, wat februari of oktober kan zijn afhankelijk van de conventie.

Twee bovenstroomse gewoonten voorkomen het meeste hiervan, en beide zijn per ontwerp locatie-neutraal. Ten eerste: stel de klok van de camera in op de gecoördineerde wereldtijd (UTC) of op lokale wintertijd, en schakel de automatische omschakeling naar zomertijd uit — leg dan de tijdzone van de uitrol apart vast. De reden dat dit “zet hem op lokale tijd” verslaat, is dat het omschakelen naar zomertijd de stille saboteur is: het legt een verborgen naad van één uur door de helft van de records, en een klok die vastzit op UTC of wintertijd heeft simpelweg geen naad om over te struikelen. Ten tweede: schrijf bij het exporteren of benoemen van bestanden tijden in een ondubbelzinnige volgorde — datum eerst, `YYYY-MM-DD` of de volledige ISO-tijdstempel — zodat niemand verderop hoeft te raden of `02/10` februari of oktober is.

Blijkt achteraf dat de klok van een uitrol met een bekend bedrag verkeerd stond, dan is het herstelbaar in bulk — het gereedschap kan de tijdstempels van elk beeld in een map met een vaste verschuiving opschuiven, wat de juiste manier is om bijvoorbeeld de firmwarefout af te handelen die een grote fabrikant uitleverde en die het jaar op zijn camera's rond de jaarwisseling 2015/2016 door de war stuurde. Maak eerst een back-up van de beelden, corrigeer dan. Het diepere punt blijft staan: een klokfout die bij het inlezen wordt gevangen is een ergernis van vijf minuten; dezelfde fout die nooit wordt gevangen is een permanente verzinning in de dataset.

De lege beelden opruimen: AI-voorfiltering

Hier is het deel van de werkstroom waar het hoeveelheidsprobleem en modern gereedschap eindelijk in het voordeel samenkomen.

Cameravallen vuren op warmte en beweging, wat betekent dat ze even gemakkelijk vuren op door de wind bewogen takken, wuivend gras, regen, verschuivend zonlicht en warme lucht als op dieren. Het gevolg is dat een grote meerderheid van de beelden in een doorsnee-uitrol helemaal geen dier bevat — het zijn lege beelden. (In het vakgebied circuleert een specifiek “70–95% leeg”-cijfer; behandel het als volksverhaal tenzij de eigen gegevens anders zeggen, want het is niet aan één solide bron gekoppeld. Wat wel goed onderbouwd is, is de kwalitatieve realiteit: de lege beelden overtreffen doorgaans ruimschoots de nuttige, en ze met de hand doorlopen is de grote tijdvreter van de hele onderneming.) Er handmatig doorheen ploegen is precies het “saaie” werk dat analistenuren opslokt.

Het standaardgereedschap om erdoorheen te snijden is een detectormodel — het bekendst MegaDetector, het open-sourcemodel van Microsofts AI for Good Lab. Het doet één taak en doet die breed: het “detecteert dieren, mensen en voertuigen in cameravalbeelden en filtert lege beelden eruit, wat het handmatig beoordelen over grote datasets vermindert”. Getraind op enkele miljoenen beelden uit vele ecosystemen, is het opgepikt door ruim honderd organisaties wereldwijd, van nationale faunadiensten tot universiteitslaboratoria over meerdere continenten. Cruciaal is het besef van de reikwijdte: MegaDetector vindt dieren; het identificeert ze niet tot op de soort. Het is een grove maar meedogenloze eerste doorloop — dier / mens / voertuig / niets — die de lege beelden opzij laat zetten en de echte aandacht laat besteden aan de beelden die daadwerkelijk iets bevatten. De coördinaten en betrouwbaarheid van de detector stromen vervolgens door naar een taghulpmiddel, dat een kader rond elke detectie tekent en het aanvaarden, verwerpen of van een soortlabel voorzien mogelijk maakt.

Een kanttekening bij wat dit wel en niet oplevert. Een detector ruimt lege beelden op; hij doet niet de soortidentificatie, en zelfs gekoppeld aan een soortclassifier blijft de nauwkeurigheid van computervisie nog achter bij een menselijke expert — dus de duurzame aanbeveling in het vakgebied is AI-ondersteunde voorfiltering plus menselijke verificatie, niet blinde automatisering. Zo gebruikt verandert het de rekenkunde van een project: in plaats van dat een persoon elk van een paar honderdduizend beelden opent, opent die de fractie die een detector als niet-leeg markeert, en verifieert van daaruit.

Een detector ruimt lege beelden op; het doet niet de soortidentificatie — koppel het aan een mens, niet aan blind vertrouwen.

Back-up en opslag: ga ervan uit dat een schijf zal falen, want dat gaat er een

Een archief is slechts zo duurzaam als zijn zwakste enkele punt van falen, en bij cameravallen is dat punt doorgaans een harde schijf op één bureau.

De hoeveelheid die al het andere lastig maakt, maakt ook back-uppen niet-triviaal: het is “niet triviaal om mediabestanden op deze schaal veilig op te slaan, te back-uppen en te beheren”. De standaardrichtlijn is clouddiensten of goed beheerde institutionele opslag te gebruiken, in de wetenschap dat dit reële kosten met zich meebrengt, en — waar dat kan — een opslagsysteem te gebruiken dat bestanden over stabiele webadressen kan aanbieden, zodat een gepubliceerde dataset de beelden rechtstreeks kan aanhalen in plaats van kopieën van alles te versturen. De algemene databeheergidsen versterken de voor de hand liggende discipline die cameravallers op eigen risico overslaan: bewuste back-up, niet slechts “het staat op mijn laptop”.

Twee ontwerpkeuzes uit het gereedschap zijn het waard te stelen, zelfs zonder de gereedschappen zelf ooit aan te raken. De eerste is het al genoemde bestanden-als-bron-van-waarheid-model: houd de gezaghebbende gegevens in de beeldbestanden (en hun sidecars), en behandel elke database als een herbouwbare cache. Raakt de database beschadigd, dan wordt hij opnieuw uit de bestanden gegenereerd; de werkelijke waarnemingen gaan nooit verloren. De tweede is het scheiden van logische ordening en fysieke locatie — waarbij de gegevens van één project meerdere schijven of een netwerkschijf kunnen beslaan terwijl ze zich toch als één schone hiërarchie presenteren — wat precies is hoe een minimalistisch systeem opschaalde tot meer dan een miljoen foto's op standaardhardware.

De rode draad is te stoppen met vertrouwen op enig enkel apparaat. Schijven falen, kaarten raken beschadigd, en de botte optelsom van fysieke storingen uit de Namibische studie — regenschade, lege batterijen, kaartstoringen, vernieling door wilde dieren — is een herinnering dat het veld vijandig is voor de gegevens lang voordat ze een computer bereiken. Redundantie is niet optioneel; het is de prijs van het levend houden van een meerjarig archief.

Datastandaarden: een taal spreken die anderen kunnen lezen

Alles tot nu toe maakt het archief bruikbaar voor de maker ervan. Standaarden zijn wat het bruikbaar maakt voor iedereen anders — en, steeds vaker, voor het eigen toekomstige zelf en de machinelearningmodellen die later getraind zouden kunnen worden.

Twee standaarden domineren, en ze nesten netjes.

Camtrap DP (het Camera Trap Data Package) is de doelgebouwde. Het is een door de gemeenschap ontwikkeld uitwisselingsformaat, beheerd onder het orgaan Biodiversity Information Standards (TDWG), dat een heel project structureert in drie gekoppelde tabellen — Deployments, Media en Observations — plus een metadatabestand dat het pakket beschrijft. Het is juist ontworpen omdat, hoewel het verwerken van cameraval-“Big Data” hanteerbaar was geworden, “harmonisatie en uitwisseling van de gegevens beperkt blijven, wat hun volle potentieel belemmert”. Het ondersteunt de volle breedte van hoe mensen werkelijk werken — menselijke en AI-classificatie, beeldgebaseerd en gebeurtenisgebaseerd — en het bouwt voort op een bestaande open dataverpakkingsspecificatie zodat standaardsoftware het automatisch kan valideren. Het is in feite de moderne opvolger van een eerdere cameraval-metadatastandaard die als eerste de nu alomtegenwoordige vierniveauhiërarchie van Project → Deployment → Image Sequence → Image definieerde en de conventie om binnen 60 seconden genomen beelden tot één reeks te groeperen.

Darwin Core is de bredere biodiversiteitsstandaard waar cameravalgegevens ook in kunnen stromen. Het is “een set termen met duidelijk gedefinieerde semantiek die door mensen kan worden begrepen of door machines geïnterpreteerd”, in 2009 als standaard geratificeerd en gebruikt om honderden miljoenen biodiversiteitsrecords te delen over honderden organisaties en tientallen landen. De termen zijn georganiseerd in klassen die dingen als gebeurtenis, locatie, voorkomen en taxon bestrijken; een cameravalwaarneming wordt afgebeeld op de klasse Occurrence. Omdat het bewust eenvoudig en technologieonafhankelijk is, kunnen dezelfde gegevens worden uitgedrukt als CSV, XML, JSON of andere coderingen.

Hoe valt te kiezen? De praktische richtlijn is helder: voor cameravalgegevens specifiek verdient Camtrap DP de voorkeur, omdat het “specifiek voor dit soort gegevens is ontworpen en meer informatie kan behouden dan een Darwin Core Archive”, terwijl een Darwin Core Archive de route is om aan te sluiten op de bredere wereld van biodiversiteitsgegevens. En de twee zijn geen rivalen — er is een R-pakket wiens hele taak het is een Camtrap DP te lezen en om te zetten naar Darwin Core (en naar EML), wat precies de brug is die een openbare repository gebruikt om cameraval­pakketten in te lezen. Werken in het cameraval-eigen formaat en toch publiceren in het algemene kan allebei.

Eén kader dat deze hele standaardenbespreking locatie-neutraal maakt en het waard is eigen te maken: bewaar de wetenschappelijke naam, ook al krijgt het publiek alleen ooit de gewone te zien. Gewone namen drijven af over regio's en talen heen en wijzen soms op geheel verschillende dieren — “elk” betekent één soort in Noord-Amerika en een andere in Europa — terwijl de wetenschappelijke naam wereldwijd consistent en ondubbelzinnig is. Houd één referentietabel bij van de verwachte soorten, afkomstig uit een gezaghebbende taxonomie, en bewaar de wetenschappelijke naam als anker. Het is een kleine gewoonte die een internationale samenwerking behoedt voor een categorie verwarring die achteraf werkelijk lastig te ontwarren is.

Delen en archiveren: een private map in een openbaar bezit veranderen

De laatste stap — en degene die een onderzoeksarchief onderscheidt van een persoonlijke schoenendoos — is de gegevens ergens publiceren waar anderen ze kunnen vinden en hergebruiken.

De bestemming is in de onderzoekswereld doorgaans een openbare biodiversiteitsrepository, bereikt via een standaardpublicatiepijplijn; de Global Biodiversity Information Facility (GBIF) is de grote, en publicatie ernaar verloopt door de gegevens eerst te standaardiseren naar Camtrap DP of Darwin Core. Het leidende doel heeft een naam — FAIR-gegevens: findable, accessible, interoperable, reusable (vindbaar, toegankelijk, interoperabel, herbruikbaar) — en het recept is concreet: deponeer de gegevens in een repository die ze een stabiele unieke identificatie geeft, voeg rijke metadata toe zodat anderen kunnen beoordelen of ze bij hun behoeften passen, voeg een open licentie toe zodat ze de gegevens mogen gebruiken, en standaardiseer het formaat zodat het daadwerkelijk combineert met andere datasets. De sterke aanbeveling is één dataset per project te publiceren, wat de reikwijdte, methoden en bijdragers op één samenhangende plek beschrijfbaar houdt.

Voordat er iets openbaar gaat, doen twee voorbereidingsstappen ertoe. Ten eerste stabiele, unieke identificaties voor de records — idealiter degene die het beheersysteem al toewees, ongewijzigd gebruikt in plaats van eraan te sleutelen, aangezien stukjes aan een identificatie plakken die alleen maar fragiel maakt. Ten tweede behandel gevoelige informatie door te veralgemenen, niet door te wissen. Cameravalgegevens dragen drie soorten gevoeligheid: de locaties van zeldzame of bedreigde soorten (die stropers kunnen aantrekken), de locaties van de eigen camera's (diefstal en vandalisme), en persoonsgegevens — de namen van deelnemers, en beelden van herkenbare mensen, die onder privacyregelgeving als de AVG vallen. De aanbevolen aanpak is de coördinaten van een gevoelige soort te vervagen in plaats van het record volledig achter te houden, beelden van mensen privé te houden, en de toegepaste veralgemening te documenteren zodat gebruikers weten waar ze naar kijken. De wereld van de burgerwetenschap doet hier al lang versies van: de locatie van bedreigde en met uitsterven bedreigde soorten maskeren zodat openbare datapunten alleen tot het centrum van een project herleiden, en data-embargo's aanbieden zodat een team als eerste kans krijgt te publiceren voordat de gegevens opengaan.

Het is het waard ronduit te zeggen waarom delen überhaupt de moeite is, want het is makkelijk publicatie als bureaucratische overlast te behandelen. De hele reden dat het “donkere data”-probleem ertoe doet, is dat cameravalgegevens die in een consistent formaat worden gedeeld ver buiten hun oorspronkelijke doel herbruikbaar zijn — voor het modelleren van soortverspreiding, voor biodiversiteitsmonitoring, zelfs als trainingsgegevens voor de volgende generatie detectiemodellen. De gegevens die je verzamelde om één vraag te beantwoorden kunnen, mits goed gearchiveerd en gedeeld, helpen een dozijn andere te beantwoorden die je nooit had bedacht te stellen. Dat is het hele argument om dit alles zorgvuldig te doen: een geordend, gestandaardiseerd, openbaar gepubliceerd archief overleeft niet alleen het project — het ontgroeit het.

De gegevens die je verzamelde om één vraag te beantwoorden kunnen, mits goed gearchiveerd, helpen een dozijn andere te beantwoorden die je nooit had bedacht te stellen.

Een minimale werkstroom, van begin tot eind

Voor het geheel als één opeenvolging volgt hier de ruggengraat die de bronnen gezamenlijk beschrijven — pas de gereedschappen aan, houd de volgorde:

1. Lees in per uitrol. Kopieer elke kaart naar zijn eigen map per uitrol, ongewijzigd; houd de ruwe kopie onaangeroerd als back-up.
2. Corrigeer eerst de klok. Verifieer tijdstempels; stond de klok van een uitrol met een bekend bedrag verkeerd, schuif hem nu in bulk op, voordat iets anders die tijden leest.
3. Bepaal het schema. Definieer de datavelden en toegestane waarden vooraf en laat de software ze afdwingen over elke tagger heen.
4. Filter de lege beelden voor. Draai een detector om lege beelden opzij te zetten zodat menselijke aandacht alleen naar beelden met iets erin gaat.
5. Tag efficiënt, in de metadata. Identificeer en annoteer met selectie boven typen en episodegroepering boven beeld-voor-beeld, en bewaar de tags in de eigen EXIF/IPTC/XMP van het beeld (of een sidecar) zodat ze meereizen.
6. Maak redundant een back-up. Cloud- of institutionele opslag, plus de discipline dat de bestanden — niet enige database — de bron van waarheid zijn.
7. Standaardiseer en deel. Exporteer naar Camtrap DP (of Darwin Core), veralgemeen alles wat gevoelig is, en publiceer één dataset per project naar een openbare repository.

Geen van deze stappen is lastig. Verscheidene ervan zijn onmogelijk later te doen. Die asymmetrie is de hele reden om de saaie stap serieus te nemen: het archief dat over vijf jaar aan een vreemde valt te overhandigen wordt gebouwd, of verloren, in het eerste uur nadat de kaarten thuiskomen.

Veelgestelde vragen