Nuage de points XYZ : définition et utilisation

Résumé

Un nuage de points XYZ est un simple fichier texte ASCII qui stocke les coordonnées des points sous forme de colonnes X, Y et Z, généralement avec un point par ligne. Il est largement utilisé pour les échanges rapides, l’inspection, les scripts et les exports légers, car sa structure est facile à lire dans un éditeur de texte. Le problème est que le nuage de points XYZ est une convention, et non une spécification d’échange formelle unique. [1] [2]

Cette ambiguïté constitue le principal risque. Un fichier nommé .xyz, .csv ou .txt peut contenir de simples coordonnées, des attributs supplémentaires, un tableau ASCII avec en-tête, ou un format entièrement différent. Ce qui manque habituellement est tout aussi important : les unités, le système de coordonnées, le SCR ou le code EPSG, le référentiel et la signification des colonnes au-delà de X/Y/Z sont souvent absents, sauf si vous les connaissez déjà grâce au contexte. Ce guide se concentre sur un flux de travail sûr : inspecter d’abord, puis ouvrir, convertir et résoudre les problèmes en tenant compte de la structure réelle du fichier. [1] [2]

Inspecter un fichier .xyz inconnu en toute sécurité (avant l’importation)

La seule extension .xyz ne suffit pas pour importer un fichier en toute sécurité. La Bibliothèque du Congrès indique que les fichiers de nuages de points XYZ peuvent utiliser xyz, csv ou txt, et FME considère également ces extensions comme conventionnelles plutôt qu’obligatoires. Un fichier texte portant l’un de ces noms peut être une simple liste de points, un tableau ASCII propre à un logiciel, ou quelque chose sans rapport avec les nuages de points. La première étape la plus sûre consiste à inspecter le contenu en texte brut avant d’envoyer le fichier dans n’importe quel importateur. [1] [2]

Vous devez rechercher un motif, et pas seulement une extension. Si la ligne 1 est un nombre d’atomes et la ligne 2 un titre ou un commentaire, il s’agit d’un XYZ chimique, et non d’un fichier XYZ de nuage de points. Si la ligne 1 est un nombre entier suivi de lignes de points, le fichier peut être de type PTS plutôt qu’un XYZ simple. Vérifiez également si le fichier utilise des espaces, des tabulations ou des virgules comme séparateur, s’il comporte un en-tête nommant les colonnes et si le nombre de champs reste cohérent d’une ligne à l’autre. [15] [4]

Utilisez cette vérification rapide avant chaque tentative d’importation d’un fichier inconnu :

• Ouvrez les 5 premières lignes en texte brut.
• Comptez les colonnes dans quelques lignes de données.
• Identifiez le séparateur.
• Repérez l’en-tête par rapport aux données.
• Détectez une ligne de nombre d’atomes et une ligne de commentaire/titre d’un XYZ chimique. [15]
• Repérez une ligne de nombre de points suggérant un fichier de type PTS plutôt qu’une simple liste de points XYZ. [4]
• Confirmez le séparateur décimal avant l’importation.

Qu’est-ce qu’un nuage de points XYZ ?

Au niveau de la convention XYZ, un nuage de points XYZ est un fichier texte ASCII brut dans lequel chaque ligne représente un point et chaque colonne une composante du point, généralement X, Y et Z. En pratique, cela signifie un point par ligne, écrit sous forme de champs numériques séparés par un délimiteur. FME décrit directement ce modèle : chaque ligne est un point et chaque colonne est une composante de point. La fiche de la Bibliothèque du Congrès souligne le caractère léger du format en indiquant qu’il n’existe ni documentation ni autodocumentation. [1] [2]

Des colonnes supplémentaires peuvent apparaître, mais elles ne s’expliquent pas automatiquement. Un quatrième champ peut correspondre à l’intensité, à une classification, au rouge, à une composante de normale ou à un élément propre à un importateur. Un en-tête peut aider, mais de nombreux fichiers XYZ n’en comportent pas. [1] [2]

Ce que XYZ ne stocke généralement pas :

• les unités ou l’échelle
• le système de coordonnées ou le SCR
• le code EPSG ou le référentiel
• la pose du scanner ou les transformations de recalage
• la topologie ou les faces
• une sémantique fiable pour les colonnes au-delà de X, Y et Z

Cela est important, car les nuages de points sont fondamentalement des ensembles de points non structurés ; leur signification doit donc souvent provenir du schéma du fichier ou de notes externes. Un simple fichier XYZ peut suffire à une visualisation ou un transfert rapide, mais il ne contient généralement pas le contexte spatial complet nécessaire à une interopérabilité robuste. [1] [18]

La présence d’un en-tête n’est pas universelle. Certains fichiers XYZ ne sont que des lignes simples, tandis que d’autres sont des tableaux ASCII génériques contenant par hasard des colonnes X/Y/Z. Voici de petits exemples :

1.0 2.0 3.0

X Y Z

Au niveau de la convention XYZ, les deux styles peuvent exister ; l’acceptation de l’un ou l’autre par un outil dépend du logiciel. [1] [2] [3]

Contexte historique et statut du format

Le nuage de points XYZ se comprend mieux comme une convention textuelle pratique qui perdure parce qu’elle est transparente et facile à échanger, et non parce qu’une spécification formelle unique de nuage de points l’aurait définie pour tous. La Bibliothèque du Congrès répertorie le nuage de points XYZ sous l’identifiant de format fdd000617, marque cette fiche comme préliminaire et ne liste aucune documentation formelle ni autodocumentation, ce qui correspond à son statut ad hoc dans les flux de travail quotidiens. La documentation du Wisconsin explique pourquoi l’ASCII brut reste attractif : il est accessible et lisible, même si le texte nécessite une analyse et que le binaire peut être lu plus directement. Des formats ultérieurs tels qu’E57 ont répondu aux limites des échanges ad hoc en offrant une méthode documentée pour stocker des nuages de points, des images associées et des métadonnées fondamentales, y compris les informations de pose afin que plusieurs jeux de données puissent être représentés dans un même système de coordonnées. [1] [6] [11]

Comment le format de fichier XYZ stocke les données de nuages de points

Au niveau de la convention XYZ, le modèle de stockage est simple : du texte séparé par un délimiteur. FME décrit Point Cloud XYZ comme des lignes et colonnes ASCII, avec des séparateurs tels que les espaces, les virgules ou les tabulations, et une ligne par point. [2]

Colonnes courantes que vous pouvez rencontrer :

• X Y Z
• X Y Z R G B
• X Y Z Intensity
• X Y Z Nx Ny Nz
• X Y Z Classification

L’avertissement est tout aussi simple : la colonne 4 et les suivantes ne sont pas autodécrites, sauf si un en-tête, une note associée ou une règle spécifique à l’outil vous indique leur signification. [1] [2] [4] [6]

Conventions au niveau du format et attentes des importateurs

Au niveau de la convention XYZ, un fichier XYZ minimaliste peut autoriser des lignes vides, des lignes de commentaire commençant par # dans la colonne 1, ainsi que des coordonnées séparées par des espaces sur une ligne. Burkardt documente exactement ce type de convention légère. Le comportement propre aux logiciels peut être beaucoup plus strict. Le module readers.text de PDAL attend une ligne d’en-tête nommant les dimensions, et chaque ligne suivante doit contenir le même nombre de champs que celui déclaré par l’en-tête. ROCK Robotic documente un autre flux de travail spécifique qui exige que la première ligne définisse le format, qu’il y ait un point par ligne ensuite et une extension .xyz pour sa plateforme. Autrement dit, « XYZ valide » et « accepté par cet importateur » ne sont pas la même question. [5] [3] [7]

Variantes du format de nuage de points XYZ et formats associés

En pratique, trois groupes de variantes sont les plus importants. Le premier est la liste de points XYZ simple, souvent sans en-tête, composée uniquement de lignes X/Y/Z. Le deuxième est la forme à lignes étendues, dans laquelle des attributs supplémentaires tels que la couleur, les normales ou l’intensité sont ajoutés mais peuvent rester non documentés. Le troisième est le tableau de points ASCII générique avec en-tête, qui nomme les dimensions en amont et se comporte davantage comme un CSV sémantique incluant des colonnes XYZ. Les formes textuelles documentées d’Open3D illustrent clairement le cas intermédiaire : xyz est [x, y, z], xyzn est [x, y, z, nx, ny, nz] et xyzrgb est [x, y, z, r, g, b]. [4] [2]

Un conflit mineur mais important, spécifique aux logiciels, concerne l’échelle RGB. La convention XYZRGB du Wisconsin utilise des positions en virgule flottante et des couleurs en octets non signés de 0 à 255, tandis qu’Open3D documente les valeurs de couleur xyzrgb comme des flottants dans la plage 0 à 1. PyMeshLab expose directement cette ambiguïté au moyen d’un choix rgbmode à l’importation de texte pour 0–255 contre 0.0–1.0. Un fichier peut donc être numériquement bien formé tout en affichant des couleurs incorrectes si l’importateur suppose la mauvaise échelle. [6] [4] [17]

Comparaison : XYZ vs E57 vs LAS/LAZ vs PLY vs PCD

Cette comparaison porte sur les métadonnées et l’interopérabilité, et non sur le classement d’un format comme universellement meilleur. XYZ est minimal et facile à inspecter, ce qui est utile lorsque vous n’avez besoin que de coordonnées ou d’un simple échange textuel. Des formats plus riches sont utiles lorsque vous avez besoin que le fichier lui-même préserve les attributs, le schéma, les images ou les informations de référence spatiale au lieu de dépendre de notes externes. [1] [10] [12] [14]

E57 est documenté par la Bibliothèque du Congrès comme un format d’échange binaire plus XML pouvant stocker des données de points 3D, des attributs de points et des images 2D. LAS ajoute des métadonnées lidar structurées, notamment des mécanismes d’en-tête et de VLR/EVLR ainsi que la prise en charge de SCR WKT. PCD est autodécrit d’une autre manière : il utilise un en-tête ASCII avec des champs nommés tels que FIELDS, SIZE, TYPE, COUNT, WIDTH, HEIGHT, VIEWPOINT, POINTS et DATA, et prend en charge des sections de données ASCII et binaires. Des conteneurs plus riches n’améliorent pas à eux seuls les données source, mais ils peuvent préserver davantage de ce que vous savez déjà. [10] [12] [14]

Les atouts et limites typiques sont les suivants, car XYZ est généralement du texte brut, tandis qu’E57, LAS et PCD transportent davantage de structure dans le fichier lui-même. [1] [10] [12] [14]

Comment ouvrir un fichier de nuage de points XYZ

Le flux de travail d’ouverture le plus sûr commence par une logique générique, et non par un produit précis. Inspectez d’abord le fichier texte. Déterminez ensuite si la première ligne est une donnée, un en-tête ou une ligne de comptage. Faites enfin correspondre le séparateur, l’ordre des colonnes et le nombre de champs à l’importateur que vous prévoyez d’utiliser. Au niveau de la convention XYZ, un fichier peut n’être rien de plus que des lignes de nombres. Les importateurs propres à un logiciel peuvent au contraire exiger des dimensions nommées, un nombre fixe de champs ou des variantes textuelles spécifiques. [1] [2] [3] [5]

Le comportement varie suffisamment selon les outils pour qu’une importation réussie ne prouve pas que le fichier est portable. Un fichier qui s’ouvre correctement dans une application peut échouer dans une autre parce que le second outil attend une règle d’en-tête, une échelle de couleur ou un mappage de champs différent. [3] [4] [7] [17]

Des exemples spécifiques aux logiciels aident à fixer les attentes. FME documente la lecture et l’écriture de Point Cloud XYZ comme données de points en lignes et colonnes. Le module readers.text de PDAL attend une ligne d’en-tête nommant les dimensions et permet également de fournir un SRS externe via override_srs ou default_srs au moyen de chaînes WKT, PROJ ou EPSG. Open3D documente la prise en charge de xyz, xyzn, xyzrgb et pts. Autodesk ReCap répertorie XYZ en importation et E57, PTS ainsi que RCP/RCS en exportation. Le manuel de CloudCompare répertorie asc, txt, neu et xyz comme fichiers ASCII de nuages de points. PyMeshLab documente à la fois le chargement et l’enregistrement de xyz. [2] [3] [4] [8] [16] [17]

Comment convertir le format de nuage de points XYZ

On convertit généralement des fichiers XYZ lorsqu’une gestion des métadonnées plus robuste que celle permise par le texte brut est nécessaire. Avant la conversion, identifiez ce que contient réellement le fichier source et consignez le contexte que les lignes de texte ne transportent pas elles-mêmes. C’est important car un convertisseur de nuages de points peut remapper les colonnes et emballer des métadonnées, mais il ne peut pas déduire une signification spatiale qui n’a jamais été capturée. Des formats tels qu’E57 et LAS peuvent préserver une structure plus riche si vous la fournissez lors de la conversion. [10] [11] [12]

Avant de convertir, consignez les éléments suivants :

• unités
• SCR/EPSG ou repère de coordonnées local
• séparateur
• ordre des colonnes
• échelle RGB
• échelle d’intensité
• scanner/logiciel source
• date d’acquisition si connue

Avertissement encadré : honnêteté de conversion

La conversion peut remapper les colonnes existantes et joindre des métadonnées fournies par l’utilisateur. La conversion ne peut pas reconstruire des unités, un SCR ou un référentiel, une pose de scanner, une topologie de numérisation structurée ou des transformations de recalage absents s’ils n’ont jamais été fournis avec le fichier XYZ.

E57 est utile lorsque vous avez besoin d’un format d’échange documenté pouvant stocker des points 3D, des attributs et des images 2D. L’article de Huber explique également pourquoi la pose est importante : plusieurs jeux de données peuvent être représentés dans un système de coordonnées unique en stockant les informations de pose associées. À titre d’exemple spécifique à un logiciel, la documentation d’export E57 d’Autodesk ReCap décrit une racine E57 avec data3D et images2D, des coordonnées cartésiennes en mètres et une pose par numérisation utilisant une translation et une rotation par quaternion. LAS est une autre cible riche : la Bibliothèque du Congrès décrit LAS comme utilisant des en-têtes structurés ainsi que des enregistrements VLR/EVLR et prenant en charge les SCR WKT. Ces conteneurs plus riches ne sont utiles que si vous connaissez réellement les métadonnées que vous voulez leur faire transporter. [10] [11] [9] [12]

Performances et limites de traitement des fichiers

Au niveau de la convention XYZ, l’ASCII brut est facile à inspecter mais coûteux à analyser par rapport au stockage binaire. Le Wisconsin énonce directement ce compromis : les fichiers texte nécessitent une analyse, tandis que les fichiers binaires peuvent être lus plus directement. [6]

Cette surcharge ne concerne pas uniquement la vitesse brute de lecture. Le format XYZ simple manque également d’en-têtes autodécrits, d’indexation organisée ou de structures de métadonnées plus riches dont bénéficient de nombreux flux de travail de plus grande ampleur. La fiche LAS de la Bibliothèque du Congrès explique clairement la raison : l’échange ASCII peut être très lent, la taille des fichiers peut devenir très importante et les informations spécifiques au lidar peuvent être perdues. C’est l’une des raisons pour lesquelles les formats binaires ou autodécrits deviennent souvent plus faciles à gérer à mesure que les projets dépassent la simple inspection et l’échange. [6] [12]

Aucun chiffre général fiable n’a été trouvé pour les ratios de taille universels, les limites de nombre de points ou une taille pratique maximale unique pour un fichier XYZ. Toute limite réelle dépend de la conception de l’analyseur, de la mémoire disponible, du comportement du système d’exploitation, du style de séparateur et du fait que le flux de travail conserve les données sous forme de texte ou les convertit en une structure binaire plus riche. [6] [12]

Applications des fichiers de nuages de points XYZ

Les fichiers de nuages de points XYZ sont surtout utiles lorsqu’une représentation ASCII simple en lignes et colonnes suffit. Les exemples courants comprennent l’export de scanner, l’export de photogrammétrie, l’échange rapide de points d’altitude SIG, les scripts, le débogage d’un pipeline et l’inspection d’archivage minimale lorsque la lisibilité compte davantage que des métadonnées intégrées riches. La documentation de FME reflète ce rôle d’échange élémentaire, et l’argumentaire du Wisconsin explique pourquoi le format perdure : l’ASCII reste accessible et facile à inspecter avec des outils ordinaires. La réserve reste la même : si le travail en aval dépend des unités, du SCR, du contexte de recalage ou d’étiquettes d’attributs non ambiguës, le fichier XYZ nécessite généralement des notes associées ou une conversion dans un format plus riche. [2] [6] [1]

Limitations et erreurs d’importation courantes

La plupart des échecs d’importation XYZ ne sont pas des corruptions mystérieuses. Ce sont des inadéquations entre une convention textuelle souple et un importateur plus strict. Au niveau de la convention XYZ, un fichier peut être une liste de coordonnées parfaitement raisonnable. Les outils spécifiques aux logiciels peuvent néanmoins le rejeter parce qu’ils attendent un en-tête, un nombre fixe de champs, un séparateur particulier ou un ordre d’attributs spécifique. PDAL et ROCK Robotic sont de bons exemples d’attentes d’importateur documentées allant au-delà de la convention simple. [3] [7] [1]

Certains échecs ne sont pas réellement des échecs de format. Un fichier peut être analysé correctement et produire malgré tout un résultat erroné parce que les unités sont fausses, que le SCR est absent, que le repère local ou de projet n’est pas documenté ou que les axes sont inversés. Le format XYZ brut ne transporte généralement pas suffisamment d’autodescription pour éviter seul ces erreurs. [1] [12]

La couleur ajoute un niveau d’ambiguïté supplémentaire. Le Wisconsin documente XYZRGB avec des couleurs en octets 0–255, Open3D documente xyzrgb avec des couleurs flottantes 0–1, et PyMeshLab propose un commutateur rgbmode précisément pour cette raison. Un fichier numériquement valide peut donc être importé avec des couleurs délavées ou écrêtées si l’hypothèse d’échelle est erronée. La même prudence générale s’applique aux autres détails d’importation de texte tels que les espaces blancs mixtes, les séparateurs répétés, les en-têtes inattendus, les virgules décimales, la notation scientifique ou des lignes supplémentaires ne contenant pas de données en tête de fichier. Un XYZ chimique peut être confondu avec un XYZ de nuage de points parce qu’il commence par une ligne de nombre d’atomes et une ligne de titre ou de commentaire, tandis que les fichiers de type PTS peuvent commencer par une ligne de nombre de points. Et une liste de points n’est pas un maillage : XYZ stocke des points, et non des faces ou une topologie. [6] [4] [17] [15]

Voici une liste de contrôle compacte pour le dépannage :

1. Vérifiez un mauvais séparateur, des séparateurs répétés ou des espaces blancs mixtes.
2. Vérifiez l’absence d’en-tête ou la présence d’un en-tête inattendu.
3. Vérifiez la virgule décimale par rapport au point décimal.
4. Vérifiez que l’importateur accepte la notation numérique employée dans le fichier, y compris la notation scientifique.
5. Vérifiez la présence de BOM parasites ou de lignes de commentaire avant le bloc de données attendu.
6. Vérifiez si RGB est 0–255 ou 0–1. [6] [4] [17]
7. Vérifiez que les unités sont documentées et plausibles.
8. Vérifiez si le SCR est absent ou si les axes sont inversés.
9. Vérifiez si le fichier est en réalité un XYZ chimique. [15]
10. Vérifiez si la première ligne est réellement un nombre de points provenant d’un fichier de type PTS. [4]
11. Vérifiez que vous n’essayez pas d’utiliser une liste de points là où un format de maillage avec faces est requis.

Quand utiliser un nuage de points XYZ, et quand ne pas l’utiliser

Utilisez un nuage de points XYZ lorsque la transparence, l’échange rapide et les scripts simples comptent davantage que les métadonnées intégrées. Il convient bien à l’inspection, aux tests et aux échanges légers précisément parce que le fichier n’est que du texte. Ne comptez pas sur lui comme seul format de production ou d’archivage lorsque les unités, le SCR, le référentiel, la sémantique des attributs, le contexte de recalage ou l’intégrité d’un schéma plus riche doivent survivre à une transmission sans approximation. La fiche de la Bibliothèque du Congrès note explicitement que XYZ ne dispose ni de documentation formelle ni d’autodocumentation, tandis qu’E57, LAS et PCD offrent des moyens plus structurés de préserver la signification dans le fichier lui-même. En bref, le nuage de points XYZ est utile lorsque les coordonnées constituent le message ; c’est un choix faible lorsque les métadonnées font aussi partie du message. [1] [10] [12] [14]

FAQ

Ces réponses courtes se concentrent sur l’interopérabilité et le dépannage. Le problème récurrent est simple : les lignes de texte sont souvent faciles à lire, mais c’est le contexte manquant autour de ces lignes qui provoque généralement la confusion. [1] [2]

Qu’est-ce qu’un nuage de points XYZ ?

Un nuage de points XYZ est une liste de points textuelle dans laquelle chaque ligne correspond généralement à un point et les colonnes stockent typiquement les coordonnées X, Y et Z. Il est simple et utile pour l’échange, mais il n’est pas fortement autodécrit. [1] [2]

Pourquoi mon fichier .xyz ne s’ouvre-t-il pas comme un nuage de points ?

Parce que .xyz est ambigu. Le fichier peut employer un mauvais séparateur, des en-têtes inattendus, une ligne de comptage supplémentaire, ou il peut en réalité s’agir d’un XYZ chimique, où la ligne 1 est le nombre d’atomes et la ligne 2 un titre ou un commentaire. [15] [4]

Un fichier de nuage de points XYZ stocke-t-il les unités (mm vs m) ou un code SCR/EPSG ?

Généralement pas à lui seul. Au niveau de la convention XYZ, ces détails sont souvent externes. Des outils spécifiques aux logiciels, tels que PDAL, peuvent appliquer des informations SRS via override_srs ou default_srs en utilisant des chaînes WKT, PROJ ou EPSG, mais il s’agit d’une logique d’importateur, et non d’une garantie du fichier XYZ lui-même. [1] [3]

Un nuage de points XYZ peut-il stocker la couleur, les normales ou l’intensité, et comment connaître la plage RGB ?

Oui, des colonnes supplémentaires peuvent stocker ces attributs, mais leur signification est souvent ambiguë à moins d’être documentée. Open3D documente xyzn et xyzrgb, le Wisconsin documente XYZRGB avec des couleurs en octets 0–255, et PyMeshLab propose un choix rgbmode entre 0–255 et 0.0–1.0. [4] [6] [17]

Comment ouvrir un fichier de nuage de points XYZ dans PDAL, Open3D ou CloudCompare sans perdre de colonnes ?

Faites correspondre le fichier aux attentes documentées de l’outil. Le module readers.text de PDAL attend une ligne d’en-tête nommant les dimensions. Open3D documente des variantes textuelles fixes telles que xyz, xyzn, xyzrgb et pts. CloudCompare documente la prise en charge de fichiers ASCII de nuages de points, dont xyz, mais vous devez toujours utiliser le bon séparateur et la bonne interprétation des colonnes. [3] [4] [16]

Comment convertir un format de nuage de points XYZ en E57 ou LAS/LAZ sans inventer les métadonnées manquantes ?

Consignez d’abord les unités, le SCR, le mappage des colonnes et la signification des attributs. La conversion peut remapper les colonnes et joindre les métadonnées que vous fournissez, mais elle ne peut pas reconstruire un contexte absent qui n’a jamais été stocké dans le fichier XYZ. E57 et LAS sont des cibles utiles parce qu’ils peuvent préserver une structure plus riche une fois ces informations connues. [10] [11] [12] [9]

Un nuage de points XYZ est-il identique à un maillage ?

Non. Un nuage de points XYZ est une liste de points. Un maillage nécessite une topologie telle que des faces ou une connectivité, que le format XYZ brut n’encode pas. [1] [14]

Sources

1. Bibliothèque du Congrès — Nuage de points XYZ (fdd000617). https://wwws.loc.gov/preservation/digital/formats/fdd/fdd000617.shtml
2. Safe Software (FME) — Lecteur/éditeur Point Cloud XYZ. https://docs.safe.com/fme/html/FME-Form-Documentation/FME-ReadersWriters/pointcloudxyz/pointcloudxyz.htm
3. PDAL — readers.text. https://pdal.org/en/latest/stages/readers.text.html
4. Open3D — E/S de fichiers (xyz/xyzn/xyzrgb/pts). https://www.open3d.org/docs/latest/tutorial/geometry/file_io.html
5. John Burkardt — Fichiers XYZ. https://people.math.sc.edu/Burkardt/data/xyz/xyz.html
6. Wisconsin Institute for Discovery (vizHOME) — Format de fichier XYZ / XYZRGB. https://pages.discovery.wisc.edu/vizhome/documentation_file_format.html
7. ROCK Robotic Help Center — Format d’import ASCII XYZ. https://learn.rockrobotic.com/xyz-format
8. Autodesk ReCap Help — Formats de fichiers pris en charge. https://help.autodesk.com/view/RECAP/ENU/?contextId=supported_file_formats
9. Autodesk ReCap — Prise en charge de l’export E57 (spécification technique). https://help.autodesk.com/cloudhelp/ENU/Reality-Capture/files/Saving_Exporting_Your_Project/export_e57_technical_specifications.html
10. Bibliothèque du Congrès — Format de fichier ASTM E57 3D (E57). https://www.loc.gov/preservation/digital/formats/fdd/fdd000563.shtml
11. Daniel Huber (CMU) — Le format de fichier ASTM E57 pour l’échange de données d’imagerie 3D (PDF). https://www.ri.cmu.edu/pub_files/2011/1/2011-huber-e57-v3.pdf
12. Bibliothèque du Congrès — Format de fichier LAS (LASer), version 1.4 (fdd000418). https://wwws.loc.gov/preservation/digital/formats/fdd/fdd000418.shtml
13. ASPRS — Spécification LAS 1.5 R00 (PDF). https://lasformat.org/_/downloads/en/latest/pdf/
14. Documentation PCL — Format de fichier PCD. https://pcl-docs.readthedocs.io/en/latest/pcl/doc/tutorials/content/pcd_file_format.html
15. Documentation Open Babel — Format de coordonnées cartésiennes XYZ chimiques. https://openbabel.org/docs/FileFormats/XYZ_cartesian_coordinates_format.html
16. Manuel utilisateur CloudCompare v2.1 (miroir PDF). https://cloud.sdsc.edu/v1/AUTH_opentopography/www/shortcourses/13SCEC_course/Documentation_CloudCompare_version_2_1_eng.pdf
17. Documentation PyMeshLab — Liste des formats E/S. https://pymeshlab.readthedocs.io/en/2021.7/io_format_list.html
18. Tychola et al. 2024 — revue systématique sur les nuages de points 3D. https://link.springer.com/article/10.1007/s00371-023-03237-7