Les travaux d'étudiants de la promotion 1973 de l’École Normale Supérieure (Normale Sup) sont à l'origine de la production, dès 1977, d'une famille de circuits intégrés (CI) dédiés à l'affichage sur écran (à l'époque, cathodique ).

Cette dépêche est consacrée à l'un d'entre eux, l'EF9365 (ou le "365" pour les intimes), qui est stricto sensu le premier GPU (excusez-du peu !) et nous verrons pourquoi.

	Le circuit intégré Thomson-Efcis EF9365
	Contrôleur de visualisation graphique,1980

Les rédacteurs de cette dépêche collaborative remercient :

• Philippe Matherat, le concepteur de ce composant ! Il a eu la gentillesse de se prêter au jeu en répondant à nos questions et en apportant de nombreuses précisions et anecdotes –les citations dans la dépêche sont intégralement de sa main– ;
• PulkoMandy, pour son journal d’archéologie informatique sur la thèse de Jean Gastinel. Sans ce journal, cette dépêche n'aurait jamais vu le jour ;
• Jean-François DEL NERO, développeur de l’émulation du 365 dans Mame, pour les échanges et les apports techniques ;
• l'équipe de rédaction du magazine Sciences et Avenir, pour l'autorisation de publier des extraits de l'article "le Silicon labo de la rue d'Ulm", n° 455 (Janvier 1985).

Sommaire

• Généalogie des puces EFxxxx
  • La génèse
  • Une question de mémoire
  • Pourquoi cette augmentation de la capacité de la RAM à cette époque ?
  • Le plastique, c'est fantastique
  • La production
    • L'histoire industrielle du fondeur
    • Dates de production
• La petite famille
  • L'EF9364, le précurseur
  • L'EF9365
  • Le NEC µPD7220 : le cousin Japonais
  • L'EF9340 et 9341
  • L'EF9345, la cheap chip
  • La suite pour ST
• Le génie de l'EF9365
  • Un vrai framebuffer
  • La décharge du CPU pour certaines tâches
    • Le tracé de lignes
    • Traitements hardware sur les caractères
      • Redimensionnement matériel (jusqu'à 16x)
      • L'effet Italique
    • Autres fonctionnalités
    • et… concrètement ?
    • Est-ce vraiment le premier GPU ?
• Et le libre dans tout ça ?
• Le 365 a-t-il fait un flop ?

Généalogie des puces EFxxxx

Un GPU est un composant informatique (une puce dédiée dans les cartes graphiques des PC ou intégrée au processeur central (CPU) de votre téléphone (soc)) initialement dédiée à l'affichage d'images.

D'abord limité à l'affichage 2D, il a rapidement pris le relais du CPU pour gérer les calculs parallèles de la 3D. Aujourd'hui, cette puissance brute sert autant au traitement vidéo qu'à des domaines bien éloignés des pixels, comme le minage de cryptomonnaies ou l'IA.

Cette bascule technologique a récemment propulsé nVidia, le principal acteur du marché, au sommet de l'économie mondiale.

Pourtant, bien avant cette folie financière et les géants américains ou asiatiques, c'est en France qu'est née cette architecture moderne.

Cette dépêche vous propose de découvrir l'histoire du 365, le premier GPU sur puce unique.

La génèse

	Extraits de l'article "le Silicon labo de la rue d'Ulm" de Dominique COMMIOT
	© Sciences et Avenir n° 455 (Janvier 1985)
	À gauche, Jean GASTINEL devant le bâtiment historique de l'ENS.
	À droite, Philippe MATHERAT et un extrait de l'article.

Philippe Matherat avait résumé ainsi le contexte de cette épopée dans l'article de PulkoMandy :

Nous étions une bande de copains, élèves de l’Ecole Normale Supérieure, de la promotion 1973.

L’informatique était balbutiante, les ordinateurs étaient gigantesques (un bâtiment), très rares et très chers. Personne n’envisageait qu’ils puissent être répandus et bon marché.
Les seuls écrans connus étaient ceux de la télévision. Les terminaux informatiques étaient des machines à écrire mécaniques actionnées par des relais électromécaniques. Ces terminaux étaient reliés à des gros ordinateurs distants, par une ligne téléphonique dédiée.
La fréquence d'horloge des ordinateurs les plus puissants était 12 MHz.

Jean Gastinel était le seul de notre promotion qui connaissait un peu ce qui se passait aux Etats-Unis, grâce à son père : Noël Gastinel, qui était professeur à Grenoble et qui avait fait des voyages dans les universités américaines et chez IBM. Il avait fait équiper l’université de Grenoble d’un ordinateur IBM 360/68.
Jean Gastinel, avec Jean-Marc Frailong et Jean-Luc Richier, ont réalisé un ordinateur 12 bits, à base de circuits MSI de Texas-Instruments, dans les années 1973-1975.

Puis Jean-Gastinel s’est lancé dans la conception du circuit d’affichage alpha-numérique, qui a été commercialisé sous le nom de SFF364 puis EF9364 (le changement de nom correspond au changement de nom de la société Sescosem en EFCIS). Cette conception a fait l’objet de sa thèse de 3è cycle.

Depuis cet article, P. Matherat a détaillé :

Quand je suis entré à l’ENS en 1973, il n’y avait pas de labo d’informatique, ni d’électronique. Les disciplines (en sciences) étaient les disciplines classiques de l’université : mathématique, physique, chimie, biologie, etc. Les chercheurs et les élèves avaient accès à un "Centre de calcul", dirigé par Maurice Vallino, qui consistait en un terminal (lecteur de cartes perforée et imprimante) connecté à un ordinateur Univac de l’université d’Orsay par une ligne à 1.200 bits/s, puis plus tard équipé d’un mini-ordinateur CII Mitra 15. Nous avons eu des cours de programmation Fortran par Jacques Arsac. Nous avions aussi accès à une formation en électronique (analogique), dans un local du labo de physique, fait par F. Lenouvel.

Quand Jean Gastinel a souhaité réaliser un ordinateur, associé à J-M Frailong et J-L Richier, ils sont allés à Jussieu, à l’institut de programmation, où il y avait une équipe qui réalisait des montages électroniques, dirigée par Gérard Noguez. Puis, ils ont souhaité continuer à l’ENS, et M. Vallino leur a cédé une petite pièce annexe du Centre de calcul, ainsi qu’un petit budget annuel de 10.000 F. C’est dans cette pièce que Jean a réalisé la maquette du 364, puis j’ai continué là avec la maquette du 365.

Ce que nous appelions "maquette" était le câblage d'une émulation de la future puce à l'aide de circuits MSI existants (des centaines), afin de pouvoir tester en temps réel la conception logique. Il n'existait aucun outil de CAO. Tout était câblé à la main, sans simulation préalable, et notre principal outil était l'oscilloscope pour vérifier les signaux. Avec des fréquences de l'ordre de quelques MHz, il nous fallait un oscilloscope haut de gamme.

Une question de mémoire

Sans la capacité d'Intel à produire en masse des puces DRAM de plus en plus denses, le 365 n'aurait jamais pu exister :

À la suite du 364, j’ai pensé qu’on pouvait faire du graphique : j'ai commencé cette étude en 1976, à l'occasion de mon DEA d'informatique. Il faut bien voir que ceci n’est devenu possible que grâce aux nouvelles mémoires de 4 Kbits, car un affichage 512 x 512 à 1 bit/pixel nécessite 64 boîtiers mémoires de 4 Kbits. En fait cela ne devient raisonnable qu’avec 16 boîtiers de 16 Kbits (soit 32 K octets). Il n’était donc pas possible de faire un GPU avant ces années-là. Mon mérite a été d’avoir le flair de voir qu’une période nouvelle pouvait s’ouvrir, et que les écrans graphiques pouvaient se démocratiser.

Mais utiliser 32 K octets rien que pour l'écran paraissait délirant, à une époque où la mémoire "centrale" utilisée par le CPU pour son programme et ses données ne dépassait pas 4 ou 8 K octets. Quand à vouloir faire de la couleur avec 3 bits par pixel, là j'étais vraiment pris pour un fou. Songez qu'un adressage sur 16 bits (cas des microprocesseurs de l'époque) ne permet pas de dépasser 64 K (= 2¹⁶ ).

	Le marché aux puces des seventies
	Naissance et évolution des composants DRAM

Notez bien que, à l'époque, la capacité de ces mémoires s'exprime en bits (non pas en octets), et par un simple « K » : ce k majuscule vaut 1 024 bits (le kibibit actuel) et non 1 000. Pour résumer et par exemple, il faut traduire 16K par 2 kio.

Pourquoi cette augmentation de la capacité de la RAM à cette époque ?

Les circuits de RAM nécessitent un très grand nombre de transistors, mais sont très répétitifs : ils coûtent donc relativement peu cher à concevoir, mais demandent une chaîne de production de semi-conducteurs de très bonne qualité. Les fabricants de semi-conducteurs Japonais sont ceux qui vont le mieux maîtriser ce type de produit, fournissant des composants de plus en plus grande capacité à des prix écrasant la concurrence américaine. Intel ne s'en remettra qu'avec de grosses difficultés. Un autre fondeur de RAM américain, Mostek, n'y survivra pas et sera revendu à Thomson-CSF, qui rentabilisera largement son investissement en exploitant les brevets ainsi rachetés.

Le plastique, c'est fantastique

En creusant le sujet de ces premières mémoires vives, on comprend qu'il y a eu une autre évolution importante : le choix du matériau pour le boîtier.

Les boîtiers des premiers CI (dont la référence est préfixée par "C" ou "D") étaient en céramique : c'était coûteux mais dans les début des années 70 seul ce matériau répondait aux besoins de dissipation thermique et d'étanchéité.
Au départ, les fabricants avaient du mal à stabiliser le plastique, car l'humidité finissait par s'infiltrer par capillarité le long des pattes en métal, provoquant la corrosion de la puce.
Pour protéger la puce, il lui a été ajouté une couche (au nitrure de silicium), dite "de passivation", qui permet le contact avec le plastique.
Plus tard dans la décennie (à partir des puces 16K soit vers 1977), la transition vers le plastique s'opère massivement, leur référence est alors préfixée par "P".
Le moulage plastique a permis de produire des puces à la chaîne à un prix dérisoire par rapport au processus artisanal du boîtier céramique multicouche.

La production

L'histoire industrielle du fondeur

• 1969 : Création de Sescosem (Société Européenne de Semiconducteurs et de Microélectronique), filiale de Thomson-CSF.  
  Selon Wikipedia : Thomson-CSF est le résultat de la fusion réalisée en 1968, du groupe électronique Thomson (filiale de Thomson-Brandt) et de la Compagnie générale de télégraphie sans fil (CSF). Leurs filiales dédiées aux circuits intégrés, respectivement SESCO et COSEM, sont donc fusionnées pour devenir SESCOSEM.
• 1976 : Sescosem devient EFCIS (Étude et Fabrication de Circuits Intégrés Spéciaux). C'est à ce moment précis que la référence change : le SFF364 devient l'EF9364.
• 1983 : Thomson-CSF réorganise ses activités. EFCIS est intégrée au sein de la branche Thomson Semiconducteurs. C'est l'époque de la grande offensive sur le marché grand public avec le Minitel et les ordinateurs (Alice, VG5000) utilisant les dérivés comme l'EF9345.
• 1987 : Thomson Semiconducteurs fusionne avec la branche composants de l'italien SGS (Société Générale Semiconduttori). Naissance de SGS-Thomson Microelectronics.
• 1998 : SGS-Thomson est renommé STMicroelectronics (ST), le nom que nous connaissons aujourd'hui : une multinationale franco-italienne de droit néerlandais.

	Fabrication de circuits à la COSEM
	source https://aconit.inria.fr/omeka/items/show/681 E. Gillet, Les transistors, ces magiciens.
	Gamma Presse, 1964. Crédits photo : René Bouillot.

Dates de production

Chronologiquement, Sescosem ou EFCIS ne faisaient pas de tels chips pour écrans avant que les élèves de l’ENS lui en apportent :

• En premier, Jean Gastinel a conçu le circuit alphanumérique EF9364, de 16 lignes de 64 caractères, qui est sorti vers 1977.
• Ensuite, j’ai conçu le premier chip graphique EF9365, de 512x512 pixels, qui est sorti vers 1980, avec sa variante EF9366 (balayage non-entrelacé).
• Le circuit 9367 est une variante du 9365, avec des performances augmentées.
• Les circuits du genre 9345 sont postérieurs au 9365, ils utilisent les éléments de base des circuits précédents, et ont été demandés par les concepteurs du minitel, qui sont donc des copies, variantes, des circuits conçus par les élèves de l’ENS.

	Chronologie de mise sur le marché
	des puces EF9xxx et quelques consœurs

La petite famille

L'EF9364, le précurseur

L'année dernière, PulkoMandy a exhumé la thèse de Jean Gastinel "Conception et intégration d'un terminal alphanumérique", qui pose avant l'heure les bases du Minitel et qui est aussi à l'origine de l'aîné de la famille : l'EF9364 est un contrôleur vidéo purement alphanumérique (affichage de 16 lignes de 64 caractères).

Cette thèse est une véritable pépite pour les férus d’archéologie informatique, on y trouve notamment tous les détails sur la réalisation du CI :

fig 1.10 - Dessin final des cinq masques superposés - Chapitre 1	fig 4.2 Montage des "puces", Chapitre III "Intégration du circuit "VISU" de la thèse

Ce composant est prévu pour réaliser un terminal passif, sans microcontrôleur. Avant son arrivée, toute la logique vidéo des terminaux était implémentée par de la logique discrète: une centaine de puces électroniques étaient nécessaires. Les autres composants d'un terminal, comme le modem et le contrôleur de clavier, bénéficiaient déjà de solutions intégrées. Ce composant rend donc possible la construction d'un terminal à très bas coût avec quelques dizaines de composants.

Il implémente tout de même des fonctionnalités de défilement de l'affichage, de déplacement du curseur, et d'effacement partiel (tout l'écran visible, la ligne courante, depuis le curseur jusqu'à la fin de la ligne). Ces fonctionnalités sont similaires à ce qui se fait sur les terminaux de l'époque (VT52 chez DEC, ADM-3A, …). Cependant, les générations suivantes de terminaux à partir du VT100 choisiront plutôt d'utiliser un microprocesseur.

La génération des caractères proprement dit est effectuée par un composant séparé appelé générateur de caractères. Il s'agit dans le cas le plus simple d'une ROM programmée avec une police bitmap de taille fixe.

Pour les nostalgiques du rendu d'affichage alphanumérique (le seul proposé par cette puce) sur un écran de l'époque, vous pouvez essayer cool-retro-term (lien qui devrait être sponsorisé par le SNOF)

	Simulation d'affichage sur tube cathodique
	par cool retro term, à la EF9364
	(alphanumérique, 64 colonnes x 16 lignes)

L'EF9365

Second de la famille, c'est l'objet de notre dépêche : voir la section suivante qui lui est dédiée.
Nous passons souvent sous silence le EF9366, qui est très proche du 365, mais les 2 sorties sont vraiment concomitantes.

En fait, les 9365 et 9366 sont sortis en même temps, c’est moi qui avais fait la modification qui supprime l’entrelacement (pour le 9366), car le premier client (Secapa), qui avait travaillé sur la maquette de simulation du 365, ne supportait pas le clignotement de l’affichage 512x512. Pour moi, l’intérêt était d’avoir une résolution élevée, et je conseillais d’utiliser un CRT avec des phosphores plus rémanents. Mais les CRT les moins chers (TV) avaient des phosphores rapides.

Nous passons aussi sous silence le EF9367, sorti plus tard, proche du 365 mais supportant des résolutions supérieures.

Le NEC µPD7220 : le cousin Japonais

Ce composant n'est pas compatible avec la série EF9365. Cependant, il a un fonctionnement assez similaire. Commercialisé en décembre 1981, il a été développé à partir de 1979, et probablement inspiré par la présentation du travail sur le 365 au SIGGRAPH en 1978.

En plus des lignes, rectanges et textes, il peut tracer des cercles, arc de cercles et autres courbes. Il est également prévu pour s'interfacer avec un contrôleur DMA, ce qui facilite l'échange de données avec le CPU de contrôle.

Le design de NEC a également été produit par Intel, qui continuera à faire évoluer cette famille de composants. C'est donc un ancêtre des GPU Intel toujours en production aujourd'hui.

L'EF9340 et 9341

Ces deux composants sont au cœur des premiers modèles de Minitel, il s'agit d'une adaptation "low cost" et d'un retour au mode alphanumérique. Ils sont conçus en 1980-1981.

Les premiers prototypes du Minitel utilisent des circuits de chez TI (que l'on retrouvera également dans l'ordinateur Exelvision EXL100). Mais les modèles de production se tournent vers une solution "made in France". Thomson EFCIS se charge de la conception de ces circuits qui sont fournis à Alcatel pour la fabrication du Minitel.

Réponse à appel d'offre du Minitel mentionnant les circuits VIN et GEN : la visualisation est confiée à deux circuits spécialisés VIN et GEN, chargés des signaux de base de temps et de la synthèse des caractères.

Ils sont associés à un microprocesseur, faisant du Minitel un terminal "intelligent" capable de réaliser certaines fonctions en autonomie, sans avoir besoin de communiquer chaque appui de touche du clavier au serveur central.

Ils ajoutent également un mode "semi-graphique" : il ne permet pas d'afficher des pixels, mais propose des 'briques', de 2x3 éléments, pré-dessinées dans la ROM du processeur.
On économise ainsi drastiquement la RAM qui coûtait, déjà, cher…
Le prix unitaire d'une RAM Intel 2107 (de 4K, soit 512 octets) était, à sa sortie en 1974, de 50 $ => avec l'inflation cumulée et la conversion, cela représente environ 295€ de 2026.

	Exemple de caractères semi-graphiques
	autorisés par L'EF9345
	Page 84 du Databook Thomson.

En plus du Minitel, ces composants seront également utilisés par Philips dans les consoles Videopac Plus, ce qui sera la première étape dans la conception du VG5000 dont on reparle au chapitre suivant.

L'EF9345, la cheap chip

Le composant EF9345 regroupe dans une seule puce les fonctionnalités du générateur de caractères et du contrôleur de timing vidéo (GEN et VIN, qui étaient auparavant deux composants séparés).
Cette photo zoomable du cœur de silicium du composant (die shot) montre bien cet assemblage.
Cela a permis de réduire le coût de production du Minitel et a également été utilisé dans quelques micro-ordinateurs personnels : l’Alice chez Matra ou le VG5000 chez Philips.

	Captures de US Rallye, le Gran Turismo de 1984

Ici, la puce ne sait pas ce qu'est un pixel : elle manipule une grille de caractères (25 lignes de 40 ou 80 colonnes).

Pour afficher une lettre ou un bloc de couleur (le fameux mode mosaïque), le processeur principal envoie juste un code d'un octet en RAM. C'est une ROM interne à la puce d'affichage qui se charge ensuite de traduire cet octet en points lumineux à l'écran.

C’était une astuce pour économiser la mémoire, mais impossible de tracer une ligne fine ou de faire bouger un élément au pixel près : on est condamnés à déplacer des blocs rigides sur une grille fixe. Au mieux, certains caractères peuvent être redéfinis, pour afficher un logo ou une image simple.

La suite pour ST

Pour ST Microelectronics, l'histoire des composants graphiques continue encore quelques années après la commercialisation de la série EF936x. Bien que les composants graphiques n'ont pas eu le volume de production de la version alphanumérique (surtout portée par le Minitel), ils ont trouvé une utilisation dans l'informatique scientifique et les appareils de mesure nécessitant la visualisation de données : spectromètres, analyseurs de spectre, ainsi que des réalisations spécifiques (cartes graphiques en kit Elektor pour machines CP/M à bus S-100).

L'offre sera complétée par l'EF9369, un circuit permettant de gérer une palette de 16 couleurs parmi 4096. Ce circuit est conçu au départ pour le micro-ordinateur Thomson TO9, mais finit par rejoindre le catalogue public de EFCIS puis de SGS-Thomson.

En parallèle, SESCOSEM avait signé un contrat avec Motorola lui permettant de produire en France des composants conçus par Motorola (permettant de rassurer les acheteurs qu'il s'agissait de productions locales). SGS-Thomson se retrouve donc à produire à la fois la famille 93xx mais aussi le EF6845, le contrôleur d'écran de la famille 68xx de Motorola. Ce contrat devait comprendre toutes les futures puces de la famille 68xx conçues par Motorola, mais cela finira mal, puisque Motorola refusera de fournir les masques nécessaires à la production du processeur 68020.

En fonction des demandes de clients, de nouveaux composants sont réalisés avec des adaptations simples (changement de timings vidéo pour afficher plus de pixels) ou plus poussés. C'est le cas de la famille TS68483 (surnommé AGAC, Advanced Graphic and Alphanumeric Controller) disponible en 1987.

Il s'agit d'une version améliorée du 9365 avec:

• une interface 16 bits avec le processeur, adapté à l'utilisation avec un 68000 par exemple.
• Des fonctions supplémentaires : tracé de courbes, cercles, remplissage de zones…
• Meilleure intégration : il n'y a plus besoin d'un séquenceur et de registres à décalage externes.
• Configuration logicielle de la résolution d'écran vidéo

Ce composant trouve également une utilisation dans des systèmes militaires, pour lesquels il existe une version "durcie", plus résistante (gamme de températures acceptables par exemple).

Plus tard (en 1995-1997), c'est également ST qui fabrique les premières puces conçues par nVidia: NV1 STG2000 puis RIVA 128. Pour la première, le principe est similaire à ce qui avait été fait pour le EF9365 : ST assure la production et la commercialisation en son nom propre (on trouve donc des datasheets ne mentionnant pas du tout nVidia). Pour la seconde génération, ST ne se charge que de la fabrication, les datasheets (et les puces elle-mêmes) font apparaître les logos des deux entreprises. Malheureusement pour ST, ce partenariat n'ira pas plus loin, et les puces nVidia des générations suivantes seront produites exclusivement par TSMC.

STG2000 (ST)		RIVA 128 (ST)		RIVA TNT (TSMC)
logo de ST seul		deux logos côte à côte		logo nVidia seul

Le génie de l'EF9365

Un vrai framebuffer

Ce composant ne se limite plus à une RAM de stockage des caractères, il dispose d'une RAM de pixels dédiée (le framebuffer) qu'il gère de manière autonome.

De ce point de vue c’est vraiment le premier chip qu’on peut qualifier de "graphique", car les autres étaient appelés "alphanumériques" ou "alpha-mosaïques".

La grosse différence entre les deux est que "graphique" suppose de pouvoir accéder à un pixel particulier, alors que les autres n’accèdent qu’à un "caractère", les pixels d’un caractère étant définis secondairement par une ROM.

Autrement dit, la RAM d’un chip graphique est une RAM de pixels (beaucoup plus grosse, par exemple 512x512), alors que dans le cas alpha-xxx c’est une RAM de caractères (16x80 par exemple).

Il faut bien voir que cette chronologie est liée à la sortie des puces mémoires de Intel : Les puces de 4 K bits ne sont apparues que vers 1974. Avant, il était impossible de faire du vrai "graphique". Il aurait été trop compliqué de stocker chaque point de l’image individuellement : en télévision, le signal vidéo était analogique, et les magnétoscopes à bande magnétique enregistraient le signal video analogique.

L'idée de stocker une image matricielle (point par point) dans une mémoire vive pour l'afficher à l'écran n'était pas nouvelle (par exemple: Evans & Sutherland Shaded Picture System qui faisait déjà du rendu 3D en 1973, premiers "frame buffers" dès 1969 chez Bell Labs, mais ce sont des solutions complexes et coûteuses). On peut également mentionner le CDP1861 de chez RCA: il s'agit d'un framebuffer mais avec une résolution de seulement 64x128 pixels (et encore, il est parfois exploité en 32x64 pixels pour économiser de la mémoire). L'EF9365 marque une rupture historique : c'est le premier processeur graphique commercialisé de manière monolithique (sur une seule puce) conçu pour piloter un framebuffer géométrique de manière autonome. Il gère non seulement le framebuffer et l'affichage à l'écran, mais aussi des fonctions de tracé de lignes et de caractères. C'est donc le premier processeur graphique à proposer une forme d'accélération matérielle sur un système à framebuffer.

L'actualisation de l'image à l'écran utilise seulement 57 % du temps (64 cycles sur 112 cycles de l'horloge externe continue).
Le temps restant est libre pour l'écriture et la mise à jour de l'image : il est possible d'écrire un point par cycle libre, ce qui donne un temps moyen de 1,3 µs par point. Dans les cas où il y a beaucoup d'informations à afficher d'un coup, il est également possible de désactiver l'affichage pendant la préparation de l'image puis de le réactiver ensuite. Malheureusement, cela ne se prête pas trop à la réalisation d'animations complexes.

La décharge du CPU pour certaines tâches

C'est ce qui définit ce composant comme le premier GPU de l'histoire : son auteur lui a câblé des registres pour prendre en charge des fonctionnalités qui déchargent le CPU (processeur central) sur des opérations graphiques !

Exemples de programmes en langage MPL qui montrent la simplicité d'utilisation

Le tracé de lignes

Le CPU peut par exemple demander à l'EF9365 de dessiner un trait d'un point A à un point B et revenir aussitôt à sa tâche. L'EF9365 prend alors le relais de manière totalement autonome. Il calcule les coordonnées intermédiaires en interne et écrit directement les pixels en RAM, à une vitesse folle pour l’époque : jusqu'à un million et demi de points par seconde, traçant une diagonale complète en moins de 700 microsecondes.

	L’algorithme de tracé de segment de Bresenham
	Présentation SIGGRAPH'78, page 5

Traitements hardware sur les caractères

Redimensionnement matériel (jusqu'à 16x)

Auparavant, pour doubler la taille d'une police ou d'un motif, on demandait au processeur principal de recalculer tous les points. L'EF9365, lui, gère cela en toute autonomie via deux registres internes dédiés aux facteurs d'échelle : CZX (Zoom en X) et CZY (Zoom en Y).

Le processeur graphique possède un compteur de pas pour dessiner le caractère pixel par pixel à partir de sa ROM interne.
Quand le zoom est activé (par exemple à 4×), au lieu d'incrémenter l'adresse de destination dans le framebuffer à chaque pixel lu, l'EF9365 va répéter la même valeur de pixel sur la ligne 4 fois de suite en horizontal avant de passer au pixel suivant. Pour la verticale, il va répéter la même ligne complète du caractère 4 fois de suite dans la mémoire d'écran.

L'avantage : comme les zooms X et Y sont indépendants, on peut appliquer un zoom 2× en largeur et 4× en hauteur. Cela permettait de faire instantanément des effets de texte étiré, condensé ou géant sans aucun calcul pour le CPU.

L'effet Italique

L'inclinaison n'est pas stockée dans une ROM ; elle est calculée « à la volée » lors de l'écriture dans la RAM de pixels.
Pour incliner un bloc de pixels, il faut appliquer un décalage horizontal progressif à mesure que l'on monte en hauteur.
À chaque fois que le générateur passe à la ligne supérieure (Y+1) pour dessiner le caractère, il ajoute automatiquement un offset fixe (un décalage d'un pixel) sur l'axe horizontal (X).

Le caractère est littéralement « cisaillé » géométriquement pendant qu'il est écrit dans le framebuffer. On obtient un effet italique parfait et fluide, directement câblé dans le silicium.

La seule inclinaison possible est 45 degrés (voir la notice page 21).
C’est beaucoup plus simple ainsi à réaliser en hardware. Je m’étais posé la question de faire tous les angles, mais j’avais abandonné.

Autres fonctionnalités

L'EF9365 marque d'autres évolutions technologiques novatrices…

Il intègre notamment un mécanisme de masquage d'écriture par plan.
En verrouillant certains plans de la RAM, il pouvait dessiner ou effacer des éléments au pixel près sans jamais altérer le fond de l'image, jetant les bases de la gestion matérielle des calques.

Il propose un module de pointillés gérés au pixel individuel (une aubaine pour la CAO industrielle).

Son interface de bus universelle est capable de dialoguer nativement aussi bien avec un Z80 qu'un Motorola 6809.

et… concrètement ?

Jean-François Del Nero a produit une démonstration des capacités de rendu du 365 sur le Squale, un micro-ordinateur de 1984 qui exploitait ce composant.
Ci-après quelques extraits, très saccadés (export gif oblige), presque fidèles (cherchez l'intrus !) :

En plus de son travail de conservation du Squale, avec l'association MO5.com (qui tient un musée permanent du jeu vidéo à Arcueil), Jean-François Del Nero a aussi contribué à son émulation dans le projet Mame, et a notamment écrit le driver du 365.
Nous avons pu reprendre le code source de sa démo, la modifier, la recompiler, et simuler le rendu du 365 grâce à Mame. Avis aux développeurs fullstack en manque d'exotisme: ici, pas de conteneurs Docker ni de dépendances npm !

Est-ce vraiment le premier GPU ?

Nous avons retenu les quatre critères suivants pour distinguer le 365 des premiers contrôleurs d'affichage sur une seule puce, comme le Motorola 6845 ou l'Atari Antic, qui gèrent la synchronisation du flux vidéo et le rafraîchissement de l'écran, sans intervenir dans le dessin des formes.
Le processeur 365 :

1. est une puce unique (LSI/VLSI) : ce n'est pas une carte remplie de circuits TTL discrets comme sur les gros systèmes vectoriels des années 70 (Evans & Sutherland, Imlac) ;
2. déleste le CPU de tâches coûteuses en ressources : le CPU n'écrit pas les pixels un par un en VRAM. Il envoie une commande de haut niveau au 365 telle que : « trace une ligne de (X1,Y1) à (X2,Y2) », et repasse à autre chose ;
3. dispose d'un moteur d'exécution algorithmique dédié, hardware (en silicium) : il embarque en dur l'algorithme de tracé/moteur de rendu (rasterizer) ;
4. gère en toute indépendance la mémoire vidéo (Framebuffer/VRAM) : le 365 contrôle l'accès, le rafraîchissement et la modification de la VRAM de façon indépendante.

Et le libre dans tout ça ?

Quittons la technique pour nous intéresser à un autre aspect des travaux de l'équipe : la diffusion de ses travaux.

Vous pourriez être étonnés qu’un circuit produit par un industriel puisse être public, dans ses moindres détails. Je dois vous raconter une anecdote :

Notre petit groupe d’élèves de l’Ecole Normale Supérieure considérait que ses productions, financées par les pouvoirs publics, devaient profiter à tout le monde. Mais cela posait un problème à l’industriel (Thomson-CSF qui avait pour filiale la société Thomson-EFCIS), qui voulait protéger son produit par des brevets. Il a été convenu que Thomson-CSF déposerait des brevets au plus tard la veille de ma soutenance de thèse. Ainsi, les brevets pouvaient être valides car ne portaient pas sur un design public.

Ma thèse a été soutenue le 19 mai 1978, et les brevets avaient été déposés le 18 mai (US4286264, US4297694, US4311998, US4266253).
Ils décrivent aussi en détails le fonctionnement du circuit, mais dans le langage juridique spécifique des brevets.

En août de la même année, l'architecture du 365 est présentée lors de la conférence SIGGRAPH 78. La liste d'articles soumis à cette conférence permet de se faire une idée des évolutions en cours dans le monde des graphismes générés par ordinateur à l'époque. On y trouve la description d'autres systèmes matériels et logiciels, des algorithmes en 2D ("How to color in a coloring book", un algorithme de remplissage de zones délimitées par des traits) et en 3D, des discussions sur les choix d'espaces de couleurs, ainsi que des exemples de mises en application (par exemple pour les simulateurs de vol de la navette spatiale américaine).

Ensuite, EFCIS a beaucoup utilisé le dessin des masques du 365 pour sa communication car c’était le seul design qui était public.
Nous n’étions pas dans l’état d’esprit de créer une start-up autour de nos designs, dans le but de gagner de l'argent. Nous nous imaginions qu’il était possible de concevoir des circuits dans un contexte académique, en étant juste payés par nos salaires, puis de les céder à un industriel pour la suite. C’était une erreur car ça ne pouvait pas fonctionner, principalement parce que l’industriel a besoin de définir sa stratégie de ligne de produits avec ses arguments marketing.
Le contrat passé entre EFCIS et l’Ecole Normale Supérieure a servi à rémunérer l’ENS, qui s’en est servi pour créer le premier labo d’Informatique de l’ENS (le LIE), et je n’ai rien reçu personnellement. Je considérais que j’avais été payé par mon salaire d’élève de l’ENS.

Dans les années 1970, nous avions l’idée naïve que les innovations techniques entraînaient des innovations sociales au sens d’une amélioration des conditions de vie pour tous, à l’image de la bagnole qui s’était démocratisée et qui était synonyme de libération. Nous ne faisions pas de grande différence entre acteurs publics et acteurs privés, et nous avions l’impression que tout était publié, ne serait-ce que par les brevets, qui ne faisaient que protéger ceux qui avaient davantage investi. En revanche, nous étions sensibles à la question de la propriété industrielle, et nous pensions que ce qui avait été développé par des fonctionnaires était la propriété de l’état (ce qui d’ailleurs est la loi), et que les universitaires ne pouvaient que publier sans restrictions. (En tant qu'élèves de l’ENS, nous étions fonctionnaires et universitaires.)…

Le 365 a-t-il fait un flop ?

Clairement non, car l'EF9365 ne mesure pas ses performances en FLOPS (Floating-point Operations Per Second) : il ne manipule aucune virgule flottante (ni même de calculs en nombres réels).
Blague d'informaticien mise à part, le 365 a certes ouvert la voie à une longue lignée de composants, qui domine aujourd'hui l'actualité de la tech, mais il n'a pas eu le succès commercial de ses descendants, et l'expérience de la rue d'Ulm a tourné court.

En France et à l'époque, il était difficile de faire dialoguer recherche, industrie et financement public.

…Mais nous n’avions pas compris les particularités de ce secteur. D’une part, les usines qui fabriquent des circuits intégrés coûtent extrêmement cher. D’autre part ce secteur était appelé à un développement exponentiel, non anticipé : la plupart des hauts responsables de l’époque pensaient que les ordinateurs seraient achetés par 100 entreprises, voire 1000, mais ne concerneraient pas le grand public. Ensuite, le coût des développements logiciels devenait lui aussi très élevé. À l’époque les plus gros logiciels n’étaient pas très complexes. Et on n’avait pas compris la relation étroite entre les logiciels et les architectures matérielles. On n’avait pas compris non plus que de prendre un monopole sur un OS était un enjeu stratégique.

Toutes ces contraintes (et d’autres que j’oublie), que nous n’avions pas comprises, faisaient que nous pensions naïvement que nous pouvions faire un développement dans notre coin, sans nous occuper du marché, mais uniquement de la performance technique, et le publier, puis dans un second temps le proposer à un industriel qui aurait les moyens de le commercialiser. L’idée sous-jacente étant que si le design était performant alors il y aurait forcément un industriel pour le vendre. C’était une grande ignorance des contraintes industrielles et des questions de marketing.

Le cœur du problème ne résidait pas dans un manque de compétences (le génie des étudiants de l'ENS en est la preuve) mais dans l'incapacité des grands capitaines d'industrie français (notamment chez Thomson) à anticiper la révolution de l'ordinateur personnel et du logiciel. Confortés dans leur monopole, ils ont ignoré le virage que les États-Unis et le Japon prenaient à pleine vitesse :

Je pense maintenant que dans le contexte des années 1970-80 en France, il n’y avait pas vraiment de possibilité pour aller plus loin. Les deux milieux, universitaires et industriels, ne se parlaient vraiment pas. Personne en France, ni chez les gouvernants, ni chez les universitaires, ni chez les industriels, ne voyaient ce qui se préparait. Nous, à 20-25 ans, nous comprenions le retard technologique de la France, ne serait-ce qu'en lisant les docs des puces que nous achetions, mais il était nié par les plus hauts responsables. Les dirigeants de Thomson disaient : "Quand il y aura vraiment un marché pour ça, nous serons en mesure de produire".

En 1984, lors d'un voyage aux États-Unis et d'une visite au mythique Xerox PARC, le chercheur français découvre un autre monde. Un monde où l'innovation de rupture n'est pas confinée aux laboratoires, mais propulsée par le capital-risque, les pépinières d'entreprises et une compréhension systémique du couple matériel/logiciel :

À un moment, au début des années 80, nous parlions avec Gastinel de monter notre boîte. Mais nous étions incompétents pour ça, nous n’avions aucune conscience des difficultés, il n’y avait pas du tout l’esprit "start-up", le capital-risque n’existait pas, les pépinières d’entreprises n’existaient pas, nous n’avions aucune connaissance de la façon dont les boîtes pouvaient se créer et croître aux USAs, nous n’avons appris ce contexte que beaucoup plus tard.

Je suis allé aux USAs en 1984 pour la conférence Siggraph (à Minneapolis) et à cette occasion après je suis passé à Xerox-Parc où j’avais un ami français (Louis Monier, plus tard créateur de Altavista chez DEC). J’y ai découvert un monde insoupçonné chez nous, avec toutes leurs innovations depuis 20 ans, et j’ai rapporté leurs publications. Pourtant cela était connu (mais pas par nous), c’était à la base du Lisa et du Macintosh de Apple, sorti cette année-là. À Parc, j’y ai rencontré Franck Crow, un anglais, un grand nom du graphique (connu en particulier pour l’anti-aliasing) qui m’a félicité pour le 365, je n’en revenais pas. J’ai compris après qu’il avait été un reviewer pour mon article de 1978, avec un avis très favorable. En 1984, il avait connaissance du minitel, sorti peu avant, et m’a dit : "Nous aux USAs, nous n’avons pas été capables de faire ça". Il faut dire que c’était avant qu’Internet se répande, avec des possibilités infiniment supérieures. Internet existait depuis plusieurs années chez Xerox, mais ne pouvait pas se répandre dans le grand public avant l’existence des ordinateurs individuels.

Les pouvoirs publics français se sont parfois immiscés dans ces choix industriels : citons la nationalisation de Thomson-CSF en 1982 et le plan "Informatique pour tous" en 1985 (un investissement énorme, estimé à 1,8 milliard de francs, soit 600 millions d'euros rapportés à aujourd'hui). Pourtant, la théorie du ruissellement n'a pas très bien fonctionné alors avec les labos de recherche ou les pépites industrielles en devenir : en témoignent le départ d'une grande partie de la bande de copains vers les US ou l'échec du Squale, dont la production s'est limitée à quelques centaines d'unités.
La capitalisation boursière de STMicroelectronics (ex-SGS-Thomson) est, en 2026, 70 fois inférieure à celle de nVidia.

En fait je crois que en France, à cette époque, les choses ne pouvaient venir que d’en haut : le nucléaire, le concorde, le minitel. Le minitel a été réalisé par des gens du corps des mines et du corps des télécom (comme son nom l’indique). les choses ne pouvaient venir que des grands corps de l’état.
Notre activité, initiée par Jean Gastinel, était plutôt folle par sa liberté, et transgessive. Le climat à l’ENS, peu après 1968 où cette école avait été au cœur des événements, était très libre, nous avions vraiment la possibilité de faire n’importe quoi, sans contrôle. Jean avait entendu parler par son père de ce qui se passait aux USAs. Et ce qui se passait en Silicon-valley aussi était fait dans un cadre très libre lié à la contre-culture des hippies (mais ça, nous ne le savions pas).

Une anecdote : au début des années 80, nous avons développé un réseau local Ethernet (alors sur câble co-axial de gros diamètre), pour relier nos Thémis réalisées en 10 exemplaires. Et nous avons eu besoin de passer sous la rue d’Ulm pour connecter le laboratoire de biologie. C’était interdit par le monopole des télécoms. En outre, le protocole de transfert par paquets était refusé car concurrent du protocole des P&T. Il nous a fallu enfreindre la loi pour passer un câble en douce.
Tout ça a basculé peu de temps après, après l’explosion de l’usage des ordinateurs individuels et de leurs applications.

Pour être tout-à-fait honnête, et rendre à César…, je dois mentionner que notre équipe a été reconnue par le CNRS en 1982, où nous avons obtenu des postes et des crédits pour continuer. Il y a eu une croissance jusqu'à 10 personnes en 1985, mais la plupart des membres de l'équipe sont partis chez Xerox en 1986.

Avec le recul je dirais : on peut faire de grandes choses quand on est très peu nombreux, ça devient plus difficile lorsqu'il faut gérer la croissance…

Le hasard du calendrier a voulu que la publication de cette dépêche coïncide avec un anniversaire : il y a 50 ans débutait l'étude du 365, avec le DEA de P. Matherat :)
Pour celles et ceux qui s’intéresseraient à ses publications ou à la suite de ses travaux, c'est consultable ici.

Dix-huit ans après ses débuts, G’MIC, cadriciel libre pour le traitement des images numériques, franchit une étape importante avec la sortie d'une nouvelle version majeure, numérotée 4.0, la version de la maturité !

L'occasion, comme chaque année, de faire le point sur les évolutions récentes de ce projet, depuis notre dernière dépêche publiée en août 2025.

N. D. A. : Cliquez sur les images pour en obtenir une version en pleine résolution, ou une vidéo correspondante lorsque les images contiennent l’icône 

Sommaire

• 1. G’MIC : Un cadriciel libre pour l'image numérique
• 2. Nouveaux filtres du greffon G'MIC-Qt
  • 2.1. Filtre « Rendering / Pixel Stretch »
  • 2.2. Filtre « Rendering / Gradients [Poles] »
  • 2.3. Filtre « Artistic / Marker Drawing »
  • 2.4. Filtre « Deformations / Heightfield Warp »
  • 2.5. Filtre « Degradations / Offset Stripes »
  • 2.6. Filtre « Colors / Transfer Colors [Multi] »
• 3. Nouveautés et améliorations du cœur du logiciel et de sa bibliothèque standard
• 4. Nouveau dépôt de codes sources: gmic-interactive-demos
  • 4.1. The SteamFace Machine
  • 4.2. Virtual Artist
  • 4.3. GREYC Warp
• 5 G'MIC et le code créatif
  • 5.1. Codes créatifs courts
  • 5.2. Continuation de la série « G'MIC Adventures »
• 6. Autres nouvelles liées au projet
• 7. Conclusion

1. G’MIC : Un cadriciel libre pour l'image numérique

Le projet G'MIC (GREYC's Magic for Image Computing) est né en juillet 2008, et a grandi au sein de l'équipe IMAGE du laboratoire GREYC de Caen (Unité Mixte de Recherche placée sous la triple tutelle du CNRS, de l'ENSICAEN et de l'Université de Caen).

Sa vocation : offrir un cadriciel libre, ouvert et extensible pour la manipulation, le traitement et la création d'images numériques. Pour ce faire, il s'appuie sur les fonctionnalités de la bibliothèque libre C++ de traitement d'images CImg, développée depuis 1999 d'abord au sein de l'INRIA, puis de l'équipe IMAGE du GREYC (également par votre serviteur).

Au cœur du projet se trouve un interpréteur de langage de script dédié, le « langage G'MIC », spécialement conçu pour prototyper rapidement de nouveaux algorithmes de traitement d'images, et les enchaîner au sein de pipelines (ou filtres) personnalisés. Autour de ce noyau viennent se greffer plusieurs interfaces, donnant à l'utilisateur accès à des centaines d'opérateurs de traitement d'images prédéfinis, comme par exemple l'outil en ligne de commande gmic ; le service Web G'MIC Online ; et le greffon G'MIC-Qt, qu'il est possible d'intégrer dans plusieurs logiciels de création et d'édition d'images, tels que GIMP, Krita, digiKam, Paint.net, Adobe Photoshop ou Affinity Photo. C'est aujourd'hui ce greffon qui est l'interface du projet la plus utilisée, avec plus de 1200 téléchargements quotidiens, en progression depuis un an. Il propose plus de 640 filtres variés pour triturer vos images et enrichir les possibilités des logiciels de retouche, et semble particulièrement apprécié des artistes numériques.

Cette version majeure 4.0 marque un tournant dans la vie du projet : la syntaxe du langage G'MIC, le code de l'interpréteur et des algorithmes de traitement d'images associés sont maintenant éprouvés. Nous souhaitons donc ralentir un peu le rythme des nouvelles releases et de l'ajout de nouvelles fonctionnalités, pour nous concentrer sur la stabilité, la robustesse, et les performances du cadriciel.

Fig. 1.1. Aperçu de quelques-unes des interfaces proposées par le projet G'MIC : Greffon G'MIC-Qt pour GIMP (en haut à gauche), Outil CLI gmic (en haut à droite), Service web G'MIC Online (en bas).

2. Nouveaux filtres du greffon G'MIC-Qt

Côté greffon G'MIC-Qt, l'essentiel des nouveautés se concentre sur l'apparition de nouveaux filtres de traitement d'images. La version 4.0 porte leur nombre à 644, tous accessibles directement depuis l'interface graphique. Je liste ci-dessous les derniers filtres ajoutés.

2.1. Filtre « Rendering / Pixel Stretch »

Le filtre « Rendering / Pixel Stretch » permet de sélectionner une « bande de pixels », et la duplique dans l'image en lui faisant suivre une trajectoire personnalisable, définie par deux courbes splines (une pour chaque bord de la bande).

Fig. 2.1.1. Le filtre « Rendering / Pixel Stretch » tel qu'il apparait dans le greffon G'MIC-Qt.

Fig. 2.1.2. Exemple de rendu du filtre « Rendering / Pixel Stretch », ici avec deux traînées de pixels ajoutées par le filtre.

Cet effet donne l'impression que l'image a été étirée localement, un peu comme une pâte élastique. Il peut servir à suggèrer ou styliser un mouvement dans une image, comme sur l'exemple ci-dessous (extrait de la vidéo tutorielle que Miguel Pineau a spécialement dédiée à ce filtre).
On peut également imaginer son utilisation pour du Glitch art ou de la création de textures abstraites.

Fig. 2.1.3. Le filtre « Rendering / Pixel Stretch » appliqué pour styliser le mouvement d'une danseuse (Crédits : Miguel Pineau).

2.2. Filtre « Rendering / Gradients [Poles] »

Toujours dans cette section « Rendering », notons l'arrivée de « Rendering / Gradients [Poles] », un filtre générant des dégradés de couleurs en interpolant spatialement des points-clés colorés, dont les positions et les couleurs sont laissées au choix de l'utilisateur. Ici, l'interpolation fait usage des fonctions de base radiale qui produisent des dégradés de couleurs lisses et harmonieux. L'utilisateur a également le choix de l'espace de couleurs dans lequel l'interpolation s'effectue. L'animation ci-dessous illustre le fonctionnement de ce filtre au sein du greffon.

Fig. 2.2.1. Le filtre « Rendering / Gradient [Poles] » crée des gradients spatiaux de couleurs possiblement complexes, à partir de quelques points de contrôle.

2.3. Filtre « Artistic / Marker Drawing »

Passons maintenant au filtre « Artistic / Marker Drawing », qui comme son nom l'indique, essaye de redessiner une image d'entrée sous la forme de traits de stylos feutres colorés. L'algorithme sous-jacent trace effectivement des splines colorées aléatoires sur une feuille blanche, le long des contours des structures géométriques présentes dans l'image à reproduire.

Fig. 2.3.1. Le filtre « Artistic / Marker Drawing » redessine une image en simulant l'utilisation de stylos feutres colorés.

Les nombreux paramètres réglables de ce filtre permettent d'obtenir des rendus potentiellement variés, plus ou moins abstraits, comme l'illustre la figure comparative suivante :

Fig. 2.3.2. Trois types de rendus du filtre « Artistic / Marker Drawing », utilisant trois jeux de paramètres différents.

2.4. Filtre « Deformations / Heightfield Warp »

Changeons maintenant de thématique avec le filtre « Deformations / Heightfield Warp » qui crée un effet 3D, en déformant une image d'entrée comme si elle était plaquée sur une carte d'élévation (définie de manière paramétrique). Un effet d'éclairage additionnel, de type ombrage de Phong, peut être activé pour accentuer davantage l'effet de volume 3D produit par ce filtre.

Fig. 2.4.1. Le filtre « Deformations / Heightfield Warp », tel qu'il apparait dans le greffon G'MIC-Qt, ici avec une élévation correspondant à une demi-sphère bombée vers la caméra.

Ce filtre est particulièrement flexible : il laisse la possibilité à l'utilisateur de définir explicitement des formules mathématiques personnalisées pour les cartes d'élévations. Les mathématiciens en herbe peuvent ainsi laisser libre cours à leur imagination pour déformer leurs images !

Fig. 2.4.2. Application de trois formules personnalisés de cartes d'élévations 3D, avec le filtre « Deformations / Heightfield Warp ».

2.5. Filtre « Degradations / Offset Stripes »

Les amateurs de Glitch art pourront être séduits par le nouveau filtre « Degradations / Offset Stripes », qui crée un effet de décalage de bandes d'images, horizontales et/ou verticales, avec des amplitudes de décalage aléatoires.

Fig. 2.5.1. Le filtre « Degradations / Offset Stripes » applique des décalages aléatoires sur des bandes d'images horizontales et/ou verticales.

Ce principe de base est tout simple, mais là encore, les nombreux paramètres du filtre donnent accès à des décalages décorrélés sur chaque canal, pour des espaces couleurs variés, en pouvant itérer ces décalages aléatoires, et autorisent ainsi une grande variété de dégradations d'images de type « Glitch », comme illustré sur la figure ci-dessous.

Fig. 2.5.2. Résultats de différents jeux de paramètres du filtre « Degradations / Offset Stripes », appliqués sur une même image de portrait.

2.6. Filtre « Colors / Transfer Colors [Multi] »

Et pour terminer ce résumé des nouveaux filtres du greffon G'MIC-Qt, j'ai gardé le plus intéressant pour la fin : le filtre « Colors / Transfer Colors [Multi] » est un nouveau filtre de transfert de couleurs entre deux images.

Le transfert de couleur consiste à appliquer une transformation couleur à une image « Source », en prenant comme référence une deuxième image (image dite de « Style ») dont on veut reproduire le style ou l'ambiance colorimétrique, et ceci bien sûr en préservant autant que possible les structures importantes (contours, objets, contenu sémantique) présentes dans l'image « Source » d'origine.

Fig. 2.6.1. Principe du transfert de couleur entre images: une image « _Source » (à gauche) est modifiée (à droite) de telle façon qu'elle « emprunte » les couleurs d'une image de « Style » (au centre)._

D'un point de vue algorithmique, il y a de nombreuses façons d'aborder ce type de transfert. Le filtre « Colors / Transfer Colors [Multi] », comme son nom le suggère, implémente trois méthodes différentes pour ce faire : une méthode ACP ; une méthode de transfert d'histogrammes ; et enfin une méthode variationnelle. Pour utiliser ce filtre dans le greffon G'MIC-Qt, il suffit de l'appeler sur une image contenant deux calques superposés : un calque contenant l'image « Source » à modifier, et un calque avec l'image « Style » contenant les couleurs de référence à transférer.

Fig. 2.6.2. Le filtre « Colors / Transfer Colors [Multi] » tel qu'il se présente dans le greffon G'MIC-Qt.

L'algorithme variationnel de transfert de couleur implémenté dans ce filtre est une production totalement originale : il est le fruit d'une collaboration de recherche entre deux membres de l'équipe IMAGE du laboratoire GREYC de Caen (D. Tschumperlé et J. Rabin), et d'une professeure du laboratoire de mathématiques LMI de l'INSA de Rouen (C. Le Guyader).

Bref, un algorithme 100 % normand, qui fonctionne forcément « vachement 🐄 bien » 😉, et que vous ne trouverez nulle part ailleurs !
On remercie chaleureusement la Fédération Normande de Recherche en Sciences et Technologies de l’Information et de la Communication (NormaSTIC) pour son aide financière qui a accéléré la mise en contact et le démarrage de cette collaboration fructueuse !

Notre méthode a plusieurs caractéristiques propres permettant de calculer des transferts de couleurs souvent pertinents, et de bonne qualité comparativement à ses concurrentes, et ce, de manière rapide et complètement automatique. La figure ci-dessous illustre des exemples de transferts de couleurs qu'il est possible d'obtenir pour une même image « Source », en choisissant des images de « Style » différentes (et en laissant les paramètres par défaut du filtre).

Fig. 2.6.3. Exemples de transferts de couleurs réalisés par le filtre « Colors / Transfer Colors [Multi] » sur une même image « Source », avec plusieurs images « Style » différentes.

La technique que nous proposons autorise également un mode « semi-supervisé » qui permet à l'utilisateur de forcer certaines correspondances de couleurs, et donc de « guider » l'algorithme pour calculer une solution de transfert plus contrainte et personnalisée.
Les deux exemples ci-dessous illustrent ce mode de contrôle de manière assez parlante :

Fig. 2.6.4. Guidage de l'algorithme de transfert de couleurs par mise en correspondance forcée de couleurs (Perruche → Mésange).

Ici, les plumes vertes du corps de la perruche (a) sont perceptuellement plus proches de la couleur jaune du corps de la mésange (b), et c'est donc cette mise en correspondance qui est réalisée par défaut par l'algorithme de transfert (résultat (c)). En explicitant des correspondances de couleurs souhaitées (liens symbolisés entre les images (a) et (b)), on peut modifier ce comportement et contraindre le transfert à assigner la couleur bleue de la mésange aux plumes de la perruche (résultat (d)).

Fig. 2.6.5. Guidage de l'algorithme de transfert de couleurs par mise en correspondance forcée de couleurs (Coccinelle → Formule 1).

Dans ce deuxième exemple, on note que la couleur rouge de la Coccinelle (a) se retrouve ailleurs dans l'image « Style » de la Formule 1 (b) : au bord de la route, sur les coquelicots… L'algorithme décide donc naturellement de conserver cette couleur quasiment telle quelle lors du transfert automatique (résultat (c)). Forcer des correspondances de couleurs explicites permet de guider l'algorithme pour lui faire changer la couleur de la Coccinelle en vert (résultat (d)).

Vous l'aurez compris, ce filtre représente l'aboutissement d'un travail de recherche de longue haleine en algorithmique du traitement d'images. Pour des chercheurs comme nous, il est réjouissant d'être arrivé au bout du processus complet : élaborer un nouvel algorithme complexe sur un bout de papier, le développer, l'implémenter, le peaufiner, en obtenir des résultats encourageants, le peaufiner encore et encore, en écrire une description détaillée dans un article scientifique (en cours de finalisation), l'intégrer proprement et le rendre utilisable par tout un chacun dans un logiciel libre, en sachant qu'il pourra être testé et utilisé potentiellement des milliers de fois !

Notons que ce n'est pas la première fois qu'une méthode de traitement d'images développée au sein de notre laboratoire de recherche se retrouve valorisée dans G'MIC. Cette page recense plusieurs publications scientifiques décrivant des algorithmes élaborés au sein de l'équipe IMAGE du GREYC, et qui sont accessibles comme filtres du greffon G'MIC-Qt.

3. Nouveautés et améliorations du cœur du logiciel et de sa bibliothèque standard

Comme évoqué précédemment, le terme G'MIC peut faire référence au langage de script du même nom. Ce langage est doté de son propre interpréteur et de sa bibliothèque standard de fonctions. Il est utilisé pour implémenter tous les filtres et opérateurs de traitement d'images mis à disposition des utilisateurs des différentes interfaces du projet.

Durant l'année écoulée, un grand nombre de petites améliorations ont été implémentées conjointement sur ce langage et sa bibliothèque standard.
En réalité, l'ensemble de ces contributions représente même la majorité du travail de développement réalisé, et en même temps ce sont des choses qu'il est difficile de valoriser dans une dépêche grand public : elles concernent principalement des points très précis et techniques du projet, comme par exemple des optimisations du parsing ou des algorithmes, du nettoyage de code, de nouvelles fonctions ou options pour l'évaluateur d'expressions mathématiques, etc.
Ce sont bien sûr des ajouts utiles pour les développeurs de nouveaux filtres dans ce langage, mais il est difficile de les mettre en valeur de manière réellement plaisante.

J'ai donc pris le parti de lister ci-dessous uniquement les quelques nouveautés facilement « illustrables » :

• La nouvelle commande random_patches réalise un rendu procédural d'images carrées contenant des formes géométriques et des textures synthétiques aléatoires. À quoi cela peut-il bien servir, me direz-vous ? Eh bien par exemple, à générer des ensembles d'images pour l'entrainement de réseaux de neurones convolutionnels, pour des tâches de débruitage et de super-résolution (ces réseaux sont ceux utilisés par les commandes denoise_cnn et scale2x_cnn).

Fig. 3.1. La commande random_patches synthétise des images carrées contenant des formes géométriques et des textures aléatoires.

Ces images sont en réalité suffisamment complexes pour qu'un réseau de neurones puisse apprendre des filtres convolutionnels pertinents pour l'analyse semi-locale de la géométrie des structures présentes dans des images plus naturelles. Ces filtres appris peuvent ensuite être utilisés dans des tâches de débruitage ou de super-résolution, qui sont des problèmes très géométriques et qui ne nécessitent pas vraiment une analyse sémantique du contenu des images. Utiliser ces données synthétiques pour entrainer des réseaux simples est donc largement suffisant pour ce type d'applications. D'une part, cela évite de stocker de grandes bases d'images volumineuses lors de l'entrainement (les images synthétiques étant générées à la volée). Et d'autre part, on évite automatiquement d'enfreindre le copyright éventuel des images présentes dans les ensembles d'apprentissage prédéfinis (dont la provenance n'est pas toujours clairement citée, avouons-le).

• La nouvelle commande shape_hilbert génère, comme son nom l'indique, une image de la courbe de Hilbert (en 2D).

Fig. 3.2. La commande shape_hilbert trace une courbe de Hilbert dans une image, commande illustrée ici avec des niveaux croissants de récursions.

• La nouvelle commande pca calcule une analyse en composantes principales (ACP) d'un ensemble de vecteurs. Ce type d'analyse permet à la fois de déterminer la dimensionnalité représentative de données vectorielles, ainsi que leurs orientations principales dans l'espace. L'ACP a de nombreuses applications en traitement d'images et plus généralement en analyse de données : débruitage, compression, reconnaissance de visages, analyse de textures, recalage géométrique, etc. L'exemple ci-dessous illustre son utilisation pour déterminer l'orientation des axes principaux (dessinés en pointillés) d'une silhouette de libellule.

Fig. 3.3. La commande pca est utilisée ici pour calculer les orientations des axes principaux d'une silhouette binaire 2D.

• Les nouvelles commandes depthmap3d et normalmap3d viennent enrichir les possibilités de rendus d'objets 3D maillés de G'MIC, en synthésisant des rendus d'un objet respectivement sous la forme de cartes de profondeurs et de normales 3D.

Fig. 3.4. Les commandes depthmap3d et normalmap3d appliquées sur un modèle 3D en rotation.

• Mentionnons enfin le travail d'amélioration général ciblé sur les algorithmes d'opérations matricielles présents dans G'MIC : arrivée de la décomposition QR (avec pivot), amélioration de la précision de calcul pour l'inversion de matrices et la résolution de systèmes linéaires… Et même s'il est difficile de rendre ça visuel, je vous propose cette petite ligne de commande qui crée une matrice carrée 40×40 aléatoire, qui l'inverse et qui calcule le produit des deux pour vérifier que l'on retrouve bien la matrice identité.

$ gmic 40,40 rand -1,1 +invert +mmul name A,invA,'A*invA'

Fig. 3.5. Exemple de l'utilisation de gmic en ligne de commande pour l'inversion d'une matrice aléatoire.

Tout ceci n'est bien sûr qu'un aperçu succinct de ce qui a été réalisé sur le cœur de G'MIC cette année. Pour plus de détails techniques, la consultation des Changelog est recommandée.

4. Nouveau dépôt de codes sources: gmic-interactive-demos

En tant que membre d'un laboratoire public de recherche, j'ai l'occasion de participer ponctuellement à des évènements de vulgarisation scientifique (tels que la Fête de la science, le FÉNO, etc.), où l'on présente certaines de nos activités de recherche au grand public (en algorithmique du traitement d'images en ce qui me concerne). Pour rendre ces présentations plus attractives et ludiques, j'ai élaboré au fil des ans, différents programmes et bornes de démonstration interactifs, en me reposant sur les possibilités offertes par le langage G'MIC.

Ces applications libres (sous licence CeCILL) sont maintenant accessibles sur ce dépôt logiciel : github.com/GreycLab/gmic-interactive-demos

Elles pourront intéresser des enseignants et/ou chercheurs souhaitant illustrer différents concepts du traitement d'images à des publics de néophytes. Ces codes illustrent aussi les capacités du langage G'MIC pour la création de programmes interactifs, et ceci indépendamment du greffon G'MIC-Qt.

Pour le moment, trois démonstrateurs sont présents dans ce dépôt logiciel. Ils sont détaillés ci-dessous.

4.1. The SteamFace Machine

« The SteamFace Machine » est le démonstrateur le plus récent. Il montre le fonctionnement des réseaux de neurones convolutionnels pour la détection d'un visage dans une image, et l'analyse de caractéristiques propres à ce visage, le tout enrobé dans un style SteamPunk du plus bel effet !

Fig. 4.1.1. Écran de lancement du démonstrateur « The SteamFace Machine ».

Le flux vidéo capturé par la webcam s'affiche à l'écran, et lorsqu'un visage est placé au centre de l'image, la jauge de détection faciale s'active. En bas à droite, on peut apercevoir la sortie de différentes couches intermédiaires du réseau de neurones réalisant la détection (classifieur binaire avec une architecture de type LeNet-5).

Fig. 4.1.2. Détection du visage par un réseau de neurones convolutionnel dans le démonstrateur « _The SteamFace Machine »._

Une fois la détection opérée, un deuxième réseau est inféré pour en extraire différentes caractéristiques faciales : genre, âge, type de cheveux, port de lunettes ou de chapeau, taille du nez…

Fig. 4.1.3. Analyse de quelques caractéristiques liées au visage détecté.

C'est une manière visuellement amusante de présenter le fonctionnement de classifieurs neuronaux au grand public, leurs capacités mais aussi leurs limites et les biais inhérents aux bases d'apprentissage utilisées pour les entrainer (dans le cas de ce démonstrateur, la base CelebA, qui contient des images assez éloignées de celles que l'on acquiert via la webcam dans un environnement non-contrôlé tel qu'un parc des expositions).

Mentionnons également la belle contribution de notre cher collègue Philippe Bernard, du service Administration système et réseaux du GREYC, qui a réalisé une borne physique de démonstration intégrant « The SteamFace Machine », facilement transportable à des évènements de médiation scientifique !

Fig. 4.1.4. Vidéo de démonstration de la borne « The SteamFace Machine » quand elle était en cours d'élaboration.

4.2. Virtual Artist

« Virtual Artist » est un deuxième démonstrateur interactif, qui cherche à illustrer le principe du « transfert de style » entre deux images.
Nous avons précédemment évoqué le transfert de couleurs (en section 2.6). Le transfert de style en est une extension naturelle : au lieu de transférer uniquement les couleurs, on cherche à transférer tout le style graphique d'une image « Style » vers l'image « Source ».
C'est bien sûr un problème autrement plus complexe, et les méthodes les plus performantes du domaine utilisent généralement de gros réseaux de neurones.

« Virtual Artist » n'a pas la prétention d'être à la pointe de l'état de l'art : c'est avant tout un démonstrateur pédagogique pour expliquer le principe général du transfert de style en traitement d'images. L'utilisateur peut jouer avec différentes images de « Source » et de « Style » prédéfinies. La figure ci-dessous illustre quelques-uns des écrans principaux de l'application.

Fig. 4.2.1. L'application « Virtual Artist » illustre le principe du transfert de style entre deux images.

Ce démonstrateur a été utilisé de nombreuses fois sur une grande table tactile, dans des évènements grand public, et fait toujours son petit effet !

Fig. 4.2.2. L'application « Virtual Artist » utilisée comme démonstrateur, ici au Festival de l'Excellence Normande (FÉNO) en 2021.

4.3. GREYC Warp

« GREYC Warp », le dernier démonstrateur de ce nouveau dépôt logiciel, implémente un miroir déformant interactif. L'utilisateur voit en direct le flux de la webcam et peut créer, déplacer ou supprimer des points clés qui définissent une déformation appliquée en temps réel. Une dizaine de transformations pré-définies sont également proposées.

Fig. 4.3.1. L'application « GREYC Warp » vous laisse déformer le flux vidéo de votre webcam, de manière interactive, et non sans humour !

Pour avoir testé ce démonstrateur en situation réelle lors d'expositions, ça fait beaucoup rire les enfants (mais pas les plus jeunes qui pensent que ça reflète vraiment l'apparence de leur tête et qui peuvent se mettre à pleurer). Une application toute simple mais néanmoins amusante !

5 G'MIC et le code créatif

Ces quelques démonstrateurs esquissent déjà l'image d'un langage G'MIC adapté au code créatif, qui consiste, selon Wikipedia, à « utiliser la programmation informatique comme un moyen d'expression artistique (visuel, musical, littéraire, interactif, performatif…) à part entière ».

5.1. Codes créatifs courts

En tant qu'ancien demomaker, le code créatif est forcément un domaine qui me tient à cœur, et j'écris et partage régulièrement des scripts courts sur le forum de G'MIC pour expérimenter de nouvelles idées d'effets graphiques, ou en reproduire certains sur lesquels je suis tombé et que je trouve captivants.
Quelques-uns de ces effets récents sont décrits ci-dessous, avec à chaque fois, un accès vers le code source correspondant (script .gmic).

• Agrégation limitée par diffusion tournoyante : Cet effet est une variante de l'agrégation limitée par diffusion, implémentant un système de particules en mouvement qui sont stoppées dès lors qu'elles rencontrent une masse d'éléments plus anciens, déjà immobiles. On ajoute à tout ça une rotation, un zoom inverse, une palette de couleurs, et le tour est joué ! Le code source de cet effet atteint difficilement les 36 lignes, commentaires inclus !

Fig. 5.1.1. L'effet animé « Agrégation limitée par diffusion tournoyante », rendu par G'MIC.

• Courbe de Hilbert néon : Cette animation stylise le dessin d'une courbe de Hilbert par un tracé incrémental faisant songer à un néon. Ici, le code source est beaucoup plus conséquent (52 lignes 😉).

Fig. 5.1.2. L'effet animé « Courbe de Hilbert néon », rendu par G'MIC.

• Morphing de formes : Ici, deux silhouettes se transforment l'une vers l'autre via un morphing continu. On utilise des edgels pour l'extraction et la paramétrisation du contour des deux silhouettes à transformer. Le code source de cet effet revient à un nombre de lignes de code quand même plus raisonnable que précédemment (36 lignes).

Fig. 5.1.3. L'effet animé « Morphing de formes », rendu par G'MIC.

• Tunnel 3D : Celui-ci est l'un de mes préférés. C'est certes un effet ultra-classique dans le monde de la scène démo, mais le rendu est sympa. Et avec ses 68 lignes, le code source pour générer cette animation de 256 frames (qui cyclent parfaitement) reste dans les limites du raisonnable !

Fig. 5.1.4. L'effet animé « Tunnel 3D », rendu par G'MIC.

• One-liner géométrique : Le langage G'MIC, grâce à sa syntaxe délibérément concise, est un candidat idéal pour la création de one-liners. Une section entière de la documentation de référence est d'ailleurs dédiée à quelques one-liners amusants. Étant tombé par hasard sur cette belle image créée avec GeoGebra par Georg Wengler, j'ai souhaité la retranscrire en langage G'MIC sous la forme d'une unique ligne de commande affichant une animation, et voici le résultat (et heureusement qu'une ligne de code ne se limite pas à 80 caractères !)

$ gmic 12,12,256,2,"a = 1 + x; b = 1 + y; t = lerp(0,2*pi*b,z/d); cos(a/b*t)*cexp([0,t])" 12,12,1,2,"S = crop(#-1,x,y,0,c,1,1,d#0,1); S = round(45*(S - avg(S)) + 50); draw(#-1,S,x,y,0,c,1,1,d#0,1)" rm. 1200,1200,1,3,255 repeat 256 { 12,12,1,1,"repeat (16,l, X = 100*[x,y] + round(I(#0,x,y,$> + l/16,2,2)); ellipse(#-1,X,1,1,0,1,0))" rm. +rs. 600 w. rm. wait 20 } rm

Fig. 5.1.5. L'effet animé « cos(ab) », rendu par G'MIC.

L'ensemble de ces nouvelles animations se retrouve dans la section Gallery du site web de G'MIC.

5.2. Continuation de la série « G'MIC Adventures »

De temps en temps, j'essaie aussi de partager l'ensemble du processus permettant d'arriver (en partant de zéro) à un résultat de code créatif.
Et cela, rédigé sous la forme d'un petit article partagé sur le forum de G'MIC. Cette série d'articles est nommée « G'MIC Adventures ». Je l'avais évoquée dans notre dernière dépêche. Deux nouveaux épisodes de cette série sont parus depuis :

• Apprentissage d'un perceptron multi-couches pour la reproduction d'une image couleur (G'MIC Adventure #5) :

Dans ce cinquième épisode, on cherche à entrainer un réseau de neurones simple (un perceptron multi-couches) capable d'apprendre une fonction image entière , c'est-à-dire un réseau capable de prédire une couleur correcte à partir d'un vecteur de coordonnées donné en entrée. Il est particulièrement intéressant de visualiser l'image couleur que le réseau est capable de reproduire à chaque itération de son apprentissage (figure ci-dessous), et ce, jusqu'à convergence.

Fig. 5.2.1. Reconstruction itérative d'une image couleur obtenue par l'apprentissage d'un perceptron multi-couches.

• S'amuser avec l'équation d'ondes (G'MIC Adventure #6) :

Dans ce sixième épisode, on s'intéresse à l'implémentation en G'MIC de l'équation d'ondes et ses possibilités pour appliquer des effets de déformations amusants sur des images, comme l'illustre la figure suivante qui correspond au résultat obtenu à la toute fin de l'article.

Fig. 5.2.2. Application d'une équation d'ondes anisotrope pour la déformation d'une image le long de ses contours.

Les exemples présentés dans cette section montrent que G'MIC a du potentiel pour le code créatif, notamment pour l'expérimentation rapide de codes d'effets graphiques. Le fait qu'il soit utilisable en ligne de commande (via la commande gmic) en fait un allié précieux pour générer des animations ou pour modifier des lots d'images de manière automatisée.

6. Autres nouvelles liées au projet

Pour finir cette longue dépêche, voici en vrac quelques autres nouvelles notables liées au projet :

• Diffusion de G'MIC : Avec le temps, la diffusion de G'MIC s'accélère et son installation se simplifie. Notons tout d'abord que G'MIC-Qt a été parmi les premiers greffons disponibles lors de la sortie de la version majeure 3.2 de GIMP. L'installation de ce greffon est maintenant aussi largement simplifiée pour les utilisateurs de macOS, grâce au travail remarquable des empaqueteurs de MacPorts, qui en proposent une version toujours très à jour.

Nous avons également appris que G'MIC suscite l'intérêt des projets suivants :

1. Le projet G'MIC-GEGL a pour objectif d'exposer les différents filtres du greffon G'MIC-Qt directement sous forme de nœuds GEGL, qui est la bibliothèque de traitement utilisée en interne dans GIMP. Cela voudrait dire que les effets de G'MIC-Qt pourraient à terme être utilisés dans des calques d'effets non-destructifs de GIMP.
2. Le projet PhotoFlare est un nouvel éditeur d'images numériques multi-plateformes, et son développeur a annoncé y avoir intégré le greffon G'MIC-Qt afin de profiter de ses centaines de filtres proposés.
3. Le projet gmic-affinity se propose de développer un greffon en Rust pour Affinity Photo, pour exposer le greffon G'MIC-Qt aux utilisateurs. Ce dernier est normalement déjà fonctionnel pour ce logiciel, via l'API 8bf (comme le montre cette vidéo), mais malheureusement pas encore pour les utilisateurs de macOS.
4. Enfin, notons l'arrivée de G'MIC-Qt sur le Snap Store, proposant ainsi une façon alternative d'installer notre greffon pour GIMP.

• Exposé : Début mai 2026, j'ai eu l'occasion de faire un bref passage au laboratoire LRDE de l'EPITA, sympathiquement invité par Marc Espie (enseignant et l'un des développeurs du projet OpenBSD), où j'ai donné une présentation intitulée « 25 ans de développement libre pour le traitement des images numériques ». Une vidéo de cette présentation a été captée et mise sur YouTube.

7. Conclusion

Cette version 4.0 marque un jalon important pour G'MIC : dix-huit ans après la première ligne de code, le projet a montré qu'un logiciel open-source né au sein d'un laboratoire de recherche public, et aux ressources modestes, peut s'installer durablement dans le paysage du graphisme numérique libre, et continuer à innover grâce à son écosystème ouvert et extensible.

Cette dépêche a cherché a montrer la maturité et la polyvalence de G'MIC. C'est un cadriciel multi-usages dont les interfaces variées peuvent toucher des publics différents, de l'artiste numérique au bidouilleur de la ligne de commande, en passant par le chercheur en traitement d'images, à partir du moment où une image numérique entre en jeu !

C'est aussi l'occasion de rappeler que rien de tout cela n'aurait été possible sans l'écosystème bienveillant qui gravite autour du projet. Nous tenons à remercier chaleureusement nos partenaires académiques (le CNRS, l'ENSICAEN, l'Université de Caen, la direction du GREYC), ainsi que l'ensemble de la communauté (testeurs, empaqueteurs, vidéastes et utilisateurs du quotidien). Votre soutien est très apprécié.

Les idées fourmillent, l'envie de triturer des pixels est toujours aussi présente, et on espère donc pouvoir continuer à développer et valoriser ce cadriciel libre comme il se doit dans le futur.

Y aura-t-il une nouvelle dépêche l'année prochaine ? L'avenir nous le dira !