Thomas Ledoux

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.

JOYEUSE JOURNÉE MONDIALE DE LA PRÉSERVATION NUMÉRIQUE

VOUS AUSSI, PARTAGEZ VOS HISTOIRES

Properly Rendering 32-bits JPEG

A colorful story by Alix Bruys, Bertrand Caron, Yannick Grandcolas and Thomas Ledoux from the National Library of France (BnF)

[Note : Ce billet existe en version française sous le titre Le blues du JPEG.]

The Context: Acquired Born-Digital Photographs of Parisian Theaters

On October the 20^th of 2017, the Department of Performing Arts of the National Library of France (BnF) acquired a set of 622 born-digital photographs representing architectural elements of the major Parisian theaters (palais Garnier, Comédie-Française, etc). Produced by photographers Sabine Hartl and Olaf-Daniel Meyer in 2012, these photographs were to illustrate the book Théâtres parisiens. Un patrimoine du XIX^e siècle published in 2013 by editor Citadelles et Mazenod. Though all 622 photographs did not appear in the book, the collection manager decided to acquire the whole set. A contract assigned to BnF the rights to publish them online  in its digital library Gallica. The photographs were delivered in the only available format: JPEG.

Thumbnails of the original photographs of the Opéra Garnier Theater, Sabine Hartl & Daniel-Olaf Meyer, 2012-2013.

In the spring of 2018, these 622 photographs were ingested in our Digital Documents Acquisition and Donation workflow, like any born-digital photographs acquired by or donated to BnF. The collection was divided into 30 sub-lots – each theater had two sub-lots, one for published photographs, one for unpublished ones. All photographs successfully passed QA procedures and were ingested in the preservation repository. When the process manager made the final visual control, after the photographs became visible in Gallica, she noticed a blatant color shift on 5 of them. Where one would expect red and gold tones, they were blue and green! In contrast, the other 617 photographs were rendered as expected.

Thumbnails of the same photographs, as available at https://gallica.bnf.fr/ark:/12148/bc6p05jkgg7

The Investigation: IT to the Rescue!

As soon as we were alerted of this situation (red alert ?), we went directly into the data storage, in order to retrieve the dissemination copies. It appears that the file was a regular JPEG 24 bits but with this distinctive blue aspect.

Then we went to query the archival system to see the technical characteristics of the preserved copy. The manifest (expressed in METS) reflects the following technical metadata:

The surprising part was the number of components mix:bitsPerSampleValue=8,8,8,8 which indicates a 32-bits JPEG!!! But the system interpreted it as a regular JPEG.

In order to go deeper, we retrieved the archival package (AIP) from SPAR, our preservation repository: there, we found the unaltered master file that was delivered initially. Opening it with XnView raised an “Alert box” that informed us of the conversion/transformation to a 24-bits RGB colorspace.

Indeed, the original file was a “Well-formed JPEG” but using 4 components (CMYK) to encode the information. This was a surprise because the only JPEGs we encountered before showed either 3 components (RGB color space) or 1 component (grayscale).

The Investigation: Backtracking on the Appraisal Step

We then interrogated the accessioning office about the preliminary controls. Unlike our initial hypothesis, the normal procedure was fully and correctly applied…

The pre-conditioning tool Frontin (a BnF in-house application bundling JHOVE among other programs) carries out a quick analysis and returns a result boiling down to a traffic light: green means that the file is accepted without restriction, red means that the file format is not accepted, yellow means the file analysis raised some warnings. In the case of the 5 CMYK files, the yellow light showed up because the files were JPEG but did not conform to the 24-bits JPEG profile we expected. When agents in charge of pre-conditioning operations are returned a yellow light, they are required to do a visual control to ensure that the content is readable and complete before submitting the package to QA procedures. This visual control was made by opening the files with XnView; the message showed above was displayed but was ignored because the image was rendered normally.

Analysis: What Exactly Went Wrong?

The question raised is whether this file should be considered valid, and does it respect any standard? In fact, “common” JPEGs (the ones coming out from cameras) are 3-components images (24 bits) in sRGB colorspace (the standard Red, Green, Blue). This colorspace is used for displaying images on screen where the different components are added to create the target color.

But here we have a 4-components image (32 bits) in CMYK colorspace. These letters stand for : Cyan, Magenta, Yellow and Key (Black). This colorspace is used for printing since in this case the components are mixed in a subtractive way. 

In order to render correctly an image in CMYK you need to convert it properly to the RGB colorspace. If you ignore the K channel, then you might end up with an inverted-color image (similar to a negative).

How comes we didn’t detect it? JPEG images are standardized in the ISO/IEC 10918 standard “Digital compression and coding of continuous-tone still images”, but 32-bits JPEGs weren’t included in the standard until Part 6 (ISO/IEC 10918-6:2013 or ITU T.872), titled “Application to printing systems”. This part 6 was first published in June 2012 when the part 1 was released 20 years before in September 1992! If we look closely to the coverage of the JHOVE JPEG module (running jhove -m JPEG-hul -h), it states that the coverage is limited to Parts 1 to 5 and to the EXIF format from version 2.0 to 2.2.

In particular, the current version 1.22 of JHOVE is not taking into account the new APP14 marker segment (one that begins by the string ‘Adobe’) which gives the proper information on color encoding (see for example this issue  and a proposed pull-request ). In fact, JHOVE detects this image as “Exif 2.1 (JEIDA-49-1998)” but this is incorrect since the EXIF standard clearly states for the ‘SamplesPerPixel’ tag: “The number of components per pixel. Since this standard applies to RGB and YCbCr images, the value set for this tag is 3.” This image couldn’t be EXIF then and should be validated as something like a ‘Adobe JPEG’.

But detecting is not enough, we also need to convert the image properly so that our dissemination tools can handle it as a more usual 24-bits RGB image.

If you look for solutions on this issue, you will discover that the problem has many solutions all implying that you correctly identify your input format to use the appropriate parameters:

• for ImageMagick, you need to spell (more details here): convert -negate -colorspace RGB input_CMYK_Image.jpg output_RGB_Image.jpg.

• in Java, the standard ImageIO library doesn’t handle it (until recently) so you need extra code or library to handle it [follow the StackExchange discussion]

In our workflow, the problem is made even more complex because every image is first converted to JPEG 2000 in order to comply with the IIIF protocol (for zooming, rotating, transforming, and the like). The initial image is therefore transformed twice: first to JPEG 2000, then back to JPEG but in RGB for Web displaying. The knowledge of the 4th component is lost during the first conversion which leads to the unwanted effect!!!

Lessons Learnt

This misadventure is full of lessons:

• know your tools well, as well as their limits,
• never underestimate simple warnings from them,
• don’t overlook the complexity of apparently simple and well-known file formats: you need to monitor them as they evolve and develop,
• be ready to monitor your tools as well, and request or make enhancements accordingly or even change them,
• be prepared to learn more and share the new knowledge you got  about the formats,
• dissemination is the ultimate judge to know if you handled correctly your information.

HAPPY WORLDWIDE DIGITAL PRESERVATION DAY

SHARE YOUR OWN STORY