Résumé : qu’est-ce qu’un fichier PTS ?
Dans cet article, un fichier PTS désigne le format de nuage de points .pts : un fichier d’échange texte brut/ASCII pour des points 3D, et non un maillage, un modèle de surface ou un solide CAO. [1] [11]
En pratique, il est préférable de considérer PTS comme une convention largement utilisée plutôt que comme une spécification unique et rigide. Une convention documentée utilise un nombre de points sur la première ligne, suivi de sept valeurs par point, mais le comportement des importateurs, l’ordre des colonnes et la gestion des attributs varient selon les logiciels. Autodesk ReCap décrit également le format brut .pts comme un nuage de points non structuré, ce qui explique notamment pourquoi PTS contient généralement moins de contexte de numérisation et de métadonnées que E57. [1] [4] [14]
| Ce qu’il contient | Ce qui lui manque généralement | Problèmes courants | Meilleure étape suivante |
|---|---|---|---|
| Lignes ASCII de XYZ et, dans de nombreux flux de travail, données facultatives d’intensité et RGB. [1] [7] | Un schéma formel auto-descriptif, une structure de numérisation riche et des métadonnées de type E57. [4] [11] [14] | Mappage de colonnes erroné, confusion d’unités et incohérences de couleur/intensité. [1] [7] | Inspectez d’abord le texte, confirmez les unités et le SCR en externe, puis convertissez uniquement si le format cible apporte une structure dont vous avez réellement besoin. [4] [11] |
Que contient un fichier de nuage de points PTS (et pourquoi le « schéma » varie)
Une convention courante est simple : la première ligne stocke un nombre de points, et chaque ligne suivante stocke un point. nanoCAD documente exactement cette disposition pour une convention PTS, et l’option en ligne de commande -ADD_PTS_COUNT de CloudCompare montre que certains outils ajoutent activement le nombre de la première ligne pour assurer la compatibilité lors de l’enregistrement de nuages ASCII. [1] [10]
Après cet en-tête, la disposition courante est XYZ avec des attributs facultatifs, souvent l’intensité et RGB, mais cette disposition n’est pas obligatoire. L’analyseur ASCII de Leica Cyclone 3DR est délibérément flexible : il peut décoder X, Y, Z, I, R, G et B à partir d’un ensemble de nombres, ignorer les valeurs supplémentaires ou accepter des fichiers dans lesquels certaines valeurs sont absentes. C’est pourquoi deux fichiers PTS valides peuvent partager la même extension tout en nécessitant un mappage d’importation différent. [2] [7]
Un petit exemple schématique ressemble à ceci :
3
1.000 2.000 3.000 120 255 240 230
1.010 2.005 3.020 118 254 239 229
1.025 2.010 3.040 121 253 238 228
Exemple schématique uniquement — les exportateurs réels peuvent omettre ou ajouter des colonnes, ou utiliser un ordre différent. [7]
L’intensité et la couleur sont des attributs distincts, et leurs conventions numériques ne sont pas universelles. Dans le comportement d’importation PTS documenté par nanoCAD, RGB est attendu de 0–255 par canal et l’intensité importée est normalisée de 0–65535. Dans la documentation d’exportation PTX de Leica Cyclone, l’intensité PTX est de 0–1, et la même note KB indique que les PTS exportés par Cyclone peuvent utiliser des valeurs entières d’intensité de -2048 à 2047. Ces différences expliquent pourquoi il vaut mieux comprendre le « format PTS » comme une convention commune que comme une règle fixe suivie par tous les outils. [1] [2]
Structuré ou non structuré : ce qu’un fichier PTS ne préserve généralement pas
Autodesk ReCap décrit explicitement le format brut .pts comme un nuage de points non structuré. En pratique, cela signifie que le fichier peut préserver les points eux-mêmes tout en perdant les informations d’origine de numérisation dont certaines opérations en aval ont besoin, telles que l’organisation par numérisation, le point de vue du scanner ou la structure requise pour une segmentation tenant compte des numérisations et des flux de travail similaires. La propre note de ReCap sur l’export E57 structuré rend le contraste explicite en mentionnant les informations de lignes/colonnes et les transformations de recalage. [3] [4]
Il est également utile de distinguer les coordonnées de la signification du système de coordonnées. Un fichier PTS peut contenir des valeurs XYZ valides tout en laissant hors du fichier un contexte important, comme les unités, le SCR du projet, le datum, la stratégie de contrôle ou les notes de recalage. Le guide CAD Interop caractérise PTS/PTX comme de l’ASCII sans norme formelle et indique que le géoréférencement n’y est pas encodé nativement ; les rapports de relevé, les fichiers de contrôle et la documentation du projet comptent donc souvent autant que les lignes de points elles-mêmes. [5] [11]
La conversion ne peut pas recréer une structure de numérisation ou un historique de recalage qui n’a jamais été écrit dans la transmission. Si l’exportation a déjà aplati des numérisations structurées dans un PTS non structuré, une conversion ultérieure peut encore préserver les coordonnées et peut-être les attributs mappés, mais elle ne peut pas reconstruire de manière fiable les origines de numérisation manquantes, l’ordre lignes/colonnes ou le contexte de recalage antérieur. [3] [4]
PTS vs PTX vs E57 (ainsi que XYZ et LAS/LAZ) — que choisir
Pour la plupart des flux de travail réels, la question est en fait PTS vs E57 pour les nuages de points, avec un cas particulier : PTX, lorsque la pose par numérisation et la structure de grille de numérisation sont importantes. Le tableau ci-dessous résume les comportements documentés dans les sources citées de fournisseurs, de projets et de normes. [1] [2] [4] [11] [12] [13] [14]
| Format | Encodage | Ce qu’il peut bien transporter | Compromis courants |
|---|---|---|---|
| PTS | Lignes ASCII en texte brut. | Échange rapide d’un nuage unique et inspection manuelle ; XYZ, intensité et RGB facultatifs par convention. | Aucune norme publiée formelle de type ASTM/ISO n’a été vérifiée dans les sources citées, et les outils en aval le traitent souvent comme non structuré. |
| PTX | ASCII avec en-têtes par numérisation. | Exportations basées sur les numérisations avec lignes, colonnes, pose du scanner et transformations. | Texte toujours volumineux, et les conventions documentées ici pour les mètres/l’intensité relèvent du comportement d’exportation Cyclone plutôt que d’une règle universelle. |
| E57 | Fichier hybride avec un petit en-tête binaire, des sections binaires et une hiérarchie XML. | Échange standardisé de nuages de points, d’attributs tels que couleur/intensité et d’images 2D. | Moins lisible par l’humain que l’ASCII brut et plus complexe qu’un export texte plat. |
| XYZ / LAS / LAZ | Cibles ASCII plus simples ou binaires compactes de type relevé, selon le format. | Échange minimal de coordonnées ou livraison en aval plus compacte. | Généralement moins transparents que le texte PTS, et ne remplacent pas une structure de numérisation manquante. |
PTS est l’option la moins contraignante. Une convention documentée consiste en un nombre sur la première ligne suivi de X Y Z intensity R G B, mais aucune norme publiée formelle de type ASTM/ISO pour PTS n’a été vérifiée dans les sources citées. [1] [11]
PTX est la branche ASCII structurée la plus étroitement liée aux exportations de numérisations terrestres. La documentation PTX de Leica Cyclone décrit des sections par numérisation avec le nombre de colonnes, le nombre de lignes, la position et les axes enregistrés du scanner, ainsi qu’une matrice de transformation 4×4. Dans ce même contexte Cyclone, les coordonnées PTX sont exportées en mètres, l’intensité PTX utilise 0–1 et PTX peut contenir un ou plusieurs nuages de numérisation. [2]
E57 est différent par nature. Le comité E57 d’ASTM répertorie ASTM E2807 comme la spécification d’échange de données d’imagerie 3D, libE57Format décrit E57 comme stockant des nuages de points avec leurs attributs associés et des images 2D, et la présentation de Huber explique que l’architecture du fichier utilise un en-tête de 48 octets, des sections binaires facultatives et une hiérarchie XML plutôt que des lignes de points ASCII en texte brut. [12] [13] [14]
Le choix dépend donc surtout de la quantité de sens qui doit survivre à la transmission. Utilisez PTS lorsque la lisibilité et l’interchange rapide suffisent, PTX lorsque la pose du scanner et le contexte de grille de numérisation importent dans un flux de travail ASCII, et E57 structuré lorsque vous souhaitez un conteneur d’échange plus standardisé pouvant préserver un contexte plus riche. LAS/LAZ et XYZ doivent plutôt être compris comme des cibles de flux de travail répondant à des besoins spécifiques en aval, et non comme des remplacements directs de l’historique structuré des numérisations. [2] [3] [4] [11]
Comment ouvrir des données de fichier PTS (visionneuse, CAO/BIM et CLI)
Puisque PTS est du texte, le flux de travail le plus sûr commence par une inspection, puis passe à une visionneuse, un outil CAO/BIM ou un pipeline CLI une fois la signification des colonnes connue. [3] [5] [9]
Liste de contrôle d’ouverture
- Conservez le fichier PTS original intact et effectuez vos essais sur une copie de travail. [4] [11]
- Inspectez la première ligne et le nombre de colonnes par ligne avant l’importation. [1] [10]
- Confirmez les unités et le SCR en externe à partir des notes du projet, du contrôle ou des livrables de relevé. [5] [11]
- Vérifiez le mappage de la couleur et de l’intensité, pas uniquement XYZ. [1] [7]
- Vérifiez si le nuage est déjà recalé ou unifié, ou si la structure numérisation par numérisation importe toujours. [2] [4]
- Alors seulement, enregistrez une copie de travail au format E57, LAZ, RCP/RCS ou dans un autre format en aval attendu par votre chaîne d’outils. [3] [6] [11]
Autodesk ReCap constitue une voie CAO/BIM courante, car son aide répertorie PTS parmi les formats d’importation et d’exportation, et la même page indique l’export E57 structuré avec des informations de lignes/colonnes et des transformations de recalage. Leica Cyclone 3DR répertorie .pts et .ptx dans la prise en charge de l’importation comme de l’exportation de nuages de points, aux côtés de E57, LAS et LAZ. FARO SCENE liste également PTS et PTX parmi ses formats d’exportation, et le tableau FILE I/O de CloudCompare inclut .pts parmi les formats de nuages de points ASCII qu’il peut lire et écrire. [3] [6] [8] [9]
Pour le travail CLI et par lots, readers.pts de PDAL lit les fichiers PTS de Leica Cyclone et déduit les dimensions des points texte. PDAL documente aussi les options default_srs et override_srs, utiles lorsque le fichier lui-même ne contient pas suffisamment de contexte de référence spatiale. L’option en ligne de commande -ADD_PTS_COUNT de CloudCompare est un autre indice pratique que le nombre de points de la première ligne est une fonctionnalité courante de compatibilité, et non une garantie universelle pour chaque fichier de nuage de points ASCII. [5] [10]
Flux de conversion : PTS vers E57, LAS/LAZ, PLY ou XYZ (deux cas)
Abordez la conversion selon deux cas : un nuage unique unifié, ou un ensemble de numérisations pour lequel le contexte structuré des numérisations reste important. Cette distinction importe davantage que l’extension de fichier seule. [3] [4]
Cas A — conversion d’un PTS unifié/non structuré (nuage unique)
Si la source est déjà un nuage unifié ou non structuré, la conversion consiste surtout à préserver les coordonnées et les attributs que vous pouvez mapper correctement. E57 structuré est généralement la meilleure cible pour l’archivage ou l’échange interplateforme, LAS/LAZ peut être le choix en aval plus compact pour les pipelines de type relevé, XYZ est la voie ASCII minimale lorsque seules les coordonnées comptent, et certains outils de nuages de points proposent également PLY comme autre cible d’exportation orientée géométrie. Avant l’enregistrement, validez les unités, le nombre de points et vérifiez si l’intensité ou RGB sont réellement présents dans les colonnes source plutôt que supposés par l’importateur. [3] [6] [9] [11]
Cas B — conversion d’ensembles de numérisations où les positions/la structure des numérisations importent
Si les positions de numérisation, l’ordre lignes/colonnes ou les transformations de recalage sont importants, PTS peut déjà être une mauvaise transmission. ReCap indique que le format brut .pts est non structuré, tandis que la documentation PTX de Cyclone décrit un en-tête par numérisation avec lignes, colonnes, axes et position du scanner, ainsi qu’une matrice de transformation 4×4. La note de ReCap sur l’export E57 structuré renvoie à la même distinction en mentionnant les informations de lignes/colonnes et les transformations de recalage. Dans la propre description de Cyclone, PTX est destiné aux nuages de numérisation maillés plutôt qu’aux nuages unifiés non ordonnés. Une fois ces relations absentes de l’export PTS, une conversion ultérieure ne peut pas les reconstruire. [2] [3] [4]
Risques de conversion à documenter
- Les unités peuvent ne pas être encodées ou évidentes, même lorsque les coordonnées elles-mêmes semblent correctes. [1] [11]
- Le SCR ou le géoréférencement peut se trouver hors du fichier ; les métadonnées associées sont donc importantes. [5] [11]
- L’échelle d’intensité peut changer entre les outils ; nanoCAD documente une normalisation de 0–65535 à l’importation, tandis que Cyclone documente l’intensité PTX comme 0–1 et indique une convention entière différente pour les PTS exportés par Cyclone. [1] [2]
- RGB peut être perdu si l’importateur attend des colonnes différentes ; le lecteur ASCII de Cyclone 3DR accepte plusieurs mappages de colonnes et des styles de jetons RGB à la fois 0–255 et 0–1. [7]
- Les métadonnées de recalage ou de pose du scanner peuvent être absentes dans PTS ; l’avertissement de ReCap sur le caractère non structuré de
.ptsest la limitation essentielle. [4] - Les grands fichiers ASCII sont lents et gourmands en mémoire ; un guide industriel donne à titre illustratif une taille d’environ 1 GB pour 10 million de points et environ 5–10× supérieure à E57 ou LAZ, mais ce chiffre dépend de la précision, des espaces et des attributs écrits. [11]
Problèmes courants lors de l’importation de PTS (et correctifs rapides)
Si le nuage est importé à la mauvaise échelle, suspectez d’abord les unités. La convention PTS courante documentée par nanoCAD décrit les lignes de points et les attributs, mais pas un système d’unités embarqué universel, et le guide CAD Interop avertit que le géoréférencement n’y est pas encodé nativement. La solution rapide consiste à vérifier une distance connue ou un point de contrôle, puis à définir explicitement les unités et la référence spatiale dans l’importateur ou le pipeline au lieu de faire confiance aux valeurs par défaut. Les options SRS de PDAL sont utiles précisément parce que ce contexte peut devoir être fourni hors du fichier. [1] [5] [11]
Si la couleur est absente ou manifestement erronée, suspectez le mappage de colonnes. Cyclone 3DR peut décoder RGB comme des entiers de 0–255 ou comme des flottants de 0–1 selon les jetons de format, tandis que nanoCAD documente une convention RGB 0–255 pour son importation PTS. Si l’importateur devine le mauvais ordre de colonnes, la couleur peut disparaître, décaler les canaux ou être interprétée comme tout autre chose. La correction consiste à inspecter les premières lignes et à mapper manuellement les champs si le logiciel le permet. [1] [7]
Si l’intensité semble délavée ou écrêtée, suspectez une incompatibilité de plage plutôt qu’une mauvaise géométrie. nanoCAD normalise l’intensité importée de 0–65535, Cyclone PTX utilise 0–1, et la KB de Cyclone indique une convention entière différente pour les PTS exportés par Cyclone. Les mêmes valeurs de points peuvent donc s’afficher très différemment selon les visionneuses. Si le fichier ne s’importe pas ou prend trop de temps, rappelez-vous que l’ASCII brut est volumineux : la valeur d’environ ~1 GB par 10 million de points du guide CAD Interop est illustrative, et non universelle, mais elle aide à expliquer pourquoi les très grands fichiers PTS sont plus lents à analyser que les alternatives binaires compactes. [1] [2] [11]
Pourquoi PTS apparaît encore dans les flux de travail modernes (et quand il est pertinent)
PTS perdure parce qu’il est transparent et reste largement pris en charge comme format d’échange ASCII. PDAL dispose d’un readers.pts dédié, CloudCompare lit et écrit .pts comme données de nuage de points ASCII, Leica Cyclone 3DR répertorie la prise en charge de l’importation et de l’exportation .pts, et FARO SCENE liste PTS/PTX parmi ses formats d’exportation. Cela rend PTS utile comme format de débogage, de transmission ou de type « ouvrez-le et inspectez-le », même lorsqu’il n’est pas le meilleur format d’archive à long terme. [5] [6] [8] [9]
La tendance plus large de l’échange et de l’archivage s’oriente toutefois vers E57. Le comité E57 d’ASTM répertorie E2807 comme norme d’échange de données, libE57Format décrit E57 comme stockant des nuages de points avec leurs attributs et des images 2D, et la présentation de Huber explique la conception hybride XML/binaire, plus auto-descriptive et plus efficace en stockage que l’ASCII plat. Aucune année d’origine fiable pour PTS n’a été vérifiée dans les sources citées. [12] [13] [14]
Quand utiliser un fichier PTS — et quand le convertir
Utilisez un fichier PTS lorsque l’objectif est une inspection rapide ou un échange simple, que l’émetteur et le destinataire s’accordent déjà sur la disposition des colonnes, et que les unités ou le SCR sont documentés ailleurs dans le projet. C’est la zone de confort du format : transmissions temporaires, résolution de problèmes et livraisons de nuages uniques où le texte lisible compte davantage que la structure embarquée. [1] [4] [5] [11]
Convertissez plus tôt lorsque vous avez besoin d’un comportement plus structuré, standardisé ou compact. E57 structuré est le choix le plus sûr lorsque les informations de lignes/colonnes et les transformations de recalage importent, PTX reste pertinent lorsque la pose de numérisation de type Cyclone doit survivre dans un flux de travail ASCII, et LAS/LAZ peut être la meilleure cible en aval lorsque le pipeline récepteur préfère des données compactes de type relevé. La règle pratique est simple : conservez PTS pour sa commodité, mais n’attendez pas de lui qu’il préserve un sens qui n’a jamais été encodé au départ. [2] [3] [6] [11] [12] [14]
FAQ
Qu’est-ce que le format de fichier de nuage de points PTS ?
Le format de fichier de nuage de points PTS est une méthode en texte brut/ASCII pour stocker des points 3D ligne par ligne. Une convention documentée utilise un nombre de points sur la première ligne suivi de lignes de points contenant XYZ, intensité et RGB, mais la documentation ASCII de Cyclone 3DR montre que les importateurs réels peuvent accepter des colonnes absentes, supplémentaires ou remappées. [1] [7]
Comment ouvrir des données de fichier PTS ?
La méthode la plus sûre consiste à inspecter d’abord le texte, puis à le charger dans un outil de nuage de points qui comprend le mappage ASCII. ReCap liste PTS en importation/exportation, PDAL fournit readers.pts, et CloudCompare lit et écrit .pts comme format de nuage de points ASCII. [3] [5] [9]
Nuage de points PTS vs E57 : lequel utiliser pour l’échange/l’archivage ?
Utilisez PTS lorsque vous avez principalement besoin d’un nuage texte lisible et rapidement transférable. Utilisez E57 lorsque vous avez besoin d’un format d’échange ou d’archive plus standardisé : Autodesk documente l’export E57 structuré avec informations de lignes/colonnes et transformations de recalage, ASTM ancre E57 avec E2807, et la documentation E57 décrit la prise en charge des données de points, attributs et images 2D dans un fichier hybride XML/binaire. [3] [12] [13] [14]
Pourquoi mon PTS est-il importé à la mauvaise échelle ?
Habituellement parce que les unités ou la référence spatiale ont été supposées, et non vérifiées. La convention courante de lignes PTS ne résout pas à elle seule l’échelle ou le SCR, et les options SRS documentées de PDAL rappellent que ce contexte peut devoir être appliqué en externe. Vérifiez une distance connue, confirmez les unités du projet et confirmez le système de coordonnées prévu avant de convertir à nouveau. [1] [5] [11]
Expert : pourquoi certains outils traitent-ils PTS comme « non structuré », et que perds-je par rapport à PTX/E57 structuré ?
Parce que PTS n’est souvent qu’un export plat de points. ReCap qualifie explicitement le format brut .pts de non structuré, tandis que la documentation PTX de Cyclone décrit des lignes, colonnes, poses de scanner et transformations par numérisation, et que la note E57 structuré de ReCap mentionne les informations de lignes/colonnes ainsi que les transformations de recalage. Ce qui est généralement perdu avec un PTS aplati est le contexte d’origine de numérisation, l’ordre de la grille de numérisation et une partie de la signification du recalage. [2] [3] [4]
Expert : pourquoi l’intensité semble-t-elle erronée après conversion ?
Parce que les conventions d’intensité diffèrent selon les outils. nanoCAD documente une normalisation de 0–65535 à l’importation, Cyclone documente l’intensité PTX comme 0–1, et la même KB Cyclone indique une convention entière différente pour les PTS exportés par Cyclone. Si la visionneuse suppose la mauvaise plage, l’affichage peut sembler écrêté, plat ou incohérent même lorsque les coordonnées sont correctes. [1] [2]
Sources
- Aide sur les formats de données de nuages de points nanoCAD —
https://nanocad.com/learning/online-help/nanocad-platform/point-clouds-data-formats/ - PDF KB du format de fichier PTX Leica Cyclone —
https://nexus.hexagon.com/community/cfs-filesystemfile/__key/communityserver-discussions-components-files/735/PTX-File-Format.pdf?_=638615963512586589 - Formats de fichiers pris en charge par Autodesk ReCap —
https://help.autodesk.com/view/RECAP/ENU/?contextId=supported_file_formats - Support technique Autodesk ReCap : impossible de créer une géométrie à partir de nuages de points segmentés —
https://help.autodesk.com/view/RECAP/ENU/?caas=caas/sfdcarticles/sfdcarticles/Creating-geometry-from-segmented-Point-Clouds.html - Documentation de PDAL
readers.pts—https://pdal.io/en/stable/stages/readers.pts.html - Spécifications techniques Leica Cyclone 3DR —
https://rcdocs.leica-geosystems.com/docs/technical-specifications-cyclone-3dr-technical-specifications - Documentation d’analyse ASCII SCloud Script Leica Cyclone 3DR —
https://cyclone3dr.leica-geosystems.com/help/2025.0/Script/class_s_cloud.html - Formats d’exportation pris en charge par FARO SCENE —
https://knowledge.faro.com/Software/FARO_SCENE/SCENE/Export_Formats_Supported_by_SCENE - Wiki FILE I/O de CloudCompare —
https://www.cloudcompare.org/doc/wiki/index.php/FILE_I/O - Wiki du mode ligne de commande de CloudCompare —
https://cloudcompare.org/doc/wiki/index.php/Command_line_mode - Guide des formats PTS/PTX de CAD Interop —
https://www.cadinterop.com/en/formats/cloud-point/pts-ptx.html - Fiche d’information du comité E57 d’ASTM —
https://mcsdocs.astm.org/committee-documents/E57_Fact_Sheet_2019.pdf - Documentation du projet libE57Format —
https://github.com/asmaloney/libE57Format - Daniel Huber, « The ASTM E57 File Format for 3D Imaging Data Exchange » —
https://publications.ri.cmu.edu/storage/publications/pub_files/2011/1/2011-huber-e57-v3.pdf
