Dépannage de WBPP : erreurs fréquentes et bugs connus
Cet article est compilé à partir de notes prises entre 2022 et 2025 ; certains outils ou flux de travail ont depuis été mis à jour, gardez-le donc à l’esprit pendant votre lecture ; les messages d’erreur et les comportements liés aux versions mentionnés dans le texte sont tous consignés tels qu’ils étaient à l’époque. Pour l’interface de WBPP, les masters de calibration et le déroulement normal de l’exécution, reportez-vous à l’autre article « Le guide complet de WBPP ».
Lancer WBPP d’un bout à l’autre d’un seul clic est certes jouissif, mais quand on l’utilise pour de vrai, on tombe toujours sur des situations où ça bloque, ça renvoie des erreurs, ou le résultat n’a pas l’air correct. Cet article regroupe les catégories de problèmes de WBPP que j’ai rencontrées ces dernières années — et sur lesquelles on m’interroge le plus souvent — en un manuel de dépannage, depuis l’état d’esprit du diagnostic jusqu’à quelques bugs connus concrets.
Première étape du dépannage : d’abord regarder la Process Console
Quand un traitement dans PixInsight pose problème, la première chose à laquelle vous devez penser est toujours de consulter la Process Console. Elle vous indique où l’erreur s’est produite et de quel type d’erreur il s’agit ; c’est le point de départ de tout diagnostic.
Cependant, WBPP est un script, et tant que le script n’est pas en cours d’exécution, la console est repliée et ne peut pas être sélectionnée. Aussi, pour voir la console, il faut souvent fermer d’abord WBPP. Cela paraît fastidieux, mais c’est pour bien des problèmes la seule source d’indices — la résolution de plusieurs des bugs qui suivent a commencé, tout entière, par cette ligne de texte rouge dans la console.
Échecs et bugs de la phase de calibration
Calibration échouée (failed) — fermez d’abord PI puis rouvrez-le. Si, en exécutant WBPP, la calibration initiale (qui utilise les masters de calibration) échoue d’emblée et que le status affiche un failed en rouge, vous pouvez mettre en pause tout le flux, fermer PI puis rouvrir WBPP et l’exécuter une nouvelle fois ; cette erreur de calibration échouée disparaît alors généralement. En traitant des images OSC, j’ai rencontré ce bug au moins quatre fois, et à chaque fois je l’ai résolu avec cette astuce.
Les flats échouent sans cesse la calibration — revenez au traitement manuel, étape par étape. Certaines versions de WBPP ont un bug qui fait échouer encore et encore la calibration des flats. Dans ces cas-là, savoir traiter soi-même, pas à pas, devient important. Profitons-en pour réviser les étapes du Pre-Process :
- Calibration :
light − dark / ((flat − flat dark) * med(flat)) - Cosmetic Correction
- Debayer : interpoler sur la matrice de Bayer
- Star Alignment
- NSG
- Integration
Quand on ne peut pas se fier à l’automatisation, décomposer le flux et l’exécuter à la main permet au contraire de repérer plus facilement à quelle étape se situe le problème.
Problèmes de chemin : deux causes possibles d’un File I/O Error
En utilisant WBPP sous Windows, si la phase de calibration (calibration) fait surgir un File I/O Error, c’est généralement l’une de ces deux causes :
- Le chemin du fichier plus le nom du fichier est trop long et dépasse la limite du système, il faut donc le raccourcir.
- Le dossier de destination n’est pas accessible en écriture, par exemple si vous placez la sortie dans un dossier système.
La première est la plus fréquente. Pour guérir « chemin trop long » à la racine, vous pouvez activer sous Windows la prise en charge des chemins longs (dans l’Éditeur du Registre (regedit), mettez LongPathsEnabled à 1) ; il est par ailleurs conseillé d’éviter les chemins contenant des caractères non ASCII (par exemple chinois). Les manipulations détaillées de ces deux prérequis d’environnement, je les ai décrites dans la section consacrée à la configuration de l’environnement Windows de « Le guide complet de WBPP », je ne les répète donc pas ici.
Le bug des coordonnées RA/DEC « 60 secondes non reportées »
C’est le problème le plus retors, et aussi celui qui mérite le plus d’être traité à part, car ses symptômes sont des plus variés alors que la cause profonde est toujours la même : dans le FITS Header, les coordonnées d’ascension droite / déclinaison présentent une valeur des secondes de « 60 » qui n’a jamais été reportée à la position suivante.
J’y ai été confronté deux fois, avec une manifestation différente chaque fois.
La première fois : WBPP ne parvenait pas à charger le fichier. J’ai fermé WBPP pour aller voir la Process Console, et j’ai découvert qu’une ligne d’un script js signalait « invalid coordinates ». Sur le moment, j’ai cru à un bug de WBPP ; j’ai pris le message d’erreur et je l’ai cherché sur Internet, et c’est seulement alors que j’ai trouvé sur le PixInsight Forum plusieurs signalements d’erreur identiques — il s’avérait que le problème de coordonnées empêchait l’image de se charger dans WBPP. Avec une direction en tête, il m’a tout de même fallu une heure pour fouiller parmi plusieurs centaines d’images brutes (lights) avant de débusquer l’image problématique : sa coordonnée OBJCTDEC était erronée. Dans PI, j’ai ouvert le processus FITSHeader, j’ai fait défiler jusqu’à OBJCTDEC, et j’ai modifié la valeur qui « aurait dû être reportée mais ne l’était pas » — dans cet exemple, en changeant -69 26 60 en -69 27 0 — et cette image s’est alors chargée sans souci, et les fichiers suivants n’ont plus été bloqués par elle.
La deuxième fois : impossible d’ajouter les fichiers, la console signalait too much recursion. Plus tard, ça m’est de nouveau arrivé : en ajoutant des fichiers à WBPP, le logiciel s’est figé et, au final, aucun fichier n’a été ajouté. J’ai fermé WBPP et, en regardant la Console, il y avait un InternalError: too much recursion rouge. Après avoir rouvert WBPP, j’ai constaté qu’une partie des fichiers était déjà chargée et une autre non ; en examinant ceux qui ne l’étaient pas, c’était bel et bien, encore une fois, une anomalie du FITS Header — cette fois DEC affichait -46 01 60, où les secondes « 60 » auraient dû être reportées en -46 02 00. Dès que WBPP lit une valeur anormale de ce genre, il se fige, et il entraîne en outre toutes les images suivantes, qui ne peuvent plus se charger non plus. De la même manière, j’ai ouvert le FITS Header et reporté les secondes à la main ; une fois corrigé, je n’ai eu qu’à ajouter de nouveau les fichiers. Quand tous les fichiers se chargent correctement, WBPP fait automatiquement apparaître un message de diagnostic, par exemple « 60 of 60 light frames were added ».
Une conclusion commune : ce problème de coordonnées qui ne se reportent pas automatiquement s’est, dans presque tous les cas que j’ai vus jusqu’ici, produit lorsque le logiciel de capture était MDL (contrôle à distance), même si je ne peux pas exclure que d’autres logiciels de capture présentent le même défaut. Ainsi, dès que WBPP se fige et que les fichiers ne s’ajoutent pas, consultez d’abord la Process Console pour confirmer le type d’erreur, puis vérifiez si le Header RA/DEC présente le bug des « 60 secondes non reportées » ; après une correction manuelle, c’est le plus souvent résolu.
Performances : pourquoi le grand pack complet est si long
Pour finir, parlons d’un problème qui, à proprement parler, n’est pas une « erreur » mais qui n’en est pas moins un supplice — le grand pack complet de WBPP est tout bonnement trop lent. J’ai un jour laissé le pack complet tourner quatre heures entières pour cinq images dont je voulais faire un HDR (la machine de l’époque était un AMD R5-4650G, DDR4 3200 32GB, SSD Gen4, avec des images de 24 mégapixels ; une attente pareille donne vraiment envie de changer d’ordinateur).
Deux endroits en particulier dévorent du temps :
- Separated RGB : traiter séparément les canaux RGB d’une photo couleur afin d’éliminer l’aberration chromatique.
- Local Normalization : choisir les quelques meilleures images comme référence et appliquer la Local Normalization aux autres.
Si vous désactivez ces deux-là, WBPP devient bien plus rapide. Faut-il les sacrifier au profit de la vitesse ? Cela dépend de vos exigences quant au produit fini — concernant les mesures concrètes de « quelles étapes désactiver, combien de temps on gagne et combien de qualité on perd », j’ai dans « Le guide complet de WBPP » un jeu de données montrant une accélération de 7 à 8 fois auquel vous pouvez vous reporter.
Résumons l’état d’esprit de ce manuel de dépannage : quand un souci survient, regardez d’abord la Process Console ; si la calibration donne failed, fermez PI et rouvrez-le ; si les flats échouent sans cesse la calibration, revenez au traitement manuel étape par étape ; un File I/O Error est le plus souvent un chemin trop long ou un dossier où l’on ne peut pas écrire ; et si les choses ne se chargent pas, se figent ou signalent recursion, allez vérifier si les RA/DEC du FITS Header ont une valeur des secondes de 60 non reportée. Maîtrisez bien ces quelques astuces et vous viendrez à bout de la plupart des humeurs de WBPP.