Traitement en temps réel des données de PISCO

Le traitement des données en mode interférométrie des tavelures ou de restauration d’images

avec des méthodes bispectrales est assez lourd car il nécessite le calcul de transformées de

Fourier de chaque image élémentaire (voirAnnexe A). Lors de sa “découverte” de

l’interféro-métrie des tavelures, Antoine Labeyrie calculait les transformées de Fourier par un traitement

optique et l’intégration des spectres de puissance se faisait directement sur des émulsions

photographiques (Labeyrie,1970).

Si on prend le cas des images den= 128×128pixels que nous traitons avec PISCO, le

calcul avec l’algorithme de transformée de Fourier discrète rapide (FFT, Fast Fourier

Trans-form) (Cooley & Tukey, 1965) nécessite de l’ordre de5nlog

(n) = 1.15×10

opérations.

Le traitement en temps réel de 50 images par seconde (i.e., poses élémentaires de 20 ms),

nécessite alors un processeur d’au moins 50 mégaflops (flops : floating point operation per

second). Pendant très longtemps (jusque vers le milieu des années 2000), les ordinateurs

dont je pouvais disposer pour PISCO n’étaient pas assez puissants pour calculer des spectres

et des bispectres en temps réel. Certains collègues y parvenaient cependant en utilisant des

processeurs spécialisés de type DSP (Digital Signal Processor)

.

Les premières caméras installées sur PISCO furent des caméras à comptage de photons,

que l’on nous prêtait pour effectuer les missions au Pic du Midi : CP40 de l’INSU, CAR

(Caméra à Anode Résistive) de l’OCA, et PAPA de P. Nissensson (Cambridge, USA). Ces

caméras fournissaient directement les coordonnées des photons détectés, en temps réel. Un

traitement bien adapté à ce format, et relativement facile à mettre en œuvre, consistait à

calcu-ler des auto-corrélations, ou des triples corrélations restreintes à quelques plans particuliers.

Pour les missions au Pic du Midi avec ces détecteurs, nous utilisions les programmes de

Laurent Koechlin qui décodaient le format de ces données et effectuaient ce traitement en

temps réel sur un ordinateur Macintosh. Pour tester les méthodes bispectrales proposées par

Lannes(1988), un traitement plus complet était nécessaire, qui ne pouvait alors se faire qu’en

temps différé. Pour cela, j’avais écrit des programmes adaptés à chaque type de caméra, qui

1Pour ma part, je préférais attendre, en pensant que l’évolution des techniques rendrait vite caduque un éven-tuel développement sur ces DSP. L’avenir m’a donné raison. Quelques années plus tard, ces calculs pouvaient être effectués en temps réel par de simple ordinateurs personnels.

reconstituaient des images élémentaires et calculaient ensuite des moyennes de spectres et

de termes bispectraux sur une “liste bispectrale” (le bispectre étant de dimension 4) (voir

Annexe A).

Ces caméras étaient très sensibles, mais elles n’étaient pas faciles à utiliser et sujettes à

de nombreuses pannes. De plus, elles avaient des défauts (distorsion, “trou du centreur”) qui

se sont révélés être très gênants pour la restauration d’images à haute résolution angulaire à

l’aide des méthodes bispectrales que nous voulions mettre en œuvre (Prieur et al., 1998). A

partir de 1998, au Pic du Midi puis à Merate, nous avons uniquement utilisé la caméra ICCD

(Intensified CCD), que nous a aimablement prêté l’équipe d’Eric Aristidi de l’Université de

Nice. Cette caméra, fabriquée par Philips, est équipée d’un amplificateur de brillance (galette

de micro-canaux avec photo-cathode SR20) couplé à un détecteur CCD, à la manière de la

caméra “Ciné-CCD” que j’avais testée au Pic du Midi lors de mon stage d’ingénieur (Prieur,

1993a;Fort et al.,1985). La caméra ICCD Philips produit un signal vidéo qui transite par une

fibre optique pour visualisation sur un moniteur vidéo et/ou enregistrement sur un

magnéto-scope. Jusqu’en 2009, les données de cette caméra étaient enregistrées sur cassettes SVHS

(Super Video Home System). J’avais mis au point un banc de numérisation automatique de

cassettes vidéo, à partir d’un magnétoscope Panasonic AG-7355 et d’une carte électronique

RIO/ELLIPS pour PC (port PCI). Le magnétoscope était piloté par ordinateur par une liaison

RS232 et la carte de numérisation RIO/ELLIPS assurait une numérisation sur 8 bits, avec une

cadence de 50 images par seconde. Cette carte ne peut être installée que sur un port PCI et

les pilotes ne sont disponibles que pour le système d’exploitation “Microsoft/Windows”.

J’ai donc été conduit à écrire un programme VCRBde traitement en langage C++, avec

des bibliothèques graphiques fonctionnant sous ce système d’exploitation (Fig. II.0). Dans

les années 1990, le traitement d’une cassette de 3 heures nécessitait presque une semaine de

calcul avec les PC de l’époque. Le programmeVCRBdevait à la fois piloter le magnétoscope

(avance, retour en arrière, lecture, arrêt, pause, lecture du compteur, etc), la carte de

numé-risation (paramétrage, numénumé-risation, stockage et transfert) et le traitement des données

(cor-rection, sélection et traitement des images élémentaires). Ce programme a été utilisé au Pic

du Midi, à Toulouse et à Merate, avec différents ordinateurs, systèmes d’exploitation

(Win-dows 3, Win(Win-dows 95 et Win(Win-dows XP), et deux magnétoscopes différents. Je l’ai amélioré

et maintenu pendant une quinzaine d’années. Il s’est montré fiable et robuste, et parvenait à

traiter des cassettes entières sans interruption, ce qui durait en général plusieurs jours.

Au début ce traitement se faisait presque exclusivement en différé, après les observations.

Ensuite, j’ai intégré progressivement de plus en plus de traitement en temps réel, pendant les

observations. Depuis 2006, grâce aux progrès techniques, l’essentiel du traitement, y compris

la restauration d’image, peut être fait sur un ordinateur personnel (PC), en temps réel. Les

données numérisées ont pu aussi être stockées sur disque, et nous n’enregistrons plus sur des

cassettes vidéo depuis 2008.

Cette caméra ICCD s’est montrée très fiable. Nous avons eu cependant quelques pannes,

causées par un mauvais contact sur la sortie en fibre optique, que nous avons réussi à réparer

(heureusement, car il n’y a plus de maintenance possible chez Philips). Le système de

fixa-tion de la fibre optique a été complètement révisé récemment par Marco Scardia et Alessio

Zanutta, pour que ce genre de problèmes ne se reproduise plus.

Attente d’événements: - "Cube 1 à traiter" - "Cube 2 à traiter" - "Arrêt du processus"

Processus dédié à la numérisation (Rio Thread) Bouton "début de la capture" Bouton "arrêt de la capture" Attente d’événements: - "Début de capture" - "Arrêt du processus" Attente de l’événement "Cube traité"

Evénement: pour la communication

inter-processus

2. Evénement"Cube #ic à traiter"

"Cube #ic à tr aiter^"

"Fin de captur e"

Arrêt de la lecture de la cassette (si batch)

Erreur fatale: arrêt des threads et sortie du programme

"Début capture"

arrêt_capture=vrai?

arrêt_capture = vrai

Mutex: pour accéder à des variables communes oui non 1. arrêt_capture = faux 1. arrêt_capture = vrai 3. n_images = 0 n_images > 0 ? arrêt du traitement ? Test compteur/événement d’interruption par l’utilisateur:

Processus dédié au traitement (DecodeThread)

Processus "Gestion de la carte de numérisation"

Rio

Fonction "Fin de capture"

1. Traitement du cube #ic et mise à jour de n_images

(images traitées) Sauvegarde du traitement (si batch) ou autorisation de sauvegarde (si interactif)

2. cube_ic_plein = faux 3. Activation de l’événement "Cube traité" "Cube tr aité" 2. activation de l’événement "Début de capture" "Début de capture" k == nz ? 1. cube_ic_ plein=vrai

Deux cubes pleins ? Envoi de requête de numérisation d’une image.

Attente d’événement de

fin de numérisation dépassé^délai

délai dépassé Cube traité

Copie de l’image dans le cube #ic à la kème

position, puis k:=k+1

non

oui

oui

cube #ic à traiter oui oui non non k:=1 ic:=(ic+1)%2 "Arrêt du processus" cube_1_plein=faux cube_2_plein=faux ic := 1 et k:=1

Envoi d’un message: "Fin de capture"

Message : pour lancer une fonction d’un autre processus

Légende: