E57, explicado: el "PDF de las nubes de puntos"
Imagine que fotografía una habitación, pero, en lugar de capturar una imagen plana, registra la posición exacta de un millón de diminutos puntos que cubren cada pared, silla y taza de café. Haga girar un láser lo bastante rápido y mida a qué distancia está cada cosa: el resultado es una nube de puntos, una "fotografía" 3D formada por puntos medidos. Esta es una guía accesible y sin tecnicismos sobre lo que contiene realmente un archivo E57 y un ingenioso truco que nuestro propio software hace con él.
¿Por qué hace falta un formato especial?
Una foto normal no es más que una cuadrícula de píxeles de colores: algo sencillo. Un escaneo 3D es más complejo. Para cada uno de sus millones de puntos, hay que almacenar dónde está en el espacio (tres números: X, Y, Z), de qué color es, con qué intensidad se reflejó el láser (su intensidad; piense en una "foto láser" en blanco y negro) y, a menudo, las fotos panorámicas que tomó el escáner al mismo tiempo.
Imagine ahora que una persona escanea con un Faro, un compañero utiliza un Leica y el cliente abre el resultado en un programa de Autodesk. Tres máquinas y tres programas que necesitan poder leer el mismo archivo dentro de varios años, sin tener que pedir a un proveedor un descodificador secreto. Ese es el problema que resuelve E57. Es un estándar abierto e independiente del proveedor (publicado como ASTM E2807 y basado en la biblioteca de código abierto libE57). Se lo conoce como el "PDF de las nubes de puntos": un único archivo portátil que todos saben cómo leer.
La gran idea: un mapa de texto con músculo binario
En esencia, un archivo E57 es un híbrido que combina dos elementos muy distintos: una pequeña sección de XML, texto sencillo y legible que funciona como índice, y grandes bloques de datos binarios que contienen millones de números sin procesar, almacenados de forma compacta para agilizar su lectura.
¿Por qué poner el mapa al final? Porque mientras un escáner está escribiendo el archivo todavía no sabe cuánto ocupará todo, así que primero vuelca los datos en bruto y, cuando termina, escribe un resumen ordenado. La ventaja es enorme: para extraer un escaneo de un archivo de 20 gigabytes, el software lee el pequeño encabezado, salta al mapa XML, encuentra la línea que dice "el escaneo #3 está en el byte 4.812.000.000" y va directo allí.
Una discreta medida de seguridad: el archivo completo se divide en "páginas" de 1024 bytes, y cada página reserva sus últimos 4 bytes para una suma de comprobación, una huella que permite al software detectar si el archivo está dañado.
Todo cuelga de una sola raíz
Abra ese mapa XML y encontrará un árbol — exactamente como las carpetas de su equipo. Hay un único root, y dos ramas hacen la mayor parte del trabajo: data3D, una lista numerada de escaneos, e images2D, una lista numerada de fotos (normalmente los panoramas de 360° que tomó el escáner).
Dos formas de escribir un punto
Un escáner láser no trabaja realmente con X, Y, Z. Permanece en un punto y gira; para cada punto, conoce tres valores: la distancia recorrida por el haz, el azimut (el giro horizontal, de izquierda a derecha) y la elevación (el ángulo hacia arriba o hacia abajo). Estas son coordenadas esféricas, el lenguaje natural del escáner. Sin embargo, la mayoría del software prefiere las sencillas coordenadas cartesianas X, Y, Z. E57 puede almacenar ambos tipos, y convertir uno en otro solo requiere un rápido cálculo trigonométrico.
Tres tipos de foto incrustada
Las fotos de images2D no son enlaces a archivos de alguna carpeta: el archivo JPEG o PNG está guardado dentro del propio E57. Y hay más de un tipo de foto incrustada. E57 envuelve cada una en una "representación" que indica al software hasta qué punto puede confiar en la geometría de la imagen. La diferencia se reduce a una sola pregunta: ¿con qué nivel de detalle se describe la cámara?
sphericalRepresentation— un panorama completo de 360° × 180°, la conocida imagen equirectangular estirada con relación 2:1. Como la proyección es conocida, cada píxel corresponde a una dirección exacta y se alinea perfectamente con la nube de puntos. Esta es la vía principal de nuestro flujo de procesamiento: leemos la imagen, ajustamos el lienzo a una relación 2:1 exacta y la enviamos al visor de panoramas.pinholeRepresentation— una foto convencional tomada con un objetivo y descrita mediante el clásico modelo de cámara estenopeica (distancia focal, tamaño del sensor y centro óptico). Esto también basta para que el software conozca la dirección de cada píxel, aunque solo dentro de un campo de visión más estrecho. En la práctica, así es principalmente como funciona Leica: guarda directamente en el E57 un mapa cúbico ya preparado — las seis caras planas de un cubo orientadas hacia fuera — y nuestro proceso de caras cúbicas une esas seis caras para formar un panorama completo. Es uno de los casos más fáciles de convertir de nuevo en una imagen de 360° limpia.visualReferenceRepresentation— una foto sin ningún modelo de cámara, explícitamente "solo para el ojo humano". No se puede medir con ella ni proyectarla sobre la nube de puntos; es solo una imagen de referencia. Nuestro importador conserva estas imágenes como comentarios adjuntos en lugar de colocarlas en 3D.
Pero hay una dificultad. sphericalRepresentation es la opción más popular, pero es sorprendentemente fácil cometer pequeños errores, y por eso el mismo escaneo puede verse distinto de un programa a otro.
- Las zonas ciegas se recortan. Todos los escáneres tienen una zona que no pueden ver — normalmente justo debajo, donde se encuentra su propio trípode. Algunas herramientas de exportación simplemente recortan el panorama en esa zona, lo que deja un hueco o una altura no estándar.
- Píxeles no cuadrados. Un panorama correcto tiene píxeles cuadrados (
pixelWidth=pixelHeight); en algunos archivos no es así, por lo que la imagen aparece estirada hasta que se reescala. - El problema está en qué se considera “hacia delante”. La rotación almacenada con un panorama indica qué dirección queda en el centro de la imagen, y ni siquiera existe un acuerdo universal sobre qué significa “hacia delante” — algunos exportadores la orientan al norte, otros al este. Un pequeño error aquí gira toda la vista.
- Las herramientas de edición pueden perder datos. Abrir y volver a guardar un E57 con CloudCompare, por ejemplo, puede eliminar la posición de captura de las imágenes
pinholeRepresentation— las fotos se conservan, pero ya no saben dónde se tomaron.
En resumen: en la práctica, distintos programas suelen mostrar el mismo E57 de manera diferente. Nuestro importador intenta corregir las peculiaridades más habituales — cambia la escala de los píxeles no cuadrados, corrige la orientación del panorama y estandariza el lienzo 2:1 — para que el tour se vea correctamente, independientemente de la herramienta que haya generado el archivo.
Cuando el panorama está integrado en la propia nube de puntos
Esta es una de las ideas más elegantes — y menos apreciadas — de todo el formato. Además de los panoramas almacenados como imágenes separadas, un panorama también puede esconderse dentro de la propia nube de puntos. Un escáner láser no dispara al azar: recorre una cuadrícula ordenada de ángulos, fila por fila, columna por columna, como un televisor antiguo pintando una pantalla. E57 puede conservar ese orden: cada punto recibe un rowIndex y un columnIndex que indican de qué celda de la cuadrícula procede. Un escaneo almacenado así se llama estructurado.
La ventaja: si los puntos están sobre una cuadrícula, la nube ya es una imagen. Léala fila por fila y cada punto caerá en un píxel: el panorama se recupera sin necesidad de reproyección alguna. El archivo incluso registra el tamaño de la cuadrícula en sus indexBounds (columnMaximum, rowMaximum), de modo que el software conoce la resolución de antemano: nuestro sintetizador toma el ancho de salida directamente de columnMaximum + 1.
Pero una cuadrícula tiene que ser un rectángulo perfecto, y el mundo real no lo es. ¿Qué ocurre con las direcciones en las que el haz se proyectó hacia el cielo abierto y no hubo retorno? La solución es pragmática: rellenar esas celdas con puntos ficticios — muy a menudo con un alcance de exactamente 0, es decir, "haz emitido, sin retorno". Mantienen intacto el rectángulo, pero no son geometría real, por lo que un lector atento debe descartarlos. El nuestro marca cada punto de alcance cero, lo sitúa a una distancia ficticia muy lejana para que los cálculos de la cuadrícula sigan funcionando y nunca trata esos puntos fantasma del cielo como superficies reales al crear el mapa de profundidad o exportar la nube.
Convertir un escaneo de nuevo en una foto en la que pueda entrar
No todos los escaneos vienen organizados en una cuadrícula: algunos son solo un conjunto de puntos dispersos y sin estructurar. La buena noticia es que el panorama aún puede recuperarse, y aquí es donde entra en juego nuestro trabajo. Como un escaneo es en realidad "una esfera completa de puntos medidos como ángulos alrededor de un único punto", puede desplegarse para formar un panorama plano.
Cada punto se proyecta según su ángulo — de izquierda a derecha a lo ancho de la imagen y de arriba abajo a lo alto de esta — y cae sobre un píxel del conocido panorama equirectangular 2:1 estirado. El mapa de profundidad es el ingrediente mágico: con una distancia asociada a cada píxel, un panorama que parece plano se puede medir y recorrer — haga clic en dos puntos de una pared y el software conocerá la distancia real, porque nunca ha perdido los datos 3D subyacentes.
Entonces, ¿por qué importa E57?
Porque es el punto de encuentro neutral. Un topógrafo escanea un puente con una marca de hardware, un ingeniero lo abre en otro software y un arquitecto lo archiva para los próximos veinte años: E57 es el único archivo en el que los tres pueden confiar, sin que ningún proveedor tenga las llaves. Mantiene juntos el color, la intensidad, la geometría, los panoramas y las importantísimas posiciones del sensor en un solo lugar, como un estándar abierto que cualquiera puede implementar.
Un último dato curioso: el momento de captura almacenado en un E57 se expresa en tiempo GPS — segundos transcurridos desde el 6 de enero de 1980, cuando comenzó el tiempo GPS — y no desde la época informática habitual de 1970. Si se interpreta mal, un escaneo realizado hoy parecerá haberse hecho en 2013.
¿Quiere profundizar más?
- libE57.org — la biblioteca de código abierto de referencia y la página principal del formato
- ASTM E2807 — el estándar oficial
- libE57Format · Image2D — definiciones exactas de las representaciones esférica, estenopeica y de referencia visual
- Paul Bourke’s E57 notes — un desglose técnico conciso del encabezado y la estructura