Sortie de GIMP 2.99.18 (version de développement)

Par : Jona Matthieu Jehan C138 orfenor Julien Jorge patrick_g Benoît Sibaud Arkem

13 mars 2024 à 03:48

Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 2.99.18 du 21 février 2024 (en anglais).

Voici enfin la dernière version de développement avant GIMP 3 ! Bien que la sortie de la version 2.99.18 soit un peu en retard par rapport au planning espéré, celle-ci contient un certain nombre de fonctionnalités et d'améliorations que nous sommes ravis de pouvoir partager avec vous.

⚠️ ☢️ Nous vous rappelons qu'une version de développement sert à présenter les travaux en cours, mais vous permet aussi de détecter et signaler les problèmes au plus tôt. En d'autres termes, cette version est instable et nous ne recommandons pas son usage en production. Utilisez-là parce que vous voulez aider à améliorer GIMP en signalant des bogues.

En particulier, cette version 2.99.18 est peut-être l'une des versions les plus instables de la série 2.99 à cause du projet « space invasion » (NDT : « invasion venue de l'espace », un jeu de mots avec l'anglais colorspace signifiant espace de couleurs). Cela est parfaitement attendu et normal. ⚠️ ☢️

Sommaire

Cette dépêche présente les changements les plus notables et les plus visibles. En particulier, elle ne contient pas de liste exhaustive des correctifs de bogues ou des améliorations un peu moins importantes. Pour une liste plus complète des changements, nous vous invitons à consulter le fichier NEWS ou à jeter un coup d’œil à l'historique du dépôt Git.

L'invasion de l'espace (des couleurs) !

Nous avons travaillé dur sur le projet Space Invasion, qui est — comme vous vous en rappelez peut-être — le nom de code que nous avons donné au projet visant à rendre GIMP plus correct en ce qui concerne les couleurs.

Ces derniers temps, nous avons réalisé le portage des anciennes structures de couleurs utilisées en interne (GimpRGB, GimpCMYK, GimpHSV…) dont nous nous servions pour stocker les informations de couleurs vers GeglColor. Cet objet générique peut contenir n'importe quelle donnée de couleur, quel que soit le modèle colorimétrique, la précision ou l'espace, du moment que ceux-ci sont pris en charge par babl, notre moteur pour l'encodage des pixels.

En ce qui concerne la justesse des couleurs, cela signifie que nous ferons maintenant les conversions de couleurs uniquement si cela est nécessaire (conversions à la dernière minute), ce qui permettra de ne pas perdre d'information lorsque cela peut être évité. Par exemple, imaginons que vous utilisiez la pipette à couleurs sur une image : si nous convertissions cette couleur vers un format intermédiaire avant de l'utiliser sur une autre image (qui peut avoir le même format de couleurs ou un format différent), deux conversions auraient lieu. Cela augmente les possibilités de perte de précision. Ce problème est encore plus flagrant si les formats d'entrée et de sortie sont les mêmes (autrement dit, lorsqu'aucune conversion n'est nécessaire). Et cela sera encore plus problématique lorsque le modèle CMJN sera pris en charge nativement (nous voulons éviter à tout prix de faire un aller-retour entre un format intermédiaire et le CMJN, qui n'a pas de relation bijective avec la plupart des autres modèles de couleurs, même en travaillant sans bornes et en ignorant les problèmes de précision).

Définition d'un espace non borné (ajout par rapport à la dépêche originelle) : lorsque la précision est entière, l'espace est toujours borné (par exemple [0-255] en 8-bit). Par contre, en flottant, où l'espace de travail standard est [0, 1], on peut décider d'accepter les valeurs négatives et supérieures à 1. Cela rend les conversions entre beaucoup d'espaces de couleurs bijectives, aux erreurs de précisions près. Notamment, les conversions entre deux espaces RVB, ou même un espace RVB et divers autres modèles, deviennent bijectives. Ce n'est pas le cas entre RVB et CMJN, même en espace de couleurs infini.

Nous sommes également en train de migrer le stockage des données de couleur vers ce type d'objet générique. Cela signifie entre autres que les palettes de couleurs pourront comporter des couleurs au format CMJN, CIELAB ou bien encore dans tout autre modèle pris en charge (et pas seulement ces couleurs après une étape de conversion vers le sRVB non borné - « unbounded sRGB »).

Une conséquence pour la maintenance logicielle est qu'il sera beaucoup plus facile de gérer les conversions de couleurs au sein de notre code, étant donné que cette structure comprend à la fois les données et leur « signification ». Cela rend la gestion des couleurs beaucoup moins susceptible d'introduire des bogues par rapport à l'approche précédente, qui consistait à faire suivre les deux types d'information séparément.

Finalement, nous travaillons à faire apparaître l'information concernant l'espace de couleurs à plusieurs endroits de l'interface où cela est pertinent, par exemple lorsque des données RVB, CMJN, TSL ou TSV sont affichées ou peuvent être choisies. Les valeurs brutes dans ces modèles de couleurs en l'absence de la connaissance de l'espace de couleurs associé n'ont pratiquement aucun sens. L'affichage dans l'interface de valeurs RVB sans autre précision est un reliquat du passé, lorsque cela signifait le plus souvent sRVB. Cela n'est plus vrai dans un contexte graphique moderne et l'interface devrait être claire à ce sujet.

La vidéo ci-dessous montre quelques aspects de ce travail sur l'interface, par exemple le fait que les modèles RVB, TSV ou CMJN affichent à tout instant l'espace de couleurs dans lequel les valeurs sont considérées (ce qui très souvent correspond au nom du profil ICC). Cela est déjà fait pour la pipette à couleurs, les échantillons de couleurs, l'ancrable des couleurs de premier/d'arrière plan, la boîte de dialogue « Changer la couleur de premier/d'arrière plan », ainsi qu'à d'autres endroits.

Non seulement cela, mais lorsque les gens sélectionnent un profil d’épreuve sur écran et activent l'épreuve sur écran (par exemple grâce à la nouvelle bascule de simulation qui a été ajoutée dans GIMP 2.99.12), nous afficherons également non seulement la zone hors gamme de l'espace colorimétrique de l'image, mais également celle de l'espace d’épreuve.

Invasion de l'espace dans l'interface - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

Avertissement très important : il s'agit encore une fois d'un portage énorme dans notre base de code, ce qui a impacté littéralement des milliers de lignes de code. Ce travail est inachevé mais il devra être terminé avant la première version candidate. Des instabilités ou des bugs sont à prévoir dans cette mise à jour donc si vous rencontrez un problème, nous recommandons de le rapporter.

Amélioration des algorithmes de couleur

Øyvind Kolås a amélioré quelques algorithmes internes :

Les pixels achromatiques de l'outil Teinte-Saturation sont désormais un cas spécial afin que les pixels en niveaux de gris (saturation de 0) ne soient modifiés que par le réglage principal, pas par le réglage rouge.
Les dégradés en niveaux de gris restent désormais achromatiques même avec "Tramage" coché dans l'outil Dégradé.

Au fur et à mesure que le projet space invasion avance, obtenir des résultats cohérents devient plus facile dans divers algorithmes liés aux couleurs, nous permettant ainsi de découvrir rapidement les problèmes et de les résoudre.

Édition non-destructive, première mouture

Un domaine dans lequel nous sommes « en avance sur le planning » est l'édition non destructive, qui était très demandée ! Les fondations de ces fonctionnalités ont été mises en place par de nombreux développeurs au cours de nombreuses années, depuis l'introduction de GEGL dans GIMP. Bien qu'initialement prévue pour la feuille de route de la version 3.2, une première implémentation a vu le jour en tant que continuation d'un projet Google Summer of Code. Si vous n'êtes pas familier avec ce terme, « édition non destructive » implique notamment que des effets de filtres tels qu'un effet de flou sont stockés séparément des pixels du calque. Cela signifie que si vous désirez plus tard modifier un réglage, réarranger ou même retirer le filtre, vous pouvez le faire très facilement sans affecter le reste de l'image. Jusqu'à présent, GIMP utilisait une procédure d'édition destructive où les effets étaient immédiatement appliqués sur le calque, c'est donc un changement majeur !

Toute opération GEGL munie d'une interface graphique est désormais appliquée aux calques de manière non destructive. (Les effets non destructifs pour les masques de calques et les canaux sont prévus pour les versions ultérieures.) Cela inclut les greffons GEGL tiers et les opérations personnalisées créées avec notre outil GEGL Graph. Ces effets peuvent être sauvegardés et chargés via les fichiers de projet .xcf, bien que toutes les propriétés GEGL ne soient pas encore prises en charge dans la version actuelle.

Une fois qu'un filtre a été appliqué, vous pouvez continuer à interagir avec lui en cliquant sur l'icône de filtre dans l'ancrable des calques. Cela ouvrira une boîte de dialogue montrant tous les filtres actuellement appliqués au calque. À partir de là, vous pouvez alterner l'état de visibilité du filtre, modifier ses réglages, réordonner les filtres et retirer les effets un à un. Vous pouvez aussi fusionner tous les filtres et les appliquer à l'image pour retrouver une procédure d'édition destructive.

Effets non destructifs - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

Notez bien que tout cela est seulement une première implémentation, et beaucoup de travail reste à faire pour disposer d'une édition non destructive complète et riche. Nous allons continuer à affiner les fonctionnalités existantes pour la sortie de la version 3.0 en nous basant sur les tests et les retours des utilisateurs, et nous les développerons davantage par la suite. L'interface elle-même ne correspond pas à notre vision idéale de cette fonctionnalité, et un premier jet de spécifications a été écrit pour définir un processus d'édition bien plus intégré.

La capture d'écran ci-dessous est une maquette réalisée à partir de ces premières spécifications. Elle montre les effets de calque placés au sein de la liste principale des calques, partageant les mêmes boutons « œil » et « cadenas », mais également avec leurs propres masques faciles à éditer :

Maquette des spécifications pour l'application non-destructive d'effets de calque

Maquette des spécifications : les effets de calque sont visibles directement dans la liste des calques, avec leur propres masques

Néanmoins, l'implémentation de cette nouvelle interface sera un défi en elle-même et nous avons donc décidé de la remettre à après la sortie de GIMP 3 et de proposer cette première mouture en premier lieu.

N'hésitez pas à partager vos opinions dans les forums de discussion et dans le suivi des incidents !

Amélioration de la prise en charge des polices de caractères

Idriss Fekir, un autre étudiant du GSoC 2023, a travaillé avec Liam Quinn, un développeur de longue date, sur l'amélioration de la prise en charge des polices de caractères par GIMP. Une grande partie de ce travail concerne le code interne de GIMP afin d'améliorer sa capacité à gérer les futures mises à jour de polices et de texte. Certains changements plus visibles sont par exemple :

GIMP n'a plus besoin que les noms des polices de caractères soient uniques pour pouvoir les distinguer les unes des autres. Cela signifie qu'il n'ajoutera plus « #1 », « #2 » et ainsi de suite, mais gardera à présent les noms originaux dans la liste de sélection des polices. Malgré des noms apparemment identiques, deux polices avec le même nom fonctionneront désormais correctement.
GIMP peut maintenant charger des polices avec des styles personnalisés (en contournant l'utilisation de Pango qui n'est pas capable de les charger).
Nous pouvons à présent charger davantage de types de polices qu'auparavant. Si jamais nous ne prenons pas encore en charge une police donnée (ou si elle est inexistante), nous sommes mieux à même de le détecter et nous pouvons nous replier sur une police par défaut. Cela permet d'améliorer la prise en charge d'un fichier .xcf créé sur un autre ordinateur avec différentes polices disponibles.
Sous Windows, nous forçons le moteur Pango à toujours utiliser l'anticrénelage. Cela augmente la lisibilité du texte des menus sous ce système d'exploitation, en particulier lorsqu'un thème sombre est utilisé.
Le code pour la sauvegarde au format XCF stocke désormais les informations concernant les polices de manière bien plus précise, ce qui aide à éviter de charger une police incorrecte lors de la réouverture d'un fichier XCF.
L'alignement du texte dans les calques de texte pour les langues écrites de la droite vers la gauche est maintenant plus cohérent avec la manière dont cela fonctionne dans d'autres programmes (par exemple LibreOffice et Scribus).

Ces changements sont beaucoup moins voyants que certaines autres fonctionnalités et pourraient sembler moins importants, mais ils constituent en fait les fondations qui permettront d'avoir une gestion du texte bien plus fiable dans GIMP. Notre vision pour le futur est d'avoir une édition de texte plus simple tout en étant plus puissante et plus riche en fonctionnalités (en particulier les fonctionnalités OpenType qui sont quelques-unes des améliorations majeures que nous espérons ajouter un jour ou l'autre).

Expansion automatique des calques

Le troisième projet GSoC de l'été dernier par l'étudiant Shubham Daule a apporté une fonctionnalité demandée depuis longtemps : l'expansion automatique de calques ! Les outils de peinture ont désormais une option supplémentaire « Étendre les calques ». Lorsque cette case est cochée, peindre au-delà des limites des calques les fera s'étendre automatiquement afin que vous n'ayez pas à gérer vous-même la taille du calque. Si vous souhaitez étendre le calque au-delà de la taille actuelle du canevas, vous devrez également cocher l'option « Afficher tout » dans le menu Affichage.

Calques à expansion automatique - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

L'option d'expansion des calques comporte également des paramètres supplémentaires lorsqu'elle est sélectionnée. Vous pouvez décider dans quelle mesure vous souhaitez que les limites du calque s'étendent chaque fois que le pinceau les atteint. Il existe également des options pour spécifier comment les nouvelles zones du calque et du masque de calque doivent être remplies une fois étendues.

Nouvelles options d'alignement

Le nouveau contributeur mr. fantastic a développé deux nouvelles options pour aligner les calques sur le canevas. Avec « Snap to Bounding Boxes » (« Aligner sur les boîtes englobantes ») activé, des guides dynamiques s'afficheront désormais pour vous montrer quand le calque que vous déplacez est aligné avec le centre ou les côtés des autres. Le calque actif s'alignera également sur ces bordures pour vous aider à les organiser correctement. La deuxième option, « Snap to Equidistance » (« Aligner à équidistance »), vous permet un alignement entre trois calques équidistants les uns des autres.

Nouvelles options d'alignement automatique - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

Thèmes

Nous avons continué à améliorer l'interface utilisateur et le style de cette version. L’une des améliorations les plus importantes concernait la gestion des « fuites de thèmes système ». Il existe des styles qui n'ont pas été spécifiquement définis dans nos thèmes, donnant ainsi l'opportunité aux règles de style du thème système de "fuiter" de manière conflictuelle dans notre interface. Avec l’aide et les retours de plusieurs contributeurs et utilisateurs, nous avons beaucoup progressé dans la définition de ces styles afin que tous aient une expérience cohérente !

Récemment, Jehan a travaillé sur la réorganisation et la simplification de notre système de thèmes. Dans les versions de développement précédentes, nous avions cinq thèmes différents : Par Défaut, Gris, Système, Plus Sombre et Compact (chacun avec des options claires et sombres). Ceux-ci ont été simplifiés dans le thème Système et un seul thème par défaut avec trois états possibles : clair, foncé et gris. De même, nos quatre thèmes d'icônes distincts ont été condensés dans l'ensemble Legacy et un thème d'icôns par défaut avec des variantes couleur et symbolique. Nous pensons que ces changements réduiront la confusion des utilisateurs et leur permettront de trouver plus facilement leur apparence d'interface préférée.

De plus, sous Windows, la barre de titre principale (et la plupart des barres de titre des boîtes de dialogue) s'ajuste désormais au mode clair ou sombre en fonction du thème sélectionné.

Boîte de dialogue de bienvenue

La boîte de dialogue de bienvenue a été étendue pour fournir un accès rapide à un certain nombre de fonctionnalités et d'options utiles. Elle comporte ainsi quatre nouvelles sections :

Personnaliser : Plusieurs options de personnalisation nécessitent de fouiller dans la boîte de dialogue des Préférences pour être modifiées. À présent, vous pouvez facilement modifier les thèmes de couleurs et d'icônes, la langue et la taille de la police de l'interface utilisateur, ainsi que certains réglages en fonction du système d'exploitation.
Créer : Cette section affiche les huit images que vous avez ouvertes en dernier et vous permet de les rouvrir rapidement. Des boutons pour créer une nouvelle image ou pour en charger une existante sont également présents. À l'instar d'autres programmes, vous pouvez demander à ce que cet écran apparaisse automatiquement au démarrage de GIMP pour un accès direct à ces fonctionnalités.
Contribuer : Nous avons réuni ici quelques-unes des nombreuses façons dont vous pouvez participer au développement de GIMP. Cette section comporte des liens pour le signalement de bogues, pour écrire du code, pour aider aux traductions ou pour faire un don.
Notes de version : Précédemment, le lien vers ces notes étaient affichées dans la moitié inférieure de la boîte de dialogue de bienvenue. À présent, nous avons un onglet entier dédié à ces notes pour une lecture plus aisée.

Formats de fichiers

Comme cela était déjà le cas avec les versions précédentes, nous avons amélioré la prise en charge de formats de fichiers déjà existants et nous avons ajouté la prise en charge de l'importation et de l'exportation pour de nouveaux formats.

DDS

Stayd, un nouveau contributeur, a travaillé avec notre développeur Jacob Boerema pour apporter de nombreuses améliorations au greffon DDS. Pour commencer, les fonctions d'importation ont été écrites afin d'être plus simples et plus faciles à étendre dans le futur. Les mises à jour supplémentaires incluent également :

Le chargement d'images DDS RVBA 16 et 32 bits/canal est maintenant possible.
Le filtre cubique Catmull-Rom a été ajouté pour la génération de mipmaps, et tous les calculs pour générer les mipmaps sont effectués avec une précision de 32 bits.
Les images DDS aux formats R8G8, R16 et R16G16 peuvent maintenant également être chargées.
Une option pour renverser verticalement les images DDS lors de l'importation a été ajoutée pour faire écho à l'option d'exportation correspondante, étant donné que certaines images de jeux stockent leurs données de cette manière.

GIF

Par le passé, écraser un fichier GIF à la sauvegarde (plutôt que de l'exporter) le convertissait systématiquement en un fichier avec une seule image. Désormais nous vérifions lors du chargement si le fichier GIF est une animation, de manière à également sauvegarder une animation lors de l'écrasement.

HEIF et JPEG-XL

Les deux greffons utilisent maintenant leurs bibliothèques respectives (libheif et libjxl) pour le chargement des métadonnées. Cela nous a permis de retirer notre code maison chargé d'interpréter l'orientation des images et d'utiliser à la place les informations fournies par ces bibliothèques.

OpenEXR

Le format OpenEXR permet aux canaux d'avoir des noms personnalisés, outre le type de couleur. Dans ce cas, nous considérons maintenant toute image à un seul canal avec un nom non conventionnel comme étant en niveaux de gris. Lors de l'importation, nous affichons une notification afin que les utilisateurs soient prévenus de cette conversion.

PDF

L'option d'exportation « Calques en tant que pages » fonctionne maintenant même s'il y a un seul groupe de calques. Auparavant, cette option n'était pas disponible car le greffon vérifiait seulement s'il y avait plus d'un « calque » sans examiner s'il s'agissait d'un groupe de calques avec de multiples sous-calques.

PNG

Les fragments de fichiers PNG qui sont « copiables sans risque » (« safe-to-copy chunks ») sont maintenant préservés lors de l'importation et inclus dans l'image exportée. Un autre souci qui existait lors de l'exportation de PNGs indexés avec transparence (et qui nous avait été souvent signalé) a été résolu. Désormais les couleurs indexées devraient être affichées correctement après exportation.

PSD

Jacob Boerema a poursuivi son travail d'amélioration du greffon PSD. En plus d'avoir résolu des bogues, par exemple dans l'ordre des calques lors de l'importation, il a aussi clarifié l'avertissement présenté lors de l'exportation et concernant la compatibilité des modes de calques entre GIMP et Photoshop.

PSP

Le greffon Paintshop Pro peut maintenant importer davantage de caractéristiques depuis un fichier projet, comme par exemple le profil de couleurs ICC, les guides, les grilles, et la sélection active lors de la sauvegarde. Les failles de sécurité ZDI-CAN-22096 et ZDI-CAN-22097 ont également été corrigées dans cette version.

Nouveaux formats d'image pris en charge : Farbfeld, Esm Software PIX, HEJ2

Nous avons récemment ajouté la prise en charge de l'importation et de l'exportation pour le format Farbfeld, un format d'image sRVB conçu pour être facile à lire, à envoyer dans des pipes et à compresser avec des outils tiers.

Nous avons aussi ajouté la prise en charge de l'importation seule pour les nouveaux formats suivants :

Esm Software PIX : Un format JPEG modifié utilisé exclusivement par l'entreprise Esm Software pour stocker leurs images propres. Cela a été implementé en réponse à un signalement de bogue qui avait confondu ce format avec le format Alias PIX que nous prenions déjà en charge.
HEJ2 : Un ajout à notre greffon HEIF déjà existant fourni par Daniel Novomeský qui permet d'importer des images JPEG 2000 compressées.

Nouveau format de palette pris en charge : Swatchbooker

Swatchbooker est un programme libre de création et de conversion de palettes de couleurs qui prend en charge de nombreux formats. Bien que le programme lui-même n'ait pas été mis à jour depuis de nombreuses années, son format de palette propre .sbz est le plus complet de tous ceux que nous prenons en charge actuellement. Parmi ses nombreuses fonctionnalités, on peut citer la possibilité de définir des couleurs dans plusieurs modèles de couleurs pour chaque entrée d'une palette, des noms et des descriptions régionalisables, et la prise en charge de profils de couleurs ICC différents pour chaque entrée.

Via notre travail sur la prise en charge de son importation, nous avons pu fournir des informations qui ont conduit à un correctif de bogue dans la prise en charge de Swatchbooker par Krita. C'est toujours sympa quand des projets peuvent collaborer et s'entraider !

Interactions avec les pads de tablettes graphiques sous Wayland

Carlos Garnacho, un contributeur GNOME de longue date, a ajouté la prise en charge de l'interaction directe des boutons de tablettes graphiques (pad) avec GIMP. Quand une tablette est branchée, vous pouvez désormais assigner différentes actions aux contrôles de la tablette depuis la boîte de dialogue « Périphériques d'entrée » dans le menu Édition.

Assigner des actions aux boutons d'une tablette graphique - GIMP 2.99.18

Ce travail a aussi impliqué le portage de fonctionnalités vers GTK 3, la boîte à outils utilisée par GIMP pour son interface graphique. Notez que cette fonctionnalité est seulement disponible sous Wayland pour le moment.

Mise à jour de l'API

L'interface de programmation d'application (API), destinée aux créateurs de greffons, est régulièrement retravaillée dans le cadre de la refonte de GIMP 3. Une partie de ce travail est de migrer l'API vers l'utilisation de GeglColor lorsque les couleurs sont impliquées, ce qui entre dans le cadre plus général du projet Space Invasion. Malgré tout, ce n’est qu’une petite partie de l’ensemble des améliorations de l’API.

Nous nous orientons également vers plus de classes pour représenter les différentes ressources gérées par GIMP (pinceaux, polices, motifs, etc.) au lieu de les représenter uniquement par des noms (ce qui était une limitation historique alors qu'il est tout à fait possible à 2 créateurs de ressources de choisir le même nom et le fait est que nous voyons de tels cas dans la nature — par exemple, 2 polices créées indépendamment peuvent avoir le même nom).

Un autre grand pas consiste à remplacer le GimpValueArray représentant les arguments ordonnés d'une procédure d'un greffon par un GimpProcedureConfig qui contient les arguments par nom plutôt que par ordre. Cela permet une utilisation beaucoup plus sémantique des procédures de greffon (surtout lorsqu'elles ont une longue liste d'arguments) et facilitera également l'amélioration des greffons à l'avenir, avec des arguments nouveaux ou réorganisés sans créer de nouvelles procédures, car l'ordre et le nombre des arguments comptent beaucoup moins. Cela signifie que l'ajout de nouveaux arguments dans le futur ne brisera plus les scripts déjà existants qui dépendaient des versions antérieures de ces greffons (les auteurs de greffons devront toujours choisir des valeurs par défaut appropriées pour les nouveaux arguments afin que cela soit vrai, bien sûr).

En parallèle, nous continuons d'améliorer la capacité de création automatique d'interfaces graphiques offerte aux greffons, rendant la création de boîtes de dialogue plus simple que jamais. Cela inclut (parmi de nombreuses autres améliorations) un nouveau type d'argument de procédure nommé GimpChoice qui est une liste de choix sous forme de chaînes de caractères qui peut être présentée aux créateurs sous forme de widgets de liste déroulante dans la boîte de dialogue de votre greffon.

Nous prévoyons d'écrire et de publier un didacticiel pour les rédacteurs de greffons dans la section Développement de ressources de notre site Web pour développeur en même temps que la sortie de GIMP 3, ou peu de temps après.

GEGL et babl

Cette version de GIMP est accompagnée de nouvelles versions de GEGL et babl, qui contribuent toutes deux au projet (Color) Space Invasion.

babl 0.1.108 apporte une nouvelle fonction babl_space_is_rgb pour nous aider à confirmer directement qu'un espace colorimétrique est RVB (plutôt que de faire plusieurs tests pour voir s'il n'est pas CMJN ou niveaux de gris). Plusieurs améliorations ont également été apportées au processus de compilation et à l'outil d'interface de ligne de commande de babl.

GEGL 0.4.48 fournit plusieurs mises à jour de l'objet GeglColor qui prend désormais en charge une grande partie des opérations de couleur de GIMP. Les améliorations spécifiques incluent la possibilité d'obtenir et de définir directement les valeurs de couleur CMJN, ainsi que l'attribution de l'espace colorimétrique lors de la définition des couleurs RVB(A).

Un crash dans le filtre gegl:voroni existant a été corrigé, et un bogue de longue date avec le filtre gegl:dropshadow qui empêchait l'effet de rétrécir a également été corrigé.

Enfin, un nouveau filtre gegl:shuffle-search a été ajouté à l'atelier. Il mélange les pixels voisins pour créer un effet de tramage plus optimisé.

Statistiques de sortie

Hormis la première version de la série (2.99.2), GIMP 2.99.18 est clairement la plus grosse mise à jour à bien des égards. Depuis la version 2.99.16 :

238 rapports ont été clôturés comme CORRIGÉS.
201 demandes de fusion ont été acceptées.
1358 commits ont été poussés.
26 traductions ont été mises à jour : allemand, basque, biélorusse, portugais brésilien, bulgare, catalan, chinois (Chine), danois, espagnol, espéranto, finnois, géorgien, grec, hongrois, islandais, italien, lituanien, norvégien nynorsk, persan, polonais, russe , slovène, suédois, turc, ukrainien, vietnamien.

60 personnes ont apporté des modifications ou des correctifs à la base de code de GIMP 2.99.18 (l'ordre est déterminé par le nombre de commits; certaines personnes apparaissent dans plusieurs groupes) :

23 développeurs pour le code principal : Jehan, Alx Sa, Shubham, Jacob Boerema, Idriss Fekir, bootchk, Anders Jonsson, Carlos Garnacho, mr.fantastic, Stanislav Grinkov, lillolollo, Øyvind Kolås, Sabri Ünal, programmer_ceds, Lukas Oberhuber, programmer-ceds, James Golden, Luca Bacci, Massimo Valentini, Niels De Graef, Zander Brown, psykose, sonia.
17 développeurs de greffons ou de modules : Jehan, Alx Sa, Jacob Boerema, bootchk, Anders Jonsson, Stayd, Zander Brown, Bruno Lopes, Daniel Novomeský, Sabri Ünal, programmer_ceds, Kamil Burda, Mark, Michael Schumacher, Stanislav Grinkov, programmer-ceds, sonia.
31 traducteurs : Yuri Chornoivan, Martin, Ekaterine Papava, Luming Zh, Sabri Ünal, Anders Jonsson, Rodrigo Lledó, Jordi Mas, Alan Mortensen, Vasil Pupkin, Asier Sarasua Garmendia, Kolbjørn Stuestøl, Boyuan Yang, Víttor Paulo Vieira da Costa, dimspingos, Alexander Shopov, Alexandre Prokoudine, Aurimas Černius, Balázs Úr, Marco Ciampa, Sveinn í Felli, Danial Behzadi, Ngọc Quân Trần, Jürgen Benvenuti, Piotr Drąg, Timo Jyrinki, Andre Klapper, Kristjan SCHMIDT, MohammadSaleh Kamyab, Rafael Fontenelle, Tim Sabsch.
9 créateurs de ressources (icônes, thèmes, curseurs, splash screen, métadonnées…) : Alx Sa, Jehan, Ferry Jérémie, Stanislav Grinkov, Anders Jonsson, Bruno Lopes, Jacob Boerema, Sabri Ünal, mr.fantastic.
5 contributeurs à la documentation : Jehan, Bruno Lopes, Jacob Boerema, Alx Sa, Anders Jonsson.
14 contributeurs pour la compilation, l'empaquetage ou l'intégration continue : Jehan, Bruno Lopes, bootchk, Alx Sa, Zander Brown, Jacob Boerema, Jacob Boerema, Stayd, Carlos Garnacho, Heiko Becker, mr.fantastic, Daniel Novomeský, U-YGGDRASIL\ender, lillolollo.

Contributions à d'autres dépôts du GIMPverse (l'ordre est déterminé par le nombre de commits) :

babl 0.1.108 est composé de 17 commits par 6 contributeurs : Jehan, Øyvind Kolås, John Marshall, Andre Klapper, John, sid.
GEGL 0.4.48 est composé de 77 commits par 20 contributeurs : Øyvind Kolås, Jehan, Anders Jonsson, Jacob Boerema, Yuri Chornoivan, Alan Mortensen, Sabri Ünal, Andre Klapper, Ekaterine Papava, Jan Tojnar, Jordi Mas, Luming Zh, Martin , Piotr Drąg, Víttor Paulo Vieira da Costa, Asier Sarasua Garmendia, Marco Ciampa, Rodrigo Lledó, dimspingos, woob.
ctx a eu 308 commits depuis la version 2.99.14 par 1 contributeur : Øyvind Kolås.
La version gimp-macos-build (scripts d'empaquetage macOS) est composée de 32 commits par 1 contributeur : Lukas Oberhuber.
La version flatpak est composée de 15 commits par 3 contributeurs : Jehan, Daniel Novomeský et Hubert Figuière.
Notre site Web principal a eu 31 commits depuis la sortie du 2.10.36 par 6 contributeurs : Jehan, Alx Sa, Sabri Ünal, Anders Jonsson, Bruno Lopes, Jonathan Demeyer.
Notre site Web des développeurs a eu 30 commits depuis la version 2.10.36 par 5 contributeurs : Bruno Lopes, Jehan, Alx Sa, bootchk, Robin Swift.
Notre documentation 3.0 a enregistré 247 commits depuis la version 2.99.16 par 17 contributeurs : Andre Klapper, Jacob Boerema, Yuri Chornoivan, Alx Sa, Jordi Mas, Alan Mortensen, Dimspingos, Anders Jonsson, Boyuan Yang, Sabri Ünal, Víttor Paulo Vieira da Costa, Juliano de Souza Camargo, Rodrigo Lledó, Kolbjørn Stuestøl, Marco Ciampa, Danial Behzadi, Emin Tufan Çetin.

N'oublions pas de remercier toutes les personnes qui nous aident à faire le tri dans Gitlab, rapportent des bogues et discutent avec nous d'éventuelles améliorations. Notre communauté est également profondément reconnaissante envers les guerriers d'Internet qui gèrent nos différents canaux de discussion ou comptes de réseaux sociaux tels que Ville Pätsi, Liam Quin, Michael Schumacher et Sevenix !

Remarque : compte tenu du nombre de pièces qui composent GIMP et son environnement, et de la manière dont nous obtenons des statistiques via des scripts git, des erreurs peuvent se glisser dans ces statistiques. N'hésitez pas à nous dire si nous avons manqué ou mal catégorisé certains contributeurs ou contributions.

Nouvelles de l'équipe et procédure de sortie

Les droits d'accès au dépôt git ont été récemment accordés à Bruno Lopes (qui a été très actif dans l'amélioration de notre processus de compilation et de l'empaquetage pour Windows).

Plusieurs développeurs ou empaqueteurs de longue date ou plus récents qui ont commencé à contribuer au nouveau site Web des développeurs ont également reçu l'accès au dépôt git associé.

De plus en plus de contributeurs participent désormais activement aux tests des versions et du processus d'empaquetage, et c'est la première dépêche depuis des années (NDT : cela désigne la news originale sur le site de GIMP) que Jehan n'a pas écrite presque entièrement ! Merci beaucoup à Alx Sa (alias Nikc ou CmykStudent) d'avoir entamé la rédaction collaborative de la nouvelle !

Il est clair que nous consolidons jour après jour une solide équipe de contributeurs et cela se voit dans notre processus de publication, avec de plus en plus de retours à chaque version.

Nous sommes également particulièrement heureux et fiers que les 4 projets GSoC que nous avons eus, depuis que nous avons recommencé à souscrire à ce programme de mentorat, aient tous été couronnés de succès et ont fini par être fusionnés avec la branche principale du code au plus tard six mois après la fin du stage.

Autour de GIMP

Des nouvelles des miroirs

Depuis la dernière dépêche, un nouveau miroir a été apporté à GIMP par :

Sahil Dhiman, à Nuremberg, en Allemagne, comme projet personnel.

Cela nous amène à un total de 46 miroirs répartis dans le monde.

Les miroirs sont importants car ils aident le projet en partageant la charge de dizaines de milliers de téléchargements quotidiens. De plus, en disposant de miroirs répartis à travers le monde, nous garantissons que tout le monde puisse avoir un accès rapide au téléchargement de GIMP.

GIMP sous Windows/ARM

Depuis notre annonce d'une version expérimentale sur Windows pour l'architecture ARM 64 bits (en anglais), nous avons reçu l'aide de Hernan Martinez, contributeur bien connu du projet MSYS2, qui a hébergé notre tout premier runner pour l'intégration continue (CI) pour Windows sur l'architecture Aarch64. Bien que cela n'ait été qu'une configuration temporaire (littéralement une machine de compilation dans le salon de quelqu'un) en attendant une situation plus stable, nous sommes extrêmement reconnaissants envers Hernan qui nous a aidés à faire notre deuxième pas sur cette plateforme (la première étape a été effectuée par Jernej, qui a créé notre premier installateur expérimental), s'est assuré que notre processus de compilation automatique fonctionne sur cette machine, et plus encore.

Depuis lors, la situation plus stable est arrivée : Arm Ltd. eux-mêmes se sont mobilisés et ont officiellement contribué trois runners pour notre processus d'intégration continue dans Gitlab ! Arm Ltd. a également sponsorisé un kit de développement Windows pour l'un de nos développeurs.

Bien que nous considérions toujours cette version comme expérimentale, en raison du manque de tests et du fait que seuls 2 contributeurs disposent actuellement d'une machine capable de l'exécuter, le plus gros facteur bloquant a été supprimé et nous sommes heureux d'annoncer que notre programme d'installation Windows universel pour GIMP 2.99.18 contient GIMP pour les 3 plates-formes (x86 32 et 64 bits, et maintenant ARM 64 bits) !

Télécharger GIMP 2.99.18

Vous trouverez toutes nos versions officielles sur le site officiel de GIMP (gimp.org) :

Flatpaks Linux pour x86 et ARM (64 bits)
Installateur Windows universel pour x86 (32 et 64 bits) et pour ARM (64 bits)
Paquets macOS DMG pour le matériel Intel
Paquets macOS DMG pour le matériel Apple Silicon

D'autres paquets réalisés par des tiers devraient évidemment suivre (paquets des distributions Linux ou *BSD, etc.).

Et ensuite ?

Alors que nous sommes maintenant entrés dans un gel des fonctionnalités, notre attention s'est déplacée vers la correction des bogues, le nettoyage et la préparation de la première version candidate 3.0.

Nous pensons en effet qu'il s'agit de la dernière version de développement puisqu'aucune nouvelle fonctionnalité ne sera introduite désormais, du moins au niveau de l'interface utilisateur (l'API est encore en évolution jusqu'à la première version candidate). Donc, ce que vous voyez maintenant est essentiellement ce que vous devriez obtenir dans GIMP 3.0.0, en termes de fonctionnalités.

C'est pourquoi nous avons sorti cette version même si nous savons qu'elle est assez instable. C'est l'heure des commentaires de dernière minute ! C'est aussi le moment de signaler et de corriger les bogues comme si demain n'existait pas. Nous espérons pouvoir bientôt livrer une RC1 et elle devrait être aussi dépourvue de bogue que possible.

Nous espérons actuellement pouvoir publier GIMP pour le prochain Libre Graphics Meeting du 9 au 12 mai. Pour être honnête, ce n’est pas un objectif facile et nous ne sommes donc pas sûrs de pouvoir l’atteindre. Ce qui est sûr, c'est que même si nous n'y parvenons pas à temps, cela ne devrait pas arriver trop longtemps après. En particulier, nous ne publierons pas simplement parce que nous avons fixé une date limite. Nous voulons offrir la meilleure expérience possible, ce qui signifie que si nous découvrons des bogues bloquants de dernière minute, nous retarderons la sortie jusqu'à ce qu'ils soient corrigés.

N'oubliez pas que vous pouvez faire un don et financer personnellement les développeurs de GIMP, c'est un moyen de donner en retour et d'accélérer le développement de GIMP. L’engagement communautaire permet au projet de se renforcer ! 💪🥳

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Vue normale