Sommaire
Formats de fichiers
TIFF et BigTIFF
GIMP prend maintenant en charge les fichiers TIFF 8 et 16 bits CMJN(A) lors de l'importation. Ceci est une des premières retombées (déjà !) du projet GSoC mené par NikcDC, sous la supervision de Jehan.
De plus, le format BigTIFF est maintenant pris en charge, aussi bien pour l'importation que pour l'exportation. BigTIFF est une évolution du format TIFF original qui rend possible des fichiers d'une taille supérieure à 4 GiO grâce à des pointeurs internes en 64 bits.
La boîte de dialogue d'exportation au format TIFF présente une case à cocher pour activer cette variante de format.
Légende : Exportation au format BigTIFF dans GIMP 2.10.31 : une nouvelle option dans la boîte de dialogue pour l'exportation au format TIFF
De plus, si vous essayez d'exporter une image au format TIFF et que cela échoue pour cause de taille de fichier maximale dépassée, GIMP vous proposera de réessayer soit au format BigTIFF soit en utilisant un autre algorithme de compression.
Et pour finir, d'autres cas un peu spéciaux liés au format TIFF sont maintenant également pris en compte, rendant ainsi le chargement de fichiers TIFF plus fiable.
JPEG XL
Le format de fichier JPEG XL est pris en charge par la version de développement depuis GIMP 2.99.8.
Daniel Novomeský a rétroporté le code d'importation vers la branche stable.
Nous vous rappelons qu'un greffon tiers créé par les développeurs de la bibliothèque libjxl existe déjà. Il est constitué d'un corps de code différent et devrait encore fonctionner avec GIMP 2.10.32. L'avantage principal de ce greffon tiers réside dans ses capacités d'exportations (que notre greffon stable ne possède pas encore), bien qu'il existe des problèmes non résolus causant l'échec du chargement ou de l'exportation pour certaines images.
Vous êtes tout à fait libres de continuer à utiliser le greffon tiers si vous préférez. Par exemple, le projet MSYS2 l'inclut désormais dans le paquet libjxl. Si vous l'installez, il prendra le pas sur notre nouveau greffon stable.
DDS
Certains moteurs de jeu nécessitent que les images DDS soient retournées verticalement. Jusqu'à présent, les créateurs de ressources graphiques devaient retourner l'image dans GIMP, l'exporter, puis annuler le retournement, ce qui n'était pas une méthode de travail très pratique.
C'est la raison pour laquelle NikcDC a ajouté une nouvelle option « Retourner l'image verticalement à l'exportation » (note: pas encore de traduction française officielle) qui vous permet de retourner l'image au moment de l'exportation.
De façon similaire, il y a maintenant une option « Calques visibles » (en plus de « Calque sélectionné », « As cube map », …) qui vous permet d'exporter l'ensemble du rendu de l'image, pas seulement un calque en particulier. Ainsi, selon votre méthode de travail, vous n'aurez plus à aplatir votre image (pour ensuite annuler cette action) avant de l'exporter.
Légende : Exportation au format DDS dans GIMP 2.10.32 : nouvelles options « Retourner » et « Tous les calques visibles »
Gestion des métadonnées (PSD…)
Plusieurs améliorations ont été apportées à la gestion des métadonnées. L'un des changements les plus importants est le fait que GIMP commencera à ignorer les étiquettes Xmp.photoshop.DocumentAncestors si plus d'un millier d'entre elles sont trouvées.
Ce cas de figure est très vraisemblablement dû à un bogue dans certaines versions de Photoshop ou d'autres programmes qui génèrent des fichiers PSD. En effet, nous avons rencontré dans certains fichiers plus de 100 000 étiquettes de ce genre (il est peu probable qu'un document puisse avoir autant de documents parents), ce qui ralentissait fortement GIMP à tel point qu'il semblait figé.
XCF
Le code pour l'importation du format XCF a aussi été amélioré de plusieurs façons, ce qui rend le programme plus robuste face à des fichiers non-valides. Dans certains cas, cela permet de récupérer davantage de données depuis des fichiers XCF corrompus, protégeant ainsi vos travaux.
Autres formats
La gestion d'autres formats a été améliorée :
BMP
Une nouvelle procédure PDB a été ajoutée pour les développeurs de greffons : file-bmp-save2. Elle prend en charge toutes les options disponibles lors d'un usage interactif.
DICOM
La conversion de boutisme (endianness en anglais) a été corrigée pour l'interprétation photométrique MONOCHROME1.
EPS
Le chargement de fichiers EPS avec transparence est maintenant pris en charge.
RAW
L'étiquette de boîte de dialogue « RGB Save Type » qui prêtait à confusion a été renommée « Palette Type », de la même manière que sur la branche de développment principale. (note: pas encore de traductions françaises officielles)
TGA
La prise en charge des images indexées avec canal alpha a été améliorée (à la fois pour l'importation et l'exportation).
WebP
La boîte de dialogue pour l'exportation a une nouvelle case à cocher pour enregistrer les métadonnées IPTC (sauvegardées via XMP) ainsi qu'une case à cocher pour enregistrer une vignette d'aperçu (rétroporté depuis la branche de développement où c'est disponible depuis 2.99.8).
Outil Texte : variantes de glyphe localisés
L'outil Texte prend désormais en charge les variantes de glyphe localisées (locl) selon la valeur de l'option « Langue » de l'outil.
Cela est utile si vous écrivez dans des langues possédant des variantes de forme régionales (par exemple le serbe et l'ukrainien utilisent tous deux l'alphabet cyrillique, mais 5 lettres présentent des variantes régionales).
Si la police de caractères choisie prend en charge plusieurs variantes, vous pouvez maintenant indiquer au système interne de formatage laquelle utiliser, via les réglages « Langue ».
Légende : Prise en charge de locl dans GIMP 2.10.32 : les mêmes caractères en serbe (à gauche) et en ukrainien (à droite), en romain (en haut) et en italique (en bas)
Ergonomie : thèmes et icônes
- Tous les thèmes officiels affichent désormais un cadre indicateur lorsque le pointeur survole la zone des boutons œil 👁️ et maillon 🔗 dans les arborescences des boîtes de dialogue Calques/Canaux/Chemin.
Légende : Effet lors du survol des boutons œil et maillon dans GIMP 2.10.32
- Dans le thème Sombre, un nouvel effet de survol sur les éléments des menus radio a été ajouté pour une meilleure lisibilité.
Légende : Effet lors du survol des éléments d'un menu radio dans GIMP 2.10.32
- Dans le thème d'icônes Couleur, de fines bordures ajoutent du contraste aux icônes
fermer et détacher afin d'améliorer leur lisibilité sur fonds sombres lors du survol par le pointeur.
Légende : Des icônes plus lisibles dans GIMP 2.10.32
- Dans le thème d'icônes Couleur, les icônes de chaîne horizontale et verticale ⛓️ ont maintenant des variantes cassées/continues plus faciles à distinguer.
Légende : À gauche, GIMP 2.10.30 - à droite, GIMP 2.10.32
Tous ces changements sont le fruit du travail de Stanislav Grinkov.
Capture d'écran améliorée sous Windows
L'option « Inclure le pointeur de la souris » manquait au greffon de Capture d'écran sous Windows.
Cette fonctionnalité qui manquait depuis longtemps, alors qu'elle était disponible pour les autres plateformes (comme Linux X11/Wayland, *BSD ou macOS) est maintenant implémentée sous Windows également !
Légende : Greffon de capture d'écran sous Windows avec GIMP 2.10.32 : nouvelles options « Inclure le pointeur de la souris »
GEGL, babl
GIMP 2.10.32 est la première version stable contenant les optimisations bien sympathiques apportées depuis babl 0.1.90 et GEGL 0.4.36, à présent qu'elles ont reçu leur baptême du feu et ont été déboguées avec la version de développement GIMP 2.99.10. En conséquence, babl 0.1.92 est sortie, avec notamment un correctif pour la fonctionnalité de détection SIMD qui posait quelques soucis sous Windows.
L'importance de ces améliorations nous a paru justifier de recopier ci-dessous leur description depuis la dépêche concernant la version 2.99.10 vers la présente dépêche de version stable, afin de souligner qu'elles s'appliquent désormais à GIMP 2.10.32.
Création automatique de LUT pour les conversions dans 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) :
Légende : 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 :
Légende : 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.
Autres améliorations
babl est maintenant également fourni avec les formats CIE Lab u8 et CIE Lab u16 prédéfinis.
[ Fin de l'extrait de la dépêche concernant la sortie de la version de développement 2.99.10 ]
GIMP au Google Summer of Code
Un projet GIMP au Google Summer of Code 2022, concernant l'ajout de fonctionnalités CMJN, a été annoncé début juin. Nous incluons ici un résumé de l'annonce originale (en anglais).
Ce projet est mené par Nikc, qui avait discuté avec nous auparavant pour bien cerner les besoins, l'état actuel du projet et la direction souhaitée. Nous avions aussi déjà travaillé avec Nikc, qui nous avait soumis des patches avant sa sélection pour le GSoC. Si quelqu'un souhaite participer au GSoC dans les années à venir, nous vous recommandons fortement de nous contacter auparavant de la même manière, plutôt que de simplement soumettre une candidature sans nous consulter avant sur la liste de diffusion ou sur IRC. 😉
Qu'en est-il de la prise en charge CMJN dans GIMP ?
Historiquement, le code original de GIMP utilisait l'espace colorimétrique sRVB pour pratiquement toutes les opérations. La prise en charge de n'importe quel espace colorimétrique RVB a été en chantier pendant pas mal d'années, et est déjà bien meilleure dans la branche stable 2.10.
Depuis la fin des années 2000s, nous pensions à intégrer une interface de liaison "tardive" vers le CMJN, ce qui aurait permis de travailler en RVB, voir des épreuves numériques en simulation CMJN et finalement exporter en CMJN. Malheureusement, il manquait encore des changements importants au moteur de traitement d'image pour rendre cela possible.
Finalement, Øyvind Kolås a ajouté les pièces manquantes à GEGL il y a quelques années, ce qui permettait par exemple de fusionner des images CMJN et RVB et d'exporter le résultat au format TIFF CMJN. Cela a ouvert la voie au projet GSoC de cette année.
Quel est l'objectif du projet GSoC ?
Tout d'abord, nous ne parlons pas encore d'un mode image CMJN, similaire à "RVB", "Niveaux de gris", ou "Couleurs indexées" comme ceux disponibles aujourd'hui. À la place, nous nous concentrerons sur :
Importer et exporter les images dans un espace colorimétrique CMJN (avec une conversion vers RVB(A) pour la visualisation et l'édition). Le détail de la prise en charge CMJN pour les différents formats de fichiers est disponible dans l'annonce originale en anglais.
Une nouvelle fenêtre ancrable pour la gestion des couleurs. Cela permettra de facilement basculer vers la pré-visualisation d'épreuves CMJN (en simulant le résultat d'une conversion en CMJN).
Des profils de pré-visualisation d'épreuves persistants. Cela éviterait de perdre ces informations de profils (pour le moment uniquement rattachées à la vue courante), en les stockant en tant que données de l'image à part entière dans le fichier XCF.
Identifier et résoudre les problèmes de gestion de couleur. Il reste toutes sortes de bogues et d'imperfections dans l'implémentation de la gestion des couleurs dans GIMP. Certains sont connus, et d'autres pourraient être détectés grâce au travail de ce GSoC. Au bout du compte, résoudre ces problèmes sera profitable non seulement pour la prise en charge CMJN, mais aussi pour la gestion des couleurs en général dans GIMP.
Quand les résultats du projet GSoC seront-ils disponibles ?
Notre objectif est que toutes les nouvelles fonctionnalités et améliorations développées par Nikc pendant le GSoC cette année soient intégrées à GIMP 3.0.
Y aura-t-il un mode CMJN dans GIMP ?
La réponse est "oui, un jour".
Par le passé, nous avons mentionné l'approche anyRGB pour l'édition (par exemple, vous pouvez ouvrir une image dans l'espace de couleur AdobeRGB et travailler dessus sans jamais la convertir en sRVB, à moins qu'une opération spécifique de GEGL en ait besoin).
Nous avons repensé cette approche anyRGB pour l'étendre en anyModel (RVB, CMJN, LAB, etc.). Cela va nécessiter un effort substantiel et nous ne prévoyons pas de pouvoir inclure ceci dans GIMP 3.0.
Même en se limitant au monde de l'impression, coder un modèle CMJN en particulier plutôt qu'avoir une approche générique serait beaucoup trop limité : comment faire si vous vouliez ajouter des canaux de couleur spécifiques (tons directs) à votre image par exemple ? L'approche anyModel est la direction que nous avons choisie, et est rendue possible grâce aux efforts cumulés de plusieurs de nos contributeurs sur de nombreuses années.
Des nouvelles de l'équipe
lukaso était déjà considéré comme co-mainteneur du dépôt de compilation pour macOS (gimp-macos-build) étant donné qu'il a fait le plus gros du travail sur GIMP pour macOS depuis de nombreux mois. Cela est maintenant officiel et son compte sur ce dépôt est à présent maintainer.
L'accès "développeur" au dépôt git principal de GIMP a été accordé à Lloyd Konneker, en particulier pour son travail apprécié sur script-fu (lequel en était à un point où son retrait de GIMP 3.0 aurait été à l'ordre du jour sinon).
Kevin Cozens, un contributeur de longue date à GIMP et mainteneur de script-fu, est de retour depuis peu et son accès au dépôt git a été rétabli. Il participera à co-maintenir script-fu avec Lloyd.
Ondřej Míchal a reçu les droits de « Rapporteur » sur le dépôt principal de GIMP (ce qui l'autorise à trier les rapports : étiquettage, fermeture, ré-ouverture, et déplacements des rapports…).
Après avoir initialement reçu les droits de « Rapporteur », NikcDC a finalement reçu un accès « développeur » au dépôt git pour faciliter son travail sur les branches des fonctionnalités liées à son projet GSoC.
Statistiques de la sortie
Dix personnes ont contribué au code de GIMP 2.10.32, sous forme de modifications ou de correctifs :
- Trois personnes ont apporté plusieurs modifications ou correctifs : Jacob Boerema, Jehan et Nikc.
- Une personne a apporté plusieurs améliorations de thèmes et d'icônes : Stanislav Grinkov.
- Six personnes ont apporté un commit chacune : Sabri Ünal, Daniel Novomeský, Lukas Oberhuber, Rafał Mikrut, smlu and Øyvind Kolås.
Concernant les traductions de cette version GIMP :
- 24 traducteurs ont contribué : Anders Jonsson, Sveinn í Felli, Alan Mortensen, Aleksandr Melman, Yuri Chornoivan, Hugo Carvalho, Luming Zh, Rodrigo Lledó, Jordi Mas, Martin, Piotr Drąg, Balázs Úr, Jiri Grönroos, Zurab Kargareteli, Boyuan Yang, Marco Ciampa, Matej Urbančič, Milo Ivir, Sabri Ünal, Tim Sabsch , Balázs Meskó, Charles Monzat, Fran Dieguez, Hannie Dumoleyn.
- 20 traductions ont été mises à jour : allemand, catalan, chinois (de Chine), croate, danois, espagnol, finnois, français, géorgien, hongrois, islandais, italien, néerlandais, polonais, portugais, russe, slovène, suèdois, turc, ukrainien.
- GIMP 2.10.32 contient une nouvelle traduction en géorgien, ce qui fait grimper le nombre total de langues disponibles pour la version stable à 83.
- GIMP était déjà traduit en galicien, mais pas l'installeur Windows… jusqu'à cette version !
Les contributions à d'autres dépôts du GIMPverse :
- Un contributeur à
babl 0.1.92 : Øyvind Kolås.
- Cinq contributeurs à
babl 0.1.90 : Øyvind Kolås, Mingye Wang, Jehan, Tomasz Golinski et Andrzej Hunt.
- Six contributeurs à
GEGL 0.4.36 : Øyvind Kolås, Anders Jonsson, Jehan, Alan Mortensen, Caleb Xu et zamfofex.
- Contributeurs à
ctx durant la même période : Øyvind Kolås et Jehan.
- Deux contributeurs à
gimp-macos-build (scripts de compilation pour macOS) : Lukas Oberhuber et Jehan.
- Quatre contributeurs à
org.gimp.GIMP (le flatpak stable) : Hubert Figuière, Ondřej Míchal, Jehan et Rebecca Wallander.
- Un empaqueteur Windows : Jernej Simončič.
- Contributeurs à
gimp-help (le manuel de GIMP) depuis les dernières statistiques :
- deux contributeurs techniques (scripts de compilation, intégration continue…) : Jacob Boerema et Jehan.
- cinq contributeurs à la documentation (le texte original en anglais) : Jacob Boerema, Anders Jonsson, Andre Klapper, Jehan et Marco Ciampa.
- 20 traducteurs : Rodrigo Lledó, Jordi Mas, Nathan Follens, Yuri Chornoivan, Anders Jonsson, Hugo Carvalho, Marco Ciampa, Tim Sabsch, Balázs Úr, dimspingos, Alan Mortensen, Aleksandr Melman, Charles Monzat, Claude Paroz, Kjartan Maraas, Luming Zh, Martin, Matheus Barbosa, Milo Ivir, Ulf-D. Ehlert.
- Six contributeurs à
gimp-web (le site web) depuis les dernières statistiques : Jehan, Alexandre Prokoudine, Anders Jonsson, Tom Gooding, Alberto Garcia Briz, Babs Keeley.
N'oublions pas de remercier également toutes les personnes qui nous aident à faire le tri sur Gitlab, qui remontent des rapports de bogues et qui discutent de l'évolution de GIMP avec nous. Et bien sûr, notre communauté est profondément reconnaissante aux combattants aguerris d'internet qui gèrent nos divers canaux de discussion ou nos comptes sur les réseaux sociaux, tels que Ville Pätsi, Alexandre Prokoudine, Liam Quin, Michael Schumacher et Sevenix !
Note : étant donné le nombre de pièces qui composent GIMP et son environnement, et la manière dont nous collectons les statistiques avec des scripts git, des erreurs peuvent se glisser dans ces statistiques. N'hésitez pas à nous faire savoir si nous avons manqué (ou incorrectement attribué) des contributeurs ou des contributions.
Autour de GIMP
Des nouvelles des miroirs
Depuis la mise en place de notre nouvelle procédure concernant les miroirs, les miroirs suivants ont été ajoutés à nos scripts de rotation :
- Get Hosted Online (Rothwell, Royaume-Uni)
- Aceldama Systems (Montreal, Canada)
- Open Computing Facility (Berkeley, CA, USA)
- Freedif (Singapour)
L'un des miroirs de la liste précédente a dû être retiré à cause de problèmes de performances, et l'acceptation d'un autre miroir est actuellement en suspens à cause du conflit et de l'instabilité en Europe de l'Est.
Une anecdote intéressante : GIMP est maintenant de retour à Berkeley via la Open Computing Facility (une organisation étudiante pour tous les étudiants, membres de la faculté et personnel de l'université de Californie à Berkeley). Pour ceux qui se demandent pourquoi c'est intéressant, nous vous recommandons de lire l'histoire de la naissance de GIMP.
TL;DR : à l'origine, GIMP est né à l'université de Californie. C'est plutôt sympa d'être de retour chez soi, non ?
Des nouvelles des livres
Notre page listant les livres avait cruellement besoin de maintenance. Quatre livres en espagnol ont été récemment ajoutés à la liste :
Nous avons profité de l'occasion pour réorganiser la page avec une section par langue.
C'est aussi un bon moment pour rappeler que tout le monde peut nous aider à garder cette page à jour. Nous savons que beaucoup d'autres livres ont été publiés au sujet de GIMP au fil des ans, et la liste est très incomplète. C'est pourquoi si vous avez écrit ou si vous connaissez un livre manquant à cette page, nous vous invitons à nous communiquer les mêmes informations que celles données pour les autres livres sur cette page afin que nous puissions les ajouter. Merci !
Télécharger GIMP 2.10.32
Comme d'habitude, GIMP 2.10.32 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
D'autres paquets préparés par des tiers sont bien sûr attendus (paquets pour distributions Linux ou *BSD, etc.).
Nouveau: GIMP sur le Microsoft Store
Dans les nouvelles intéressantes, GIMP a finalement été publié sur le Microsoft Store peu après la sortie de GIMP 2.10.32.
Cela a pu se produire grâce à l'aide appréciable d'un membre d'une équipe Microsoft de relations avec les développeurs qui a vraiment suivi notre cas de près et nous a beaucoup aidé. Nous remercions cette personne et Microsoft (vous ne nous voyez pas souvent remercier Microsoft! Mais sur le coup, ils ont été très bien, faut dire ce qui est) qui ont vraiment permis cela.
En réalité, GIMP était déjà publié en de nombreux exemplaires sur la boutique en ligne, mais par des tiers inconnus. Notons que cela n'a rien d'illégal ni n'est même forcément problématique en soi. Nous avons même une page dédiée pour expliquer pourquoi vendre GIMP n'est pas illégal.
Néanmoins dans les faits, nous avons remarqué que cela posait de nombreux problèmes de sécurité notamment, puisque GIMP est tellement connu qu'il est téléchargé assez massivement. Quiconque peut ainsi inclure des malwares, potentiellement pernicieux et difficilement détectables (tels que faire rentrer la machine sur un botnet, ou simplement utiliser votre puissance processeur comme on voit ces dernières années beaucoup avec le calcul de monnaies cryptographiques notamment).
Moins malveillant, nous avons vu des cas de versions de GIMP compilés avec des changements plus ou moins subtils, et des bugs ajoutés divers (exprès ou non). Nous avons vu des problèmes de fuites de données importantes avec des empaqueteurs qui fournissent GIMP en usage distant avec une sécurité absolument défaillante où les images ouvertes étaient visibles par d'autres utilisateurs. Et ainsi de suite.
En plus de nuire à l'image de GIMP (quand les gens ne se rendent pas compte qu'il ne s'agit pas d'une version officielle), nous n'aimions pas que les gens utilisent notre nom et notre réputation pour nuire à autrui (alors qu'on fournit GIMP pour exactement l'opposé).
Au contraire, nos paquets officiels ne contiennent aucun malware, ne font rien de vos données et n'ajoutent ni pub ni aucun autre système sournois de financement. Nous avons une politique de respect de la vie privée assez claire sur ces sujets.
D'ailleurs en parlant d'utiliser le nom, il y a aussi la problématique de se faire des sous faciles en induisant en erreur les acheteurs. Beaucoup croyaient aider le développement du projet GIMP en payant sur la boutique en ligne. Ce n'était pas forcément une usurpation d'identité claire (quoique nous avons eu au moins un cas où cela rentrait probablement dans cette catégorie avec une fausse fondation et cette fois, on s'était plaint auprès de la boutique qui avait autorisé cela), mais beaucoup laissaient simplement un flou suffisant en n'annonçant pas explicitement être un empaqueteur tiers tout en mettant un prix (il suffisait de regarder les commentaires de ces versions tierces pour se rendre compte que beaucoup de gens se sentaient floués quand ils découvraient cela après-coup). Ce n'était pas agréable que des gens aient ainsi la sensation de se faire arnaquer en utilisant la réputation de notre logiciel.
Notons qu'en soi, il peut y avoir de vrais bonnes raisons de faire payer GIMP. On pourrait imaginer un empaqueteur qui fournit un gros travail supplémentaire avec des scripts additionnels, de la documentation de haute qualité (et pas juste la nôtre! On a déjà vu des gens qui font payer notre documentation communautaire aussi!), et du support technique qui répondrait vraiment aux demandes. Voire si ce service additionnel impliquait de la correction de bugs, non seulement un tarif élevé ne me choquerait pas, mais en plus cela profiterait à tous (le client, l'empaqueteur avec un emploi payé au juste prix et le projet GIMP qui pourrait recevoir des corrections).
D'ailleurs dans des modèles économiques b2b (business à business), ce type de prestation se monte à de hauts tarifs. Malheureusement force est de constater que des empaqueteurs se contentaient de reprendre notre travail et de le faire payer en gardant le flou sur la provenance. Certes pas illégal, mais un business bien tristounet.
Au final notre version de GIMP sur la boutique Microsoft est gratuite, comme toutes les autres versions accessibles en direct sur notre site. Si certains veulent soutenir GIMP, comme d'habitude, nous les invitons à financer les divers financements participatifs de contributeurs pour financer les développeurs à la source, plutôt qu'à payer sur un quelconque store.
Et ensuite ?
Vous avez peut-être remarqué que les sorties de versions stables ont tendance à ralentir (GIMP 2.10.30 est sorti il y a six mois) au fur et à mesure que la stabilité globale sur cette branche devient bonne, bien que nous soyons limités par notre toolkit vieillissant. À présent notre attention se porte principalement sur la branche de développement. Malgré tout, nous continuerons à fournir des mises à jour et des correctifs à la branche 2.10 jusqu'à ce que GIMP 3.0 soit sorti.
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, les mainteneurs de GEGL et GIMP utilisent le financement participatif afin de pouvoir travailler à plein temps sur le logiciel libre. 🥳
