Je démarre un nouveau projet: une bibliothèque de type boite-à-outils pour aider à la création d'applications sur le sujet de la SfM.

Sujet passionnant me dira t'on, mais qu'est-ce que c'est?

SfM ou Structure from Motion regroupe un ensemble de techniques, méthodes et algorithmes pour permettre d'obtenir une modélisation numérique tridimensionnelle d'une scène, à partir du mouvement de région et/ou de points de cette scène.

En général cette scène bidimensionnelles d'un environnement réel filmé par une ou plusieurs caméras mobiles: dans la succession d'image bidimensionnelles, on va retrouver une modélisation tridimensionnelle de la scène, ainsi que du mouvement de la ou des caméra(s).

C'est un sujet activement étudié par beaucoup de laboratoires de recherche en vision, robotique ou simplement mathématique. On retrouve des travaux sur le sujet dès les années 80-90, lancés par l’essor de la robotique et de l'arrivé des caméras numérique.

Depuis les algorithmes ont très évolués, en efficacité et en performance, au point de retrouver des applications interactives de réalité augmentée (une des applications phares du sujet) pour les téléphones mobiles de Mr-tout-le-monde.

Je suis intéressé par le sujet et je le suis depuis quelques années déjà, mais malgré ces années un problème subsiste: c'est encore un monde trop réservé à la recherche.
Les algorithmes sont complexe et leur implémentations souvent très… orienté recherche: utilisation massive et quasiment unique du C++ (voir pire: Matlab, fortran, …), pas de gestion fiable des ressources (bibliothèques idéalistes ne tenant pas compte du système où elles seront utilisés), etc.

En gros les chercheurs dans ce domaine ne sont pas souvent les meilleurs informaticiens et leur recherche d'optimisation se restreins uniquement à celle de la diminution de la complexité mathématique. Et si cela ne suffit pas, on ne cherchera pas à savoir ce qui cloche avec le code pour baisser la quantité de traitement, mais on cherchera plutôt à augmenter la vitesse de traitement en utilisant du matériel dédié au calcul spécifique (et donc plus rapide) comme les GPU.
Dommage que l'on tombe dans le même problème que toutes les applications complexes actuelles: si elles sont trop lente sur un CPU donnée… augmentons la vitesse du CPU car c'est pas la faute du code!

Bien qu'une certaine industrialisation existe (existence de logiciels de traitements vidéo connus), leur code étant complètement fermé ne permet pas de connaître des implémentations ad-hoc optimales, souvent faite par des experts dans leur domaines (ici l'informatique).

On retiendra de tout ceci que l'informatique appliquée n'est pas le monde de celle de la recherche fondamentale.
Etant plus orienté “pratique” que “théorique” voilà pourquoi je débute ce projet de reprendre les algorithmes actuels et de leur faire, passer moi l'expression, sortir leurs tripes!

Comme dit précédemment il existe déjà beaucoup d'implémentations avec une algorithmie fiable et performante. De plus elle est souvent disponible sur la toile. Le hic étant que ces implémentations sont faite à 85% en C++, de la façon la plus générique possible (code STL, regroupé en fichiers .h, impossible à optimiser pour un système précis).

Donc mes débuts, hormis de comprendre les méthodes de la SfM, serons de faire une recherche de ces implémentations et de les ré-écrire pour être plus manipulables.

Ce titre est idoine à une situation bien actuelle dans l'informatique: on recherche à ne pas perdre du temps à “écrire du code” pour implémenter un concept et pour ce faire on va utiliser toutes les sucreries données par les langages modernes, en particulier celle du C++, que je trouve personnellement les plus odieuses!

Le principe du C++ est de ne pas payer pour ce que l'on ne veut pas.
Bien beau principe malheureusement mal employé, voir complètement raté. Pour faire simple, on part d'un concept purement mathématique que l'on va écrire sous forme informatisée génériques où les valeurs numériques ne sont pas typées dans l'écriture du code. Mais déjà le premier problème arrive: le C++ c'est fortement typé!
C'est pas grave, on a inventé l'écriture STL pour ça! Et voilà comment on commence à aller contre nature.

Ensuite on écrit tout dans des .h, même du code perfomant¹⁾, on casse donc la méthode d'utilisation du langage.
Finalement on se retrouve à compiler un unique fichier .cpp, action qui peut²⁾ prendre un temps certain avec comme résultat un fichier monstrueux! J'ai pour exemple la bibliothèque FLANN totalement écrite en C++ et templates à gogo, dont le fichier, unique certe, contenant toutes les fonctions d'accès en C qui se compile avec un CPU occupé 100% pendant plus de 5 minutes! On espère alors de ne pas à avoir à refaire cela souvent pour la moindre virgule oubliée ou erreur d'algorithme… et en plus pour obtenir un fichier de 28Mo (symboles de debug inclus certe, mais la section de code n'est pas petite, encore 3Mo si on garde que la partie utile).
On est bien loin de l'esprit initial³⁾.

Alors quel est l’intérêt du C++?: apporter un ensemble syntaxique⁴⁾ pour faciliter la programmation orientée objet (POO).

Mais rappelons fortement que cette dernière n'est pas une syntaxe, mais un concept méthodologique!

Cela veut dire qu'on fait de la POO avec n'importe quel langage suffisamment fournis. De la POO avec de l'assembleur c'est long et difficile mais c'est parfaitement possible et fonctionnel!

Bon je n'irai pas jusque là, et je me contenterai du C qui apporte tout ceci:

• facile d'emplois et de manipulation.
• compilable, donc exécution rapide.
• compilateurs maintenant très performants dans l'optimisation de ce type de code.
• déverminage facile!

Par contre il en coûtera un peu plus de temps d'écriture⁵⁾, mais si on s'applique et que l'on suit des règles strictes, ce langage apportera finalement plus en points positifs que n'importe quel autre plus évolué.

• une bibliothèque d'outils qui va me permettre de simplifier l'écriture d'applications.
• une API pragmatique et logique qui n'implique pas son utilisateur d'être poing et main lié avec elle.
• suffisamment modulaire pour pouvoir proposer plusieurs implémentation de la même fonctionnalité en vue d'utiliser des co-processeurs comme GPU ou unités vectorielles (SIMD).

• des centaines de dépendances externes toutes ayant leur propres méthodologies et usages.
• ni d'une usine à gaz pesant 100Mo à charger en mémoire, car elle peut manipuler tous les types possibles.
• cette bibliothèque n'est pas pour un usage scientifique, elle ne contiendra pas une API exhaustive de manipulation de données sur N dimensions. Elle n'est pas un sujet de recherche.

• ce qui est du domaine mathématique utilisera la programmation fonctionnelles classique.
• ce qui est du domaine d'interface pourra être implémenté en POO.
• le C doit être utilisé en langage primaire: une routine optimisée SIMD doit avoir en premier lieu ça version en C pour pouvoir être comparée et vérifiée.
• de même l'API sera suffisamment simple pour être utilisable dans d'autre langages de plus haut niveau, comme C++ ou Python:
  • aucune fonction avec plus de 8 paramètres, sinon passer par un pointeur sur une structure.
  • les exceptions sont gérées par le retour d'une valeur particulière, pas d'utilisation de globale comme errno.
• le code sera segmenté et compilé dans la mesure du possible dans un maximum de fichiers objets pour permettre une intégration statique au besoin et ne pas alourdir les applications.
• le code sera écrit de façon à ne pas être dense, la lecture d'une ligne du code doit être explicite dans ça fonctionnalité et non pas implicite.
• les structures de données seront utilisées à bon escient de façon à permettre une utilisation OO aisée aux besoins futurs.
• les implémentations doivent se tenir à être parfaitement utilisable dans un contexte parallélisable (point de variables globales, sauf constantes) et multi-utilisateurs.
• on ne mélange pas tout: une fonctions manipulant des données ne les affiche pas à l'utilisateur.
• si une fonction peut retourner une valeur d'erreur alors on vérifie les valeurs retournées⁶⁾!