Application de la segmentation sémantique 3D pour IASBIM

Dans un précédent article, nous avons eu l’occasion de découvrir KPConv_torch, l’outil de segmentation sémantique 3D exploité dans le cadre d’IASBIM. Ce nouvel article va être l’occasion de présenter des résultats concrets obtenus en utilisant cette bibliothèque Python.

Rappel: la nomenclature S3DIS

Les résultats présentés dans cet article exploitent un modèle entraîné à partir du jeu de données S3DIS. Ce jeu de données est constitué de 13 classes :

• plafond
• sol
• mur
• colonne
• poutre
• fenêtre
• porte
• table
• chaise
• bibliothèque
• canapé
• tableau
• divers

Les couleurs associées à ces différentes classes sont les suivantes, elles sont directement définies par le producteur du jeu de données :

Fig 1: nomenclature du jeu de données S3DIS

Le modèle KPConv entraîné à partir de ce jeu de données l’a été durant 100 époques, la métrique optimisée étant une adaptation de l’indice de Jaccard, où sont comparés l’ensemble des points prédits et l’ensemble des points réels.

*Fig 2: Indice de Jaccard, ou IoU (Intersection over Union)

Ici, on considère la moyenne de cet indice pour chaque classe sémantique, sur le jeu de données de validation (le plus gros des 6 nuages de points qui constitue le jeu de données). Les valeurs relevés pour cette métrique, pour le modèle retenu, sont les suivantes :

En substance, le modèle devrait parvenir à bien se comporter sur la détection des limites des pièces (sol, murs, plafond), mais devrait être un peu moins précis sur les accès (portes et fenêtres). La détection du mobilier n’est pas dans le périmètre de IASBIM, ces classes sont toutefois laissées en l’état dans le modèle par simplicité.

Environnement indoor

Le premier jeu de données correspond à un intérieur atypique fourni par un entreprise partenaire d’IASBIM, un plateau en chantier dans un environnement ressemblant à un entrepôt. Le nuage de point considéré est un fichier .xyz de 600Mo environ, pour un peu moins de 15 millions de points.

Fig 2: exemple de jeu de données indoor

En appliquant la routine d’inférence de KPConv_torch sur ce nuage de points, à partir du modèle entraîné évoqué précédemment, on obtient une nouvelle version sémantisée, après près de deux heures de calcul :

Fig 3: jeu de données sémantisé en contexte indoor

Comme imaginé au départ, les sols et les murs sont plutôt bien détectés (idem pour les plafonds, absents des copies d’écran). Le modèle a cependant un peu plus de mal à identifier l’emplacement exact des fenêtres. En réalité, ce n’est pas si surprenant : le modèle a été entraîné avec des données représentant des salles de cours et des amphithéâtres, dans une université. On peut aisément imaginer que l’environnement industriel présent ici est mal reconnu…

Environnement outdoor

Le deuxième exemple proposé dans cet article pousse encore un peu plus les limites du modèle, en mettant en scène un environnement essentiellement outdoor (le modèle a été entraîné sur des données indoor). Il s’agit d’un relevé effectué par Bimdata contenant un peu plus de 212 millions de points, dans un fichier de plus de 1.4Go au format .laz.

Fig 4: jeu de données sémantisé en contexte outdoor

Il nous a ici fallu presque 6h de calcul sur le serveur utilisé pour nos tests pour générer ce résultat. Quels enseignements tirer de l’exercice ? Encore une fois, les classes les plus “simples” (murs, toits, sols) apparaissent globalement correctes, alors que les emplacements des fenêtres sont imprécis. Cela dit, l’interprétation doit rester prudente, on note visuellement les limites de l’utilisation du modèle indoor sur une donnée de ce genre.

Cet exemple, au-delà de ces résultats, donne cependant un témoignage précieux au regard de la capacité de la bibliothèque Python à attaquer des gros nuages de points. Ces résultats peuvent également proposer une information capitale en aval, pour les procédures de reconstruction de surface construites par les acteurs du consortium IASBIM.

Perspectives

Le projet IASBIM nous a permis de proposer une solution de segmentation sémantique 3D prête à être industrialisée. De futurs travaux pourront être réalisés pour améliorer l’industrialisation du projet, en fonction des besoins exprimés par les clients de cette solution. En particulier, la question des performances pour l’opération d’inférence reste ouverte : passer de plusieurs heures à seulement quelques minutes (voire moins, si l’objectif est donné de procéder à des annotations en temps-réel) doit être un objectif pour les prochains jalons de la bibliothèque KPConv_torch.

Nous n’avons pas exploré les notions de transfer learning, ni cherché à réduire le nombre de classe par rapport à ce que propose S3DIS, cela constitue à notre sens un gisement pour améliorer les résultats présentés ici.

En outre, l’annotation de la donnée d’entrée est et reste la clé de voute d’un système de segmentation sémantique. Associer un outil d’annotation à un outil de visualisation apparaît comme le verrou technique et ergonomique principal dans cette quête. Cette question, bien qu’hors du périmètre de KPConv_torch, pourra être traitée dans des efforts ultérieurs de R&D. En accroissant la disponibilité des nuages de points annotés, nul doute que l’entraînement de modèles de segmentation via KPConv_torch sera d’autant plus profitable, pour une base d’utilisateurs potentiels plus importante.