Le défi

La page couverture d’un livre est un des éléments les plus tangibles pour décrire une oeuvre. Elle est souvent utilisée pour mettre les oeuvres en valeur dans les librairies et les bibliothèques. C’est également cas, quasi systématiquement, dans les références en ligne : librairies et bibliothèques numériques, cartes enrichies dans les résultats sur Google, réseaux sociaux spécialisés dans la lecture…

Il n’est donc pas étonnant que les professionnels de l’édition consacrent tant d’efforts à créer de « bonnes » pages couvertures, et tentent de comprendre les facteurs qui font qu’une couverture « vend ».

D’un autre côté, on constate qu’il existe assez peu de moyens, dans une perspective de découvrabilité, de trouver des oeuvres en fonction de leur couverture. On peut assez facilement retrouver un livre dont on connaît l’auteur, le titre et la maison d’édition. Mais ce n’est pas le cas si on se souvient seulement que la page couverture est bleue et grise et montre un cheval tirant une voiture devant une grande maison.

Or, notre conviction, c’est qu’un certain nombre de consommateurs cherchent des livres comme ça : parfois avec un élément du titre, et typiquement avec une description de la page couverture. Nous émettons donc l’hypothèse qu’il serait avantageux d’enrichir les métadonnées qui décrivent les livres par un descriptif de leur page couverture. Cette description pourrait prendre la forme d’une énumération de ce qu’on y voit et des couleurs dominantes.

Nous croyons également qu’il est nécessaire de le faire de façon automatisée ou semi-automatisée, sur de grands volumes de titres. Cela permettra d’obtenir la masse critique qui amènera les plateformes qui présentent les oeuvres à utiliser ces nouvelles métadonnées.

Nous émettons donc une seconde hypothèse : il est possible d’automatiser la création de métadonnées descriptives d’images. Nous avons donc entrepris une expérience pour vérifier cette seconde hypothèse. Voici notre démarche, et les résultats obtenus à ce jour.

Identification des outils à notre disposition

Les avancées en traitement d’images constituent un des éléments les plus frappants dans le domaine de l’intelligence artificielle. Et il existe une panoplie d’outils disponibles gratuitement ou à peu de frais pour entraîner des réseaux de neurones à identifier les éléments présentés dans une image.

Dans l’esprit d’arriver rapidement à des résultats de façon efficace, nous avons choisi d’aborder le problème en utilisant des algorithmes de reconnaissance d’images préexistants, mais qui ne sont pas spécialisés dans le traitement des couvertures de livres. L’alternative aurait été d’entraîner nous-mêmes des réseaux neuronaux — mais c’est une solution qui aurait été clairement plus complexe et vraisemblablement plus coûteuse.

Il existe différentes API de description d’images. Nous en avons identifié six, offertes par les grands joueurs de l’industrie techno (IBM, Microsoft, Google, Amazon) ou des startups spécialisés en IA (Clarifai, Cloudsight).

Méthodologie d’évaluation

Comme première démarche d’évaluation des différentes API, nous souhaitons avoir un portrait global des résultats obtenus sur un échantillon représentatif de pages couvertures.

Nous avons choisi de façon aléatoire une cinquantaine d’images de notre corpus (environ 2500 titres provenant de 6 éditeurs québécois au moment de faire l’expérience), avec une représentativité de chaque éditeur proportionnelle à la taille du catalogue auquel nous avions accès. Nous avons fait une démarche de description des images, avec des mots-clés et des couleurs, « à la main » (donc pas d’API impliquée, mais un humain qui faisait le travail). Le fichier de travail est ici.

Dès cette première étape, il nous est apparu évident que nos API auraient du mal à décrire certaines images… Notre échantillon contenait certaines couvertures claires, montrant des images simples. Mais il contenait également des images abstraites, floues, ou avec un traitement artistique particulier qui les rend plus difficiles à décrire, même pour un humain.

Nous souhaitions par la suite obtenir les résultats des API identifiées. Avec 50 images pour 6 API, l’utilisation des outils de tests manuels en ligne aurait impliqué beaucoup, beaucoup de manipulations… Heureusement, Gaurav Oberai a partagé l’outil qu’il a développé, nommé Cloudy Vision, pour automatiser une démarche similaire à la nôtre en 2016. Il s’agit essentiellement d’un script qui utilise les API, soumet les images, et génère un rapport agrégeant tous les résultats.

Après avoir installé le script, nous avons constaté que les API avaient beaucoup changé depuis 2016. Il fut donc nécessaire de faire des adaptations… Nous en avons profité pour bonifier le script pour lui faire extraire quelques informations supplémentaires et les afficher dans le rapport. Il s’agit des couleurs dominantes, et des annotations en français lorsqu’elles étaient disponibles.

Notre version modifiée du code source est disponible sur le compte Github de Projet TAMIS, et nos modifications seront vraisemblablement intégrées dans le projet d’origine.

Résultats

Le rapport généré par Cloudy Vision est intégralement disponible en ligne.

Nous observons toutefois déjà quelques tendances.

Sur les couleurs, seule l’API d’IBM retourne des noms de couleurs qui correspondent (plus ou moins) à une requête que formulerait un humain. Les codes de couleur retournés par l’API de Google ne sont d’aucune utilité pour les besoins qui nous intéressent.

CloudSight semble identifier la majorité de nos livres… comme des livres! Comme il ne fournit pas de description de ce qui est illustré sur la couverture, il est de bien peu d’utilité.

Les résultats de description d’images ont de l’intérêt pour les photos ou les illustrations réalistes. Les résultats se gâtent pour les illustrations trop stylisées, ou les représentations plus abstraites.

Il faut noter que les résultats sont assez inégaux. Sur l’illustration précédente, Google a donné des résultats corrects : « cartoon (.94) , facial expression (.94) , text (.93) , flower (.83) , emotion (.82) , clip art (.81) , play (.78) , art (.75) , smile (.75) , child (.74) ». Les écarts de performance sont visibles ailleurs également.

Il faut également noter que seule l’API d’IBM permet d’obtenir des résultats en français. Dans tous les autres cas, les résultats sont en anglais. Cela ajoutera un défi supplémentaire à l’utilisation des résultats. Il existe des solutions pour traduire des textes de façon automatique, et on peut penser que les résultats seront plus satisfaisants sur de simples mots (ce que nous traitons) que pour de longs textes. Toutefois, sans le contexte, on peut également émettre l’hypothèse que certaines traductions seront erronées.

Parmi les autres trouvailles étonnantes, notons que l’API de Google permet d’identifier les oeuvres reprises sur les pages couvertures.

Nous publierons prochainement notre analyse plus détaillée de ces résultats, afin d’identifier si certaines de ces API sont suffisamment précises pour atteindre nos objectifs initiaux, à tout le moins pour certaines catégories d’images.

Mise à jour 27 septembre 2018: la deuxième partie du texte est maintenant disponible.