E57 uitgelegd: de "PDF van puntenwolken"
Stel u voor dat u een kamer fotografeert, maar geen platte afbeelding vastlegt. In plaats daarvan legt u de exacte positie vast van een miljoen kleine punten die elke muur, stoel en koffiemok bedekken. Laat een laser snel genoeg ronddraaien en meet hoe ver weg alles is, en u krijgt een puntenwolk: een 3D-"foto" die uit gemeten punten bestaat. Dit is een toegankelijke, jargonvrije rondleiding door de inhoud van een E57-bestand — inclusief een slimme truc die onze eigen software ermee uitvoert.
Waarom überhaupt een speciaal formaat?
Een gewone foto is simpelweg een raster van gekleurde pixels. Een 3D-scan is ingewikkelder. Van elk van de miljoenen punten wilt u opslaan waar het zich in de ruimte bevindt (drie getallen: X, Y, Z), welke kleur het heeft, hoe sterk het laserlicht werd teruggekaatst (de intensiteit — vergelijkbaar met een zwart-witte "laserfoto") en vaak ook de panoramafoto's die de scanner tegelijkertijd maakte.
Stel dat de ene persoon met een Faro scant, een collega een Leica gebruikt en de klant het resultaat in Autodesk-software opent. Drie apparaten, drie programma's — en die moeten allemaal hetzelfde bestand kunnen lezen, ook over jaren, zonder bij een leverancier om een geheime decoder te hoeven bedelen. Dat is het probleem dat E57 oplost. Het is een open, leveranciersonafhankelijke standaard (gepubliceerd als ASTM E2807 en gebaseerd op de opensourcebibliotheek libE57). E57 wordt wel de "PDF van puntenwolken" genoemd: één overdraagbaar bestand dat iedereen op dezelfde manier kan lezen.
Het grote idee: een tekstkaart met binaire spierkracht
In de kern is een E57-bestand een hybride combinatie van twee heel verschillende onderdelen: een klein stuk XML — gewone, voor mensen leesbare tekst die als inhoudsopgave dient — en grote blokken binaire gegevens met miljoenen ruwe getallen, compact opgeslagen voor snelle verwerking.
Waarom de kaart aan het einde zetten? Omdat een scanner tijdens het schrijven van het bestand nog niet weet hoe groot alles zal worden, dus eerst de ruwe gegevens streamt en pas aan het einde een nette samenvatting schrijft. De winst is enorm: om één scan uit een bestand van 20 gigabyte te halen, leest de software de kleine header, springt naar de XML-kaart, vindt de regel die zegt "scan #3 staat op byte 4.812.000.000" en gaat daar meteen heen.
Een onopvallend vangnet: het hele bestand is opgedeeld in "pagina's" van 1024 bytes. Op elke pagina zijn de laatste 4 bytes gereserveerd voor een controlesom — een vingerafdruk waarmee software kan vaststellen of het bestand beschadigd is.
Alles vertakt zich vanuit één wortel
Open die XML-kaart en u vindt een boom — net als de mappenstructuur op uw computer. Er is één root, en twee takken doen het meeste werk: data3D, een genummerde lijst van scans, en images2D, een genummerde lijst van foto's (meestal de 360°-panorama's die de scanner maakte).
Twee manieren om een punt op te slaan
Een laserscanner denkt niet echt in X, Y en Z. Hij staat op één plek en draait rond. Voor elk punt kent hij drie waarden: afstand (hoe ver de straal heeft afgelegd), azimut (de horizontale hoek, van links naar rechts) en elevatie (de verticale hoek, omhoog of omlaag). Dat zijn bolcoördinaten — de moedertaal van de scanner. De meeste software werkt echter liever met gewone cartesische X-, Y- en Z-coördinaten. E57 kan beide opslaan en met wat eenvoudige trigonometrie kan het ene stelsel snel naar het andere worden omgerekend.
Drie soorten ingesloten foto's
De foto's in images2D zijn geen links naar bestanden in een map — de daadwerkelijke JPEG of PNG zit in de E57 zelf. En er is meer dan één soort ingesloten foto. E57 verpakt elke foto in een "representatie" die software vertelt in hoeverre de afbeelding geometrisch betrouwbaar is. Het verschil komt neer op één vraag: hoe volledig is de camera beschreven?
sphericalRepresentation— een volledig panorama van 360° × 180°: het bekende uitgerekte equirectangulaire 2:1-beeld. Omdat de projectie bekend is, komt elke pixel overeen met een exacte richting en sluit het beeld perfect aan op de puntenwolk. Dit is de belangrijkste route in onze verwerkingsketen: we lezen het beeld in, passen het beeldvlak aan tot een zuivere 2:1-verhouding en geven het door aan de panoramaviewer.pinholeRepresentation— één gewone lensfoto, beschreven aan de hand van het klassieke pinholecameramodel (brandpuntsafstand, sensorgrootte en optisch middelpunt). Daarmee kan software ook de richting van elke pixel bepalen, maar alleen binnen een kleiner gezichtsveld. In de praktijk werkt vooral Leica zo: het schrijft een kant-en-klare cubemap — de zes platte, naar buiten gerichte kubusvlakken — rechtstreeks naar het E57-bestand. Onze verwerking voor kubusvlakken voegt die vervolgens samen tot een volledig panorama. Dit is een van de eenvoudigste gevallen om weer om te zetten in een zuiver 360°-beeld.visualReferenceRepresentation— een foto zonder enig cameramodel, expliciet "alleen voor het menselijk oog". U kunt er niet mee meten of de foto op de puntenwolk projecteren; het is alleen een referentieafbeelding. Onze importer bewaart deze als bijgevoegde opmerkingen in plaats van ze in 3D te plaatsen.
Hier zit een addertje onder het gras. sphericalRepresentation is de populaire keuze, maar daarbij ontstaan verrassend makkelijk subtiele fouten — en precies daarom kan dezelfde scan er in het ene programma anders uitzien dan in het andere.
- Dode hoeken worden bijgesneden. Elke scanner heeft een plek die hij niet kan zien — meestal recht eronder, waar zijn eigen statief staat. Sommige exportprogramma's snijden het panorama daar simpelweg bij, waardoor een gat of een afwijkende hoogte ontstaat.
- Niet-vierkante pixels. Een zuiver panorama heeft vierkante pixels (
pixelWidth=pixelHeight); in sommige bestanden is dat niet zo, waardoor het beeld uitgerekt lijkt totdat het opnieuw wordt geschaald. - De verkeerde richting wordt als “vooruit” gezien. De rotatie die bij een panorama is opgeslagen, geeft aan welke richting zich in het midden van de afbeelding bevindt. Er is geen universele afspraak over wat “vooruit” überhaupt betekent — sommige exportprogramma's richten die naar het noorden, andere naar het oosten. Een kleine fout hier draait het hele beeld.
- Bewerkingstools kunnen gegevens verliezen. Als een E57 bijvoorbeeld in CloudCompare wordt geopend en opnieuw opgeslagen, kan de opnamepositie van
pinholeRepresentation-afbeeldingen verloren gaan — de foto's blijven behouden, maar hun opnamelocatie is niet meer bekend.
Het gevolg: in de praktijk geven verschillende programma's hetzelfde E57-bestand vaak anders weer. Onze importer probeert veelvoorkomende eigenaardigheden op te vangen door niet-vierkante pixels opnieuw te schalen, de oriëntatie van het panorama te corrigeren en het beeldvlak te standaardiseren op 2:1. Zo ziet een virtuele tour er goed uit, ongeacht met welk programma het bestand is gemaakt.
Wanneer het panorama in de puntenwolk zelf is ingebakken
Dit is een van de elegantste — en minst gewaardeerde — ideeën van het hele formaat. Naast panorama's die als afzonderlijke afbeeldingen worden opgeslagen, kan een panorama ook verborgen zitten in de puntenwolk zelf. Een laserscanner vuurt niet willekeurig — hij doorloopt een net raster van hoeken, rij voor rij, kolom voor kolom, zoals een oude tv die een beeld opbouwt. E57 kan die volgorde bewaren: elk punt krijgt een rowIndex en een columnIndex die aangeven uit welke rastercel het komt. Een scan die zo is opgeslagen, heet gestructureerd.
Het voordeel: als de punten op een raster staan, is de puntenwolk al een afbeelding. Lees hem rij voor rij en elk punt valt op een pixel — het panorama komt terug zonder slimme herprojectie. Het bestand legt de rastergrootte zelfs vast in zijn indexBounds (columnMaximum, rowMaximum), zodat de software de resolutie vooraf kent — onze synthesizer haalt de uitvoerbreedte rechtstreeks uit columnMaximum + 1.
Maar een raster moet een perfecte rechthoek zijn, en de echte wereld is dat niet. Wat gebeurt er met richtingen waarin de bundel de open lucht in schoot en er niets terugkwam? Het pragmatische antwoord is: vul die cellen met fictieve punten — heel vaak met een afstand van precies 0, wat betekent: "bundel verzonden, niets geraakt". Ze houden de rechthoek intact, maar zijn geen echte geometrie, dus een oplettende lezer moet ze terzijde schuiven. Onze importer markeert elk punt met afstand nul, plaatst het op een fictieve, grote afstand zodat de rasterberekeningen blijven werken, en behandelt die schijnpunten in de lucht nooit als echte oppervlakken wanneer hij de dieptekaart maakt of de puntenwolk exporteert.
Een scan weer omzetten in een foto waarin u kunt staan
Niet elke scan wordt aangeleverd in een kant-en-klaar raster — sommige zijn gewoon een losse, ongestructureerde hoop punten. Het goede nieuws: het panorama is nog steeds te herstellen, en hier komt ons eigen werk om de hoek kijken. Een scan is namelijk in feite "een volledige bol van punten, gemeten als hoeken rond één plek". Die kunt u uitrollen tot een vlak panorama.
Breng elk punt op basis van zijn hoek in kaart — van links naar rechts over de breedte en van boven naar beneden over de hoogte van het beeld — en het komt terecht op een pixel in het bekende uitgerekte equirectangulaire 2:1-panorama. De dieptekaart is het magische ingrediënt: met een afstandswaarde achter elke pixel wordt een ogenschijnlijk vlak panorama meetbaar en doorloopbaar. Klik op twee punten op een muur en de software kent de werkelijke afstand, omdat de onderliggende 3D-gegevens nooit verloren zijn gegaan.
Waarom is E57 dan belangrijk?
Omdat het de neutrale ontmoetingsplek is. Een landmeter scant een brug met hardware van het ene merk, een ingenieur opent de scan in software van een ander merk en een architect archiveert hem voor de komende twintig jaar — en E57 is één bestand waarop ze alle drie kunnen vertrouwen, zonder dat een leverancier de sleutels in handen heeft. Het houdt kleur, intensiteit, geometrie, panorama's en de uiterst belangrijke sensorposities op één plek bijeen en is een open standaard die iedereen kan implementeren.
Nog een leuk weetje: de opnametijd in een E57-bestand wordt opgeslagen als GPS-tijd — het aantal seconden sinds 6 januari 1980, toen de GPS-tijd begon — en niet volgens de gebruikelijke computerepoch van 1970. Als dit verkeerd wordt geïnterpreteerd, lijkt een scan van vandaag uit 2013 te komen.
Wilt u meer weten?
- libE57.org — de opensource-referentiebibliotheek en de thuisbasis van het formaat
- ASTM E2807 — de officiële norm
- libE57Format · Image2D — nauwkeurige definities van de sferische weergave, de pinholeweergave en de visuele referentieweergave
- Paul Bourke’s E57 notes — een beknopt technisch overzicht van de header en structuur