Suite à mon article précédent datant de 2024, j'ai réalisé une interface graphique qui permet une gestion plus fluide des processus de traitement d'image. Cette interface a été déployée sur mon serveur local puis rendue accessible via un tunnel (= reverse-proxy). Cependant, ce serveur doit exécuter un serveur X11 (Xorg) pour que l'inférence (= exécution d'un réseau de neurones entraîné pour en tirer un résultat) soit possible. Pour résumer, cela signifie qu'un écran lié au serveur soit allumé, ou que la variable d'environnement DISPLAY soit correctement initialisée. L'objectif était donc de ré-implémenter la chaîne actuelle des traitements d'images pour que l'exécution d'un tel serveur ne soit plus nécessaire. Cela permettra notamment l'inférence possible sur une machine en mode texte, ou utilisant le nouveau protocole d'affichage qui commence à être utilisé par défaut sur de nombreux bureaux Linux : Wayland.
Existant
Le processus d'inférence utilisé pour RelaxG est basé sur le logiciel open-source ChaiNNer et son GUI. Une chaîne de traitements d'image est ensuite exécutée en utilisant le mode CLI de ChaiNNer, expérimental, et necéssitant toujours un serveur X11 en cours d'exécution pour fonctionner. Le serveur local étant mon propre ordinateur, sur le plan matériel, la variable DISPLAY initialisée est passée dans le conteneur docker hôte de l'application. Le processus d'inférence est donc fonctionnel.
Implémentations possibles pour répondre au besoin
Pour répondre au besoin d'éliminer la nécessité d'initialisation de la variable DISPLAY, et donc pour ouvrir le support logiciel au protocol Wayland et au full-CLI, plusieurs choix étaient possibles :
- Développer un nouveau processus d'inférence en partant des fonctions et méthodes de PyTorch uniquement ;
- Extraire les fonctions et méthodes des traitements internes de ChaiNNer, tout en excluant les fonctionnalités GUI ;
J'ai sélectionné l'option 2, afin d'obtenir des résultats identiques aux (bons) résultats actuels. Cette décision est rationnalisée par une donnée supplémentaire que je vais exprimer en fin de paragraphe. Par curiosité, j'ai tenté de réaliser un processus d'inférence se basant sur la classe d'architecture RRDBNet du projet ESRGAN et sur les fonctions et méthodes de PyTorch (option 1), mais les résultats ne furent pas convaincants : Mauvaise gestion du tiling dans mon algorithme (= découpage de l'image en parts égales pour ne pas saturer la mémoire du GPU), et les poids du modèle .pth que j'utilisent ne correspondaient pas exactement à ceux attendus par la classe RRDBNet que j'ai utilisé. Pour gagner du temps sur la mise à disposition de la v2 de mon application sur GitHub, j'ai privilegié l'option 2 pour une raison supplémentaire aux résultats identiques : ChaiNNer a externalisé ses processus d'inférence dans une librairie nommée Spandrel, ce qui assure une certaine pérénnité de part le concept même du package. Si l'équipe de ChaiNNer a décidé de packager ces processus, c'est sûrement pour les maintenir indépendamment du GUI et pour que d'autres applications puissent en dépendre.
Résultat
Pour une image en entrée, une image traitée est produite à l'identique du processus d'inférence précédent. Le besoin de cette itération de développement est donc comblé.
Discussion et ouverture
Il conviendrait d'explorer les solutions pour intégrer le code python dans le reboot du projet RelaxG, ainsi que dans le projet RelaxG actuellement en production. Je pense à un package python, mais aussi à remplacer complètement le back-end Express.js par le nouveau backend Django et son système d'authentification personnalisé.