Sortie de GIMP 2.99.10 (version de développement)

GIMP 2.99.10 représente une fois encore une avancée significative dans notre feuille de route vers GIMP 3.0. Nous avons revu la conception de certains éléments au cœur de GIMP (les « calques liés », l'interface graphique des verrous d'objets, l'option de la dynamique de brosse), la nouvelle API a été grandement améliorée et se rapproche d'une version publiable, babl et GEGL ont reçu des optimisations incroyables, plus d'attention a été portée à macOS et à Wayland, le tout en améliorant les formats de fichiers… Et bien plus encore !

La dépêche ci-dessous présente les changements les plus intéressants.

Sommaire

• Fonctionnalités centrales revues et corrigées
  • Les « calques liés » remplacés par les « ensembles de calques »
  • Les verrous d'objets revus et corrigés
  • Simplification de l'activation/désactivation de la dynamique de brosse
• Nouvelles fonctionnalités centrales
  • Nouvelle option pour le mode « Détection de traits » de l'outil de remplissage
  • Boîte de dialogue de bienvenue
• Aller plus loin avec le « curseur compact »
• Greffons officiels
  • PSD
  • JPEG-XL
  • Curseur Microsoft Windows (.cur)
  • Capture d'écran
  • HEIF
  • Obsolescence des greffons help-browser et webpage
• Compilation et documentation
  • Mise à jour de la gestion des thèmes d'icônes
  • Vérification "clang-format" dans l'intégration continue
  • Outil de bisection/test pour les anciennes versions de flatpak
  •  Nouvelle documentation pour les contributeurs
• Amélioration de l'API des greffons
• Prise en charge de Wayland et macOS
• babl et GEGL
  • Création automatique de LUT pour les conversions avec babl
  • Compilations SIMD pour x86_64 et ARM neon (ctx, babl et GEGL)
  •  Autres améliorations
• Des nouvelles de l'équipe
• Statistiques de la sortie
• Télécharger GIMP 2.99.10
• Et ensuite ?

"Expériences" par Aryeom, Creative Commons by-sa 4.0 - GIMP 2.99.10
Pour une liste plus exhaustive des changements apportés, vous pouvez consulter le fichier NEWS ou jeter un œil à l'historique des modifications.

Fonctionnalités centrales revues et corrigées

Les « calques liés » remplacés par les « ensembles de calques »

Notre série stable (2.10) utilise toujours l'idée de « calques liés », qui sont surtout employés pour transformer plusieurs calques à la fois. Par exemple, si vous voulez appliquer une translation, une rotation ou toute autre déformation sur plusieurs calques exactement de la même façon, vous pouvez les lier avec l'icône "lien" 🔗 à côté de chaque calque dans l'ancrable Calques.

Dans GIMP 3.0, nous pouvons sélectionner plusieurs calques simultanément et tous les outils de transformation ont déjà été modifiés pour pouvoir travailler sur plusieurs calques à la fois. Cela rend le concept de « calques liés » redondant et déroutant. Malgré tout, il avait encore un avantage : celui de servir à enregistrer une relation existante entre plusieurs calques.

C'est pour cette raison que nous avons décidé de retirer la fonctionnalité de liaison et de la remplacer par une fonctionnalité d'« ensemble de calques ». Un « ensemble de calques » est une sélection de calques enregistrée sous un nom.

Dialogue flottant pour "layer set" (ensemble de calques) au bas de l'outil Calques

Par exemple, vous pouvez sélectionner quelques calques et enregistrer cette sélection en tant qu'ensemble de calques. Plus tard, vous pouvez sélectionner les mêmes calques à nouveau en un seul clic, sans avoir à cliquer sur chacun d'eux l'un après l'autre. Dans l'illustration ci-dessous, je crée un ensemble de calques contenant des marmottes endormies avec un nom sémantique :

À gauche : sélection de calques puis ajout d'un nom pour l'ensemble - à droite : l'ensemble peut être re-sélectionné en un clic à tout moment

Et il y a plus ! La même boîte de dialogue permet de rechercher par nom parmi les calques. Imaginons que je désire sélectionner tous les calques contenant « marmotte » ou « fleur » : je peux simplement rechercher le mot-clé correspondant.

Recherche des calques dont le nom comporte « flower » ; trois ont été trouvés dans cette liste de calque gigantesque

Pour les plus geeks d'entre nous : par défaut, cette fonctionnalité utilise une simple recherche de texte, mais dans les Préférences, onglet « Interface », vous pouvez également régler l'entrée de recherche pour utiliser la syntaxe Glob ou les expressions régulières.

Réglages pour la syntaxe de la recherche : recherche texte, glob ou expression régulière

Les verrous d'objets revus et corrigés

Les verrous (position, contenu et alpha) étaient auparavant situés tout en haut des ancrables de Calques et de Canaux. Pour savoir si un calque en particulier était verrouillé, cela forçait à le sélectionner. Pire, lorsque plusieurs calques étaient sélectionnés, les boutons pouvaient montrer une information contradictoire (si certains calques étaient verrouillés alors que d'autres non).

Du coup, nous avons déplacé les verrous vers l'endroit laissé vacant par l'icône « lien » 🔗 maintenant disparue, à proximité de chaque objet. Un clic sur un verrou ouvre un petit dialogue flottant dans lequel vous pouvez sélectionner le type de verrou. La sélection d'un seul verrou le montrera à côté de l'icône de visibilité (œil 👁️), et la sélection de plusieurs verrous montrera une icône générique multi-verrous. Chacune des nouvelles icônes, spécifique ou générique, a été conçue par Aryeom. À présent vous pouvez savoir d'un seul coup d'œil sur la liste des calques lesquels sont verrouillés ou non.

À gauche : boîte flottante après clic sur la zone de verrou; au milieu : position verrouillée (icône spécifique visible); à droite : contenu verrouillée (deux verrous utilisés : icône multi-verrous visible)

Les icônes de verrouillage permettent, entre autres avantages, l'interaction Majuscule-clic de la même manière que pour les icônes de visibilité, ce qui permet de basculer les verrous de plusieurs objets à la fois. Nous avons aussi créé une nouvelle interaction Alt-clic qui permet de basculer les verrous de tous les calques sélectionnés. Nous avons donc maintenant :

• Simple clic sur une icône de visibilité ou de verrou : la visibilité ou le verrouillage de l'objet cliqué est changé(e).
• Majuscule-clic : l'objet cliqué demeure visible/verrouillé alors que la visibilité/le verrouillage de tous les autres objets de même niveau dans l'arbre des calques est basculé(e) vers ON ou OFF.
• Alt-clic : l'objet cliqué demeure visible/verrouillé alors que la visibilité/le verrouillage de tous les autres objets sélectionnés est basculé(e) vers ON ou OFF.

Vous remarquerez que nous avons aussi ajouté un nouveau verrou, le "Verrou de Visibilité". Comme son nom l'indique, il empêche la modification de l'état de visibilité. Cela est particulièrement utile associé aux fonctionnalités permettant de modifier plusieurs objets à la fois, comme les interactions Majuscule-clic et Alt-clic décrites plus haut. Vous pouvez par exemple avoir une image d'arrière-plan verrouillée pour être toujours visible, puis vous pouvez modifier la visibilité des calques d'avant-plans tout en gardant l'arrière-plan visible. À l'opposé, vous pouvez éviter de rendre visible votre croquis initial par erreur.

Verrouillage de la visibilité des calques d'arrière-plan en « toujours visible » et du calque de croquis en « jamais visible »

Parmi les autres changements sur ce sujet, les verrous de transparence et de position peuvent maintenant être appliqués sur les groupes de calques :

• Le verrou de transparence (alpha) pour les groupes marche à peu près comme le verrou de contenu pour les groupes (si ce n'est qu'il n'affecte que le canal alpha), c'est à dire qu'il empêche de modifier le canal alpha des calques fils.
• Le verrou de position marche dans les deux sens en empêchant de déplacer les calques fils mais aussi les calques parents.

Un document a aussi été rédigé pour mieux spécifier le comportement des différents verrous.

Enfin, deux changements ont été apportés pour améliorer la découvrabilité des boutons de visibilité et, surtout, de verrouillage :

• L'en-tête des colonnes de visibilité et de verrouillage dans l'ancrable comportent à présent des icônes, ce qui rend leur présence plus flagrante.
• Notre thème par défaut fournit désormais des indices visibles autour des zones de boutons inactifs lors du survol de ces zones cliquables.

Notez les icônes d'en-tête « Visibilité » et « Verrou » et la bordure visible autour des zones cliquables lors du survol par le pointeur

Simplification de l'activation/désactivation de la dynamique de brosse

Il est désormais possible d'activer et de désactiver la dynamique de brosse via une simple case à cocher, au lieu d'avoir à sélectionner la dynamique neutre « Dynamics Off ». Bien sûr, cette dynamique neutre a été retirée de la liste des données installées.

Cela permet de désactiver la dynamique de brosse en un seul clic, et de ne pas avoir à se rappeler de la dernière dynamique utilisée lorsque vous voulez la réactiver.

Activation et désactivation de la dynamique de brosse en un clic

Pour les utilisateurs avancés, nous avons également ajouté la nouvelle action context-dynamics-toggle. Vous pouvez ainsi créer un raccourci (menu Édition > Raccourcis clavier) pour (dés)activer la dynamique de brosse encore plus facilement.

Ajout d'un raccourci pour activer/désactiver la dynamique de brosse dans le dialogue des Raccourcis Clavier

Nouvelles fonctionnalités centrales

Nouvelle option pour le mode « Détection de traits » de l'outil de remplissage

Nous avons ajouté une nouvelle option « Autoriser la fermeture des traits dans le calque sélectionné » dans le mode « Remplir par détection de traits de dessin » de l'outil de remplissage. Le nom de l'option n'est pas forcément final, car il a été difficile à choisir.

Voici ce qu'elle permet : lorsque vous choisissez la source « Calque [sous le|au-dessus du] calque actif », le calque actif n'est pas utilisé comme source du dessin au trait (comme le nom l'indique). Cependant, avec cette option vous avez la possibilité de peindre avec votre couleur de remplissage directement dans le calque actif et d'adjoindre ces données en tant que données de fermeture.

Une fois encore, le calque actif n'est pas utilisé comme source pour la détection de dessin au trait, ce qui signifie que cela n'entraîne aucun nouveau calcul. Cela constitue seulement des données additionnelles pour une fermeture des traits à la main, après la détection initiale de traits et le calcul des fermetures de traits.

Un des usages principaux pourrait être de régler la « Longueur d'intervalle maximale » à zéro, ce qui désactive entièrement le calcul de fermeture des traits et réduit beaucoup les calculs (d'où un gain de rapidité pour les grandes images en dessin au trait). Ensuite, la fermeture des traits se ferait entièrement à la main. Malheureusement, parfois vous ne voulez pas clore un trait avec la couleur/la brosse/le style de votre trait mais plutôt avec la couleur/la brosse/le style de votre remplissage. C'est là que cette option entre en jeu.

Par exemple, voici une vidéo démontrant comment vous pourriez remplir le dessin au trait avec la fermeture automatique qui résulterait en une segmentation excessive si la « Longueur d'intervalle maximale » n'est pas bien réglée. De plus, la fermeture de trait (ici au bas des jambes du personnage) serait sans doute différente du style désiré :

• Voir la vidéo de démonstration en mp4
• Voir la vidéo de démonstration en webm

À présent, désactivons l'algorithme de fermeture automatique et utilisons plutôt la nouvelle option. Nous allons tout simplement peindre avec la couleur de remplissage et le style désirés afin de fermer le dessin au trait, et cela sera considéré comme « trait » sans recalcul. De cette façon, le remplissage est instantané et le style de la fermeture est exactement celui désiré :

• Voir la vidéo de démonstration en mp4
• Voir la vidéo de démonstration en webm

Cette nouvelle option est basée sur une astuce d'Aryeom pour le dessin numérique avancé concernant la manière de mettre en couleurs un croquis efficacement (elle utilisait cette approche bien avant la fonctionnalité de « Remplissage par détection de dessin au trait » de GIMP, avec Sélection contiguë et l'option « Échantillonner sur tous les calques ». La fermeture des traits de dessin avec le style de remplissage est une des nombreuses techniques qu'elle enseigne aux étudiants en art numérique à l'université. Nous avons pensé qu'intégrer cette approche dans notre outil de dessin au trait serait un avantage significatif, car Aryeom était déçue par l'absence de style et de contrôle avec l'outil de fermeture automatique.

Note : nous avons conscience que les réglages de cet outil sont un peu compliqués à appréhender. Nous espérons améliorer l'interface bientôt.

Boîte de dialogue de bienvenue

GIMP a maintenant une boîte de dialogue de bienvenue qui apparaît une seule fois après une nouvelle installation ou une mise à jour. Elle affichera l'image d'accueil, un court texte et des liens vers la documentation.

Elle présente également un onglet « Notes de sortie » avec la liste des changements de la nouvelle version afin que chacun puisse jeter un œil aux nouveautés.

Boîte de dialogue de bienvenue après une nouvelle installation ou une mise-à-jour

Note : la version actuelle de l'installeur pour macOS ne contient pas les notes de sortie (c'était aussi le cas pour Windows mais ça a été résolu dans une révision de l'installeur).

Les actualités publiées sur le site web (celles que vous pouvez lire en anglais sur gimp.org ou en traduction sur LinuxFr!) continueront à fournir des textes plus étoffés avec des captures d'écran explicatives. Mais les personnes qui ne visitent pas le site web pourront au moins lire la boîte de dialogue de bienvenue.

Par ailleurs, un des avantages des notes de sortie présentes dans la boîte de dialogue de bienvenue est qu'elles peuvent être intégralement régionalisées par nos traducteurs (contrairement au site web dans sa version actuelle). Par exemple, voici les notes de sorties qui apparaissent dans la version portugaise de GIMP :

Les notes de sortie de la boîte de dialogue de bienvenue sont régionalisées; par exemple ici en Portugais.

Cette boîte de dialogue de bienvenue pourra être amenée à évoluer. Par exemple, un onglet de « Personnalisation » pour certains des réglages les plus controversés (comme les thèmes et les icônes) sera probablement ajouté.

Une autre question est l'ajout de fonctionnalités dédiées à un usage plus quotidien, comme la liste des dernières images ouvertes ou une option « Nouvelle Image », ce qui permettrait d'éviter d'avoir à utiliser les menus ou les raccourcis au démarrage. Bien sûr, cela implique d'offrir une option pour afficher la boîte de dialogue à chaque démarrage (au lieu de l'afficher uniquement après une mise à jour comme c'est le cas actuellement).

Aller plus loin avec le « curseur compact »

Notre « curseur compact » était uniquement accessible dans le code principal jusqu'à récemment. Cela impliquait que les greffons ne pouvaient pas utiliser ce curseur. Ce widget a été déplacé vers la bibliothèque libgimpui, ce qui le rend désormais utilisable par n'importe quel greffon qui désire un curseur esthétique et pratique avec des mouvements relatifs lents, des mouvements de glissement rapides et une édition directe par le clavier (cf. une partie du travail sur l'ergonomie dans une ancienne dépêche, tout cela en maximisant l'espace.

Quelques uns de nos greffons officiels l'utilisent déjà.

La boîte de dialogue du greffon d'exportation de PNG avec curseur compact

De plus, notre thème par défaut System le rend encore plus compact, car il y avait des réclamations comme quoi ce curseur compact ne l'était pas assez (compact) !

Greffons officiels

PSD

Comme souvent ces derniers temps, notre greffon PSD a reçu des soins attentionnés pour élargir nos capacités de prise en charge :

• nouvelle prise en charge pour charger des images CMYK avec canaux 16 bits.
• nouvelle prise en charge des fichiers en espace de couleur LAB.
• nouvelle prise en charge pour charger des images avec canaux 32 bits (du code existait déjà mais n'avait peut-être jamais vraiment fonctionné).
• ajout de groupes de calques supplémentaires lors du chargement d'images PSD avec des masques d'écrêtage de calques: Photoshop et GIMP gèrent les masques différemment. La seule solution pour obtenir un résultat similaire est d'ajouter des groupes de calques supplémentaires. Les calques PSD ayant l'écrêtage activé, combinés avec le premier calque sans écrêtage en dessous, sont groupés ensemble dans un nouveau groupe de calques. Cela produit la même image que l'image PSD fusionnée, à moins que d'autres éléments PSD que nous ne prenons pas encore en charge soient présents.
• Les calques PSD avec écrêtage activé nécessitent comme mode de composition « Attacher à la toile de fond » : certains calques PSD ont un marqueur appelé "clipping" réglé à 1. Nous ne prenions pas en charge ce marqueur et nous avons reçus des signalements de débordements de couleurs. Nous réglerons le mode de composition des calques de GIMP à « Attacher à la toile de fond », ce qui est ce que nous pouvons faire de plus proche du "clipping" de Photoshop. De cette manière, les couleurs ne déborderont plus.

JPEG-XL

Notre prise en charge de JPEG-XL continue également à être améliorée :

• La profondeur de couleur peut maintenant être sélectionnée dans l'exportation vers JXL.
• L'importation avec une précision entière sur 8 ou 16 bits est maintenant possible (auparavant GIMP importait toutes les images JXL en images avec précision flottante sur 32 bits).
• Nouveaux réglages pour l'exportation très rapides : tonnerre et éclair (le plus rapide).
• Le curseur de compression est désactivé pour le sans perte.

Curseur Microsoft Windows (.cur)

GIMP est maintenant capable de charger et d'exporter les Curseurs Microsoft Windows, avec la possibilité de lire lors de l'importation, et de conserver et d'éditer lors de l'exportation, la position du point chaud (« hot spot », c'est à dire là où le curseur pointe) pour chaque curseur présent dans le fichier.

Capture d'écran

Nous avons définitivement retiré la prise en charge des portails KDE et GNOME pour les captures d'écran. Dans les versions récentes de ces portails, de nouvelles contraintes de sécurité les rendaient inutilisables pour GIMP qui ne disposait pas des permissions adéquates.

Nous utilisons maintenant uniquement le portail Freedesktop sous Linux (à moins que l'accès direct via X11 soit possible, c'est à dire que nous utilisons le portail sous Wayland, l'accès direct sous X11), ce qui est l'approche à présent recommandée à la fois par les équipes de GNOME et de KDE.

Sous Windows, le greffon de Capture d'écran a enfin une option « Inclure le pointeur de la souris ».

HEIF

Le greffon HEIF appliquait auparavant une heuristique pour le choix de la profondeur de couleur par défaut lors de l'exportation, en fonction de l'encodage de l'image. Cependant, tout le monde n'était pas satisfait par cette heuristique.

Cela allait aussi à contre-courant du stockage des réglages qui est maintenant une fonctionnalité de base de la plupart des greffons.

C'est pourquoi nous avons décidé de tout simplement abandonner cette heuristique et de laisser la responsabilité du choix de la profondeur de couleur entièrement à l'utilisateur.

Obsolescence des greffons help-browser et webpage

Nous avons deux greffons qui dépendent de la bibliothèque WebkitGTK :

1. help-browser: pour l'affichage de la documentation html. Tous les ordinateurs ayant un navigateur de nos jours, ce greffon était redondant. Cependant son principal avantage était son « arbre de sujets » très agréable, qui est une sorte de menu latéral pour naviguer à travers la documentation très rapidement.
2. web-page: un greffon pour la capture d'écran de pages web, qui permet de capturer toute la page et non pas seulement la partie visible. C'est une fonctionnalité très pratique, mais elle est également fournie par la plupart des navigateurs web de nos jours. Dans Mozilla Firefox par exemple, vous pouvez faire un clic droit puis sélectionner « Effectuer une capture d’écran » dans le menu contextuel de la page.

D'un autre côté :

1. WebkitGTK est long et difficile à compiler. Nous avons rencontré des difficultés plus d'une fois et nous les redoutons. En fait, notre paquet macOS ne l'inclut pas pour le moment à cause de ce genre de difficultés.
2. D'après ce que nous avons compris, il n'y a pas de support officiel pour les versions récentes sous Windows et nous ne savons pas quand/si cela changera bientôt.

Nous avons donc deux de nos plateformes principales qui n'utilisent pas WebkitGTK, cette bibliothèque conduit à de nombreux problèmes pour l'empaquetage, tout cela pour des fonctionnalités qui sont de toute façon plutôt redondantes avec les navigateurs modernes. C'est pourquoi nous avons décidé de jeter l'éponge, au moins pour le moment, en rendant obsolètes ces deux greffons. À moins que la situation ne s'améliore, nous ne recommandons plus aux responsables des paquets d'assembler ces greffons.

Compilation et documentation

Mise à jour de la gestion des thèmes d'icônes

Notre code pour gérer les thèmes d'icônes était un peu confus à cause des trop nombreux cas à prendre en charge, nous l'avons donc retravaillé :

• Nous utilisons à présent exactement la même liste pour les thèmes d'icônes Color et Symbolic, à la fois dans leurs versions SVG et PNG.
• La version PNG des deux thèmes est désormais entièrement générée à partir des fichiers SVG plutôt que de tout dupliquer et de risquer des bogues étranges avec certaines options de compilation particulières.
• Notre intégration continue comporte maintenant une tâche hebdomadaire pour vérifier que les règles de compilation pour meson et autotools sont à jour et synchronisées en ce qui concerne les icônes.
• Nous avons commencé à grouper les icônes dans des listes sémantiques quand cela était possible afin de décider plus facilement des tailles à choisir pour générer les versions PNG.

En passant, pourquoi gardons-nous la version PNG disponible ? Nous avions d'abord l'intention de la retirer, mais il s'avère que la dépendance librsvg utilisée pour charger les GdkPixbuf, et qui a été portée en Rust dans ses dernières versions, ne compile pas sur toutes les plateformes et architectures (étant donné que Rust n'est pas encore entièrement portable). Cela veut dire que certaines plateformes peuvent avoir besoin soit d'utiliser de très vieilles versions de librsvg, soit de préférer l'usage d'icônes PNG uniquement. C'est la raison pour laquelle nous gardons la version PNG pour le moment. Cela n'est pas optimal et nous conseillons fortement d'utiliser les icônes SVG sur les plateformes pour lesquelles librsvg n'est pas un problème. Mais de cette manière, une alternative est disponible.

Il faut aussi noter qu'il y a un autre cas pour lequel nous dépendons de librsvg : le greffon d'importation SVG, qui a été rendu obligatoire. Nous ne changeons pas cela car, en tant que professionnels du graphisme, nous considérons que de nos jours il est nécessaire de pouvoir importer des images SVG même dans un programme d'images matricielles. Ce format est tout simplement un standard professionnel et il semblerait absurde de ne pas le prendre en charge. Néanmoins, nous comprenons que cela peut être un problème pour certaines plateformes : responsables des paquets, n'hésitez pas à désactiver le greffon SVG si cela est vraiment un problème pour vous, comme cela nous a été rapporté. Cela devrait être assez simple à faire.

Vérification "clang-format" dans l'intégration continue

Un nouveau fichier .clang-format a été ajouté à notre dépôt et désormais chaque demande de fusion déclenchera une tâche d'intégration continue pour vérifier le style du code introduit dans le correctif proposé.

Pour être francs, nous ne sommes pas totalement satisfaits avec les résultats de cette vérification, et c'est pourquoi les échecs de cette tâche ne sont pas bloquants, seulement informatifs. Disons que c'est un premier pas, en espérant que cette vérification de style de code s'améliorera.

Outil de bisection/test pour les anciennes versions de flatpak

Note : ceci est un peu une fantaisie de développeur, et peut ne pas être d'un grand intérêt pour les autres.

Flatpak a des limites mais aussi des fonctionnalités assez intéressantes. L'une d'entre elles est la possibilité d'installer d'anciennes versions du paquet facilement. Cela peut être un outil assez sympa pour les développeurs lorsqu'on veut tester quelque chose sur une ancienne version de GIMP, une sorte de git bisect mais avec les paquets flatpak. Néanmoins faire la liste des anciennes versions, désinstaller la version courante, installer l'ancienne version concernée, et se souvenir des lignes de commande pour tout ça (étant donné qu'on ne le fait pas tous les jours non plus) rendait cette approche peu utilisable en pratique.

Voici où cet outil intervient :

$ tools/flatpak-releases  -h
Usage: ./flathub-releases [--beta] [--system] [-X] [org.example.app]

List all flatpak builds stored on Flathub or GNOME repository.
The builds for org.gimp.GIMP are looked up by default unless
you provide explicitely another AppStream ID.

Adding a -X number as option install the numbered release
instead of listing them.

Options:

-0: install the last build.
-1: install the previous build.
-2: install the before-previous build (and so on).

--beta: list or install a beta release
--nightly: list or install a nightly release
--system: install as system flatpak (default to user install)

Imaginons que je désire connaître la liste des versions beta encore disponibles sur Flathub :

$ tools/flatpak-releases --beta
 0: Working around weird install path of appstream file. (be96fed3) [2022-02-24 00:37:25 +0000]
 1: Update dependencies (127a0fa7) [2022-01-13 16:59:43 +0000]
 2: Issue #106:  File->Create->From Screenshot not working. (9c831b14) [2021-12-14 21:46:52 +0000]
 3: Release GIMP 2.99.8. (908bf5b0) [2021-10-20 20:29:00 +0000]
 4: Release GIMP 2.99.6. (e04355dd) [2021-04-26 14:08:32 +0000]
 5: Make sure the default path for plug-ins and scripts point to the extension point (8b02ea26) [2021-03-31 16:12:06 +0000]
 6: Build Little-CMS 2.12 ourselves. (ae60863e) [2021-03-29 16:03:51 +0000]
 7: Add extension point for Gimp3 (34b2f8c0) [2021-03-27 12:40:57 +0000]
 8: Release GIMP 2.99.4. (20a0a962) [2020-12-22 23:45:19 +0000]
 9: Update to GNOME Platform 3.38. (a84da0fa) [2020-11-14 23:08:38 +0000]
10: Use org.gnome.Platform//3.36beta. (12017e04) [2020-11-06 22:59:59 +0000]
11: Release GIMP 2.99.2! (58fef365) [2020-10-25 22:20:18 +0000]
12: Add shared module for intltool. (a1d2b211) [2020-06-01 18:34:15 +0000]

Le numéro 0 correspond à la version 2.99.10 de GIMP (le paquet a enregistré le message du dernier commit, qui peut ne pas être aussi informatif que nous le voudrions). À présent, imaginons que je veuille installer la version 2.99.6 de GIMP pour faire un test :

$ tools/flatpak-releases --beta -4
[1/2] Installing org.gimp.GIMP
Looking for matches…
Skipping: org.gimp.GIMP/x86_64/beta is already installed
[2/2] Updating to commit '9165cae20b6ad8549ff8053385b0facd15bb11fc8733e0b9c50aed0e961a6c3e' (4's previous build)
Looking for updates…


        ID                     Branch         Op         Remote               Download
 1. [✓] org.gimp.GIMP          beta           u          flathub-beta         43.4 MB / 75.5 MB

Updates complete.
Build 4 released on 2021-04-26 14:08:32 +0000 was installed.
Build subject: Release GIMP 2.99.6. (e04355dd)
Build commit on flathub-beta: 9165cae20b6ad8549ff8053385b0facd15bb11fc8733e0b9c50aed0e961a6c3e

Et voilà ! En deux commandes et en moins d'une minute, je peux maintenant lancer notre paquet flatpak beta pour GIMP 2.99.6, qui correspond à un retour 4 paquets en arrière.

Cette commande permet d'installer facilement les paquets stables, beta et les compilations hebdomadaires.

 Nouvelle documentation pour les contributeurs

Notre documentation destinée aux développeurs était un peu légère et plus trop maintenue ces derniers temps, et l'écriture d'une nouvelle version a débuté. Elle est encore très incomplète et certains passages sont basés sur d'anciennes docs qui peuvent ne plus être à jour, ou mériteraient au moins une relecture. En tout cas, le travail est en cours.

Pour celles et ceux qui désirent contribuer à GIMP, vous pouvez commencer par ici.

Amélioration de l'API des greffons

Nous sommes toujours en plein travail sur l'API. Voici les changements les plus notables qui ont eu lieu pendant la préparation de GIMP 2.99.10 :

Changements dans libgimp :

• Le type GimpStringArray a été abandonné au profit de GStrv. Plusieurs API de libgimp ont été mises à jour pour utiliser GStrv, et les procédures de greffons correspondantes avec des arguments ou des valeurs retournées de type GStrv ont également été mises à jour.
• Nouvelles fonctions :
  • gimp_context_are_dynamics_enabled()
  • gimp_context_enable_dynamics()
  • gimp_item_get_lock_visibility()
  • gimp_item_set_lock_visibility()
  • gimp_pdb_run_procedure_config()
• Fonctions retirées :
  • gimp_item_get_linked()
  • gimp_item_set_linked()

Changements dans libgimpui :

• Nouveaux objets graphiques (widgets) :
  • GimpLabelColor (maintenant utilisé par défaut pour les propriétés GimpRGB dans GimpProcedureDialog)
  • GimpLabelEntry (maintenant utilisé par défaut pour les propriétés de chaînes de caractères dans GimpProcedureDialog)
  • GimpSpinScale (voir plus haut)
• Nouvelles fonctions :
  • gimp_color_area_enable_drag()
  • gimp_event_triggers_context_menu() : une alternative à gdk_event_triggers_context_menu() avec la capacité supplémentaire d'utiliser les événements de « bouton relâché » comme déclencheur de menu contextuel (au lieu des événements de « bouton pressé »), ce qui peut être préférable dans certains cas. À part cela, cette fonction utilise exactement les mêmes conditions que son équivalent dans GDK.
  • gimp_procedure_dialog_get_spin_scale()
  • gimp_prop_label_color_new()
  • gimp_prop_label_entry_new()
  • gimp_prop_spin_scale_new()
  • gimp_prop_widget_set_factor()
• Fonctions améliorées :
  • gimp_procedure_dialog_get_widget() peut maintenant générer des widgets de type GimpSpinScale (pour les propriétés int/double) et GimpLabelColor ou GimpColorButton (pour les propriétés GimpRGB).
  • gimp_procedure_dialog_get_color_widget() renvoie à présent des widgets GimpLabelColor (modifiables ou non).

D'autre part, les liaisons Vala gimp-3.vapi et gimp-ui-3.vapi ont été renommées respectivement en gimp-3.0.vapi et en gimp-ui-3.0.vapi dans la compilation avec autotools (ce qui est maintenant cohérent avec meson).

En passant, il semble qu'il existe toujours des problèmes avec les greffons Vala et Lua sous Windows avec l'installeur que nous fournissons. Nous ne connaissons pas encore l'origine de ces problèmes et nous devons creuser cela plus avant.

Prise en charge de Wayland et macOS

Différents correctifs de bogues et améliorations ont été apportés spécifiquement à la prise en charge de Wayland et de macOS. Ces deux systèmes vont souvent de pair car nous avons remarqué que de nombreux problèmes qui apparaissent avec l'un sont aussi présents avec l'autre.

Cependant, pour macOS en particulier il existait de gros problèmes de ralentissements avec la série de développement 2.99, à tel point que notre mainteneur de paquet a craint à un moment que GIMP 3.0 ne serait jamais utilisable sur macOS. Aujourd'hui, nous sommes fiers d'annoncer que ce pessimisme n'était pas justifié car nous avons finalement trouvé des solutions pour certains aspects, des contournements pour d'autres, parfois pas très élégants mais en tout cas suffisants pour que GIMP soit finalement utilisable et même plus rapide que la série 2.10 dans notre batterie de tests ! Notre seule incertitude est que le code a été principalement testé sur macOS Monterey. Nous ne connaissons pas encore la situation sur Big Sur, où les problèmes avaient commencé.

Plusieurs aspects des solutions ont conduit à des correctifs pour GTK. Tout n'est pas encore remonté en amont, mais nous utilisons déjà un ensemble de correctifs dont nous sommes contents pour notre paquet DMG. Cela aidera d'autres projets qui utilisent GTK3 et qui rencontrent des problèmes similaires.

babl et GEGL

Comme d'habitude, cette sortie s'accompagne des sorties de babl 0.1.90 et de GEGL 0.4.36.

Et celles-ci sont particulièrement intéressantes.

Création automatique de LUT pour les conversions avec babl

Citant Øyvind dans un compte-rendu récent :

babl fonctionne comme un traducteur universel de l'encodage des pixels en ayant un convertisseur de référence pas nécessairement rapide, capable de traiter n'importe quel entrée, et une collection de convertisseurs qui peuvent être mis à la chaîne pour former ce que babl appelle des poissons. Les poissons font la course entre eux pour trouver le meilleur convertisseur que babl est capable de créer.

[ Traduction libre de:

babl works as a universal pixel encoding translator by having - a not
necessarily fast reference conversion able to deal with everything - and
a collection of conversions that can be chained together into what babl
calls fishes. The fishes are raced against each other to find the best
conversion babl is able to create.

]

Dans certaines situations, une LUT (Look-Up Table, table de correspondance) aura de meilleures performances. Nous connaissons maintenant les performances de LUTs pour diverses combinaisons de bits par pixel en entrée et en sortie, et nous pouvons marquer les poissons qui marchent mieux en tant que LUTs lors de leur création. Si un tel poisson est utilisé suffisamment, le remplissage d'une LUT est déclenché.

Pour le moment un inconvénient est que cela peut ralentir légèrement la première conversion pour une paire entrée > sortie donnée. La solution qui sera peut-être implémentée plus tard serait de créer les LUTs en tâche de fond dans un fil d'exécution et de continuer à réaliser les conversions sans LUTs jusqu'à ce que cette tâche soit achevée.

Les LUTs créées au fur et à mesure sont aussi soumises à un ramasse-miettes après quelques minutes sans être utilisées, pour éviter de remplir la mémoire avec des LUTs utilisées une seule fois.

Compilations SIMD pour x86_64 et ARM neon (ctx, babl et GEGL)

Tout babl, GEGL et ctx ont reçu les mêmes changements pour les compilations et redirections SIMD.

Un code de traitement d'image écrit pour être portable et performant se prête bien à la prise en charge de l'auto-vectorisation avec SIMD par les compilateurs modernes. Nous faisons cela via des changements dans le système de compilation. Pour le moment le code reste le même pour toutes les cibles mais l'approche peut être étendue avec des fonctions intrinsèques conditionnelles.

Pour avoir une idée de l'effet que cela peut avoir, voici un test de remplissage d'un cercle avec ctx et ses différentes cibles d'encodage de pixel, sur un Raspberry Pi avec les options par défaut du compilateur (et sans prise en charge de neon). Notez que la référence de comparaison avec Cairo est le format BGRA8 (le seul autre format proposé par Cairo est A8) :

Remplissage répété d'un cercle de 256px de rayon dans un tampon de 512x512 pixels, sans Neon (plus petit = meilleur)

Et voici le même test, avec le compilateur autorisé à utiliser les instructions Neon :

Remplissage répété d'un cercle de 256px de rayon dans un tampon de 512x512 pixels, avec Neon (plus petit = meilleur)

Notez bien que les versions optimisées et non-optimisées sont toutes deux incluses, et que la disponibilité des instructions concernées est déterminé par des tests à l'exécution. Cela rend ces optimisations très portables, bien qu'elles soient basées sur des instructions d'architectures récentes.

ℹ️ Notez que ces changements (la génération automatique de LUT et le dispatch SIMD) s'appliqueront également aux versions de GIMP 2.10 dans l'avenir. Pour le moment ils sont disponibles dans 2.99 comme une sorte de beta test. Nous apprécions tous les retours si jamais vous rencontrez des soucis avec eux.

 Autres améliorations

babl est maintenant également fourni avec les formats CIE Lab u8 et CIE Lab u16 prédéfinis.

Des nouvelles de l'équipe

Sur notre dépôt source principal, l'accès « reporter » (qui permet de trier les signalements : étiquetage, fermeture, réouverture, déplacement des signalements…) a été accordé à nmat et Liam Quin.

L'accès en écriture a été accordé à Ondřej Míchal sur le dépôt des paquets flatpak sur Flathub (versions stable et beta), après les améliorations diverses apportées par ses soins à nos paquets flatpak dont un très bon travail pour la détection automatique de dépendances obsolètes avec l'outil flatpak-external-data-checker. Ce contributeur rejoint donc Hubert Figuière et moi-même (Jehan) pour la maintenance de ces paquets.

Statistiques de la sortie

42 personnes ont contribué à GIMP 2.99.10 :

• 17 développeurs ont contribué au code de GIMP pour cette micro-version :
  • 1 développeur avec plus de 300 commits (Jehan)
  • 4 développeurs avec 10 à 30 commits (Jacob Boerema, Niels De Graef, Lukas Oberhuber et Daniel Novomeský)
  • 12 développeurs avec 1 à 4 commits: Øyvind Kolås, Anders Jonsson, Asalle, Emily Gonyer, Luca Bacci, Markus Volk, Ondřej Míchal, Stanislav Grinkov, Yoshinori Yamakawa, bartoszek, Nikc et Tomasz Goliński.
• 20 traductions ont été mises à jour : allemand, anglais (GB), basque, catalan, chinois (Chine), danois, espagnol, grec, hongrois, italien, kabyle, letton, lithuanien, polonais, portugais, russe, slovène, suédois, ukrainien, vietnamien.
• 24 traducteurs ont contribué : Yuri Chornoivan, Hugo Carvalho, Anders Jonsson Matej Urbančič Rodrigo Lledó, Rūdolfs Mazurs, Asier Sarasua Garmendia, Luming Zh, Bruce Cowan, Jordi Mas, Piotr Drąg, Ask Hjorth Larsen, Boyuan Yang, Marco Ciampa, Alan Mortensen, Daniel Mustieles, Yacine Bouklif, Alexandre Prokoudine, Aurimas Černius, Balázs Meskó, Luna Jernberg, Ngọc Quân Trần, Tim Sabsch et dimspingos.
• 4 personnes ont aidé avec la documentation dans le dépôt de source : Jehan, Niels De Graef, Alexandre Prokoudine et Daniel Novomeský.
• 2 personnes ont contribué aux icônes : Aryeom et Jehan.
• 9 personnes ont contribué au système de compilation: Jehan, Lukas Oberhuber, Øyvind Kolås, Asalle, Daniel Novomeský, Yoshinori Yamakawa, Aryeom Han, Markus Volk et bartoszek.
• Une nouvelle image d'accueil par Aryeom Han.

Voici les statistiques du côté de babl, GEGL et ctx :

• 4 contributeurs à babl 0.1.90 :
  • 1 contributeur avec plus de 70 commits (Øyvind Kolås).
  • 4 contributeurs avec 1 à 4 commits : Mingye Wang, Jehan, Tomasz Golinski and Andrzej Hunt.
• 6 contributeurs à GEGL 0.4.36 :
  • 1 contributeur avec plus de 20 commits (Øyvind Kolås).
  • 5 contributeurs avec 1 à 2 commits : Anders Jonsson, Jehan, Alan Mortensen, Caleb Xu and zamfofex.
• ctx n'a pas de sorties en tant que telles puisqu'il s'agit de code embarqué dans le projet. Si on dénombre les commits au cours de la période entre GIMP 2.99.8 and 2.99.10 :
  • 1 contributeur avec plus de 600 commits (Øyvind Kolås)
  • 1 contributeur avec 1 commit (Jehan)

N'oublions pas non plus le dépôt pour la documentation qui voit une activité accrue ces jours derniers, grâce à la maintenance reprise par Jacob. Dans la même période que celle débouchant sur GIMP 2.99.10, il y a eu 5 contributeurs :

• 2 contributeurs pour la documentation même : Jacob Boerema et Anders Jonsson.
• 4 contributeurs ont travaillé sur les traductions : Rodrigo Lledó, Anders Jonsson, Jordi Mas et Piotr Drąg.

Enfin, le travail sur le dépôt pour macOS doit aussi être mentionné, grâce à notre nouveau mainteneur des paquets DMG, Lukas :

• 1 contributeur avec plus de 60 commits (Lukas Oberhuber).
• 2 contributeurs avec 1 à 2 commits : Jehan et Andreas Scherer.

Télécharger GIMP 2.99.10

Comme d'habitude, GIMP 2.99.10 est disponible sur le site officiel de GIMP (gimp.org) sous trois formes :

• le flatpak de développement pour Linux
• l'installeur Windows
• le paquet DMG pour macOS

Les autres paquets préparés par des tiers devraient bien sûr suivre (paquets pour distributions Linux ou *BSD, etc.).

ℹ️ Une anecdote : nous avons appris que GIMP avait été compilé avec succès sous Haiku OS (un système d'exploitation de plus, et pas un des plus répandus mais on en parle d'ailleurs régulièrement sur LinuxFr) et est maintenant disponible via leur système de paquets. Bien qu'on le sache déjà, cela nous émerveille toujours de voir à quel point GIMP est multi-plateforme au vu de sa présence sur presque tous les systèmes d'exploitation (oui GIMP est aussi sur GNU/Hurd d'après ce que nous avons entendu !) et toutes les micro-architectures existants. 😊

Et ensuite ?

Cette sortie est assez chargée en termes de mises à jour de l'API, ce qui est un des gros points bloquants pour la sortie de GIMP 3.0 (il y a encore des travaux en cours de ce côté). Le concept de « lien » était aussi un vieux concept qui devait disparaître pour GIMP 3.0, donc cela fait un obstacle de moins étant donné que cette évolution est maintenant achevée.

Le portage vers GTK est un autre obstacle majeur ; un travail important a été commencé dans cette direction par quelques contributeurs concernant une réorientation vers GApplication et GtkApplication et le portage de GAction. Ces correctifs sont encore en plein travaux et doivent être évalués, ils n'ont donc pas été inclus du tout dans GIMP 2.99.10. Nous aurons probablement l'occasion d'en dire plus lors de la prochaine sortie.

Pendant ce temps, les travaux concernant la prise en charge de Wayland et de macOS continuent à prendre pas mal de temps aux développeurs, comme vous pouvez le voir.

N'oubliez pas que vous pouvez faire un don au projet et soutenir financièrement plusieurs développeurs de GIMP, ce qui est une manière de donner en retour et d'accélérer le développement de GIMP.

Comme vous le savez, moi-même en tant que mainteneur de GIMP et Aryeom — qui est, dans l’ombre, responsable d’énormément d’améliorations, design, tests et de nouvelles fonctionnalités — (nous deux via le projet ZeMarmot, notamment sur Patreon et Liberapay; vous pouvez donc considérer ces comptes comme les comptes officiels de maintenance de GIMP, la majorité du code vient de là), de même qu’Øyvind en tant que mainteneur de GEGL (sur Patreon et Liberapay) sommes financés de manière participative pour pouvoir travailler à plein temps essentiellement sur du Logiciel Libre et de l’Art Libre. 🧑‍💻👩‍🎨