Prendre en charge correctement du JPEG 32 bits

Une histoire haute en couleur d’Alix Bruys, Bertrand Caron, Yannick Grandcolas et Thomas Ledoux de la Bibliothèque nationale de France (BnF)

[Note : This blog is the french version of the JPEG got the Blues blog]

Le contexte : acquisition de photographies nativement numériques de théâtres parisiens

Le 20 octobre 2017, le département des Arts du spectacle de la BnF acquiert un ensemble de 622 photographies numériques natives, consacrées aux éléments architecturaux des principaux théâtres parisiens (Palais Garnier, Comédie française, etc.). Produites par les photographes Sabine Hartl et Olaf-Daniel Meyer en 2012, ces photographies étaient destinées à illustrer le livre Théâtres parisiens. Un patrimoine du XIXe siècle paru en 2013 aux éditions Citadelles et Mazenod. Toutes n’ont pas été publiées mais la chargée de collections décide d’acquérir l’ensemble de ces photographies, publiées et inédites, accompagnées d’une cession de droits de propriété intellectuelle autorisant la BnF à diffuser les photographies sur internet, dans le cadre de la bibliothèque numérique Gallica. Ces photographies sont fournies dans le seul format disponible : le JPEG.

Vignettes des photographies originales de l’Opéra Garnier, Sabine Hartl & Daniel-Olaf Meyer, 2012-2013.

Au printemps 2018, ces 622 photographies, sont traitées dans le cadre de la filière « Acquisitions et dons de documents numériques », de la même manière que les autres fonds photographiques du même type. Elles sont d’abord réparties en 30 lots – deux par par théâtre, en distinguant les photos publiées, des photos restées inédites – puis traitées par la chaîne d’entrée et versées dans le système d’archivage. Au terme de ce traitement, lors du contrôle visuel final dans Gallica, la responsable de filière découvre 5 photos « bleues » … là où on attendait du rouge et du doré ! Les 617 autres photographies, en revanche, présentent un rendu de la couleur conforme aux attentes.

Vignettes des mêmes photographies,rendues visibles sur https://gallica.bnf.fr/ark:/12148/bc6p05jkgg7

L’enquête : l’informatique sur le pont !

Dès que nous avons été alerté de la situation (une alerte rouge, bien sûr 😉), nous sommes allés voir directement dans les données stockées, pour récupérer les copies de diffusion. Le fichier récupéré était un fichier JPEG 24 bits classique mais avec un bleu très marqué.

Nous avons alors interrogé le système de préservation pour récupérer les caractéristiques techniques de la copie de préservation. Le manifeste (exprimé en METS) montrait les métadonnées techniques suivantes :

La partie surprenante était le nombre de composants mix:bitsPerSampleValue=8,8,8,8 qui indique un JPEG en 32 bits !!! Mais le système le considère comme un JPEG classique.

Afin d’approfondir la question, nous récupérons le paquet d’archive (AIP) depuis notre système de préservation, SPAR : là, nous avons bien le fichier maître inchangé équivalent à celui fourni initialement. En l’ouvrant avec XnView, une boîte de dialogue d’avertissement nous informe d’une conversion/transformation dans l’espace de couleur RVB en 24 bits.

En effet, le fichier original est bien un “JPEG bien formé” mais utilisant 4 composants (CMJN) pour coder l’information. C’est une surprise pour nous puisque les seuls JPEG que nous avions rencontrés jusqu’à présent avaient soit 3 composants (espace de couleur RVB) soit 1 composant (en niveaux de gris).

L’enquête : retour arrière sur l’étape d’évaluation

Nous avons ensuite enquêté auprès des responsables des entrées pour savoir comment s’étaient passés les contrôles préliminaires. Contrairement à ce qu’on aurait pu imaginer de prime abord, la procédure avait été appliquée comme prévu.

L’outil de contrôle Frontin (application interne BnF qui utilise JHOVE) propose un contrôle rapide et renvoie un résultat synthétique sous la forme d’un indicateur de type feu de signalisation : vert pour fichier accepté sans restriction, rouge pour un format de fichier non acceptable et jaune pour signaler que le contrôle a soulevé des réserves. Dans notre cas, les 5 fichiers ont allumé le signal jaune car, si les fichiers étaient bien des JPEG, ils n’étaient pas conformes au profil de format attendu (JPEG 24 bits pour les images en couleur). Dans ce cas-là, la consigne veut que l’on procède à un contrôle visuel pour s’assurer de la lisibilité et de la complétude du contenu, avant de procéder au versement dans la chaîne d’entrée. Ce contrôle visuel a été effectué en ouvrant les fichiers avec XnView ; le message d’alerte déjà cité s’est affiché… mais celui-ci a été ignoré puisque la restitution à l’écran semblait normale.

L’analyse : qu’est-ce qui a mal tourné ?

La question se pose de savoir si ce fichier peut être considéré comme valide, et s’il respecte un standard. En fait, les JPEG “classiques” (ceux qui sont produits par les appareils photos) sont des images avec 3 composants (24 bits) dans l’espace de couleur RVB (le classique Rouge, Vert, Bleu). Cet espace de couleur est utilisé pour afficher des images sur un écran où les différents composants sont ajoutés pour créer la couleur cible.

Mais ici nous avons une image avec 4 composants (32 bits) dans l’espace de couleur CMJN. Ces quatres lettres signifient : Cyan, Magenta, Jaune et Noir. Cet espace de couleur  est utilisé dans l’impression puisque dans ce cas les composants sont traitées via une synthèse négative. Pour avoir un rendu correct d’une image en CMJN, il faut donc la convertir convenablement dans l’espace de couleur RVB. En particulier, si le composant N est ignoré, vous obtenez une image intervertie, analogue à un négatif.

Comment se fait-il que rien n’ait été détecté ? Les images JPEG sont standardisées par la norme ISO/IEC 10918, intitulée “Compression numérique et codage des images fixes de nature photographique”, mais les JPEG 32 bits n’étaient pas inclus dans la norme avant la Partie 6 (ISO/IEC 10918-6:2013 or ITU T.872), intitulé “ Application aux systèmes d’impression”. Cette partie 6 a vu sa première publication en Juin 2012 alors même que la partie 1 a été publiée 20 ans auparavant en Septembre 1992 ! Or, si l’on observe attentivement la couverture du module JPEG de JHOVE (en exécutant jhove -m JPEG-hul -h), il est énoncé que cette couverture est limitée aux Parties 1 à 5 ainsi qu’au format EXIF des version 2.0 à 2.2.

En particulier, la version courante  1.22 de JHOVE ne prend pas en compte le nouveau segment marqué APP14 (celui qui commence par la chaîne de caractères ‘Adobe’) qui fournit la bonne information sur l’encodage de la couleur (voir en particulier cette demande et la correction proposée). En fait, JHOVE détecte cette image comme un “Exif 2.1 (JEIDA-49-1998)” ce qui est incorrect puisque le standard EXIF stipule clairement pour l’étiquette ‘SamplesPerPixel’ : “Nombre de composants par pixel. Comme ce standard s’applique aux images RVB ou YCbCr, la valeur de cette étiquette vaut 3.[The number of components per pixel. Since this standard applies to RGB and YCbCr images, the value set for this tag is 3].”  Cette image ne peut donc être EXIF et devrait être validée comme une image du genre ‘Adobe JPEG’.

Mais la détection n’est pas suffisante, nous devons aussi convertir cette image correctement de telle sorte que les outils de diffusion puissent gérer une image 24 bits RVB plus conventionnelle.

Si vous cherchez des solutions à ce problème, vous découvrirez que ce dernier a de nombreuses solutions qui impliquent toutes d’identifier clairement le format d’entrée pour mettre en œuvre les paramètres adéquats :

• pour ImageMagick, vous devez utiliser l’incantation suivante (plus de détails ici) : convert -negate -colorspace RGB input_CMYK_Image.jpg output_RGB_Image.jpg
• en Java, la librairie standard ne gère pas cela (jusqu’à récemment) et nécessite du code supplémentaire ou une librairie spécifique pour y parvenir [suivre la discussion StackExchange]

Dans notre chaîne de traitement, le problème est rendu encore plus complexe parce que chaque image est d’abord convertie en JPEG 2000 pour permettre la mise en oeuvre du protocole IIIF (qui permet le zoom, la rotation, la transformation, et toutes ces sortes de fonctionnalités). L’image initiale est donc transformée deux fois : d’abord en JPEG 2000, puis de nouveau en JPEG mais en RVB pour une diffusion sur le Web. La connaissance du 4^ème composant est perdue pendant la première conversion ce qui provoque cet effet inattendu !!!

Quelques leçons à retenir

Cette mésaventure est pleine d’enseignements :

• apprenez à bien connaître vos outils, ainsi que leurs limites,
• ne sous-estimez jamais leurs avertissements, même les plus élémentaires,
• ne négligez pas la complexité des formats de fichiers apparemment simples et connus : vous devez les surveiller au fur et à mesure de leur évolution et de leur développement,
• soyez prêt à surveiller également vos outils, et demandez, ou faites les améliorations nécessaires, ou alors changez-en,
• soyez disposé à en apprendre toujours plus sur les formats et à partager cette connaissance nouvelle,
• la diffusion est le juge ultime pour vous assurer que votre information est correctement traitée.