Cet article constitue la seconde sous-partie sur les images compressées.
Il traite des syntaxes de transfert et des différents schémas de compression adoptés par DICOM.
Une partie des descriptions des différents schémas de compression est inspirée de l'article « Place des standards dans le contexte de la compression des données médicales » de Bernard Gibaud et Joël Chabriais (voir les références en bas de la page).
En informatique, lorsque l'on désire échanger un objet avec d'autres applications, on utilise un mécanisme de sérialisation. Ce dernier permet de mettre un objet sous une forme (textuelle ou binaire) depuis laquelle il pourra être reconstitué à l'identique. Ainsi il pourra être stocké sur un disque dur ou transmis au travers d'un réseau.
En DICOM, la sérialisation d'un objet (en DICOM classique, XML et JSON) est guidée par la syntaxe de transfert. Cette dernière représente un ensemble de règles qui s'articule autour de deux notions:
Pour une sérialisation au format XML ou JSON, la VR est toujours Explicit car encodée directement dans la représentation XML et JSON d'un Data Element.
Pour l'encodage au format DICOM Classique, la syntaxe de transfert indique si l'encodage de la VR doit se faire implicitement ou explicitement.
Il a été vu dans les articles « Les images en DICOM - Partie 1 » et « Les images en DICOM - Partie 2 » qu'une image peut être compressée ou pas.
Mais comment savoir si une image est compressée ou non?
Une solution consisterait à analyser le tag (7FE0, 0010) Pixel Data. Si une séquence apparaît alors les pixels sont compressés, sinon les pixels ne le sont pas.
Il n'est néanmoins pas possible d'aller plus loin dans l'analyse et de savoir si les pixels sont encapsulés en « JPEG Baseline » par exemple ou en « JPEG2000 Lossless ».
Par conséquent, impossible pour un logiciel de savoir quel Codec utiliser pour décompresser l'image.
La syntaxe de transfert permet de résoudre ce problème en indiquant comment les pixels sont encodés (Natif ou Encapsulé) et quel type de compression a été utilisé.
Une syntaxe de transfert est représentée par un nom et un identifiant unique. Cet identifiant est sous la forme d'un UID (un enchaînement de chiffres et de points - voir PS 3.5 section 9 pour plus de détails).
Exemple : 1.2.840.10008.1.2
Ainsi, en lisant cet identifiant, il est possible de savoir comment les pixels sont encodés et donc de savoir quel Codec utiliser pour décompresser une image.
Avec ces types d'encodages, il n'est pas nécessaire de disposer de codec pour lire ou écrire des images dans un objet DICOM.
L'International Standards Organisation ISO/IEC JTC1 a développé deux standards internationaux nommés ISO/IS-10918-1 (JPEG Part 1) et ISO/IS-10918-2 (JPEG Part 2), et connus comme le standard JPEG.
Ce standard définit des méthodes de compressions avec perte (lossy) et sans perte (lossless). Parmi les 29 procédés de codage (process en anglais) disponibles dans le standard JPEG, DICOM en a retenu 4 (cf. PS3.5 - Tableau A.4-3): les procédés 1, 2, 4 et 14.
La méthode de compression RLE (Run Length Encoding) est utilisée par de nombreux formats d'images tels que BMP, PCX et TIFF. Elle est basée sur la répétition d'éléments consécutifs.
JPEG-LS, à savoir ISO/IS-14495-1 (JPEG-LS Part 1) désigne un autre standard proposé par l'International Standards Organisation ISO/IEC JTC1 pour représenter les images compressées, avec ou sans perte de données. Il spécifie un mode de compression unique, fondé sur une méthode prédictive utilisant un modèle statistique, modélisant les différences entre les pixels et leur voisinage. Cette méthode est réputée plus efficace que celle spécifiée dans JPEG. JPEG-LS peut traiter des images jusqu'à une profondeur de 16 bits (cf. PS3.5 Annexe F.2).
JPEG-2000 est le nom usuel du standard ISO/IEC 15444 (JPEG 2000), toujours dédié à la représentation des images compressées. JPEG 2000 introduit de nouveaux schémas de compression par ondelettes et sur des transformations multi-composantes, applicables notamment aux images en couleur.
La partie 2 du standard (ISO/IEC 15444-2) complète la partie 1 (ISO/IEC 15444-1) avec des extensions des transformations multi-composantes ICT (Irreversible Colour Transform) et RCT (Reversible Colour Transform).
Ces extensions sont d'une part des schémas de prédiction de type DPCM, et d’autre part des transformations plus complexes comme la Transformée de Karhunen-Loeve2. La compression par ondelettes est particulièrement appropriée pour les images.
Voici une section bonus permettant de présenter des syntaxes de transferts un peu spéciales. Le but est de savoir qu'elles existent.
Il traite des syntaxes de transfert et des différents schémas de compression adoptés par DICOM.
Une partie des descriptions des différents schémas de compression est inspirée de l'article « Place des standards dans le contexte de la compression des données médicales » de Bernard Gibaud et Joël Chabriais (voir les références en bas de la page).
En informatique, lorsque l'on désire échanger un objet avec d'autres applications, on utilise un mécanisme de sérialisation. Ce dernier permet de mettre un objet sous une forme (textuelle ou binaire) depuis laquelle il pourra être reconstitué à l'identique. Ainsi il pourra être stocké sur un disque dur ou transmis au travers d'un réseau.
En DICOM, la sérialisation d'un objet (en DICOM classique, XML et JSON) est guidée par la syntaxe de transfert. Cette dernière représente un ensemble de règles qui s'articule autour de deux notions:
- la VR : implicit ou Explicit ;
- La compression des pixels d'une image.
Remarque: Avant 2016, une troisième notion entrait en jeu : l'Endianisme.
L'encodage en Big Endian ayant été retiré du standard en 2016, seul l'encodage Little Endian peut maintenant être utilisé. En théorie, depuis 2016, il ne faut donc plus sérialiser d'objet en Big Endian mais uniquement en Little Endian.
L'encodage en Big Endian ayant été retiré du standard en 2016, seul l'encodage Little Endian peut maintenant être utilisé. En théorie, depuis 2016, il ne faut donc plus sérialiser d'objet en Big Endian mais uniquement en Little Endian.
1. La sérialisation de la VR (Implicit/Explixit)
Pour une sérialisation au format XML ou JSON, la VR est toujours Explicit car encodée directement dans la représentation XML et JSON d'un Data Element.
Pour l'encodage au format DICOM Classique, la syntaxe de transfert indique si l'encodage de la VR doit se faire implicitement ou explicitement.
Remarque : Les notions Implicit et Explicit ont été vues dans les articles « L'encodage d'objet DICOM - partie 1 » et « L'encodage d'objet DICOM - partie 2 ».
2. La compression des pixels d'une image
Il a été vu dans les articles « Les images en DICOM - Partie 1 » et « Les images en DICOM - Partie 2 » qu'une image peut être compressée ou pas.
Mais comment savoir si une image est compressée ou non?
Une solution consisterait à analyser le tag (7FE0, 0010) Pixel Data. Si une séquence apparaît alors les pixels sont compressés, sinon les pixels ne le sont pas.
Il n'est néanmoins pas possible d'aller plus loin dans l'analyse et de savoir si les pixels sont encapsulés en « JPEG Baseline » par exemple ou en « JPEG2000 Lossless ».
Par conséquent, impossible pour un logiciel de savoir quel Codec utiliser pour décompresser l'image.
La syntaxe de transfert permet de résoudre ce problème en indiquant comment les pixels sont encodés (Natif ou Encapsulé) et quel type de compression a été utilisé.
Remarque: La syntaxe de transfert s'applique pour les images fixes et animées (les films) - cf. PS3.6 - Table A.1.
3. Mais comment ça marche une syntaxe de transfert ?
Une syntaxe de transfert est représentée par un nom et un identifiant unique. Cet identifiant est sous la forme d'un UID (un enchaînement de chiffres et de points - voir PS 3.5 section 9 pour plus de détails).
Exemple : 1.2.840.10008.1.2
Ainsi, en lisant cet identifiant, il est possible de savoir comment les pixels sont encodés et donc de savoir quel Codec utiliser pour décompresser une image.
Remarque et spoiler : Pour les fichiers DICOM, la syntaxe de transfert est stockée dans le « File Meta Header » d'un fichier DICOM. En lisant cet en-tête en premier lieu, on détermine s'il faut utiliser un dictionnaire de données ou non pour interpréter les éléments (Implicit ou Explicit) et quel codec il faut utiliser si besoin.
Pour un échange via un réseau, la syntaxe de transfert est négociée entre l'émetteur et le récepteur en début de connexion via une procédure de handshake appelée « Association DICOM » (à l'exclusion des échanges DICOMweb).
4. Les principaux types de compressions pour les images
4.1. Les types Natifs (Non Compressés)
Avec ces types d'encodages, il n'est pas nécessaire de disposer de codec pour lire ou écrire des images dans un objet DICOM.
| Nom | Syntaxe de transfert | Description |
|---|---|---|
| Implicit VR Little Endian | 1.2.840.10008.1.2 | Lorsque cette syntaxe de transfert est utilisée, tous les Data Element doivent être encodés en Little Endian sans inclure la VR (Implicit). Puisque la VR est implicite, il est nécessaire de disposer d'un dictionnaire de données pour apporter un sens aux données. Cette syntaxe de transfert est la seule obligatoire par le standard; c'est-à-dire qu'elle doit être supportée par tous les constructeurs et éditeurs d'applicatifs DICOM. Aucune autre syntaxe de transfert dans le standard n'utilise de VR implicite. En utilisant cette syntaxe de transfert, le tag (7FE0,0010) Pixel Data doit utiliser une Value Representation de type OW (cf. PS3.5 Annexe A.1). |
| Explicit VR Little Endian | 1.2.840.10008.1.2.1 | Avec cette syntaxe de transfert, tous les tags doivent être encodés en Little Endian en incluant la VR (Explicit). Cette syntaxe de transfert est plus régulièrement utilisée, car chaque type de données DICOM est spécifié. En utilisant cette syntaxe de transfert, il n'est plus nécessaire de disposer d'un dictionnaire de données pour interpréter la valeur d'un tag DICOM (cf. PS3.5 Annexe A.2). |
| Explicit VR Big Endian | 1.2.840.10008.1.2.2 | Similaire à la syntaxe de transfert Explicit VR Little Endian à l'exception de l'ordre de stockage des octets. Cette syntaxe de transfert ne fait plus partie du standard depuis 2016 (cf. PS3.5 Annexe A.3). |
4.2. Les types de compressions JPEG
L'International Standards Organisation ISO/IEC JTC1 a développé deux standards internationaux nommés ISO/IS-10918-1 (JPEG Part 1) et ISO/IS-10918-2 (JPEG Part 2), et connus comme le standard JPEG.
Ce standard définit des méthodes de compressions avec perte (lossy) et sans perte (lossless). Parmi les 29 procédés de codage (process en anglais) disponibles dans le standard JPEG, DICOM en a retenu 4 (cf. PS3.5 - Tableau A.4-3): les procédés 1, 2, 4 et 14.
| Nom | Syntaxe de transfert | Description(1), (2), (3) |
|---|---|---|
| JPEG Baseline (Process 1) | 1.2.840.10008.1.2.4.50 | C'est le procédé de base de JPEG (tout décodeur JPEG doit au moins gérer ce mode). Il est basé sur une transformée en cosinus discrète1 (DCT) de base (baseline), et exploite le codage de Huffman. La DCT permet d'éliminer des données non pertinentes pour l’œil humain (destruction de données) avec un ratio ajustable Ce format est toujours destructeur (avec perte) indépendamment du ratio de compression choisi (une image compressée avec une qualité de 100% ne sera pas identique à l'originale). Ce procédé ne fonctionne que pour des images de 8 bits de profondeur (SamplePerPixel = 8). (cf. PS3.5 - Annexe F.1, PS3.5 - Annexe A.4.1, PS3.5 - section 10.3) |
| JPEG Extended (Process 2 & 4) | 1.2.840.10008.1.2.4.51 | Ce procédé ajoute des extensions au mode JPEG Baseline (Process 1). Il peut par exemple, gérer des images ayant 12 bits de profondeur. Ce format est toujours destructeur (avec perte).
- « Process 2 » indique un codage de type DCT séquentiel étendu avec un codage d'Huffman. Chaque échantillon est codé sur 8 bits (SamplePerPixel = 8). - « Process 4 » indique un codage de type DCT séquentiel étendu avec un codage d'Huffman. Chaque échantillon est codé sur 12 bits (SamplePerPixel = 12). |
| JPEG Lossless, Non-Hierarchical (Process 14) | 1.2.840.10008.1.2.4.57 | Ce système de codage correspond au procédé 14 décrit par le standard JPEG, qui indique un codage de type DPCM avec un codage d'Huffman. Chaque échantillon est codé sur 2 à 16 bits. L'idée générale de la méthode DPCM est de prédire la valeur de chaque pixel en fonction de la valeur des pixels précédents. Ce mode de compression est sans perte. |
| JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]) | 1.2.840.10008.1.2.4.70 | Ce mode de codage reprend le précédent en ajoutant une contrainte sur la prédiction (il fait intervenir une prédiction d'ordre 1 - horizontale). Il est également sans perte. |
Remarque: Une image de 8 bits de profondeur peut être encodée via le procédé (process) 1 ou 2. Le standard DICOM recommande d'utiliser le procédé 1 (JPEG Baseline) pour encoder une image de 8 bits de profondeur, à moins que des spécificités liées aux extensions proposées par JPEG Extended ne soient requises (cf. PS3.5 - Annexe A.4.1 - Note 3).
Remarque: Afin de faciliter l'interopérabilité des applications faisant appel aux syntaxes de transfert JPEG, le standard mentionne explicitement:
- que les applications implémentant JPEG « lossless » doivent supporter JPEG Lossless, Non-Hierarchical (Process 14) (cf. PS3.5 - Section 10.2) ;
- que les applications implémentant JPEG « lossy » pour des images sur 8 bits doivent supporter JPEG Baseline (Process 1) (cf. PS3.5 - Section 10.3) ;
- que les applications implémentant JPEG « lossy » pour des images sur 12 bits doivent supporter JPEG Extended (Process 4) (cf. PS3.5 - Section 10.3).
4.3. Le type de compression RLE
La méthode de compression RLE (Run Length Encoding) est utilisée par de nombreux formats d'images tels que BMP, PCX et TIFF. Elle est basée sur la répétition d'éléments consécutifs.
| Nom | Syntaxe de transfert | Description(2), (3) |
|---|---|---|
| RLE Lossless | 1.2.840.10008.1.2.5 | Cette méthode de compression sans perte compresse les données en y recherchant des successions d'octets identiques. L'efficacité de cet algorithme dépend grandement du contenu et de la qualité de l'image. Si les répétitions d'éléments consécutifs ne sont pas nombreuses, l'algorithme n'est pas performant, voir contre-productif (la version compressée est plus volumineuse que la version originale). En réalité, RLE ne compresse que lorsque cela est nécessaire (il laisse la chaîne telle quelle lorsque la compression est contre-productive). Cette méthode fonctionne donc bien sur les images possédant de larges parties uniformes. |
4.4. Le type de compression JPEG-LS
JPEG-LS, à savoir ISO/IS-14495-1 (JPEG-LS Part 1) désigne un autre standard proposé par l'International Standards Organisation ISO/IEC JTC1 pour représenter les images compressées, avec ou sans perte de données. Il spécifie un mode de compression unique, fondé sur une méthode prédictive utilisant un modèle statistique, modélisant les différences entre les pixels et leur voisinage. Cette méthode est réputée plus efficace que celle spécifiée dans JPEG. JPEG-LS peut traiter des images jusqu'à une profondeur de 16 bits (cf. PS3.5 Annexe F.2).
| Nom | Syntaxe de transfert | Description(2), (3) |
|---|---|---|
| JPEG-LS Lossless | 1.2.840.10008.1.2.4.80 | Ce codage utilise JPEG-LS en mode sans perte. Nativement, le standard JPEG-LS spécifie un mode avec perte (near-lossless), mais une compression sans perte peut être atteinte en contraignant la valeur d'erreur à 0 (cf. PS3.5 Annexe F.2). |
| JPEG-LS Lossy (Near-Lossless) | 1.2.840.10008.1.2.4.81 | Similaire à JPEG-LS Lossless mais avec une erreur bornée à une valeur précise. (cf. PS3.5 Annexe F.2). Ce format est avec perte. |
4.5. Le type de compression JPEG-2000
JPEG-2000 est le nom usuel du standard ISO/IEC 15444 (JPEG 2000), toujours dédié à la représentation des images compressées. JPEG 2000 introduit de nouveaux schémas de compression par ondelettes et sur des transformations multi-composantes, applicables notamment aux images en couleur.
La partie 2 du standard (ISO/IEC 15444-2) complète la partie 1 (ISO/IEC 15444-1) avec des extensions des transformations multi-composantes ICT (Irreversible Colour Transform) et RCT (Reversible Colour Transform).
Ces extensions sont d'une part des schémas de prédiction de type DPCM, et d’autre part des transformations plus complexes comme la Transformée de Karhunen-Loeve2. La compression par ondelettes est particulièrement appropriée pour les images.
| Nom | Syntaxe de transfert | Description(2), (3) |
|---|---|---|
| JPEG 2000 (Lossless Only) | 1.2.840.10008.1.2.4.90 | Ce codage utilise JPEG-2000 Partie 1 en mode sans perte. Il fait appel à un schéma de compression par ondelettes, ou à une transformée multi-composantes en mode réversible, sans quantification. |
| JPEG 2000 | 1.2.840.10008.1.2.4.91 | Ce codage utilise JPEG-2000 Partie 1 en mode avec perte de données. Ce mode peut s'appuyer sur des transformées réversibles ou non réversibles, avec ou sans quantification. |
| JPEG 2000 Part 2 Multi-component (Lossless Only) | 1.2.840.10008.1.2.4.92 | Ces deux modes étendent les possibilités des deux précédentes syntaxes de transfert en exploitant les possibilités offertes par JPEG-2000 Partie 2. Il s'agit d'une généralisation du codage multi-composantes (qui est appliqué dans la partie 1 de JPEG-2000), en considérant que toute séquence d'images peut être vue comme une image multi-composantes. Un mécanisme souple permet en outre d'ordonner et de rassembler les composantes en groupes de composantes, pour une efficacité optimale. Appliquées à des images DICOM multi-frames, ces codages permettent une élimination des redondances inter-images. Ceux-ci devraient donc être de plus en plus utilisés, avec la diffusion des nouveaux IOD Enhanced CT et Enhanced MR, qui utilisent largement les images multi-frames. |
| JPEG 2000 Part 2 Multi-component | 1.2.840.10008.1.2.4.93 |
5. Les formats spéciaux
Voici une section bonus permettant de présenter des syntaxes de transferts un peu spéciales. Le but est de savoir qu'elles existent.
| Nom | Syntaxe de transfert | Description(2), (3) |
|---|---|---|
| Deflated Explicit VR Little Endian | 1.2.840.10008.1.2.1.99 | Contrairement aux autres modes de compression du standard, celui-ci ne compresse pas seulement les pixels d'une image, mais encode l'objet DICOM en entier. Pour faire cela, l'algorithme Deflate définit par la RFC 1951 est utilisé. Cela revient à zipper tout l'objet DICOM. Ce format de compression est particulièrement bien adapté pour des objets DICOM sans image (par exemple des objets DICOM SR). Il peut néanmoins être utilisé par la compression d'un objet contenant des images mais des algorithmes comme JPEG-2000 sont mieux adaptés. Ce format de compression est sans perte. Pour plus de détails, voir PS3.5 - Annexe A.5. |
| JPIP Referenced | 1.2.840.10008.1.2.4.94 | Ce système de compression permet de transférer des images de manière progressive, c'est-à-dire en permettant l'affichage des données, avec une précision croissante au fur et à mesure de la transmission. L'utilisateur peut donc voir l'image avant que le transfert ne soit terminé, et l'interrompre si celui-ci n'est plus nécessaire. L'implémentation de ce mécanisme s'appuie sur le Protocole Interactif proposé dans le cadre de JPEG 2000 (JPEG 2000 Interactive Protocol ou JPIP). Son utilisation dans DICOM consiste à ne plus utiliser le tag (7FE0, 0010) Pixel Data mais à utiliser le tag (0028, 7FE0) Pixel Data Provider URL à la place. Ce dernier contient l'URL du site duquel on peut récupérer les images via le protocole JPIP. L'objet DICOM est donc très allégé (car il ne contient plus les pixels de l'image) mais une connexion réseau est nécessaire pour obtenir l'image. Pour plus de détails, voir PS3.5 - Annexe A.6. |
| JPIP Referenced Deflate | 1.2.840.10008.1.2.4.95 | Ce système combine le système JPIP Referenced et Deflated Explicit VR Little Endian. Les pixels sont retirés de l'objet DICOM et mis à disposition sur un serveur via une URL. Le résultat est ensuite compressé en utilisant l'algorithme Deflate. Pour plus de détails, voir PS3.5 - Annexe A.7. |
Ressources :
(1) La transformée en cosinus discrète : http://www.ulb.ac.be/cours/acohen/travaux_2006_infodoc/CompressionNumerique/AvecPertesTDC.htm
(2) Place des standards dans le contexte de la compression des données médicales https://www.researchgate.net/publication/44813913_Place_des_standards_dans_le_contexte_de_la_compression_des_donnees_medicales.
(3) MedicalConnections - Transfer Syntax : https://www.medicalconnections.co.uk/kb/Transfer-Syntax/
