Informationswissenschaft - Theorie, Methode und Praxis / Sciences de l'information - théorie, méthode et pratique

Examinons un cas concret qui rappelle que chaque appareil gère son propre espace de couleurs. Prenons le cas d’un utilisateur qui visionne sur un écran une image numérisée à l’aide d’un scanner. Supposons que certains pixels de l’image aient été codés comme du rouge primaire par le scanner: (255,0,0) dans l’espace de couleurs RVB du scanner. Si cette image est fournie sans aucune précaution, l’écran affichera le rouge primaire (255,0,0) correspondant à son propre espace RVB. Et cet espace n’a aucune raison d’être le même que celui du scanner. Par conséquent, l’image que l’utilisateur visionne sur l’écran ne correspond pas, en termes de couleurs, au document qui a été numérisé.

De sorte à pouvoir maintenir la fidélité des couleurs tout au long d’une chaîne allant de la production des images à leur visualisation, on utilise un espace de couleurs intermédiaire et standardisé. Différents espaces de couleurs standardisés par la CIE existent. Par exemple, CIE L*a*b*, datant de 1976, est un tel espace. Ce standard décrit l’ensemble des couleurs qu’un humain perçoit. De plus, cet espace est conçu pour que la distance mathématique entre deux triples associés à deux couleurs corresponde à la différence de perception visuelle entre ces deux couleurs. A titre d’exemple, il y a la même différence de perception entre les couleurs représentées par (50,100,150) et (50,100,200) et entre les couleurs représentées par (50,100,200) et (50,150,200).

L’existence d’un tel espace standard permet de respecter les couleurs tout au long d’une chaîne. Mais pour cela il faut introduire le concept de profil ICC, introduit par l’ICC et reconnu conjointement par l’Organisation Internationale de normalisation (ISO) et par l’ICC (ISO 15076–1). Un profil ICC établit la correspondance entre un espace de couleur d’intérêt (par exemple celui d’un scanner ou d’un écran) et un espace de couleur standardisé (CIE L*a*b* par exemple).

Retournons à l’exemple de l’utilisateur qui visionne sur un écran une image numérisée par un scanner. Cette fois, supposons que le scanner est muni d’un profil ICC. De même, supposons que l’écran dispose de son propre profil ICC. A nouveau, regardons le cas du pixel dont la couleur est codée (255,0,0) par le scanner. Lorsque l’écran affiche ce pixel, il va suivre le processus suivant: il cherche d’abord à quelle couleur dans l’espace CIE L*a*b* correspond (255,0,0), en utilisant le profil ICC du scanner. Appelons «rouge» cette couleur. Puis il s’agit de voir à quoi correspond ce «rouge» dans l’espace de couleurs de l’écran, en utilisant le profil ICC de ce dernier. Ce pourrait être (252,10,15) par exemple. Maintenant, le respect des couleurs est assuré tout au long de la chaîne!

Comme le rouge, codé (255,0,0), du scanner pouvait être représenté par l’écran, il a été possible de conserver cette couleur sur le chemin entre le scanner et l’écran. Toutefois, il peut arriver que le gamut de l’écran ne contienne pas le rouge indiqué par le scanner. Dans un tel cas, l’écran affiche le rouge le plus «proche» possible.

Pour que ce qui précède puisse fonctionner, il est nécessaire que les logiciels permettant l’affichage d’une image aient accès au profil ICC du scanner. Pour cela, il y a deux possibilités. L’une est d’intégrer le profil dans le fichier de l’image. Pour ce faire, il faut que l’image matricielle soit codée dans un format qui permet d’intégrer le profil ICC du scanner. La solution alternative est d’indiquer l’endroit où les logiciels peuvent trouver le profil ICC, sauvegardé de manière indépendante.

Il semble que la solution qui s’est imposée soit celle de l’intégration du profil ICC dans le fichier de l’image. Cette solution a l’avantage de lier le profil avec l’image. Cela permet de faciliter la gestion de la correspondance entre les images et le profil ICC du scanner lors de l’échange d’images, mais aussi dans le cours de l’archivage. A l’inverse, il y a aussi un désavantage puisque l’on constate que le même profil est susceptible d’être conservé en de multiples copies. Ce qui augmente légèrement l’espace de stockage nécessaire. A titre d’illustration, remarquons que la Bibliothèque de Genève (BGE) conserve actuellement plus de 800 000 images dans le cadre du projet e-rara. Chacune de ces images contient un profil ICC, alors que seuls 5 profils différents ont été utilisés. Sur la base d’un poids moyen de 265 Ko par profil ICC, il en résulte un poids supplémentaire d’environ 200 Go. Ce poids correspond approximativement à 1,5 % du poids total des 800 000 images, ce qui donne la mesure de l’économie qui pourrait être réalisée en n’intégrant pas les profils dans les images.

Il existe un très grand nombre de formats d’images, comme cela est illustré par le travail de J. Murray et W. van Ryper. 17Dans le présent article, on se contente d’examiner l’utilisation des formats largement acceptés dans le monde des archives, des bibliothèques et au-delà. En effet, porter son choix sur un format rarement utilisé comporte des risques importants pour des raisons évidentes.

Le format TIFF, propriété d’Adobe et publié pour la première fois en 1986 par Aldus, est un format dont la principale caractéristique est une grande souplesse. Par exemple, il peut être utilisé sans compression, mais il peut aussi être utilisé avec une compression sans perte (algorithme RLE, de Huffman, LZW, Groupe 3 et Groupe 4) ou avec perte (JPEG). Il peut également être utilisé en mode «multi-page», qui permet de conserver et transmettre plusieurs images en un seul fichier. En ce qui concerne les couleurs, il peut aller jusqu’à 48 bits par pixel, voire plus.

Toutefois, cette souplesse peut aussi être un obstacle: en effet, un logiciel de visualisation donné ne décode pas nécessairement toutes les versions possibles du format TIFF. Par exemple, les logiciels de visualisation peuvent se contenter d’afficher la première image d’un fichier multipage, sans capacité de lire les images suivantes.

Le format TIFF est répandu. En particulier, le secteur des archives et des bibliothèques a fait du format TIFF (TIFF 6.0 datée de 1992) sans compression le standard de fait dans le domaine de l’archivage à long terme. 18De même, Google fait usage de ce format pour sa bibliothèque numérique «Google Livres» selon A. Jacquesson. 19

La spécification du format TIFF est divisée en deux parties. La première partie définit le format TIFF Baseline, et les Archives et bibliothèques exigent souvent que les images respectent ces exigences plus restrictives.

La spécification du format TIFF, gratuitement disponible sur le site web d’Adobe, ne prévoit pas l’intégration d’un profil ICC. Mais la flexibilité du format TIFF permet tout de même l’intégration d’un profil ICC dans un fichier respectant ce format. Ceci est expliqué dans l’annexe de la spécification du format ICC. 20Toutefois, étant donné l’absence d’indication dans la spécification du format TIFF, les logiciels capables de décoder un fichier TIFF n’en tiennent pas nécessairement compte.

En fait, JPEG n’est pas un format mais un algorithme de compression efficace, mis au point par le comité JPEG et normalisé par l’ISO et l’UIT en 1992 (ISO/IEC 10918–1 ou UIT-T T.81). L’algorithme JPEG peut être utilisé dans divers formats, tel TIFF ou PDF. Toutefois, il existe un format spécifiquement conçu pour JPEG: c’est le format JFIF (ISO/IEC FDIS 10918–5), et c’est à lui que l’on pense lorsqu’il est question de JPEG comme format d’image. Ce format permet de gérer des images en couleurs allant jusqu’à 24 bits par pixel.