Découverte de DICOM, le format d'imagerie médicale - PARTIE 2 : les données

File Preamble et DICOM Prefix

Comme on l'a vu dans le précédent article, un fichier DICOM commence par un préambule et un préfixe qui ne sont pas encapsulés dans une structure de donnée, ce qui nous donne quelque chose comme ça :

File Meta Information Group Length (0002,0000)

Ensuite vient notre premier élément de donnée structuré. Ce champ donne la longueur restante de la partie Meta Information, donc le nombre d'octets de l'entête sans compter le préambule, le préfixe et cette première structure. Pour le moment je laisse cette valeur vide, on la remplira à la fin puis qu'il faudra compter nos octets... 😅️

File Meta Information Version (0002,0001)

On poursuit avec la version de l'entête, qui s'écrit sous forme de flags : la valeur ne s'interprète pas comme un nombre mais les bits passent à 1 pour indiquer le support d'une version particulière, et ces versions sont cumulatives... Bref, on ne va pas rentrer dans les détails, ici il faudra juste toujours mettre la valeur 0x00 0x01. Attention le champ est de type « tableau d'octet », il n'est donc pas question de big ou de little endian ici, il faut écrire la valeur telle quelle ! 😉️

Media Storage SOP Class UID (0002,0002)

Maintenant on passe au « Media Storage SOP Class UID »... Derrière cette dénomination barbare se cache le type de donnée médicale que l'on va stocker dans le fichier DICOM : mammographie, courbe d'électrocardiogramme, tomodensitométrie (a.k.a scanographie ou scanner), image aux rayons X, etc.

Chaque type d'examen / de donnée se voit attribuer un identifiant unique que vous retrouverez dans le tableau ci-dessous :

• Liste des types de données médicales standards (PS3.4 B.5-1)

Dans notre cas on va déclarer que notre fichier contient une image de type « CT Image » (« Computed Tomography » ou tomodensitométrie en français). Ce type d'image a pour identifiant unique "1.2.840.10008.5.1.4.1.1.2".

Media Storage SOP Instance UID (0002,0003)

Il s'agit d'un UID que vous pouvez à priori définir à la valeur que vous voulez mais qui doit être unique. Si vous avez une série de fichiers DICOM (ce qui est le cas pour les scanners et les IRM), vous pouvez par exemple donner comme ID 1.2.3.1 pour la première image, puis 1.2.3.2 pour la seconde, etc.

Transfer Syntax UID (0002,0010)

On en a déjà pas mal parlé dans la première partie de l'article donc pas de surprise ici. Il faut déclarer dans cet attribut l'identifiant de la syntaxe de transfert que l'on va utiliser dans le Data Set. Pour rappel nous on va utiliser la « DICOM Explicit VR Little Endian Transfer Syntax » (PS3.5 A.2), qui a pour identifiant "1.2.840.10008.1.2.1".

Références utiles :

• Spécification de la syntaxe de transfert « DICOM Explicit VR Little Endian » (PS3.5 A.2)

Implementation Class UID (0002,0012)

Bon pour celui-là j'ai pas 100 % compris, mais à priori c'est un identifiant unique qui sert à identifier le logiciel ou le matériel qui a servi à générer le fichier... À priori on peut mettre un peu ce qu'on veut, ça ne semble pas bien important à ce stade. 🤷‍♂️️

Implementation Version Name (0002,0013) [Optionnel]

Pour terminer, on va écrire le nom et la version de notre logiciel dans ce dernier champ [oui il est optionnel, mais ça me semble important de le définir au cas où un jour on chercherait à savoir qui a commis ce fichier DICOM qui ne respecte pas les standards ! 😛️].

On finalise l'entête

Et voilà on a fait le tour des éléments à définir dans l'entête du fichier. On peut donc à présent compter nos octets pour remplir la toute première structure qu'on a vu. Notre entête fait 124 octets de long (en enlevant le préambule, le préfixe et la première structure). En hexa ça donne 0x7C, on va donc pouvoir écrire 0x7C 0x00 0x00 0x00 comme valeur dans la structure (entier 32 bits non signé encodé en little endian).

Une fois tout recollé ensemble ça nous donne ça :

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
00000080  44 49 43 4D 02 00 00 00  55 4C 04 00 7C 00 00 00  DICM....UL..|...
00000090  02 00 01 00 4F 42 00 00  02 00 00 00 00 01 02 00  ....OB..........
000000A0  02 00 55 49 1A 00 31 2E  32 2E 38 34 30 2E 31 30  ..UI..1.2.840.10
000000B0  30 30 38 2E 35 2E 31 2E  34 2E 31 2E 31 2E 32 00  008.5.1.4.1.1.2.
000000C0  02 00 03 00 55 49 06 00  31 2E 32 2E 33 00 02 00  ....UI..1.2.3...
000000D0  10 00 55 49 14 00 31 2E  32 2E 38 34 30 2E 31 30  ..UI..1.2.840.10
000000E0  30 30 38 2E 31 2E 32 2E  31 00 02 00 12 00 55 49  008.1.2.1.....UI
000000F0  08 00 31 2E 32 2E 33 2E  34 00 02 00 13 00 53 48  ..1.2.3.4.....SH
00000100  0A 00 46 4C 4F 5A 7A 20  31 2E 30 20              ..FLOZz 1.0

C'est un bon début, passons donc au Data Set ! 😄️

SOP Common Module (PS3.3 C.12.1)

On commence notre tournée des modules par le « SOP Common Module » qui contient des informations nécessaires à l'identification du Data Set.

Ici on va définir 2 éléments de donnée :

• SOP Class UID (0008,0016),
• et SOP Instance UID (0008,0018).

Si ça vous dit quelque chose, c'est normal car ils correspondent respectivement aux éléments (0002,0002) et (0002,0003) que l'on a déjà définis dans l'entête du fichier et ils doivent contenir strictement la même valeur (enfin techniquement c'est ceux de l'entête qui doivent être identiques à ceux du Data Set mais bon vous avez compris 🙃️).

Voici concrètement à quoi tout ça ressemble :

Références utiles :

• Spécification du « SOP Common Module » (PS3.3 C.12.1)

Patient Module (PS3.3 C.7.1.1)

Passons ensuite à la fiche du patient. Ici on va se contenter de définir son nom et un identifiant unique pour le représenter, ce qui correspond aux éléments de données suivants :

• Patient's Name (0010,0010),
• et Patient ID (0010,0020).

Références utiles :

• Spécification du « Patient Module » (PS3.3 C.7.1.1)

CT Image Module (PS3.3 C.8.2.1)

Comme je l'ai mentionné quand on a parlé du « Media Storage SOP Class UID » dans l'entête, on va écrire une image censée être issue d'un scanner dans notre fichier DICOM. On va donc devoir définir les éléments de donnée issus du module « CT Image ».

Bon ici on ne va en définir qu'un :

• Image Type (0008,0008)

Cet élément permet d'identifier les caractéristiques de l'image. Il s'agit d'une chaine de caractère qui contient (à priori) de 2 à 4 composantes que l'on va dans notre cas définir à "ORIGINAL\PRIMARY\AXIAL". Je ne vais pas rentrer dans les détails ici, mais si vous voulez en savoir plus, vous pouvez vous référer à la section PS3.3 C.7.6.1.1.2 de la norme pour les deux premières composantes, et à la section PS3.3 C.8.2.1.1.1 pour la troisième.

Ce module définit d'autres champs essentiels à l'interprétation de l'image, mais ils sont communs avec le module « Image Pixel Module » donc on en parlera juste après. 😉️

Références utiles :

• Spécification du « CT Image Module » (PS3.3 C.8.2.1)
• Spécification pour les deux premières composantes du type de l'image (PS3.3 C.7.6.1.1.2)
• Spécification pour la troisième composante du type de l'image (PS3.3 C.8.2.1.1.1)

Image Pixel Module (PS3.3 C.7.6.3)

Passons maintenant à l'image en elle-même. Vous trouverez la liste complète des éléments de données à définir dans le tableau PS3.3 C.7.11a, ainsi que dans le tableau PS3.3 C.7-11c (qui est référencé par le premier) :

• Tableau « Image Pixel Module Attributes » (PS3.3 C.7.11a)
• Tableau « Image Pixel Description Macro Attributes » (PS3.3 C.7-11c)

On va commencer par définir les attributs qui permettent de caractériser l'image. Voici ceux dont on va avoir besoin :

• Samples per Pixel (0028,0002) : Nombre de composantes pour chaque pixel de l'image. Dans notre cas il s'agira d'une image en niveau de gris, donc cette valeur sera à définir à 1. Si on avait voulu stocker une image couleur RGB, cette valeur aurait été à 3. Reportez-vous à la section PS3.3 C.7.6.3.1.1 de la spec pour plus d'informations.

• Photometric Interpretation (0028,0004) : Interprétation graphique des octets qui composent l'image. Dans notre cas on mettra MONOCHROME2, ce qui signifie qu'un octet à 0 représente un pixel noir et un octet à la valeur maximale (255 pour cet exemple car on va coder les pixels sur 8 bits) représente un pixel blanc. Toutes les valeurs intermédiaires représentent un pixel gris plus ou moins lumineux. Il existe d'autres représentations comme MONOCHROME1 qui est simplement l'inverse du précédent (0 représente le blanc et la valeur maximale le noir), ou encore RGB pour une image en couleurs non indexées. Il en existe plein d'autres que vous retrouverez dans la section PS3.3 C.7.6.3.1.2.

• Rows (0028,0010) : Hauteur de l'image. Dans notre cas elle fera 2 px de haut.

• Columns (0028,0011) : Largeur de l'image. Dans notre cas elle fera 2 px de large.

• Bits Allocated (0028,0100) : Nombre de bits à allouer pour chaque pixel de l'image. Dans notre cas ça sera 8. Les valeurs acceptables sont 1 (image monochrome, sans niveau de gris) ou un multiple de 8.

  NOTE : Allouer 8 bits ici implique que notre élément Pixel Data sera de type (VR) OB. Si on avait mis 16 on aurait dû utiliser le type (VR) OW.

• Bits Stored (0028,0101) : Sur le nombre de bits alloués, combien de bits sont effectivement utilisés pour représenter l'image. Cette valeur est obligatoirement inférieure ou égale à celle de Bits Allocated. Dans notre cas ça sera 8.

  Prenons un second exemple pour clarifier un peu tout ça. Si on voulait avoir une image avec une profondeur de 12 bits par pixel, dans ce cas on aurait dû définir Bits Allocated à 16 et Bits Stored à 12 (donc on va consommer 16 bits par pixel d'espace dans le fichier, mais il n'y a que 12 bits sur les 16 qui sont utilisés).

• High Bit (0028,0102) : Numéro du bit le plus significatif. Normalement cette valeur devrait valoir Bit Stored  – 1. Dans notre cas ça sera donc 7.

• Pixel Representation (0028,0103) : Indique si les nombres utilisés pour représenter les pixels sont signés (complément à 2) ou non signés. Dans notre cas on va utiliser des nombres non signés et donc on stockera 0 dans ce champ.

Voilà comment tout ça se traduit en structures de données :

Maintenant qu'on a donné toutes les caractéristiques de notre image... il nous reste plus qu'à l'écrire en utilisant un élément Pixel Data (7FE0,0010) :

Références utiles :

• Documentation de l'échantillonnage par pixel (PS3.3 C.7.6.3.1.1)
• Documentation de l'interprétation photométrique (PS3.3 C.7.6.3.1.2)
• Exemple d'encodage d'image dans des éléments « Pixel Data » (PS3.5 D)