E57 uitgelegd: de ‘PDF van puntenwolken'
Stel je voor dat je een kamer fotografeert — maar in plaats van een vlakke foto leg je de exacte positie vast van een miljoen kleine puntjes die elke muur, stoel en koffiemok bedekken. Laat een laser snel genoeg ronddraaien en meet hoe ver alles weg is, en dat is wat je krijgt: een puntenwolk, een 3D-"foto" van gemeten punten. Dit is een vriendelijke, jargonvrije rondleiding door wat er echt in een E57-bestand zit — en een slimme truc die onze eigen software ermee doet.
Waarom überhaupt een speciaal formaat?
Een gewone foto is gewoon een raster van gekleurde pixels — simpel. Een 3D-scan is ingewikkelder. Voor elk van de miljoenen punten wil je opslaan waar het zich in de ruimte bevindt (drie getallen: X, Y, Z), welke kleur het heeft, hoe sterk de laser terugkaatste (de intensiteit — denk aan een zwart-witte "laserfoto") en vaak ook de panoramafoto's die de scanner tegelijk maakte.
Stel je nu voor dat de ene persoon scant met een Faro, een collega een Leica gebruikt en de klant het resultaat opent in Autodesk-software. Drie machines, drie programma's — en ze moeten allemaal jaren later nog hetzelfde bestand kunnen lezen, zonder een leverancier om een geheime decoder te hoeven smeken. Dat is het probleem dat E57 oplost. Het is een open, leveranciersneutrale standaard (uitgegeven als ASTM E2807 en gebouwd op de open-sourcebibliotheek libE57). Men noemt het de "PDF van puntenwolken": één draagbaar bestand dat iedereen kan lezen.
Het grote idee: een tekstkaart met binaire spierkracht
In de kern is een E57-bestand een hybride van twee heel verschillende dingen die aan elkaar zijn geplakt: een klein stukje XML — gewone, voor mensen leesbare tekst die als inhoudsopgave dient — en grote blokken binaire gegevens met de ruwe miljoenen getallen, compact opgeslagen voor snelheid.
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.
Stille veiligheidsnet: het hele bestand is opgedeeld in "pagina's" van 1024 bytes, en elke pagina reserveert de laatste 4 bytes voor een checksum — een vingerafdruk waarmee software merkt of het bestand beschadigd is.
Alles hangt aan één wortel
Open die XML-kaart en je vindt een boom — precies zoals mappen op je 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 schrijven
Een laserscanner denkt niet echt in X, Y, Z. Hij staat op één plek en draait rond, en voor elk punt weet hij drie dingen: afstand (hoe ver de bundel heeft afgelegd), azimut (hoe ver rond, links-rechts) en elevatie (hoe ver omhoog of omlaag). Dat zijn sferische coördinaten — de moedertaal van de scanner. De meeste software geeft echter de voorkeur aan gewone cartesische X, Y, Z. E57 slaat beide probleemloos op, en de omzetting is een beetje snelle trigonometrie.
Drie soorten ingesloten foto
De foto's in images2D zijn geen links naar bestanden in een map — de echte JPEG of PNG zit recht in de E57. En er is meer dan één soort ingesloten foto. E57 verpakt elk ervan in een "representatie" die software vertelt hoeveel geometrisch vertrouwen het in de afbeelding kan hebben. Het verschil komt neer op één vraag: hoe volledig is de camera beschreven?
sphericalRepresentation— een volledig 360° × 180°-panorama, de bekende uitgerekte 2:1 equirectangulaire afbeelding. Omdat de projectie bekend is, komt elke pixel overeen met een exacte richting, zodat het perfect uitlijnt met de puntenwolk. Dit is de hoofdroute in onze pipeline: we lezen het, maken het canvas netjes 2:1 en geven het door aan de panorama-viewer.pinholeRepresentation— één gewone lensfoto, beschreven door het klassieke pinhole-cameramodel (brandpuntsafstand, sensorformaat, optisch centrum). Dat is genoeg voor software om ook de richting van elke pixel te kennen, alleen met een smaller gezichtsveld. In de praktijk werkt Leica meestal zo: het schrijft een kant-en-klare cubemap — de zes vlakke kubusvlakken naar buiten gericht — rechtstreeks in de E57, en onze kubusvlak-route zet die precies om in een volledig panorama. Dat is een van de eenvoudigste gevallen om weer om te zetten in een zuivere 360°-afbeelding.visualReferenceRepresentation— een foto zonder cameramodel, expliciet "alleen voor het menselijk oog". Je kunt er niet mee meten of ze 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 de adder onder het gras. sphericalRepresentation is de populaire keuze, maar het is verrassend makkelijk om het subtiel fout te doen — en precies daarom kan dezelfde scan er in het ene programma anders uitzien dan in het andere.
- Blinde zones worden bijgesneden. Elke scanner heeft een plek die hij niet kan zien — klassiek recht naar beneden, waar zijn eigen statief staat. Sommige exporteurs snijden het panorama daar gewoon af, waardoor een gat of een afwijkende hoogte overblijft.
- Rechthoekige pixels. Een zuiver panorama heeft vierkante pixels (
pixelWidth=pixelHeight); sommige bestanden hebben dat niet, waardoor de afbeelding uitgerekt lijkt totdat die opnieuw wordt geschaald. - De verkeerde richting is “forward”. De rotatie die bij een panorama is opgeslagen, geeft aan welke richting in het midden van de afbeelding staat, en er is geen universele afspraak over wat “forward” überhaupt betekent — sommige exporteurs richten het op het noorden, andere op het oosten. Een kleine fout hier draait het hele beeld.
- Bewerkingstools kunnen gegevens verliezen. Een E57 heen en terug opslaan via CloudCompare kan bijvoorbeeld de opnamepositie van
pinholeRepresentation-afbeeldingen verwijderen — de foto's blijven bestaan, maar weten niet langer waar ze zijn genomen.
Kortom: in de praktijk laat verschillende software vaak dezelfde E57 anders zien. Onze importeur probeert de bekende eigenaardigheden glad te strijken — rechthoekige pixels vierkant maken, de panoramaoriëntatie corrigeren en het 2:1-canvas standaardiseren — zodat een tour er goed uitziet, ongeacht welk hulpmiddel het bestand heeft geschreven.
Wanneer het panorama in de puntenwolk zelf is ingebakken
Hier 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 netjes raster van hoeken, rij voor rij, kolom voor kolom, als een oude tv die een scherm tekent. 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 wolk al een afbeelding. Lees hem rij voor rij en elk punt valt op een pixel — het panorama komt terug zonder slimme reprojactie. 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 doe je 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. De onze markeert elk punt met nulafstand, zet het op een fictieve verre 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 waar je in kunt staan
Niet elke scan komt aan op 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 het formaat samen met ons eigen werk. Want een scan is eigenlijk "een volledige bol van punten gemeten als hoeken rond één plek", dus je kunt die uitrollen tot een vlak panorama.
Noteer de hoek van elk punt, laat links-rechts over de beeldbreedte lopen en boven-onder over de beeldhoogte, en elk punt belandt op een pixel — het vertrouwde uitgerekte 2:1-equirectangulaire panorama. De dieptekaart is het magische ingrediënt: met achter elk pixel een afstand wordt een vlak ogend panorama meetbaar en begaanbaar — klik twee punten op een muur aan en de software kent de echte afstand, omdat die de onderliggende 3D-data nooit is vergeten.
Waarom is E57 dan belangrijk?
Omdat het de neutrale ontmoetingsplek is. Een landmeter scant een brug met een bepaald hardwaremerk, een ingenieur opent die in andere software en een architect archiveert hem voor de komende twintig jaar — en E57 is het ene 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 samen op één plek, als een open standaard die iedereen kan implementeren.
Nog een leuk weetje: de opnametijd in een E57 wordt geteld in GPS-tijd — seconden sinds 6 januari 1980, het moment waarop de klokken van de GPS-satellieten werden ingeschakeld — en niet vanaf het gebruikelijke computer-epoch van 1970. Doe je dat fout, dan leest een scan van vandaag alsof die in 2013 is gemaakt.
Wil je dieper gaan?
- libE57.org — de referentie-open-sourcebibliotheek en de thuisbasis van het formaat.
- ASTM E2807 — de officiële standaard.
- libE57Format · Image2D — exacte definities van de sferische, pinhole- en visuele-referentieweergaven.
- Paul Bourke’s E57 notes — een beknopte technische uiteenzetting van de header en structuur.