Base de conhecimento · formatos de ficheiro

E57, explicado: o "PDF das nuvens de pontos"

Imagine fotografar uma sala — mas, em vez de captar uma imagem plana, regista a posição exata de um milhão de pequenos pontos que cobrem todas as paredes, cadeiras e canecas. Faça um laser girar com rapidez suficiente e meça a distância a tudo o que o rodeia: o resultado é uma nuvem de pontos, uma "fotografia" 3D formada por pontos medidos. Este é um guia acessível e sem jargão sobre o que realmente existe dentro de um ficheiro E57 — e um truque interessante que o nosso próprio software realiza com ele.

Porquê um formato especial, afinal?

Uma foto comum é apenas uma grelha de pixels coloridos — simples. Uma digitalização 3D é mais complexa. Para cada um dos seus milhões de pontos, é preciso armazenar onde se encontra no espaço (três números: X, Y, Z), qual é a sua cor, com que intensidade o laser foi refletido (a sua intensidade — pense numa "foto a laser" a preto e branco) e, muitas vezes, as fotos panorâmicas captadas pelo scanner ao mesmo tempo.

Agora imagine que uma pessoa digitaliza com um Faro, um colega usa um Leica e o cliente abre o resultado num software da Autodesk. São três equipamentos e três programas — e todos precisam de ler o mesmo ficheiro daqui a vários anos, sem depender de um fabricante para obter um descodificador secreto. Esse é o problema que o E57 resolve. É um padrão aberto e independente do fabricante (publicado como ASTM E2807 e baseado na biblioteca de código aberto libE57). É conhecido como o "PDF das nuvens de pontos": um ficheiro portátil que todos sabem ler.

A grande ideia: um mapa de texto com força binária

Em essência, um ficheiro E57 é um híbrido de dois elementos muito diferentes: uma pequena secção em XML — texto simples e legível que funciona como um índice — e grandes blocos de dados binários que contêm milhões de números brutos, armazenados de forma compacta para agilizar o acesso.

Um ficheiro E57 é lido de trás para a frente: um cabeçalho de 48 bytes aponta para o "mapa" XML no final, que, por sua vez, indica onde se encontra cada bloco binário.

Por que razão colocar o mapa no final? Porque, enquanto um scanner está a escrever o ficheiro, ainda não sabe quanto espaço será necessário para todo o conteúdo. Por isso, grava primeiro os dados brutos e escreve um resumo organizado quando termina. A vantagem é enorme: para obter uma digitalização de um ficheiro de 20 gigabytes, o software lê o pequeno cabeçalho, salta para o mapa XML, encontra a linha que diz "a digitalização n.º 3 está no byte 4 812 000 000" e vai diretamente até lá.

Uma proteção discreta: o ficheiro inteiro é dividido em "páginas" de 1024 bytes, e cada página reserva os últimos 4 bytes para uma soma de verificação — uma impressão digital que permite ao software detetar se o ficheiro está corrompido.

Tudo parte de uma única raiz

Abra esse mapa XML e encontrará uma árvore — exatamente como as pastas de um computador. Existe um único root, e dois ramos fazem a maior parte do trabalho: data3D, uma lista numerada de digitalizações, e images2D, uma lista numerada de fotos (normalmente, os panoramas 360° captados pelo scanner).

Cada digitalização e cada foto têm a sua própria pose — a posição do dispositivo e a direção para a qual está orientado (armazenada como um quatérnio) — , o que permite encaixar várias digitalizações num único modelo alinhado.

Duas formas de escrever um ponto

Um scanner a laser não pensa propriamente em X, Y, Z. Fica num ponto e gira e, para cada ponto, conhece três valores: alcance (a distância percorrida pelo feixe), azimute (o ângulo horizontal, para a esquerda ou para a direita) e elevação (o ângulo para cima ou para baixo). São coordenadas esféricas — a língua materna do scanner. A maioria dos programas, porém, prefere as simples coordenadas cartesianas X, Y, Z. O E57 permite guardar qualquer um dos dois sistemas, e a conversão de um para o outro exige apenas alguns cálculos rápidos de trigonometria.

Os pontos ficam numa tabela compacta que o E57 chama de CompressedVector: o XML define as colunas uma única vez (X, Y, Z, cor, intensidade...), e o bloco binário armazena sucessivas linhas de valores compactados.

Três tipos de foto incorporada

As fotos em images2D não são links para ficheiros numa pasta — o próprio JPEG ou PNG está guardado dentro do E57. E há mais de um tipo de foto incorporada. O E57 associa cada uma a uma "representação" que indica ao software até que ponto pode confiar na geometria da imagem. A diferença resume-se a uma única pergunta: com que nível de detalhe está descrita a câmara?

Um detalhe elegante: uma única entrada de imagem pode conter tanto um raster preciso (estenopeico ou esférico) como uma versão simples de referência visual — assim, o visualizador mostra a imagem mais fácil de interpretar, mantendo a versão mensurável para os cálculos.

sphericalRepresentation — um panorama completo de 360° × 180°, a conhecida imagem equirectangular alongada na proporção 2:1. Como a projeção é conhecida, cada pixel corresponde a uma direção exata, permitindo um alinhamento perfeito com a nuvem de pontos. Este é o principal percurso do nosso fluxo de processamento: lemos a imagem, ajustamos as respetivas dimensões para uma proporção exata de 2:1 e enviamo-la para o visualizador de panoramas.
pinholeRepresentation — uma fotografia tirada com uma lente comum, descrita pelo clássico modelo de câmara pinhole (distância focal, tamanho do sensor e centro óptico). Isto também basta para que o software determine a direção de cada pixel, mas apenas num campo de visão mais estreito. Na prática, é principalmente assim que a Leica trabalha: grava diretamente no E57 um cubemap pronto — as seis faces planas de um cubo voltadas para fora — , e o nosso fluxo de processamento de faces do cubo combina precisamente essas imagens num panorama completo. É um dos casos mais fáceis de reconverter numa imagem 360° sem distorções.
visualReferenceRepresentation — uma fotografia sem qualquer modelo de câmara, explicitamente "apenas para observação humana". Não é possível utilizá-la para fazer medições nem projetá-la na nuvem de pontos; é apenas uma imagem de referência. O nosso importador mantém estas imagens como comentários anexos, em vez de as colocar em 3D.

Eis o problema. sphericalRepresentation é a opção mais popular, mas é surpreendentemente fácil cometer pequenos erros — e é precisamente por isso que a mesma digitalização pode ter um aspeto diferente de um programa para outro.

As zonas cegas são recortadas. Todos os scanners têm uma área que não conseguem captar — normalmente, diretamente para baixo, onde se encontra o respetivo tripé. Alguns exportadores limitam-se a recortar o panorama nessa zona, deixando uma lacuna ou uma altura não convencional.
Pixels não quadrados. Um panorama sem distorções tem pixels quadrados (pixelWidth = pixelHeight); em alguns ficheiros, os pixels não são quadrados, pelo que a imagem parece esticada até ser redimensionada.
O lado errado fica “à frente”. A rotação guardada com um panorama indica a direção que fica no centro da imagem, mas nem sequer existe consenso sobre o significado de “para a frente” — alguns exportadores apontam essa direção para norte, outros para leste. Um pequeno erro aqui roda toda a vista.
As ferramentas de edição podem perder dados. Importar e voltar a exportar um E57 através do CloudCompare, por exemplo, pode eliminar a posição de captura das imagens pinholeRepresentation — as fotografias continuam presentes, mas deixa de ser possível saber onde foram tiradas.

Em resumo, na prática, programas diferentes apresentam frequentemente o mesmo E57 de formas diferentes. O nosso importador tenta corrigir as peculiaridades mais comuns — redimensionando pixels não quadrados, corrigindo a orientação do panorama e normalizando as dimensões da imagem para a proporção 2:1 — para que o tour virtual tenha o aspeto correto, independentemente da ferramenta que tenha criado o ficheiro.

Quando o panorama é incorporado na própria nuvem de pontos

Esta é uma das ideias mais elegantes — e menos valorizadas — de todo o formato. Além dos panoramas guardados como imagens separadas, um panorama também pode ficar escondido dentro da própria nuvem de pontos. Um scanner a laser não dispara aleatoriamente — percorre uma grelha ordenada de ângulos, linha por linha, coluna por coluna, como um televisor antigo a desenhar um ecrã. O E57 pode preservar essa ordem: cada ponto recebe um rowIndex e um columnIndex que indicam a célula da grelha de onde provém. Uma digitalização guardada desta forma é denominada estruturada.

Numa digitalização estruturada, a nuvem de pontos e o panorama são o mesmo objeto — a imagem não é uma foto separada, mas a própria disposição dos pontos.

A vantagem: se os pontos estiverem numa grelha, a nuvem já é uma imagem. Leia-a linha a linha e cada ponto corresponde a um pixel — o panorama é recuperado sem qualquer reprojeção sofisticada. O ficheiro regista até o tamanho da grelha nos seus indexBounds (columnMaximum, rowMaximum), pelo que o software conhece antecipadamente a resolução — o nosso sintetizador obtém a largura de saída diretamente de columnMaximum + 1.

Mas uma grelha tem de ser um retângulo perfeito, e o mundo real não é. E quanto às direções em que o feixe foi disparado para o céu aberto e nada voltou? A solução pragmática é preencher essas células com pontos fictícios — muitas vezes com uma distância de exatamente 0, ou seja, "feixe enviado, nada atingido". Estes mantêm o retângulo intacto, mas não são geometria real, pelo que um leitor atento deve ignorá-los. O nosso leitor assinala todos os pontos com distância zero, coloca-os a uma distância fictícia muito elevada para que os cálculos da grelha continuem a funcionar e nunca trata esses pontos fantasma do céu como superfícies reais ao construir o mapa de profundidade ou exportar a nuvem.

Transformar novamente uma digitalização numa foto em que se pode entrar

Nem todas as digitalizações chegam numa grelha já formada — algumas são apenas um conjunto disperso e não estruturado de pontos. A boa notícia é que o panorama continua a ser recuperável, e é aqui que o formato se cruza com o nosso próprio trabalho. Uma digitalização é, na verdade, "uma esfera completa de pontos medidos como ângulos em torno de um único local", pelo que é possível desdobrá-la num panorama plano.

Uma nuvem de pontos, três imagens: a cor preenche os pixels, a intensidade do laser produz uma imagem nítida em tons de cinzento e sem sombras, e a distância transforma-se num mapa de profundidade — é isso que torna um panorama plano mensurável e navegável.

Mapeie cada ponto de acordo com o ângulo — da esquerda para a direita ao longo da largura da imagem e de cima para baixo ao longo da altura — e este corresponderá a um pixel no conhecido panorama equirectangular alongado de proporção 2:1. O mapa de profundidade é o ingrediente mágico: com uma distância associada a cada pixel, um panorama aparentemente plano torna-se mensurável e navegável — clique em dois pontos de uma parede e o software saberá a distância real, pois nunca perdeu os dados 3D subjacentes.

Então, porque é que o E57 é importante?

Porque é o ponto de encontro neutro. Um topógrafo digitaliza uma ponte com equipamento de uma marca, um engenheiro abre a digitalização noutro software e um arquiteto arquiva-a para os próximos vinte anos — e o E57 é o único ficheiro em que os três podem confiar, sem que nenhum fornecedor detenha as chaves. Mantém reunidas num só lugar a cor, a intensidade, a geometria, os panoramas e as importantíssimas posições dos sensores, sob a forma de uma norma aberta que qualquer pessoa pode implementar.

Uma última curiosidade: o instante da captura registado num E57 é contado em tempo GPS — segundos desde 6 de janeiro de 1980, quando começou a contagem do tempo GPS — e não segundo a época informática habitual, de 1970. Se este cálculo estiver errado, uma digitalização feita hoje parecerá ter sido realizada em 2013.

Quer aprofundar o tema?

libE57.org — a biblioteca de código aberto de referência e o principal site do formato
ASTM E2807 — a norma oficial
libE57Format · Image2D — definições exatas das representações esférica, de câmara estenopeica e de referência visual
Paul Bourke’s E57 notes — uma análise técnica concisa do cabeçalho e da estrutura