E57, expliqué : le "PDF des nuages de points"
Imaginez que vous photographiez une pièce, mais qu'au lieu d'obtenir une image plane, vous capturez la position exacte d'un million de petits points couvrant chaque mur, chaise et tasse à café. Faites tourner un laser assez vite et mesurez la distance de chaque élément : vous obtenez un nuage de points, une "photographie" 3D composée de points mesurés. Voici une présentation accessible et sans jargon de ce que contient réellement un fichier E57, ainsi que d'une astuce ingénieuse utilisée par notre propre logiciel.
Pourquoi un format spécial, au juste ?
Une photo ordinaire n'est qu'une grille de pixels colorés : rien de compliqué. Un scan 3D est plus complexe. Pour chacun de ses millions de points, il faut enregistrer sa position dans l'espace (trois nombres : X, Y, Z), sa couleur, la force du signal laser réfléchi (son intensité, comparable à une "photo laser" en noir et blanc) et, souvent, les photos panoramiques prises simultanément par le scanner.
Imaginez maintenant qu'une personne effectue un scan avec un Faro, qu'un collègue utilise un Leica et que le client ouvre le résultat dans un logiciel Autodesk. Trois appareils, trois logiciels : tous doivent pouvoir lire le même fichier, même des années plus tard, sans avoir à demander un décodeur propriétaire à un fournisseur. C'est le problème que résout E57. Il s'agit d'une norme ouverte et indépendante des fabricants (publiée sous le nom ASTM E2807 et fondée sur la bibliothèque open source libE57). On l'appelle le "PDF des nuages de points" : un fichier portable dont le mode de lecture fait consensus.
L'idée clé : une carte textuelle et la puissance du binaire
Un fichier E57 est fondamentalement un hybride qui associe deux éléments très différents : une petite section XML, du texte brut directement lisible qui sert de table des matières, et de gros blocs de données binaires contenant des millions de nombres bruts, stockés de manière compacte pour accélérer leur traitement.
Pourquoi mettre la carte à la fin ? Parce que pendant qu'un scanner est en train d'écrire le fichier, il ne sait pas encore quelle taille fera chaque élément ; il enregistre donc d'abord les données brutes au fil de l'eau, puis écrit un résumé bien structuré une fois l'opération terminée. L'avantage est énorme : pour extraire un scan d'un fichier de 20 gigaoctets, le logiciel lit le petit en-tête, accède à la carte XML, trouve la ligne qui dit "le scan n° 3 se trouve à l'octet 4 812 000 000", et y va directement.
Un dispositif de sécurité discret est également prévu : le fichier entier est découpé en "pages" de 1 024 octets, chacune réservant ses 4 derniers octets à une somme de contrôle — une empreinte qui permet au logiciel de détecter si le fichier a été corrompu.
Tout est rattaché à une racine unique
Ouvrez cette carte XML et vous trouverez un arbre — exactement comme les dossiers de votre ordinateur. Il y a un seul root, et deux branches font l'essentiel du travail : data3D, une liste numérotée de scans, et images2D, une liste numérotée de photos (généralement les panoramas 360° pris par le scanner).
Deux façons d'écrire un point
Un scanner laser ne raisonne pas vraiment en X, Y, Z. Il reste à un endroit et tourne sur lui-même. Pour chaque point, il connaît trois valeurs : la distance (la longueur parcourue par le faisceau), l'azimut (l'angle horizontal, de gauche à droite) et l'élévation (l'angle vers le haut ou le bas). Ce sont des coordonnées sphériques, le langage naturel du scanner. La plupart des logiciels préfèrent toutefois les coordonnées cartésiennes X, Y, Z. E57 peut stocker indifféremment les unes ou les autres, et quelques calculs trigonométriques rapides suffisent pour passer d'un système à l'autre.
Trois types de photos intégrées
Les photos de images2D ne sont pas des liens vers des fichiers placés dans un dossier — les véritables fichiers JPEG ou PNG sont stockés au cœur même du fichier E57. Et il existe plusieurs types de photos intégrées. E57 encapsule chacune dans une "représentation" qui indique au logiciel dans quelle mesure il peut se fier à l'image sur le plan géométrique. La différence se résume à une seule question : dans quelle mesure la description de la caméra est-elle complète ?
sphericalRepresentation— un panorama complet à 360° × 180°, sous la forme bien connue d'une image équirectangulaire étirée au format 2:1. La projection étant connue, chaque pixel correspond à une direction précise et s'aligne donc parfaitement avec le nuage de points. C'est la voie principale de notre chaîne de traitement : nous lisons l'image, la ramenons à un format 2:1 exact, puis la transmettons à la visionneuse de panoramas.pinholeRepresentation— une photo prise avec un objectif ordinaire, décrite par le classique modèle de caméra à sténopé (distance focale, taille du capteur et centre optique). Ces informations suffisent également au logiciel pour déterminer la direction de chaque pixel, mais sur un champ de vision plus étroit. En pratique, c'est surtout la méthode employée par Leica : une cubemap prête à l'emploi — les six faces planes d'un cube orientées vers l'extérieur — est inscrite directement dans le fichier E57. Notre chaîne de traitement dédiée aux faces du cube les assemble ensuite en un panorama complet. C'est l'un des cas les plus simples à reconvertir en une image 360° nette.visualReferenceRepresentation— une photo sans aucun modèle de caméra, explicitement "pour l'œil humain seulement". On ne peut ni mesurer avec elle ni la projeter sur le nuage de points ; ce n'est qu'une image de référence. Notre importateur conserve ces images comme commentaires associés plutôt que de les placer en 3D.
Voici le piège. sphericalRepresentation est le choix le plus courant, mais il est étonnamment facile d'y commettre de petites erreurs — c'est précisément pourquoi le même scan peut s'afficher différemment d'un programme à l'autre.
- Les zones aveugles sont recadrées. Tous les scanners ont une zone qu'ils ne peuvent pas voir, généralement juste en dessous, à l'emplacement de leur propre trépied. Certains logiciels d'exportation coupent simplement le panorama à cet endroit, ce qui laisse un vide ou produit une hauteur non standard.
- Pixels non carrés. Un panorama correct possède des pixels carrés (
pixelWidth=pixelHeight) ; ce n'est pas le cas de certains fichiers, dont l'image paraît alors étirée tant qu'elle n'est pas redimensionnée. - La mauvaise direction est considérée comme l'“avant”. La rotation enregistrée avec un panorama indique quelle direction se trouve au centre de l'image, et il n'existe aucun accord universel sur ce que signifie réellement “avant” — certains exportateurs l'orientent vers le nord, d'autres vers l'est. Une légère erreur à ce niveau fait tourner toute la vue.
- Les outils d'édition peuvent perdre des données. Le fait d'ouvrir puis de réexporter un fichier E57 dans CloudCompare, par exemple, peut supprimer la position de capture des images
pinholeRepresentation— les photos sont conservées, mais leur position de prise de vue est perdue.
En résumé, différents logiciels affichent souvent différemment le même fichier E57. Notre outil d'importation tente de corriger les particularités les plus courantes — redimensionnement des pixels non carrés, correction de l'orientation du panorama et normalisation de l'image au format 2:1 — afin que la visite s'affiche correctement, quel que soit l'outil ayant produit le fichier.
Quand le panorama est intégré au nuage de points lui-même
Voici l'une des idées les plus élégantes — et les moins reconnues — de tout le format. En plus des panoramas stockés sous forme d'images distinctes, un panorama peut aussi se cacher à l'intérieur du nuage de points lui-même. Un scanner laser n'émet pas ses impulsions au hasard : il balaie une grille régulière d'angles, ligne par ligne, colonne par colonne, comme un ancien téléviseur composant une image à l'écran. E57 peut conserver cet ordre : chaque point reçoit un rowIndex et un columnIndex indiquant de quelle cellule de la grille il provient. Un scan stocké de cette façon est dit structuré.
L'avantage : si les points sont disposés sur une grille, le nuage est déjà une image. Lisez-le ligne par ligne et chaque point correspond à un pixel — le panorama réapparaît sans la moindre opération complexe de reprojection. Le fichier enregistre même la taille de la grille dans ses indexBounds (columnMaximum, rowMaximum), de sorte que le logiciel connaît la résolution à l'avance — notre outil de synthèse détermine directement la largeur de sortie d'après columnMaximum + 1.
Mais une grille doit former un rectangle parfait, contrairement au monde réel. Que faire dans les directions où le faisceau est parti à ciel ouvert et où rien n'est revenu ? La réponse est pragmatique : remplir ces cellules avec des points fictifs — très souvent à une distance exactement égale à 0, ce qui signifie "faisceau envoyé, rien touché". Ces points préservent l'intégrité du rectangle, mais ne correspondent à aucune géométrie réelle : un logiciel de lecture doit donc les écarter. Le nôtre signale chaque point à distance nulle, l'affecte à une distance fictive très élevée pour que les calculs sur la grille continuent de fonctionner, et ne traite jamais ces points fantômes du ciel comme de vraies surfaces lorsqu'il construit la carte de profondeur ou exporte le nuage.
Transformer un scan en une photo dans laquelle on peut entrer
Tous les scans n'arrivent pas sur une grille toute prête — certains ne sont qu'un simple amas non structuré de points. La bonne nouvelle : le panorama est quand même récupérable, et c'est là que le format rejoint notre propre travail. Car un scan est en réalité "une sphère complète de points mesurés suivant des angles autour d'un même point", que l'on peut dérouler en un panorama plat.
Projetez chaque point en fonction de son angle — de gauche à droite sur la largeur de l'image et de haut en bas sur sa hauteur — et il se place sur un pixel du panorama équirectangulaire étiré au format 2:1 bien connu. La carte de profondeur est l'ingrédient magique : avec une distance associée à chaque pixel, un panorama apparemment plat devient mesurable et parcourable. Cliquez sur deux points d'un mur et le logiciel connaît la distance réelle, car les données 3D sous-jacentes sont toujours présentes.
Alors, pourquoi E57 est-il important ?
Parce qu'il constitue un point de rencontre neutre. Un géomètre scanne un pont avec le matériel d'une marque, un ingénieur l'ouvre dans un autre logiciel et un architecte l'archive pour les vingt prochaines années : E57 est le fichier commun sur lequel tous trois peuvent compter, sans qu'aucun fournisseur n'en détienne les clés. Il réunit la couleur, l'intensité, la géométrie, les panoramas et les indispensables positions des capteurs dans un même fichier, selon une norme ouverte que chacun peut mettre en œuvre.
Dernière anecdote : l'heure de capture enregistrée dans un fichier E57 est exprimée en temps GPS, c'est-à-dire en secondes écoulées depuis le 6 janvier 1980, date de départ du temps GPS, et non depuis la date de référence habituelle des systèmes informatiques, fixée en 1970. Une mauvaise interprétation ferait apparaître un scan réalisé aujourd'hui comme datant de 2013.
Envie d'aller plus loin ?
- libE57.org — la bibliothèque open source de référence et le site officiel du format
- ASTM E2807 — la norme officielle
- libE57Format · Image2D — les définitions exactes des représentations sphérique, par sténopé et de référence visuelle
- Paul Bourke’s E57 notes — une présentation technique concise de l'en-tête et de la structure