L'IA peut-elle réparer déchirures et rayures ? Chiffres de faisabilité

Oui, et cet article consigne les mesures qui l'ont fait passer d'un espoir de feuille de route à une fonction en production : ce que le pipeline faisait auparavant aux scans abîmés, les chiffres de la preuve de concept qui ont justifié la construction de l'étape, et les résultats de bout en bout de la version qui tourne désormais derrière la case « Réparer rayures et déchirures ».

Ce que le pipeline faisait à une photo déchirée, avant

La restauration n'avait pas d'étape d'inpainting : rien qui puisse retirer une zone et en synthétiser un remplacement. Vérifié sur un portrait fortement craquelé : à l'intérieur des zones de visage, les dommages disparaissaient incidemment (le modèle de visages resynthétise tout le recadrage) puis réapparaissaient brutalement à la frontière de fusion, une craquelure qui s'arrête à la joue, ce qui peut paraître pire qu'aucune réparation. Partout ailleurs, les dommages étaient accentués : la passe de netteté avivait les bords des déchirures comme s'ils étaient des détails, et le modèle de colorisation teintait les lignes blanches des craquelures comme du contenu de la scène.

Preuve de concept

Sujet de test : un portrait noir et blanc de 510×817 avec un réseau de craquelures dans l'émulsion. Matériel : un bac à sable délibérément faible, CPU seul, si bien que chaque temps est un pire cas. Deux étapes : un réseau de détection des rayures (issu du projet open source « Bringing Old Photos Back to Life » de Microsoft^[2]) produit un masque des dommages ; le modèle d'inpainting LaMa^[1] remplit ensuite seulement les zones masquées, par tuiles de 512 px, les deux sur le fournisseur CPU d'ONNX Runtime^[3].

Le masque des dommages couvrait 18,4 % des pixels sur cette photo fortement abîmée. Résultat qualitatif : le réseau de craquelures a été retiré sur le visage, les vêtements et l'arrière-plan, sans faux positif dommageable : la nappe en dentelle, le piège classique des détecteurs de rayures, a survécu.

Ce qui a été livré, mesuré de bout en bout

L'étape de production s'exécute en premier dans l'ordre de restauration, pour que les craquelures ne soient jamais colorisées ni accentuées avant leur retrait. La détection tourne à un petit côté de 256 avec une dilatation du masque de 2 px ; l'inpainting se fait par zones à la résolution native, plafonné à 12 zones par photo, les plus grandes régions abîmées l'emportant. Deux invariants sont imposés plutôt qu'espérés : seuls les pixels masqués sont jamais écrits (chaque pixel intact de la sortie est identique octet pour octet à l'entrée) et un garde-fou de couverture saute entièrement l'étape quand la zone détectée est inférieure à 0,5 % (rien qui vaille une réparation) ou supérieure à 35 % (plus probablement une texture mal détectée que des dommages).

Une révision de production ultérieure a ajouté un second discriminateur, plus fin, au garde-fou automatique : la forme. La couverture seule ne peut pas distinguer une déchirure capillaire du bruit du détecteur, mais leur géométrie diffère d'un ordre de grandeur : une déchirure est longue et fine, le bruit est fait de taches. Pour chaque composante connexe du masque, de boîte englobante b_w×b_h et d'aire en pixels A, nous calculons

Points de calibration du banc : un visuel marketing propre obtient une élongation maximale de 2,4 ; le scan au réseau de craquelures obtient 29,8. Le seuil de 6 se tient bien à l'écart des deux, et chaque exécution en production journalise sa couverture et son élongation, pour que le garde-fou continue d'être réglé sur du trafic réel plutôt que sur deux photos.

Deux contrôles : avec la case décochée, l'étape ne s'est jamais exécutée et les temps ont correspondu exactement au pipeline précédent. Sur une photo presque propre, le détecteur n'a signalé que les 0,81 % de pixels réellement abîmés (craquelures résiduelles dans les coins et poussière) avec zéro faux positif sur les visages, la dentelle ou les textures.

Pourquoi c'est optionnel plutôt qu'activé par défaut

Le mode d'échec connu de la réparation automatique des dommages, ce sont les faux positifs : un détecteur qui signale des fils de clôture, des mèches de cheveux ou de la dentelle comme des rayures effacera du contenu réel, et un inpainter est très doué pour effacer. Deux photos de contrôle sont des indices, pas un banc d'essai. L'étape est donc livrée derrière une case à cocher explicite, et chaque exécution journalise sa couverture des dommages pour que les seuils puissent être réglés sur du trafic réel avant toute promotion en défaut. Nous avons aussi rejeté le raccourci consistant à envoyer les photos à une API générative d'images externe : cet outil traite les photos de façon transitoire sur notre propre infrastructure, et un re-rendu génératif complet fait dériver l'identité ; le but est de réparer les dommages, pas de repeindre ton parent.