E57 o "PDF das nuvens de pontos" um arquivo aberto que contém milhões de pontos 3D medidos, suas cores e as fotos panorâmicas que os acompanham.
Base de conhecimento · formatos de arquivo

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

Imagine fotografar uma sala — mas, em vez de uma imagem plana, você capturou a posição exata de um milhão de pontinhos cobrindo cada parede, cadeira e xícara de café. Gire um laser rápido o suficiente e meça a distância de tudo, e é isso que você obtém: uma nuvem de pontos, uma "fotografia" 3D feita de pontos medidos. Este é um tour amigável e sem jargão sobre o que realmente existe dentro de um arquivo E57 — e um truque interessante que o nosso próprio software faz com ele.

Por que um formato especial, afinal?

Uma foto normal é apenas uma grade de pixels coloridos — simples. Uma varredura 3D é mais complexa. Para cada um dos seus milhões de pontos, você quer armazenar onde ele está no espaço (três números: X, Y, Z), qual cor ele tem, com que intensidade o laser retornou (sua intensidade — pense em uma "foto a laser" em preto e branco) e, muitas vezes, as fotos panorâmicas que o scanner tirou ao mesmo tempo.

Agora imagine uma pessoa escaneando com um Faro, um colega usando um Leica e o cliente abrindo o resultado em software Autodesk. Três máquinas, três programas — e todos precisam ler o mesmo arquivo, anos depois, sem implorar a um fornecedor por um decodificador secreto. Esse é o problema que E57 resolve. É um padrão aberto e neutro em relação ao fornecedor (publicado como ASTM E2807 e baseado na biblioteca de código aberto libE57). As pessoas o chamam de "PDF das nuvens de pontos": um arquivo portátil que todos concordam em ler.

A grande ideia: um mapa de texto com músculo binário

No fundo, um arquivo E57 é um híbrido de duas coisas muito diferentes unidas: um pequeno trecho de XML — texto simples, legível por humanos, que funciona como índice — e grandes blocos de dados binários que guardam os milhões de números brutos, armazenados de forma compacta para ganhar velocidade.

Anatomia de um arquivo E57 um arquivo = um pequeno cabeçalho + grandes blocos binários + um "índice" de texto no final Cabeçalho 48 bytes Dados de pontos (binários) milhões de X, Y, Z + cor Imagens (binárias) panoramas JPEG / PNG incorporados Seção XML "mapa" legível de tudo início do arquivo fim do arquivo o cabeçalho registra exatamente onde o mapa XML começa (xmlPhysicalOffset) O software abre primeiro o cabeçalho de 48 bytes — ele diz "o mapa está no byte N". Ele vai para o mapa XML, lê o que há dentro e depois salta direto para o bloco binário de que precisa. Não é preciso ler gigabytes para encontrar uma varredura — o mapa torna o acesso instantâneo.
Um arquivo E57 é lido de trás para frente: um cabeçalho de 48 bytes aponta para o "mapa" XML no final, que por sua vez diz onde fica cada bloco binário.

Por que colocar o mapa no final? Porque, enquanto um scanner está gravando o arquivo, ele ainda não sabe o tamanho de tudo, então transmite primeiro os dados brutos e escreve um resumo organizado quando termina. A vantagem é enorme: para pegar uma varredura de um arquivo de 20 gigabytes, o software lê o pequeno cabeçalho, pula para o mapa XML, encontra a linha que diz "a varredura #3 está no byte 4.812.000.000" e vai direto até lá.

Rede de segurança discreta: todo o arquivo é dividido em "páginas" de 1024 bytes, e cada página reserva seus últimos 4 bytes para um checksum — uma impressão digital que permite ao software perceber se o arquivo foi corrompido.

Tudo depende de uma única raiz

Abra esse mapa XML e você encontrará uma árvore — exatamente como as pastas no seu computador. Há um único root, e dois ramos fazem a maior parte do trabalho: data3D, uma lista numerada de varreduras, e images2D, uma lista numerada de fotos (normalmente os panoramas de 360° que o scanner capturou).

A árvore E57: tudo depende de uma única raiz a seção XML é uma árvore de pastas — abra a raiz e desça até qualquer varredura ou foto root data3D uma lista de varreduras [ scan 0, scan 1, ... ] metadados quem / quando sistema de coordenadas images2D uma lista de fotos [ pano 0, pano 1, ... ] scan 0 pontos + pose scan 1 … points prototype X Y Z · R G B · intensity pose = onde o scanner estava posição (x,y,z) + rotação (quaternion) cada foto também traz sua própria pose, para que o visualizador saiba onde colocá-la
Cada varredura e foto carrega sua própria pose — a posição do scanner mais sua direção de orientação (armazenada como um quaternion) — e é isso que permite que várias varreduras se encaixem em um único modelo alinhado.

Duas formas de escrever um ponto

Um scanner a laser não pensa realmente em X, Y, Z. Ele fica parado em um ponto e gira, e para cada ponto ele sabe três coisas: alcance (o quanto o feixe percorreu), azimute (o quanto gira ao redor, da esquerda para a direita) e elevação (o quanto sobe ou desce). Essas são coordenadas esféricas — a língua materna do scanner. A maioria dos softwares, porém, prefere X, Y, Z cartesianos. O E57 armazena ambos sem problema, e converter um no outro é só um pouco de trigonometria rápida.

Duas formas de escrever um ponto um scanner pensa em ângulos & distância — E57 pode armazenar pontos de qualquer uma das formas Esférico — como o sensor vê scanner o ponto alcance (distância) azimute (esquerda-direita) + elevação (cima-baixo) alcance · azimute · elevação natural para um scanner a laser giratório cartesiano — como o software quer Z X Y o ponto X · Y · Z coordenadas de grelha simples que todos entendem rápido trigonometria
Os pontos ficam em uma tabela compacta que o E57 chama de CompressedVector: o XML define as colunas uma vez (X, Y, Z, cor, intensidade...), e então o bloco binário guarda linha após linha de valores compactados.

Três tipos de foto incorporada

As fotos em images2D não são links para arquivos em alguma pasta — o JPEG ou PNG real está guardado diretamente dentro do E57. E há mais de um tipo de foto incorporada. O E57 envolve cada uma em uma "representação" que diz ao software o quanto ele pode confiar na imagem do ponto de vista geométrico. A diferença se resume a uma única pergunta: quão completamente a câmera está descrita?

Três formas de o E57 conter uma foto mesmo ficheiro, três "representações" — diferem em quanto a câmara é descrita sphericalRepresentation um panorama completo de 360° × 180° envolvido numa esfera Mensurável ✓ cada pixel = uma direção conhecida direção a partir do scanner o "olhar à volta a partir daqui" panorama que a maioria dos scanners produz pinholeRepresentation objetiva foto plana Mensurável ✓ uma foto normal com objetiva, totalmente calibrada a distância focal + o tamanho do sensor permitem ao software conhecer o ângulo de cada pixel visualReferenceRepresentation apenas uma imagem Não serve para medir ✗ sem qualquer modelo de câmara - puramente para o olho humano "foi assim que o local parecia " — uma miniatura, uma foto do local
Um detalhe elegante: uma única entrada de imagem pode conter tanto um raster preciso (pinhole ou esférico) quanto uma versão simples de referência visual — assim o visualizador mostra a imagem amigável enquanto mantém a mensurável para os cálculos.
  • sphericalRepresentation — um panorama completo de 360° × 180°, a familiar imagem esticada equiretangular 2:1. Como a projeção é conhecida, cada pixel corresponde a uma direção exata, então ele se alinha perfeitamente com a nuvem. Este é o caminho principal no nosso pipeline: nós o lemos, ajustamos a tela para um 2:1 limpo e o entregamos ao visualizador de panorama.
  • pinholeRepresentation — uma foto com lente comum, descrita pelo clássico modelo de câmera pinhole (distância focal, tamanho do sensor, centro óptico). Isso basta para o software saber também a direção de cada pixel, só que com um campo de visão mais estreito. Na prática, é sobretudo assim que a Leica funciona: ela grava um cubemap pronto — as seis faces planas do cubo voltadas para fora — diretamente no E57, e o nosso caminho das faces do cubo as junta exatamente num panorama completo. É um dos casos mais fáceis de transformar de volta numa imagem 360° limpa.
  • visualReferenceRepresentation — uma foto sem nenhum modelo de câmera, explicitamente "apenas para o olho humano". Não dá para medir com ela nem projetá-la na nuvem; é só uma imagem de referência. Nosso importador as mantém como comentários anexados em vez de colocá-las em 3D.

Aqui está o problema. sphericalRepresentation é a opção mais popular, mas é surpreendentemente fácil errar de forma sutil — e é exatamente por isso que o mesmo scan pode parecer diferente de um programa para outro.

  • As zonas cegas são recortadas. Todo scanner tem um ponto que não consegue ver — normalmente diretamente para baixo, onde fica o próprio tripé. Alguns exportadores simplesmente recortam o panorama ali, deixando uma lacuna ou uma altura fora do padrão.
  • Pixels retangulares. Um panorama limpo tem pixels quadrados (pixelWidth = pixelHeight); alguns arquivos não têm isso, então a imagem parece esticada até ser redimensionada.
  • A direção errada é “forward”. A rotação armazenada com um panorama indica qual direção fica no centro da imagem, e não há um acordo universal sobre o que “forward” sequer significa — alguns exportadores a apontam para o norte, outros para o leste. Um pequeno deslize aqui gira toda a vista.
  • As ferramentas de edição podem perder dados. Fazer um round-trip de um E57 pelo CloudCompare, por exemplo, pode apagar a posição de captura das imagens pinholeRepresentation — as fotos sobrevivem, mas já não sabem onde foram tiradas.

Em resumo: no mundo real, softwares diferentes muitas vezes mostram o mesmo E57 de forma diferente. O nosso importador tenta suavizar as peculiaridades comuns — tornar quadrados os pixels retangulares, corrigir a orientação do panorama e padronizar a tela 2:1 — para que um tour fique com a aparência certa, não importa qual ferramenta tenha escrito o arquivo.

Quando o panorama é incorporado na própria nuvem

Aqui está uma das ideias mais elegantes — e menos valorizadas — de todo o formato. Além de panoramas armazenados 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 — ele percorre uma grade organizada de ângulos, linha por linha, coluna por coluna, como uma TV antiga desenhando uma tela. O E57 pode preservar essa ordem: cada ponto recebe um rowIndex e um columnIndex que indicam de qual célula da grade ele veio. Uma varredura armazenada assim é chamada de estruturada.

Quando o panorama está incorporado na nuvem uma digitalização "estruturada" guarda os seus pontos numa grelha — por isso a nuvem já é uma imagem a digitalização, tal como armazenada: linhas × colunas coluna → azimute (0° ... 360° à volta) linha → elevação (cima ... baixo) céu: o laser não atingiu nada pontos fictícios de preenchimento (alcance = 0 / "sem retorno") ler a grelha em ordem = píxeis → panorama 2:1 instantâneo, sem reprojeção largura da grelha (columnMaximum + 1) = largura do panorama Porque cada ponto se lembra do seu rowIndex e columnIndex, a imagem e a geometria 3D são o mesmo objeto. Os pontos fictícios do céu são o preço a pagar para manter a grelha como um retângulo perfeito — o software real sabe ignorá-los.
Em uma varredura estruturada, a nuvem 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 em uma grade, a nuvem é uma imagem. Leia-a linha por linha e cada ponto cai em um pixel — o panorama volta sem nenhuma reprojeção engenhosa. O arquivo até registra o tamanho da grade em seus indexBounds (columnMaximum, rowMaximum), então o software sabe a resolução de antemão — nosso sintetizador usa 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 resposta é pragmática: preencher essas células com pontos fictícios — muitas vezes com um alcance exatamente de 0, ou seja, "feixe enviado, nada atingido". Eles mantêm o retângulo inteiro, mas não são geometria real, por isso um leitor atento deve deixá-los de lado. O nosso assinala todos os pontos de alcance zero, coloca-os a uma distância fictícia muito distante para que a matemática da grelha continue a funcionar e nunca trata esses pontos fantasma do céu como superfícies reais quando constrói o mapa de profundidade ou exporta a nuvem.

Transformar uma varredura de volta numa foto em que se pode entrar

Nem toda varredura chega numa grelha pronta — algumas são apenas um conjunto solto e não estruturado de pontos. A boa notícia: o panorama ainda pode ser recuperado, e é aqui que o formato se cruza com o nosso próprio trabalho. Porque uma varredura é, na verdade, "uma esfera completa de pontos medidos como ângulos em torno de um único ponto", por isso é possível desdobrá-la num panorama plano.

De uma nuvem de pontos para uma foto em que você pode olhar ao redor o truque por trás deste projeto: desdobrar a esfera de pontos em um panorama plano 1 · o scan fica ao seu redor cada ponto tem um ângulo a partir do centro desdobrar 2 · os ângulos viram uma grelha plana cima ↕ baixo ← 360° completos da esquerda para a direita → preencher lacunas 3 · três imagens panorama colorido intensidade (P/B) mapa de profundidade A nuvem de pontos é o panorama — medida em ângulos, ela se desdobra em uma imagem plana 2:1. A cor pinta os pixels, a intensidade do laser dá uma visualização em tons de cinza nítida e a distância vira um mapa de profundidade.
Uma nuvem, três imagens: a cor pinta os píxeis, a intensidade do laser dá uma escala de cinzentos nítida e sem sombras, e a distância torna-se um mapa de profundidade — é isso que torna um panorama plano mensurável e percorrível.

Anote o ângulo de cada ponto, deixe esquerda-direita percorrer a largura da imagem e cima-baixo a sua altura, e cada ponto cai num píxel — o familiar panorama equirectangular 2:1 esticado. O mapa de profundidade é o ingrediente mágico: com uma distância atrás de cada píxel, um panorama que parece plano torna-se mensurável e percorrível — clique em dois pontos numa parede e o software sabe a distância real, porque nunca se esqueceu dos dados 3D por baixo.

Então, por que o E57 é importante?

Porque é o ponto de encontro neutro. Um topógrafo faz a varredura de uma ponte com uma marca de hardware, um engenheiro abre-a 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 tenha as chaves. Mantém cor, intensidade, geometria, panoramas e as importantíssimas posições do sensor juntos num só lugar, como um padrão aberto que qualquer pessoa pode implementar.

Um último facto curioso: a hora de captura dentro de um E57 é contada em tempo GPS — segundos desde 6 de janeiro de 1980, o momento em que os relógios dos satélites GPS foram ligados — e não desde a época informática habitual de 1970. Errar isso faz com que uma varredura feita hoje pareça ter acontecido em 2013.

Quer aprofundar?

Assistente de IA
Olá! Sinta-se à vontade para fazer qualquer pergunta sobre tours virtuais, nuvens de pontos, 3D Gaussian Splatting, modelos 3D, uso do site, pagamentos e mais. Vou encontrar a resposta ou encaminhar sua pergunta para nossa equipe de suporte.
Nossa IA não conseguiu responder à sua pergunta. Nossa equipe de suporte terá prazer em responder à sua pergunta. Por favor, informe seu endereço de e-mail. Não usamos e-mail para newsletters. Usamos apenas para responder à sua pergunta.