Nuage de points E57 : ce que stocke le format

Résumé : qu’est-ce qu’un nuage de points E57 ?

Un nuage de points E57 désigne généralement les mesures de numérisation elles-mêmes, tandis qu’un fichier E57 est le conteneur qui transporte ces mesures ainsi que les métadonnées associées. [1] Dans la terminologie ASTM actuelle, « fichier E57 » est un raccourci désignant le format de fichier ASTM E57 en 3D défini par ASTM E2807-11(2026). [1]

En pratique, le format de fichier E57 est un format d’échange neutre pour les données d’imagerie 3D, et non un modèle de scanner, un format de solide CAO ou un fichier projet propriétaire. [1] La norme indique qu’un fichier E57 peut stocker des données de points 3D, des attributs de points tels que la couleur et l’intensité, ainsi que des images 2D, en utilisant une combinaison de données binaires et de XML avec un mécanisme d’extension pour les besoins futurs. [1] Ce que le format peut stocker n’est pas identique à ce que chaque exportateur ou importateur préserve, et le document de conception présente E57 comme un format d’échange plutôt que comme un format de projet de travail. [1] [3]

En bref

• Ce que c’est : un conteneur d’échange indépendant des fournisseurs pour les données d’imagerie 3D. [1]
• Ce qu’il peut contenir : des points, des attributs tels que la couleur ou l’intensité, des métadonnées et des images 2D facultatives. [1]
• Ce qu’il ne garantit pas : la précision du scanner, la préservation intégrale des champs ou un comportement identique selon les logiciels. [3]
• Meilleure première étape de validation : ouvrir le fichier localement, inspecter les scans et attributs visibles, puis le tester dans l’outil cible avant la livraison. [6] [11]

Historique du format de fichier E57

Le comité ASTM E57 sur les systèmes d’imagerie 3D a été créé en 2006 afin d’élaborer une terminologie normalisée, des méthodes d’essai, des bonnes pratiques et des spécifications d’interopérabilité des données pour les systèmes d’imagerie 3D. [2] Le document de conception de Daniel Huber, publié en janvier 2011, décrivait les objectifs, la structure et le contexte des premières implémentations du format. [3] Ce document demeure important historiquement, mais il ne constitue pas la norme actuellement applicable. Il fait également référence à l’approbation récente du format sous le nom ASTM E2761, ce qui doit désormais être considéré uniquement comme un contexte historique. [3] Au 5 juin 2026, la page active de la boutique ASTM identifie la spécification actuellement applicable comme étant ASTM E2807-11(2026). [1]

Ce qu’est et ce que n’est pas un fichier E57

E57 est un format d’échange pour les données d’imagerie 3D. [1] Ce n’est pas un type de scanner, pas un format de solide CAO, pas principalement un format de maillage, et pas un fichier projet au même sens que les écosystèmes logiciels qui maintiennent des index internes, des caches, des régions, des annotations et un état d’application. [3] Le document de conception précise explicitement qu’E57 n’est pas destiné à être un format de données de travail ou un format de projet, et que les objets modélisés dérivés ne doivent pas y être inclus. [3]

Cette distinction importe car les utilisateurs s’attendent souvent à ce qu’un fichier .e57 partagé se comporte comme le projet source. La documentation ReCap d’Autodesk distingue les exportations neutres telles qu’E57, PTS et PCG des structures de projet RCP/RCS centrées sur Autodesk, dans lesquelles RCP référence des données de nuage de points indexées plutôt que de servir de conteneur neutre. [7] La documentation SCENE de FARO établit une limite similaire sous un autre angle : sa note sur E57 indique que le format est destiné aux points de scan, et non aux objets. [10]

Format de fichier E57 : principes techniques (anatomie conceptuelle, pas guide d’analyseur)

Sur le plan conceptuel, E57 adopte une conception hybride. [3] La hiérarchie est basée sur XML afin que la structure soit auto-descriptive et extensible, tandis que les charges utiles importantes telles que les points et les images sont stockées efficacement sous forme binaire. [3] Le document de Huber décrit cela comme un compromis entre des structures souples et auto-documentées, et le besoin pratique d’entrées/sorties plus rapides ainsi que d’un stockage moindre que les exports de points en texte brut. [3]

L’anatomie générale est simple : un fichier E57 est divisé en un en-tête, des sections binaires facultatives et une section XML. [3] Quelques faits au niveau des octets sont solidement étayés sans transformer ceci en guide d’analyseur : l’en-tête fait 48 octets, les pages binaires font 1024 octets avec 1020 octets de charge utile plus un CRC 32 bits, les sections binaires utilisent l’ordre des octets little-endian, et la section XML est un unique document XML 1.0 utilisant l’encodage UTF-8. [3] [4]

Cela compte dans les flux de travail, car E57 n’est pas « simplement du XYZ avec une extension différente ». [3] Le format peut regrouper plusieurs jeux de données 3D, des images facultatives, des métadonnées structurées et des charges binaires vérifiables par erreur dans un même conteneur d’échange. [3] [4] C’est pourquoi une livraison E57 peut préserver davantage de contexte qu’une simple exportation texte, mais également pourquoi deux outils peuvent tous deux « ouvrir E57 » tout en différant sur les éléments qu’ils conservent. [3] [4]

Éléments centraux d’un fichier E57

• En-tête : un en-tête de fichier de 48 octets contenant des informations critiques au niveau du fichier. [3] [4]
• Binaire paginé avec CRC : les données binaires sont organisées en pages, avec 1020 octets de charge utile et un CRC 32 bits par page de 1024 octets. [3] [4]
• Hiérarchie XML 1.0 UTF-8 : la section XML obligatoire est un unique document XML 1.0 encodé en UTF-8. [4]
• Data3D : le conteneur principal pour les jeux de données 3D tels que les scans ou ensembles de points. [3] [4]
• Images2D : le conteneur facultatif pour les images 2D associées. [3] [4]
• CoordinateMetadata : une chaîne facultative pour un contexte CRS normalisé. [3] [4]
• CompressedVector : un type central non terminal utilisé pour stocker des enregistrements ordonnés sous forme binaire compressée. [3] [4]

Data3D, Images2D et métadonnées (ce que le schéma cherche à exprimer)

Dans la hiérarchie, Data3D est l’emplacement d’un jeu de données 3D de type scan. [3] Chaque Data3D contient des données de points dans un CompressedVector, et les descriptions publiques désignent couramment la structure logique par point comme PointRecord. [3] [4] Le format est flexible : il peut représenter des coordonnées cartésiennes ou sphériques, et un enregistrement donné peut inclure des champs tels que la couleur RGB, l’intensité, des indices de ligne et colonne, des informations de retour ou des horodatages. [3] Chaque fichier ne contient pas nécessairement tous les champs, et certains logiciels peuvent aussi exposer des normales ou champs dérivés associés dans leur propre modèle de données ; il faut donc vérifier la présence des champs plutôt que la supposer. [5] [6]

Images2D est le conteneur parallèle des images facultatives associées aux scans. [3] Le document public de conception décrit quatre représentations d’image : Visual Reference, Pinhole, Spherical et Cylindrical. [3] Les images sont stockées sous forme de blobs JPEG ou PNG, et le modèle vise à préserver une relation significative entre les pixels et le système de coordonnées du scan lorsque cette relation existe. [3] [4] Si les images disparaissent après importation, la raison habituelle n’est pas qu’E57 ne peut pas les stocker, mais que l’exportateur les a omises, que l’association était incomplète ou que l’outil récepteur ne prend en charge qu’un sous-ensemble des représentations d’image. [3] [6]

Que contient un format de données de scan E57 ? (Et qu’est-ce qui est facultatif ?)

Au niveau des capacités, un format E57 de données de scan peut stocker de la géométrie, des attributs de points, des métadonnées et des images facultatives dans un seul conteneur. [1]

La question pratique est moins « que peut stocker E57 ? » que « qu’est-ce que ce fichier et cette chaîne d’outils ont préservé ? ». [1] [3] Un fichier peut contenir plusieurs jeux de données Data3D, des métadonnées au niveau du fichier, des informations de pose au niveau du scan, un contexte CRS facultatif et des images, mais un importateur peut aplatir les scans, supprimer les images, ignorer le texte CRS ou ne conserver que les attributs communs à tous les nuages internes. [3] [4] C’est pourquoi les livrables E57 doivent toujours être évalués comme une capacité du format par rapport à la prise en charge logicielle. [1] [3]

Vérifiez ces champs de livrable avant d’accepter un fichier de nuage de points E57

• Nombre de points par scan, si l’outil l’affiche. [5]
• Exportation structurée ou non structurée. [8] [9]
• RGB présent ou absent. [1] [3]
• Intensité présente ou absente. [1] [3]
• Normales présentes ou absentes. [5] [6]
• Images intégrées, liées ou absentes. [3] [4]
• Notes sur le système de coordonnées et métadonnées CRS présentes ou absentes. [3] [4]
• Poses de scan ou transformations d’enregistrement présentes ou absentes. [3] [8]
• Paramètres d’exportation pouvant modifier les données, tels que l’exportation de nuage unifié, la décimation ou le comportement de découpe. [8] [9]

Où les données E57 peuvent résider (et ce qui est couramment perdu)

La plupart des plaintes relatives à un « champ manquant » surviennent lorsque les attentes traversent ces niveaux. [3] Un expéditeur peut savoir que le projet source contient des panoramas, une structure par scan et des poses, tandis que le destinataire vérifie seulement que les points se sont ouverts. [6] [8] Pour la livraison, le seul test sûr consiste à vérifier que les informations requises survivent dans l’application cible. [11]

Données de nuage de points E57 structurées ou non structurées (schéma d’abord, logiciel ensuite)

Dans les discussions sur E57, les données structurées ou maillées renvoient d’abord à l’organisation de l’ensemble de points, et non à un terme de marque d’un logiciel particulier. [3] Le document de conception de Huber décrit E57 comme capable de représenter des nuages de points non ordonnés ainsi que des données organisées en lignes et colonnes, ce qui constitue la base au niveau du schéma pour des jeux de données semblables à une grille de scan. [3] Cette organisation peut compter dans les flux de travail basés sur la position du scanner, l’alignement de panoramas et les traitements sensibles aux lignes ou colonnes. [3]

À l’inverse, les données non structurées ou non organisées se comportent davantage comme une simple liste de points dans l’espace. [3] Les coordonnées peuvent rester valides, mais lorsqu’un outil aplatit un scan structuré en exportation non structurée, il peut perdre l’organisation en lignes/colonnes, les relations d’image ou d’autres repères de type station que les outils en aval utilisent pour la navigation et l’affichage. [3] C’est pourquoi un nuage de points peut paraître « complet » dans un programme tout en perdant le comportement de panorama ou de station de scan dans un autre. [3]

Le comportement logiciel vient ensuite. Autodesk indique que ReCap peut exporter un E57 structuré avec des scans individuels, les informations de ligne/colonne et les transformations d’enregistrement, mais avertit également que cette exportation n’applique pas les suppressions ni les découpes du projet. [8] Leica indique que les Setups sur trépied sont exportés de manière structurée avec grille de scan et panoramas, tandis que les sources non structurées sont exportées sans grille de scan. [9] Ainsi, « structuré » est significatif, mais ne garantit pas que chaque programme cible recréera une expérience de station de scan ou de panorama. [8] [9]

Repères de coordonnées, poses et métadonnées CRS (éviter l’erreur n°1 des livrables)

E57 a été conçu afin que plusieurs jeux de données dans un même fichier puissent être représentés dans un système de coordonnées commun au niveau du fichier. [3] En pratique, un scan peut exister dans des coordonnées locales du capteur, tandis qu’une pose facultative ou une transformation rigide indique au logiciel comment ce scan se place dans le repère plus large au niveau du fichier. [3] C’est le pont entre « l’espace du scan individuel » et « l’espace du projet enregistré ». [3]

Les informations CRS constituent une couche distincte mais liée. [3] La racine peut contenir des CoordinateMetadata facultatives sous forme de chaîne CRS normalisée dans un contexte OGC/WKT, tandis que le périmètre ASTM indique également que les quantités normalisées utilisent les unités SI et que les angles plans sont en radians. [1] [4] Les exportateurs des fournisseurs peuvent documenter leurs propres conventions par-dessus cela ; Autodesk ReCap, par exemple, indique que ses exportations E57 utilisent des mètres cartésiens et des angles en radians. [5] Même lorsqu’un fichier est qualifié de « géoréférencé », cela peut rester ambigu si un outil lit les transformations de pose mais ignore le texte CRS, ou inversement. [3] [4]

Avertissement : Le géoréférencement peut être présent sous forme de transformations et/ou de métadonnées CRS, mais tous les logiciels ne lisent ou n’écrivent pas ces éléments de manière cohérente. [4] Validez toujours les coordonnées, l’orientation et le comportement CRS dans l’outil cible avant la livraison. [4]

Comment ouvrir un fichier de nuage de points E57 (visionneuse, BIM, conversion ou code ?)

La manière d’ouvrir un fichier de nuage de points E57 dépend de votre objectif : inspection visuelle, importation de projet, conversion ou traitement programmatique. [6] [11] Il n’existe pas de méthode unique qui fonctionne pour chaque livrable E57. [3]

De manière générale, les visionneuses neutres sont les plus adaptées à l’inspection initiale, les écosystèmes des fournisseurs à la vérification des comportements spécifiques aux projets, et les bibliothèques ou outils de données aux traitements par lots ou par code. [17] [18] Autodesk ReCap documente les comportements d’importation et d’exportation E57, Leica documente la manière dont ses exportations préservent les configurations structurées et non structurées, FARO documente l’import/export E57 comme échange de points de scan, et PDAL documente un lecteur plus restreint destiné aux flux de nuages de points cartésiens. [5] [6] [9] [10] [11]

Les vérifications importantes ne sont pas seulement « est-ce que le fichier s’est ouvert ? », mais « qu’est-ce qui s’est ouvert ? ». [3] Confirmez si un fichier multi-scan est resté multi-scan, si les panoramas ou images ont été importés, si les informations structurées ont survécu, si des attributs tels que RGB ou l’intensité sont conservés, et si l’outil cible a silencieusement aplati ou filtré certains éléments. [6] [8] [11]

Évitez par défaut de téléverser des données de scan confidentielles dans des convertisseurs web ; privilégiez des outils locaux ou d’entreprise pour les jeux de données sensibles, réglementés ou très volumineux.

1. Dupliquez l’E57 original et préservez le fichier source intact.
2. Ouvrez la copie localement dans une visionneuse neutre telle que CloudCompare pour une première inspection. [17]
3. Confirmez le nombre de scans ou la structure multi-scan visible, puis vérifiez la boîte englobante ainsi que les problèmes évidents d’unités ou d’axes.
4. Vérifiez quels attributs ont été importés, notamment RGB, intensité, normales et images lorsque cela est pertinent. [5] [6]
5. Validez le même fichier dans l’application cible, telle que ReCap, Cyclone, SCENE ou une chaîne BIM en aval. [6] [9] [10]
6. Convertissez ou exportez seulement ensuite, en documentant la décimation, les transformations et les attributs supprimés. [8] [9]

Prise en charge E57 documentée par outil (au niveau des fonctions, pas du marketing)

Une règle pratique découle de ce tableau : validez d’abord la catégorie de contenu qui vous importe. [3] Si le travail dépend de la préservation de la grille de scan, des panoramas, des données sphériques ou des métadonnées au niveau du scan, vous avez besoin d’une documentation de l’exportateur et de l’importateur couvrant explicitement ces fonctions, et non d’une simple coche à côté de « E57 ». [6] [8] [9] [11]

E57 face aux autres formats de données de scan (LAS/LAZ/COPC, PTX/PTS, PLY, RCP/RCS)

Aucun format de nuage de points n’est le meilleur pour tous les flux de travail. [1] E57 est particulièrement adapté lorsque vous avez besoin d’un échange neutre de scans terrestres avec un contexte plus riche que de simples fichiers texte de type XYZ. [1] LAS/LAZ et COPC sont plus adaptés lorsque le travail concerne la livraison de LiDAR géospatial, le tuilage, la recherche et l’accès spatial à grande échelle. [12] [13] [14] RCP/RCS est particulièrement adapté lorsque l’environnement de travail est centré sur Autodesk et indexé autour du comportement propre à Autodesk en matière de projet/cache, plutôt que sur un échange neutre. [7]

Le tableau ci-dessous se lit de gauche à droite : « usage idéal » désigne le flux de travail, « préserve couramment » indique l’avantage habituel, et « principale précaution » indique ce qui surprend souvent les utilisateurs lors d’un échange. [1] [7]

Pour les livrables géospatiaux, le contraste est particulièrement concret. [15] La page actuelle de la USGS Lidar Base Specification pour 2025 rev. A indique que les livrables ponctuels doivent être en LAS 1.4-R15 en utilisant PDRF 6, 7, 8, 9, ou 10, ce qui explique notamment pourquoi LAS/LAZ domine de nombreux flux de cartographie nationale et de type 3DEP. [15]

Brève note sur l’orientation du marché : OGC a annoncé la publication du LAZ 1.4 Community Standard le 3 septembre 2026, définissant une compression sans perte pour LAS 1.4 avec stockage en blocs, tandis que COPC 1.0 construit la recherche et le sous-ensemble optimisés pour le cloud sur l’organisation octree de LAZ 1.4. [13] [14] Ces objectifs diffèrent du rôle d’E57 comme conteneur d’échange riche et orienté scan. [1] [14]

Indicateurs de performance et qualité des données (ce qu’E57 ne garantit pas)

E57 ne définit pas en soi l’exactitude, la précision, la résolution ou la densité de points d’un scanner. [3] Il peut transporter des valeurs mesurées et des métadonnées associées, mais la qualité de ces valeurs dépend toujours de l’instrument, de l’étalonnage, de la méthode d’acquisition, du flux d’enregistrement et du traitement ultérieur. [3]

La taille des fichiers et les performances dépendent également du contexte. [3] Les exportations structurées peuvent être plus volumineuses parce qu’elles peuvent inclure des informations de grille de scan et des images panoramiques, tandis que la décimation, la politique de découpe, l’inclusion d’images et les attributs présents peuvent tous modifier le résultat. [8] [9] E57 utilise aussi en interne des structures binaires compressées, mais il n’existe aucune valeur universelle fiable pour la compression E57, la vitesse d’importation ou la taille par rapport à LAS, LAZ, PTX ou PTS sur des projets réels. [3]

E57 peut encoder des valeurs mesurées et des métadonnées, mais l’exactitude du scanner, les résidus d’enregistrement, l’état d’étalonnage et les choix de décimation sont externes au format de fichier. [3]

Applications des fichiers de nuages de points E57 (quand est-ce un bon choix ?)

Comme E57 est conçu pour échanger des données de points 3D, des attributs et des images facultatives, il convient bien partout où les données de scan doivent circuler entre les outils de capture, de revue et d’analyse en aval. [1] [2] Cela inclut couramment la documentation de l’existant, la transmission pour relevé et construction, la documentation d’installations industrielles, les flux de mesure 3D liés à la fabrication et l’enregistrement du patrimoine culturel. [2] Dans les contextes de coordination BIM ou de rétro-ingénierie, sa valeur provient généralement du transport d’un contexte de scan suffisant pour mieux survivre au transfert que les formats texte nus. [1] [3]

Le livrable utile n’est pas l’extension .e57 seule. [3] Une bonne transmission est celle dont les scans, attributs, contexte de coordonnées et images survivent dans le flux de travail de réception. [1] [3]

Limites et risques d’interopérabilité (pourquoi des champs disparaissent)

La force d’E57 est sa souplesse, mais cette souplesse crée des options. [1] [3] Le format peut stocker de nombreux types de données, mais un fichier donné peut en omettre certains, et un outil donné peut n’en préserver qu’un sous-ensemble. [1] [3] C’est pourquoi deux personnes peuvent toutes deux « utiliser E57 » et pourtant voir des scans, champs ou images différents après l’échange. [3]

Les exemples documentés sont instructifs. Le lecteur E57 de PDAL prend en charge les nuages de points cartésiens, lit plusieurs nuages internes comme un seul, ne conserve que les dimensions présentes dans tous les nuages et ne prend pas en charge les nuages de points sphériques. [11] SCENE de FARO indique qu’E57 concerne les points de scan, pas les objets. [10] Autodesk ReCap indique que son importation de panoramas ne prend en charge que la représentation E57_SPHERICAL, avec des images JPEG ou PNG. [6]

Une importation réussie n’est donc qu’un point de départ. [3] Vous devez toujours confirmer si les images, grilles de scan, poses, normales, horodatages et plages d’attributs ont été préservés. [5] [6] [11]

Avertissement : « Ouvert avec succès » ne prouve pas la préservation des images, grilles de scan, poses, normales, horodatages ou de tous les attributs. [6] [11] Validez le fichier dans le flux de travail de destination avant de valider définitivement la livraison. [6] [11]

Conclusion : quand utiliser le format de nuage de points E57

Utilisez le format de nuage de points E57 lorsque vous avez besoin d’un conteneur d’échange neutre, orienté scan, capable de transporter davantage de contexte que du texte brut de type XYZ, mais ne confondez pas cette capacité avec la garantie que chaque outil préservera chaque champ. [1] [3] C’est généralement le bon choix pour la transmission de scans terrestres entre fournisseurs, tandis que LAS/LAZ ou COPC conviennent mieux à de nombreux livrables géospatiaux et que RCP/RCS convient mieux aux flux de projet centrés sur Autodesk. [7] [12] [14] Avant la livraison, parcourez la liste de contrôle des champs et le tableau comparatif, puis vérifiez le résultat dans l’application de destination. [6] [8] [11]

FAQ sur les nuages de points E57

Qu’est-ce qu’un nuage de points E57 (et en quoi diffère-t-il d’un fichier E57) ?

Un nuage de points E57 est la donnée de scan elle-même, tandis qu’un fichier E57 est le conteneur qui peut contenir ces données avec des attributs, métadonnées et images facultatives. [1] Le raccourci ASTM actuel traite « fichier E57 » comme le format de fichier ASTM E57 en 3D défini par ASTM E2807-11(2026) ; le fichier est donc le paquet et le nuage de points est un type de charge utile à l’intérieur. [1]

Que contient un format de données de scan E57 — et qu’est-ce qui est facultatif ?

Le format peut stocker des données de points 3D, des attributs tels que la couleur ou l’intensité, ainsi que des images 2D. [1] Il peut aussi représenter plusieurs jeux de données 3D, des images facultatives, des informations de pose et des métadonnées de coordonnées facultatives pour un contexte CRS. [3] [4] Mais tous ces éléments doivent être considérés comme « potentiellement présents », car un exportateur spécifique peut les omettre et un importateur spécifique peut les ignorer. [3]

Pourquoi mon nuage de points E57 paraît-il différent après l’importation dans un autre programme ?

Parce que « le format peut le stocker » n’est pas la même chose que « cet outil l’a préservé ». [1] [3] Certains programmes aplatissent plusieurs scans, certains ignorent certaines images, certains ne prennent en charge que des représentations spécifiques de panorama et certains ne conservent que les dimensions communes à tous les nuages intégrés. [6] [11] Si l’apparence ou le comportement a changé, comparez les paramètres d’exportation source avec les limites documentées de l’outil de destination. [8] [9]

Comment ouvrir en toute sécurité un fichier de nuage de points E57 (sans convertisseurs web risqués) ?

Créez une copie du fichier original, inspectez cette copie localement dans une visionneuse neutre ou un outil de bureau, vérifiez les scans et attributs visibles, puis testez le même fichier dans l’application cible avant toute conversion. [17] [6] [11] Les convertisseurs web peuvent être pratiques, mais ils ne constituent pas le choix sûr par défaut pour les jeux de données de scan confidentiels, réglementés ou très volumineux.

Le format de fichier E57 garantit-il l’exactitude du scanner, la qualité d’enregistrement ou la densité de points ?

Non. [3] E57 peut encoder des valeurs mesurées et des métadonnées, mais l’exactitude du scanner, les résidus d’enregistrement, l’état d’étalonnage et la décimation sont externes au format de fichier. [3] L’extension indique le conteneur, non si la capture est bonne, l’enregistrement précis ou la densité adaptée à une tâche donnée. [3]

Expert : que signifie « structuré » dans E57 — cela garantit-il une navigation par station de scan/panorama ?

Structuré signifie que les données préservent une organisation de type grille de scan, telle qu’un contexte de lignes et de colonnes, plutôt que d’être simplement une liste de points non ordonnée. [3] Cela peut aider les flux de travail en aval basés sur les stations ou panoramas, mais ce n’est pas une garantie universelle. [3] Autodesk et Leica documentent tous deux le comportement E57 structuré dans leurs propres flux d’exportation, mais l’application cible doit toujours prendre en charge et reconstruire correctement cette information. [8] [9]

Expert : comment considérer les repères de coordonnées, transformations de pose et métadonnées CRS facultatives dans les livrables E57 ?

Raisonnez par couches. Un scan peut être local au capteur, une transformation de pose peut le placer dans un repère commun au niveau du fichier, et des CoordinateMetadata facultatives peuvent décrire le contexte CRS plus large sous forme de texte normalisé. [3] [4] Ces couches sont liées mais non interchangeables ; « géoréférencé » peut donc rester ambigu tant que vous ne vérifiez pas à la fois les coordonnées et le comportement CRS dans le logiciel de réception. [4]

Sources

1. ASTM International — E2807 Standard Specification for 3D Imaging Data Exchange, Version 1.0 (ASTM E2807-11(2026)). https://store.astm.org/standards/e2807
2. NIST — ASTM E57 – Systèmes d’imagerie 3D. https://www.nist.gov/publications/astm-e57-3d-imaging-systems
3. Daniel Huber, Carnegie Mellon University — Le format de fichier ASTM E57 pour l’échange de données d’imagerie 3D. https://publications.ri.cmu.edu/storage/publications/pub_files/2011/1/2011-huber-e57-v3.pdf
4. Library of Congress — ASTEM E57, format de fichier 3D (E57). https://www.loc.gov/preservation/digital/formats/fdd/fdd000563.shtml
5. Autodesk ReCap Help — Prise en charge de l’exportation E57 – Spécification technique. https://help.autodesk.com/cloudhelp/ENU/Reality-Capture/files/Saving_Exporting_Your_Project/export_e57_technical_specifications.html
6. Autodesk ReCap Help — Prise en charge de l’importation E57 – Spécification technique. https://help.autodesk.com/cloudhelp/ENU/Reality-Capture/files/Creating_Scan_Projects/Importing_Scans/E57_Panorama_Images/import_e57_support.html
7. Autodesk ReCap Help — À propos des fichiers et projets de scan et de photogrammétrie. https://help.autodesk.com/cloudhelp/ENU/Reality-Capture/files/Getting_Started/Supported_File_Formats/scan_photogrammetry.html
8. Autodesk ReCap Help — Formats de fichier pris en charge. https://help.autodesk.com/view/RECAP/ENU/?contextId=supported_file_formats
9. Leica Geosystems RCDOCS — Exportation de fichiers tiers (Cyclone REGISTER 360 PLUS). https://rcdocs.leica-geosystems.com/docs/cyclone-register-360-third-party-file-export
10. FARO Knowledge Base — Formats d’exportation pris en charge par SCENE. https://knowledge.faro.com/Software/FARO_SCENE/SCENE/Export_Formats_Supported_by_SCENE
11. PDAL Documentation — readers.e57. https://pdal.org/en/stable/stages/readers.e57.html
12. OGC — Spécification LAS – Format ouvert pour les données de nuages de points LiDAR. https://www.ogc.org/standards/LAS/
13. OGC — OGC annonce la publication du LAZ 1.4 Community Standard. https://www.ogc.org/announcement/ogc-announces-publication-of-the-laz-1-4-community-standard/
14. COPC — Spécification Cloud Optimized Point Cloud – 1.0. https://copc.io/copc-specification-1.0.pdf
15. USGS — Lidar Base Specification: exigences de traitement et de gestion des données. https://www.usgs.gov/ngp-standards-and-specifications/lidar-base-specification-data-processing-and-handling-requirements
16. IANA — Registre des types de médias. https://www.iana.org/assignments/media-types
17. CloudCompare Wiki — E/S DE FICHIERS. https://www.cloudcompare.org/doc/wiki/index.php/FILE_I/O
18. libE57Format — README du dépôt GitHub. https://github.com/asmaloney/libE57Format
19. Library of Congress — Famille Polygon File Format (PLY). https://wwws.loc.gov/preservation/digital/formats/fdd/fdd000501.shtml