Stockage d'images tridimensionnelles sur le serveur d'images GigaView

par Benoit Gennart, Laboratoire de Systèmes Périphériques, EPFL

Les interfaces graphiques et multimédia exigent l'utilisation d'outils informatiques pour la visualisation d'images numérisées. Dans les domaines de la modélisation scientifique, l'imagerie médicale, la cartographie et les arts graphiques, il y a un besoin urgent pour de très grandes capacités de stockage, avec accès rapide et visualisation interactive d'images numérisées.

Un serveur d'images à haute performance doit fournir aux utilisateurs connectés au réseau un ensemble de services d'accès immédiat aux images numérisées. Ces services comprennent entre autres l'extraction de parties d'images, le rééchantillonnage pour les opérations de zoom, l'extraction de sections 2-D à partir d'une image 3-D, et l'accès à des séquences d'image à un rythme régulier.

D'autres travaux de recherches dans le domaine ont visé à augmenter le débit de transfert entre l'unité centrale et les disques en utilisant la technologie RAID (Redundant Array of Inexpensive Disks [3]). L'accès aux données est parallélisé, mais la gestion des fichiers et le traitement des données restent séquentiels.

Constatant le problème que posent la sélection, l'accès et la visualisation d'images de grandes dimensions dans une base de données de grande taille, le Laboratoire de Systèmes Périphériques (LSP, Département d'Informatique) a développé un système de stockage et de restitution rapide d'images numérisées [1, 2]. Ce serveur d'images, appelé GigaView, possède une architecture multiprocesseur multidisque qui supporte efficacement non seulement le stockage mais aussi la restitution et le traitement d'images numérisées à deux et à trois dimensions.

Le GigaView est déjà utilisé comme serveur de cartes topographiques (1:25'000ème), intégré à HyperBird, le système d'information géographique (SIG) développé par la maison BSI à Lausanne. Il permet d'accéder en temps réel à n'importe quelle partie de carte, avec transition correcte d'une carte à l'autre, association des données altimétriques aux cartes, intégration des données vectorielles et passage aux plans d'ensemble (1:5'000ème) et cadastraux (1:500ème).

Pour les besoins d'une démonstration, le LSP a acquis et stocké sur le serveur GigaView une image tridimensionnelle résultant d'une analyse au scanner à résonance magnétique nucléaire (RMN). Cette image représente environ 100Moctets de données (384x512x512 pixels de 8 bits). Le GigaView permet de visualiser au rythme de plusieurs images par seconde, des coupes dans l'image tridimensionnelle, selon n'importe quel plan principal. Les images proviennent directement des disques du serveur, sans passer par une coûteuse opération de préchargement des données en mémoire.

D'où provient la performance? Tout d'abord de la subdivision de l'image tridimensionnelle en cubes de petite taille (32x32x32 pixels) appelés éléments volumiques. Cette organisation des données, intégrée dans le système de fichiers MDFS (système de fichier multidimensionnel), permet de sélectionner très rapidement les parties de l'image requises par l'utilisateur, sans avoir à relire l'image entière à chaque opération. De plus, la quantité de données à lire dépend uniquement de la taille de la fenêtre de visualisation, et non de la taille de l'image stockée sur le serveur d'images. Quand on sait que l'image tridimensionnelle d'un corps humain complet (National Library of Medecine, Visible Human Project, Bethesda, Maryland) représente environ 20Goctets de données, cette propriété du système de fichier MDFS prend toute son importance.

La performance provient ensuite de la répartition des éléments volumiques sur les différents disques du serveur GigaView. En répartissant intelligemment les éléments volumiques sur les disques de l'architecture, il est possible de multiplier le débit d'accès aux données par le nombre de disques dans l'architecture, et ce, quelle que soit la partie de l'image sélectionnée.

La performance provient enfin de l'existence de processeurs associés aux disques du serveur. Ceux-ci permettent de sélectionner en parallèle dans les éléments volumiques les données demandées par l'utilisateur. Les processeurs permettent aussi des opérations plus sophistiquées telles que la rotation d'image, la (dé)compression, ou tout autre traitement numérique localisé appliqué aux images.

Le GigaView est aussi adapté au stockage d'images bidimensionnelles, telles que des radiographies. Il permet de conserver une base de données d'images numérisées et d'y accéder instantanément.

Le serveur parallèle GigaView

L'architecture du GigaView comporte une interface SCSI-2, un processeur d'interface ainsi que plusieurs noeuds de stockage intelligents (figure 1: l'architecture parallèle du serveur GigaView). Chaque noeud de stockage comporte un processeur connecté à un ou plusieurs disques. L'architecture peut être adaptée aux besoins de l'utilisateur: si les besoins de stockage sont importants, on associera deux ou quatre disques à chaque noeud de stockage; si par contre les besoins de calcul sont essentiels, on augmentera le nombre de noeuds de stockage (et donc le nombre de processeurs), mais avec seulement un disque par noeud. Une architecture de base comporte quatre noeuds de stockage avec chacun un disque de 1Goctet, pour un total de 4Goctets. Une architecture performante comportera par exemple 8 noeuds de stockage, chacun avec 4 disques de 2 Goctets, pour un total de 64Goctets. Par l'intermédiaire de son port SCSI­2, le GigaView se connecte à un Macintosh ou une station de travail UNIX.

Pour obtenir une bonne efficacité, il faut que la charge résultant d'un accès image soit répartie équitablement sur chacun des disques. Les recherches faites au LSP montrent qu'en spécifiant de manière adéquate la taille des éléments volumiques, on obtient une bonne répartition de la charge pour n'importe quelle fenêtre de visualisation. On obtient ainsi un accroissement des performances pratiquement linéaire pour des architectures comportant jusqu'à 8 noeuds de disques fonctionnant en parallèle.

L'architecture GigaView est caractérisée aussi bien par le système de fichiers parallèle multidimensionnel (MDFS) que par un ensemble de noeuds de stockage formés de processeurs et de disques assurant l'accès et le prétraitement parallèle des données. Selon le type d'application rencontré, l'architecture GigaView peut être adaptée aux systèmes matériels suivants:

  1. Serveur back-end performant, composé de processeurs et disques magnétiques, connecté à un Macintosh, un PC ou une station UNIX par le biais d'un bus SCSI-2.
  2. erveur multi-CD-ROM capable d'accéder en parallèle à des données réparties sur plusieurs CD-ROMs.
  3. Serveur UNIX multiprocesseur haut de gamme incorporant plusieurs sous-systèmes périphériques SCSI-2.

La solution 2 est particulièrement avantageuse. Elle permet de bénéficier du coût de distribution des données sur CD-ROM, tout en palliant à son manque de débit de transfert.

Le système de fichier MDFS

Dans le système de fichier MDFS (figure 2: l'organisation des données tridimensionnelles, à gauche par section, et à droite par éléments volumiques), l'image tridimensionnelle est créée à partir d'une série d'images bi-dimensionnelles numérisées (gauche). Ces images représentent les sections d'un solide prises à intervalle régulier. Nous les appellerons les sections originales et feront l'hypothèse qu'elles sont orientées selon les axes X et Y.

Stocker l'image tridimensionnelle par sections présente un défaut essentiel: pour accéder aux données de l'image, il faut charger du disque en mémoire les sections originales qui intersectent la fenêtre de visualisation, retirer de chaque section originale les données qui font partie de la fenêtre de visualisation, et les recopier au bon endroit dans la fenêtre de visualisation. Cette opération est facile lorsque la fenêtre de visualisation coïncide avec une des sections originales, mais devient critique dans tous les autres cas: le temps d'accès dépend du plan d'accès choisi. Pour contourner le défaut du stockage par section, MDFS réorganise les données sur le disque en cubes appelés éléments volumiques. Chaque élément volumique contient un ensemble tridimensionnel de pixels contigus.

Pour fixer les idées, considérons une image tridimensionnelle de 2048x2048x2048 pixels de 8bits (soit 8Goctets de données, pour une image tridimensionnelle de bonne qualité), stockée sur un système conventionnel disposant d'un disque qui permet d'accéder aux données au rythme de 2Moctets/sec. Sélectionner une fenêtre de visualisation de 512x512 pixels de 8 bits (250Koctets) dans une image tridimensionnelle organisée par section prendrait, selon le plan XY: 0.3s, selon le plan XZ: 5.4s et selon le plan YZ: 2600s. Si l'on considère l'organisation des données en éléments volumiques de 32x32x32 pixels de 8 bits, le temps d'accès pour la même fenêtre de visualisation est de 4s seulement, quel que soit le plan d'accès. Ce temps d'accès est nettement meilleur, et peut être obtenu sans le bénéfice du parallélisme. Avec une architecture GigaView comportant 8 disques, le temps d'accès descend en dessous de la seconde, soit un temps d'accès pratiquement instantané.

Figure 3: accès aux données tridimensionnelles selon les trois plans principaux

Le LSP poursuit le développement du GigaView, en y intégrant des primitives de synchronisation permettant de supporter les applications multimédia, et en ajoutant des fonctions de chargement de programmes utilisateurs sur les processeurs locaux. Pour plus d'informations contacter Benoit Gennart. tél: (021) 693 - 3941; fax: (021) 693 - 6680.

Références

  1. R. D. Hersch. Parallel storage and retrieval of pixmap images. In Proc. 12th IEEE Symposium on Mass Storage System, IEEE Press, 221-226, Monterey, 1993.
  2. Benoit Gennart and R. D. Hersch. Multimedia Performance Behavior of the GigaView Parallel Image Server. In Proc. 13th IEEE Symposium on Mass Storage System, IEEE press, 90-98, Annecy, 1994.
  3. D. A. Patterson, G. A. Gibson, and R. H. Katz. The case for RAID: redundant arrays of inexpensive disks. In Proceedings ACM SIGMOD Conference, pages 106-113, Chicago, IL, May 1988. >/ol>


    article paru dans le Flash informatique spécial été 1994 du 6 septembre 1994