bunch of stuff
This commit is contained in:
parent
5960caaaa3
commit
25946fae17
BIN
assets/pvd-architecture.png
(Stored with Git LFS)
Normal file
BIN
assets/pvd-architecture.png
(Stored with Git LFS)
Normal file
Binary file not shown.
|
@ -24,3 +24,11 @@
|
||||||
month = {Feb},
|
month = {Feb},
|
||||||
url = {https://perceptron.blog/defusing-diffusion/}
|
url = {https://perceptron.blog/defusing-diffusion/}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@techreport{shapenet2015,
|
||||||
|
title = {{ShapeNet: An Information-Rich 3D Model Repository}},
|
||||||
|
author = {Chang, Angel X. and Funkhouser, Thomas and Guibas, Leonidas and Hanrahan, Pat and Huang, Qixing and Li, Zimo and Savarese, Silvio and Savva, Manolis and Song, Shuran and Su, Hao and Xiao, Jianxiong and Yi, Li and Yu, Fisher},
|
||||||
|
number = {arXiv:1512.03012 [cs.GR]},
|
||||||
|
institution = {Stanford University --- Princeton University --- Toyota Technological Institute at Chicago},
|
||||||
|
year = {2015}
|
||||||
|
}
|
||||||
|
|
104
src/paper.tex
104
src/paper.tex
|
@ -132,14 +132,14 @@
|
||||||
|
|
||||||
\newacronym{go}{Go}{Gigaoctet}
|
\newacronym{go}{Go}{Gigaoctet}
|
||||||
|
|
||||||
\newglossary{symbols}{sym}{sbl}{Notations mathématiques et symboles}
|
% \newglossary{symbols}{sym}{sbl}{Notations mathématiques et symboles}
|
||||||
|
|
||||||
\newglossaryentry{fn}{
|
% \newglossaryentry{fn}{
|
||||||
type={symbols},
|
% type={symbols},
|
||||||
name={\ensuremath{F_n}},
|
% name={\ensuremath{F_n}},
|
||||||
sort=fn,
|
% sort=fn,
|
||||||
description={Empirical (sample) distribution function}
|
% description={Empirical (sample) distribution function}
|
||||||
}
|
% }
|
||||||
|
|
||||||
\makenoidxglossaries
|
\makenoidxglossaries
|
||||||
|
|
||||||
|
@ -165,7 +165,7 @@
|
||||||
|
|
||||||
J'aimerais également remercier l'ensemble de mes professeurs de l'\gls{n7}, pour m'avoir permis d'acquérir les connaissances nécessaires à la réalisation de ce projet.
|
J'aimerais également remercier l'ensemble de mes professeurs de l'\gls{n7}, pour m'avoir permis d'acquérir les connaissances nécessaires à la réalisation de ce projet.
|
||||||
|
|
||||||
\gls{fn}
|
% \gls{fn}
|
||||||
}
|
}
|
||||||
|
|
||||||
\clearpage
|
\clearpage
|
||||||
|
@ -711,8 +711,7 @@ La stack technique utilisée par l'équipe est basée sur Python, avec des bibli
|
||||||
À la suite de ma recherche bibliographique, j'ai consacré du temps à expérimenter diverses implémentations des articles que j'avais identifiés. Voici la liste des implémentations que j'ai évaluées, les idées que j'ai explorées, ainsi que mes observations relatives à chaque approche, dans un ordre approximativement chronologique.
|
À la suite de ma recherche bibliographique, j'ai consacré du temps à expérimenter diverses implémentations des articles que j'avais identifiés. Voici la liste des implémentations que j'ai évaluées, les idées que j'ai explorées, ainsi que mes observations relatives à chaque approche, dans un ordre approximativement chronologique.
|
||||||
|
|
||||||
\FloatBarrier
|
\FloatBarrier
|
||||||
\glsunset{vae}
|
\subsection{Test de GraphVAE}
|
||||||
\subsection{Approche par \acrfull{vae}}
|
|
||||||
|
|
||||||
% parler du fait que pytorch geometric à facilité un peu la tache d'implem
|
% parler du fait que pytorch geometric à facilité un peu la tache d'implem
|
||||||
|
|
||||||
|
@ -738,23 +737,21 @@ Une seconde solution consitait à utiliser une architecture plus intelligente, t
|
||||||
Face aux difficultés rencontrées avec les réseaux basés sur les VAE et les limitations de l'architecture Graph U-Net, nous avons pris la décision de mettre de côté ces approches. Et plus largement puisque la connectivité de nos graphes est "locale" (les noeuds sont connectés à leurs voisins proches dans l'espace), nous avons décidé de nous orienter vers des approches basées uniquement sur les positions des noeuds. En effet, la connectivité d'un nuage de points peut facilement être retrouvé via diverses techniques~\cite{peng_shape_2021,sulzer_deep_2022}.
|
Face aux difficultés rencontrées avec les réseaux basés sur les VAE et les limitations de l'architecture Graph U-Net, nous avons pris la décision de mettre de côté ces approches. Et plus largement puisque la connectivité de nos graphes est "locale" (les noeuds sont connectés à leurs voisins proches dans l'espace), nous avons décidé de nous orienter vers des approches basées uniquement sur les positions des noeuds. En effet, la connectivité d'un nuage de points peut facilement être retrouvé via diverses techniques~\cite{peng_shape_2021,sulzer_deep_2022}.
|
||||||
|
|
||||||
\FloatBarrier
|
\FloatBarrier
|
||||||
\glsunset{nf}
|
\subsection{Test de PointFlow}
|
||||||
\subsection{Approche par \acrfull{nf}}
|
|
||||||
|
|
||||||
% Pointflow (à l'origine du dataset PointFlow, une modif de shapenet, code à chier)
|
L'approche la plus connue pour utilise des \glspl{nf} sur des nuages de points est PointFlow~\cite{yang_pointflow_2019}. Adapter l'implémentation originale afin d'y intégrer l'utilisation de Rotor37\_1200 s'est avéré être une tâche aisée, entraînant des résultats supérieurs à ceux obtenus par GraphVAE, bien que sans être exceptionnels. La structure du code s'est cependant révélée relativement diffusers à manipuler pour toute autre tâche plus complexe (comme souvent avec du code académique).
|
||||||
|
|
||||||
Pointflow est approche la plus connue pour faire du nf sur des nuages de points. Modifier l'implémentation originale pour pouvoir utiliser Rotor\_37 était facile, les résultats étaient meilleurs que ceux de GraphVAE, mais pas exceptionnels. L'architecture du code était également plutôt difficile à utiliser et à modifier, tel un bon code académique.
|
PointFlow a néanmoins apporté une contribution significative à la création d'un dataset de référence pour la génération de nuages de points, qui est actuellement exploité par de multiples articles de recherche. Ce jeu de données repose sur ShapeNet~\cite{shapenet2015}, un ensemble de données dédiée à une variété d'objets en trois dimensions (tels que des avions, des chaises, des voitures, etc.), modifié par Furthest Point Sampling pour contenir uniquement 2048 points par nuages.
|
||||||
|
De plus, PointFlow a joué un rôle essentiel dans l'implémentation de différentes métriques et distances en CUDA, telles que la \gls{cd}, l'\gls{emd}, et bien d'autres.
|
||||||
|
|
||||||
PointFlow aura tout de même contribué à la création d'un dataset de référence pour les nuages de points, qui est désormais utilisé par de nombreux articles de recherche. Ce dataset est basé sur ShapeNet, un dataset d'objets 3D, et a été modifié via un furthest point sampling. De même PointFlow aura contribué à l'implémentation en cuda des différentes méteriques et distances telles que la chamfer distance, la earth mover distance, etc.
|
% insérer ici résultats
|
||||||
|
|
||||||
\FloatBarrier
|
\FloatBarrier
|
||||||
\glsunset{vdm}
|
\subsection{Présentation de PointNet}
|
||||||
\subsection{Approche par \acrfull{vdm}}
|
|
||||||
|
|
||||||
Pour prédire le bruit dans le processus de diffusion, conformément à la section intitulée "État de l'art" dans ce document, il est essentiel de sélectionner une architecture de réseau de neurones. Dans notre cas, puisque nous travaillons sur nuages de points, il convient d'utiliser des architectures adaptées à ce type de données.
|
Dans le contexte de l'apprentissage sur les nuages de points, une architecture standard est PointNet. PointNet est une architecture basée sur des shared \glspl{mlp} (pouvant être envisagés comme des convolutions à noyau 1x1), qui permettent de traiter des nuages de points, indépendemment du nombre de points. Cette architecture présente un intérêt notable du fait de son invariance par permutation, ainsi que de sa résilience face à certaines transformations telles que les rotations et les translations.
|
||||||
|
|
||||||
Dans le contexte de l'apprentissage sur les nuages de points, une architecture standard est PointNet. PointNet est une architecture basée sur des shared MLPs (Multi-Layer Perceptrons, qui peuvent être vus comme des convolutions de noyau 1x1) qui permettent de traiter des nuages de points, indépendemment du nombre de points. archi interessante car permutation invariant, mais aussi robuste à certaines transformations comme les rotations et translations.
|
Par la suite, une avancée significative du modèle PointNet a conduit à l'émergence de PointNet++, qui est désormais reconnu comme l'architecture de référence dans ce domaine. PointNet++ propose une approche hiérarchique en profondeur qui combine judicieusement des techniques d'échantillonnage (telles que le Furthest Point Sampling) et d'agrégation (comme la recherche des K Nearest Neighbors) appliquées aux points du nuage. Cette approche vise à étendre la portée des opérations locales de manière à englober des champs réceptifs globaux, contribuant ainsi à l'amélioration des performances du réseau.
|
||||||
Par la suite, une amélioration conséquente du modèle PointNet a abouti à l'émergence de PointNet++, désormais considérée comme l'architecture de référence dans le domaine. PointNet++ présente une approche hiérarchique en profondeur qui capitalise sur une fusion de techniques d'échantillonnage (furthest point sampling) et d'agrégations (knn) des points du nuage. Cette approche permet ainsi d'élargir la portée des opérateurs locaux pour englober des champs globaux réceptifs, et ainsi améliorer les performances du réseau.
|
|
||||||
|
|
||||||
% insérer ici image archite pointnet et poitnet++
|
% insérer ici image archite pointnet et poitnet++
|
||||||
\begin{figure}[h!]
|
\begin{figure}[h!]
|
||||||
|
@ -764,10 +761,8 @@ Par la suite, une amélioration conséquente du modèle PointNet a abouti à l'
|
||||||
\label{fig:pointnet_archi}
|
\label{fig:pointnet_archi}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
% KPConv (c'est français, pas mal non ?)
|
\FloatBarrier
|
||||||
autre archi bien connue dans le traitement de point clouds, archi semblable à pointnet++, mais le sampling est fait via une grille de voxelle, et l'aggragation est faite via des KPConv, qui sont une ball query. c'est français
|
\subsection{Présentation des KPConv}
|
||||||
|
|
||||||
Une autre architecture largement reconnue dans le domaine du traitement de nuages de points, présentant des similitudes avec PointNet++, est nommée KPConv. Cette architecture utilise un échantillonnage basé sur une grille de voxels et l'opération d'agrégation par des KPConv, qui sont des convolutions sur boules. Cette architecture est également très efficace, et surpasse généralement les autres architectures sur les taches de segmentation.
|
|
||||||
|
|
||||||
\begin{figure}[h!]
|
\begin{figure}[h!]
|
||||||
\centering
|
\centering
|
||||||
|
@ -776,10 +771,17 @@ Une autre architecture largement reconnue dans le domaine du traitement de nuage
|
||||||
\label{fig:kpconv_archi}
|
\label{fig:kpconv_archi}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
Appliqué à de la diffusion, KPFCNN
|
Une autre architecture largement reconnue dans le domaine du traitement de nuages de points, présentant des similitudes avec PointNet++, est nommée KPConv. Cette architecture utilise un échantillonnage basé sur une grille de voxels et des opérations d'agrégation via des KPConvs, qui sont des convolutions sur boules. Cette architecture est également très efficace, et surpasse généralement les autres architectures sur les taches de segmentation.
|
||||||
|
|
||||||
% PVCNN (code à chier, basé sur pointnet)
|
\FloatBarrier
|
||||||
point voxel convolution, efficace, mais bcp de cuda
|
\subsection{Test de KPFCNN}
|
||||||
|
|
||||||
|
Dans notre situation, nous avons la possibilité d'opter pour le réseau KPFCNN, initialement conçu pour la segmentation, mais pouvant être ajusté pour la prédiction de bruit. À cette fin, nous faisons usage de la bibliothèque easy\_kpconv, laquelle met en œuvre les KPConv et nous autorise à maintenir un code clair et réutilisable. Lorsque nous l'entraînons sur le jeu de données rotor37\_1200\_mmd2048, nous obtenons des résultats hautement probants.
|
||||||
|
|
||||||
|
% insérer ici résultats
|
||||||
|
|
||||||
|
\FloatBarrier
|
||||||
|
\subsection{Présentation des PVConv}
|
||||||
|
|
||||||
\begin{figure}[h!]
|
\begin{figure}[h!]
|
||||||
\centering
|
\centering
|
||||||
|
@ -788,25 +790,49 @@ point voxel convolution, efficace, mais bcp de cuda
|
||||||
\label{fig:pvconv_archi}
|
\label{fig:pvconv_archi}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
% SPVCNN (torchsparse, pas réussi à faire marcher pour la diffusion)
|
Une seconde alternative aux opérations de convolutions et d'aggregation de PointNet++ sont les PVConvs. Les PVConvs proposent d'utiliser des voxels afin de retomber sur des structures régulières, permettant ainsi d'effectuer efficacement des convolutions classiques en 3D. Par conséquent, une PVConv est composée de deux branches distinctes. La première branche, appelée "coarse-grained", transforme les points en voxels, applique des convolutions, puis reconvertit les voxels en points à l'aide d'une interpolation trilinéaire. La seconde branche, nommée "fine-grained", est constituée de shared \glspl{mlp}. Ces deux branches sont ensuite combinées par sommation.
|
||||||
version plus efficace, mais pas trop réussi à faire marche, cuda très esotérique
|
|
||||||
|
|
||||||
% PVD (checkpoint, code à chier, trop chiant les opérations de voxelization devox en cuda + les métriques qui changent entre chaque papiers emd chamfer 1-NNA, en cuda aussi)
|
Ainsi, PVCNN se présente comme l'équivalent de PointNet, tandis que PVCNN++ équivaut à PointNet++. Il est à noter que la différence réside dans le fait que le nombre de points reste constant à chaque couche du réseau. Sur les benchmarks, PVCNN++ s'avère au moins aussi efficace que pointNet++ tout en étant bien plus efficace. Cependant PVCNN++ est plus complexe à implémenter, et nécessite l'utilisation plusieurs modules CUDA.
|
||||||
archi basée sur PointNet++, mais pas de sampling, juste des pvconv
|
|
||||||
|
|
||||||
% LION (pas de checkpoint, mais code utile)z
|
Par conséquent, PVCNN peut être considéré comme l'équivalent de PointNet, tandis que PVCNN++ correspond à PointNet++. Une distinction importante réside dans le maintien d'un nombre constant de points à chaque couche du réseau. Les benchmarks démontrent que PVCNN++ est au moins autant performant que PointNet++, tout en surpassant nettement ce dernier en termes d'efficacité globale. Cependant, il est important de noter que l'implémentation de PVCNN++ est assez complexe et nécessite l'utilisation de plusieurs modules CUDA (les opérations de voxelization et de dévoxelization étant impossible à écrire en Pytorch classique).
|
||||||
le plus récent
|
Il existe également une légère amélioration de PVConv nommée SPVConv, reposant sur des opérations de convolutions creuses. improvements, mais cuda très esotérique
|
||||||
|
|
||||||
à dire en plus, les metrics pour évaluer la qualité des nuages de points générés ne sont pas vraiment normalisées, changent d'un papier à l'autre, ou implem change d'un papier à l'autre.
|
\FloatBarrier
|
||||||
|
\subsection{Test de PVD}
|
||||||
|
|
||||||
%%% old stuff, merge with what's before
|
Le premier papier à utiliser une architecture du type PVCNN++ pour la générations de nuages de point est PVD. Si l'on récupère l'implémentation des auteurs et que l'on la modifie pour utiliser rotor37\_37\_mmd2048 on obtient de très bon résultat. Cependant, une bonne partie de la codebase étant basé sur celle de PVCNN++ et de PointFlow, celle-ci est tout aussi difficile à modifier.
|
||||||
|
|
||||||
Les premiers résultats concluant que nous avons obtenus ont été avec l'architecture KPFCNN. Cette architecture est basée sur PointNet++ et utilise des convolutions de type KPConv. Nous avons utilisé cette archi pour prédire le bruit lors de l'entraiment d'un \gls{vdm} (schedulers via huggingface diffusers). Les résultats étaient encourageants, mais nous avons constaté que le réseau avait du mal à apprendre à prédire le bruit en fin de sampling. en effet, les aubes finales semblaient encore un peu bruitées.
|
\begin{figure}[h!]
|
||||||
<insérer image ici>
|
\centering
|
||||||
|
\includegraphics[width=0.8\textwidth]{pvd-architecture.png}
|
||||||
|
\caption{Architecture de PVD~\cite{zhou_3d_2021}}
|
||||||
|
\label{fig:pvd_archi}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
\FloatBarrier
|
\FloatBarrier
|
||||||
\glsunset{ldm}
|
\glsunset{ldm}
|
||||||
\subsection{Approche par \acrfull{ldm}}
|
\subsection{Test de LION}
|
||||||
|
|
||||||
|
\begin{figure}[h!]
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=0.8\textwidth]{LION.jpg}
|
||||||
|
\caption{Architecture de LION~\cite{zeng_lion_2022}}
|
||||||
|
\label{fig:lion_archi}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
LION~\cite{zeng_lion_2022} représente l'architecture la plus récente en matière de génération de nuages de points, et constitue une amélioration par rapport à PVD. LION exploite la diffusion latente via un \gls{vae} à deux étapes pour comprimer les nuages de points avant d'appliquer le processus de diffusion.
|
||||||
|
Un premier encodeur transforme le nuage de points en un vecteur latent.
|
||||||
|
Un deuxième encodeur transforme le nuage de points original, en utilisant le vecteur latent comme conditionnement, afin de générer un nuage de points latent.
|
||||||
|
Ce nuage de points latent est ensuite décodé pour obtenir une reconstruction du nuage de point original.
|
||||||
|
Le processus de diffusion a lieu à la fois sur le vecteur latent et sur le nuage de points latent.
|
||||||
|
|
||||||
|
% insérer résultat
|
||||||
|
|
||||||
|
\FloatBarrier
|
||||||
|
\subsection{Synthèse des méthodes}
|
||||||
|
|
||||||
|
% obligé de faire ma propre implem car, les implems des papiers sont tellement chelou que comme on veut conditionner avec des scalaires, j'arrive pas à modifier leur code, donc je fais ma propre implèm.
|
||||||
|
% souvent trop de params pour le problème aussi
|
||||||
|
|
||||||
Pour essayer d'améliorer ces résultats, on peut apprendre à faire de la diffusion sur des variables latente, plutout que direct sur nos données. avantage, réduciton de dimension + informtion latente.
|
Pour essayer d'améliorer ces résultats, on peut apprendre à faire de la diffusion sur des variables latente, plutout que direct sur nos données. avantage, réduciton de dimension + informtion latente.
|
||||||
|
|
||||||
|
@ -814,8 +840,6 @@ dans un premier temps on compresse donc nos nuages de point via une PCA, ça mar
|
||||||
|
|
||||||
on test d'autres méthodes parameter free, comme la POD, marche moins bien
|
on test d'autres méthodes parameter free, comme la POD, marche moins bien
|
||||||
|
|
||||||
second temps, on compress nuages de points via un AE, pas encore finis, mais inch ça marche
|
|
||||||
|
|
||||||
\FloatBarrier
|
\FloatBarrier
|
||||||
\glsunset{cfg}
|
\glsunset{cfg}
|
||||||
\subsection{Application du \acrfull{cfg}}
|
\subsection{Application du \acrfull{cfg}}
|
||||||
|
|
Loading…
Reference in a new issue