Par Stephen Albanese, Matrox Imaging

Compte tenu de la puissance et de la flexibilité qu'ils confèrent aux applications exigeantes comme les inspections de la qualité et la visualisation médicale en direct, les processeurs de signaux numériques sont des composants de choix pour les cartes de traitement d'images. Toutefois, le concepteur de système sait qu'une solution efficace comporte plus qu'un processeur DSP intégré à une carte. En traitement d'images, la conception de cartes doit aussi prendre en compte un fort débit entrée/sortie et le besoin toujours grandissant d'un rendement plus élevé.

Les développeurs de systèmes d'imagerie scientifique, médicale et industrielle, font face aux pressions du marché pour la réduction des coûts et du delai de mise en marché, et aux besoins d'accroître la performance. Le PC est devenu un allié formidable grâce, en partie, aux technologies contributives telles que PCI, Windows NT, les processeurs Pentium Pro, les périphériques à prix modique, la convivialité et l'abondance croissantes des outils de développement de logiciels. En imagerie haut de gamme, les processeurs d'image PCI architecturés autour de processeurs DSP sont utilisés à des fins de vision industrielle, d'imagerie médicale et d'analyse d'images, alors que par le passé les OEM et les intégrateurs de systèmes s'en sont remis à des solutions exclusives ou architecturées autour du bus VME. Matrox, fournisseur chevronné de systèmes d'imagerie, vient de mettre en marché un système auxiliaire architecturé autour d'une plate-forme PC, conçu pour surpassser le ratio prix/performance des autres solutions matérielles et logicielles proposées tout en offrant une voie de migration intégrée vers une performance accrue.

Le Matrox Genesis fait appel à un processeur DSP optimisé pour des opérations de traitement d'images, le TMS320C80 de Texas Instruments. Le Matrox Genesis possède des fonctions d'acquisition, de traitement et d'affichage incorporées à une même carte PCI de performance évolutive par ajout de cartes processeurs auxiliaires. L'intégration poussée du système et son évolutivité flexible simplifient sa complexité tout en réduisant le total des coûts.

Pour de telles applications, le matériel de traitement d'images doit comporter une mémoire d'images et une fonction de traitement intégrées à la carte. Le processeur TI C80 DSP est un point de départ à la fois excellent et économique pour ces besoins de rendement, offrant une puissance et une flexibilité de programmation suffisantes pour l'exécution de plusieurs opérations de traitement d'images, malgré les contraintes de temps réel. Pour décharger les tâches de gestion de données et permettre au DSP de réaliser son plein potentiel de traitement, Matrox a conçu une interface vidéo ASIC (VIA). Cette interface exécute des transferts optimisés à la carte ou en provenance de celle-ci, gère les flux de données, contrôle l'accès du bus et accomplit d'autres tâches afin d'assurer une performance maximale.

Le TI C80 est un multiprocesseur DSP qui comporte un processeur maître RISC (PM), quatre processeurs parallèles (PP) ayant chacun leur propre mémoire SRAM et reliés par réseau crossbar. L'acheminement des données est exécuté par un contrôleur de transfert dédié. Tel qu"illustré dans le schéma fonctionnel de la carte principale (Illustration 1), le Matrox Genesis utilise cette puce comme l'un des composants de sa fonction de traitement.

Afin de satisfaire ces besoins de saisie d'image, le module d'acquisition du Matrox Génésis, en mezzanine à la carte principale, est entièrement programmable. On peut l'interfacer pratiquement à toutes les caméras : analogiques, numériques, monochrome, couleur, ou à balayage linéaire. En plus de contrôler le flux des données, la puce d'interface VIA peut reformater, à l'entrée, les données pixel reçues en temps réel de dispositifs vidéo produisant des données de pixels non contigus.

La fonction d'affichage intégrée à la carte principale du Matrox Genesis est régie par une deuxième puce d'interface VIA et inclut le processeur graphique MGA 2064W de Matrox, jusqu'à 8 Mo de mémoire WRAM, et une puce RAMDAC 220 MHz pour des résolutions atteignant 1600 x 1200 à 85 Hz, gage d'une accélération graphique et d'un grand bureau électronique. Deux mémoires tampon, une pour l'image (8 ou 24 bits) et la deuxième pour le recouvrement (8 bits) permettent de superposer, de façon non destructive, votre bureau électronique et d'autres images, à votre fenêtre de vidéo en direct.

Les opérations soumises à un noeud de traitement sont traitées automatiquement, le noeud ayant recours à toutes les ressources nécessaires pour que les opérations soient exécutées à la vitesse maximale. Il n'est pas nécessaire que le développeur optimise le processeur maître du TI C80, les processeurs parallèles ou le processeur NOA. Un contrôle d'optimisation est cependant disponible, si nécessaire.

Il y a plusieurs façons de répartir les tâches d'une application entre les noeuds. Le développeur peut choisir de laisser chaque noeud saisir une partie différente des données reçues et de traiter cette partie seulement. On obtient ainsi le temps d'attente le plus court pour produire une image, mais cette approche n'est pas appropriée pour certains algorithmes qui requièrent qu'un seul processeur ait accès à toute l'image. Une autre approche serait de permettre à chaque noeud de saisir et de traiter les données d'une image complète, chaque image subséquente étant dirigée vers un noeud différent. La période d'attente sera plus longue, mais la performance sera directement proportionnelle au nombre de noeuds utilisés et vous pourrez exécuter presque n'importe quel algorithme (car chaque noeud aura accès à une image complète). Une autre façon serait d'affecter un noeud à la saisie et de le laisser exécuter la première partie du traitement avant de soumettre les résultats partiels obtenus au noeud suivant du pipeline.

En d'autres mots, le Matrox Genesis supporte les topologies parallèle et pipeline, ou toute combinaison de ces deux approches. La nature de l'application en cause déterminera quelle approche sera la meilleure, mais diverses caractéristiques du Matrox Genesis aideront le développeur à programmer un algorithme multitraitement. Premièrement, les images saisies sont présentées à tous les noeuds d'un système. Chaque noeud peut prendre toute l'image ou une partie seulement, réduisant ainsi les transferts internoeuds. Deuxièmement, le canal VM relie tous les noeuds; il est donc facile d'acheminer les résultats vers un noeud spécifique pour un traitement plus poussé ou pour affichage. De plus, chaque TI C80 a un accès direct à chaque noeud du bus PCI. Normalement, on utilisera cette caractéristique pour l'acheminement de messages ou pour le partage d'une quantité limitée de données.

Chaque application étant différente, les exigences de traitement varieront. Elles seront influencées par la résolution de la caméra, la profondeur de bits ainsi que par le nombre et les types d'opérations à exécuter à l'intérieur des contraintes de traitement en temps réel. Par exemple, une caméra haute résolution, 60 images/seconde, impose des contraintes de temps réel plus sévères que celles d'une caméra standard à 30 images/seconde. Certaines opérations, comme la corrélation normalisée, font appel à des algorithmes de plus haut niveau qui requièrent une plus grande puissance de traitement qu'un simple ajout à une image, par exemple. Le cas échéant, l'évolutivité du Matrox Genesis donne aux développeurs une voie de migration facile vers une performance accrue; on peut donc développer les algorithmes ultérieurement. Les deux exemples suivants illustrent de quelle façon un développeur jouit d'une maîtrise complète en ce qui a trait à la configuration optimale du traitement par noeuds multiples.

Dans l'exemple d'algorithme que nous avons retenu, un seul noeud prendra environ 20 ms pour accomplir le filtrage des parasites et le filtrage temporel d'une image 1k x 1k x 10 bits à 30 trames/seconde. La mise en évidence des bordures, au moyen de grandes convolutions 7 x 7, requerra 26 ms, alors qu'il faudra 11 ms pour l'ajustement luminance/contraste. Parce que cet algorithme requiert approximativement 57 ms s'il est exécuté par un seul noeud, on aura normalement recours à trois noeuds pour le traitement en temps réel (l'utilisation de 3 noeuds laisse amplement de puissance si, par la suite, on devait ajouter des opérations supplémentaires à l'algorithme).

Tel qu'illustré (voir Illustration 3), les images sont saisies et transmises simultanément aux trois noeuds. Chaque noeud saisit un secteur d'intérêt différent pour le traiter. Un secteur a la dimension de 1024 x 350 pixels (on utilise un léger chevauchement pour éviter les effets de bordure). Le VIA primaire de chaque noeud achemine pour affichage, par le canal VM, les résultats de chaque secteur traité; le VIA du module d'affichage de la carte principale "recolle" l'image ensemble, en temps réel.

Dans l'exemple suivant (voir Illustration 4), voici l'algorithme qu'il faut utiliser pour faire l'inspection d'un boîtier BGA et détecter les billes manquantes. En premier lieu, il faut repérer des coins opposés du boîtier pour en déterminer l'orientation précise. Ensuite, on procédera à l'alignement de l'image source à l'image de référence et à la soustraction d'image. Finalement, un compte des taches (bille manquante) sera fait. Souvent, en vision artificielle, les algorithmes se prêtent mal à la subdivision d'une image. Par exemple, les opérations comme le filtrage ou l'analyse de taches exigent une recherche de l'image en son entier.

Chaque filtrage, pour trouver l'image de référence qui montre les deux coins opposés du boîtier, dure environ 5 ms (x 2=10 ms). L'alignement, à une fraction de pixel près, avec l'image de référence (rotation avec interpolation bilinéaire des pixels) demandera 22 ms. La soustraction d'image de l'image de référence exigera 4 ms et l'analyse de tâches pour repérer les billes manquantes prendra en moyenne 10 ms. Le temps de traitement requis pour cet exemple est donc de 46 ms. Pour une exécution en temps réel, il faudra recourir à deux noeuds de traitement (c'est-à-dire un traitement de moins de 33 ms puisque l'exemple donné fait usage d'une caméra standard RS-170). Dans ce cas-ci, la configuration optimale serait probablement l'utilisation d'une carte principale avec une carte processeur comportant un seul noeud.

Le premier noeud traitera une image complète. Comme 46 ms sont requises pour traiter une image complète, un deuxième noeud traitera l'image suivante (n + 1) pendant que le premier noeud termine sa tâche. Si l'on dispose d'assez de noeuds, il sera possible de maintenir un traitement en temps réel, même dans le cas d'algorithmes complexes, de caméras plus rapides, ou de résolutions plus élevées. De plus, il sera facile d'écrire un programme pour que l'application utilise autant de noeuds que nécessaire pour une exécution en temps réel.

La bibliothèque MIL fera appel aux commandes équivalentes de Native Library lorsqu'on l'utilise pour mettre une application au point. La bibliothèque Native Library est un ensemble de programmes de substitution, un pour chaque code opérationnel supporté. Les commandes de Native Library sont enclenchées par le processeur hôte et adressent des appels de procédure à distance aux fonctions de traitement du C80 (les commandes en langage machine {Shell} de Native Library sont dans la mémoire SDRAM du processeur). Les commandes répartissent les tâches, automatiquement, entre les processeurs multiples (les processeurs parallèles du TI C80 et le processeur d'opérations de voisinage NOA). Cependant, un ensemble de commandes a été prévu pour assurer le contrôle des processeurs, si désiré (il n'est pas nécessaire d'utiliser la trousse DTK pour répartir les tâches entre les processeurs).

Si la portabilité n'est pas un impératif, vous pouvez écrire toute l'application avec Native Library. L'extensibilité de Native Library permet à l'utilisateur de personnaliser des fonctions du TI C80 pour des applications spéciales. On peut utiliser la trousse DTK pour ajouter des fonctions spécialisées à la bibliothèque. On ajoutera, de façon transparente, ces fonctions personnalisées au programme de l'application. Les applications complètes mises au point avec Native Library peuvent être portées, au besoin, au TI C80 pour traitement interne.

Contactez nos services Communication.