GIMP a fêté ses 25 ans d’existence le 21 novembre 2020. Passé de petit projet d’étudiants qui l’ont abandonné du jour au lendemain à projet majeur incontestable du graphisme mondial qui a fait bouger les lignes du logiciel Libre… ce logiciel aura eu un impact sur le monde.
Peu avant cet anniversaire, la version de développement GIMP 2.99.2 est sortie le 25 octobre. Bien que ce ne soit qu’une version de développement, il s’agit de la première étape publique du chemin menant à GIMP 3 !
Nouveautés marquantes de GIMP 2.99.2 :
- Interface utilisateur maintenant en GTK3, incluant donc la prise en charge native pour Wayland et les écrans haute densité de pixels (HiPPI).
- Réorganisation et nettoyage du code
- Nouvelle interface de développement (API) pour les greffons
- Les greffons peuvent maintenant être écrits en Python 3, JavaScript, Lua, et Vala.
- L’invasion spatiale (colorimétrique) continue
- Cache de rendu pour des performances améliorées
Note de la modération : LinuxFR a la chance d’avoir parmi ses contributeurs : Jehan, très actif dans le développement de GIMP depuis quelques années déjà (entre autres choses). Grâce à lui, non seulement vous découvrez les nouveautés de chaque version de GIMP dans la langue de Molière Gims, mais en plus vous lisez bien souvent une version enrichie de l’annonce initiale en anglais. C’est notamment le cas avec cette dépêche.
Sommaire
- Interface utilisateur en GTK3
- Sélectionner plusieurs calques à la fois
- Interface de programmation (API) pour les greffons
- Extensions
- L’invasion spatiale
- Cache de rendu
- Règles d’import améliorées
- Curseurs compacts
- Amélioration continue du code
- Paquets téléchargeables
- Et ensuite ?
- GIMP a 25 ans!
- Financer le développement de GIMP
Splash screen de GIMP 2.99.2 par Aryeom, Creative Commons by-sa 4.0
GIMP 2.99.2 avec le poster du film Coffee Run par Hjalti Hjálmarsson
Interface utilisateur en GTK3
La première différence est bien sûr visuelle, avec un sentiment d’interface un peu plus moderne, ainsi que l’utilisation possible de nouveaux éléments d’interface. Diverses boîtes de dialogue profitent aussi maintenant de décorations de fenêtre côté client. Cependant les différences esthétiques sont loin d’être l’attrait majeur de GTK3.
Gauche : GIMP 2.10.22 - Droite : GIMP 2.99.2
Vraie prise en charge des écrans à haute densité de pixels
L’une des faiblesses majeures de GTK+2 est l’absence de prise en charge d’écrans à haute densité de pixels (par exemple de petits écrans avec une haute résolution ou de grands écrans avec une extrêmement haute résolution). Ces derniers ne sont pas majoritaires mais deviennent de plus en plus répandus, notamment chez les professionnels du secteur graphique. GIMP 2.10 avait une prise en charge limitée (dont j’étais d’ailleurs à l’origine de l’implémentation), comme une rustine de code, qui aidait dans certains cas intermédiaires mais n’était pas appropriée aux usages plus intensifs.
GTK3 fournit donc une vraie prise en charge dans GIMP qui suivra désormais les préférences système pour le redimensionnement d’interface.
État : fini.
Prise en charge améliorée des périphériques d’entrée
Par « périphérique d’entrée », on entend surtout les tablettes graphiques et tablette-écrans. Ces périphériques étaient bien sûr déjà pris en charge, mais avec pas mal d’insuffisances jusqu’à GIMP 2. Notamment il fallait brancher la tablette avant de démarrer GIMP et l’activer explicitement dans les préférences du logiciel. Pire, débrancher la tablette en cours d’usage pouvait rendre GIMP instable (un problème que j’ai plus ou moins mitigé dans GTK+2, pendant la série 2.8, l’un de mes premiers patchs majeurs mais qui néanmoins n’est pas la solution idéale que nous apporte GTK3).
GIMP 3 (et donc cette version de développement aussi) nous permet ainsi le branchement à chaud. En d’autres termes: démarrez GIMP, branchez la tablette, c’est bon. Vous êtes maintenant paré pour dessiner avec prise en charge de la pression, de l’angle et de toute autre entrée du stylet.
L’une des choses que l’on souhaite améliorer maintenant est la simplification de la configuration avancée de ces périphériques d’entrée.
Pour ce qui est de la prise en charge des évènements tactiles multi-point (pour zoomer, faire tourner ou se déplacer sur le canevas par exemple), nous avons un peu expérimenté cela à un moment. Nous n’avons néanmoins pas achevé cela, car nous avons vite réalisé qu’il ne s’agissait pas d’une priorité en comparaison d’autres fonctionnalités.
Le tactile est une fonctionnalité très sympathique, mais elle peut aussi s’avérer gênante. D’ailleurs de nombreux artistes professionnels finissent par désactiver le tactile pour ainsi éviter des actions non voulues (au point que de nos jours, les tablettes haut de gamme tendent à sortir avec un interrupteur physique permettant de désactiver matériellement le tactile, même si on peut aussi le désactiver logiciellement). C’est pourquoi ce n’est pas une priorité. Nous ne savons donc pas si GIMP v3.0 sortira avec prise en charge des gestes multi-points. Bien sûr, nous accueillons avec plaisir tout patch de quiconque voudrait en faire sa priorité et ainsi s’assurer que GIMP ait cette fonctionnalité.
État : encore du travail à faire dans la simplification de la configuration des tablettes maintenant que certaines fonctionnalités historiques ne sont plus utiles ou peuvent être présentées de manière plus compréhensible. Il existe aussi des fonctionnalités spécifiques à Wayland pour les tablettes que nous pourrions ajouter en fonction du temps disponible et de l’intérêt exprimé.
Personnalisation du thème
Nous héritons aussi bien entendu du système de thème de GTK3, basé sur le langage de style CSS. Cela signifie malheureusement que tous les thèmes personnalisés des versions passées ne seront pas compatibles avec GIMP 3.0 et les sorties futures. Le bon côté des choses est qu’il s’agit d’un standard bien connu et répandu, ce qui devrait rendre la personnalisation de l’interface de GIMP bien plus accessible à un plus grand monde.
De même, les thèmes d’icônes symboliques sont bien mieux pris en charge. Les couleurs s’adapteront aux couleurs de premier et arrière plans définies dans le thème. Si vous avez déjà changé le thème de GIMP 2.10.x, en passant d’un thème sombre à un thème clair, vous vous souvenez probablement que vous deviez aussi changer le thème d’icône manuellement. Ce n’est plus nécessaire vu que les icônes seront automatiquement recolorées en fonction de votre thème.
Enfin le « thème sombre » est un concept central de GTK3, ce qui signifie que même les décorations de fenêtre seront recolorées si le système de fenêtre le permet (voir la capture plus haut).
Notons aussi qu’un même thème peut proposer à la fois une variante sombre et claire. C’est pourquoi la page de préférences de Thème propose une case à cocher « Utiliser la variante de thème sombre si disponible ». De même, un thème d’icône peut proposer à la fois des versions symboliques et couleurs, ce pourquoi la page « Thème d’icône » propose la case à cocher "Utiliser les icônes symboliques si disponibles". Vous êtes ainsi libre de personnaliser GIMP selon vos préférences.
Passer de la variante sombre à claire en cochant une case, ce qui recolore aussi les icônes symboliques
État : en attente de contributeurs de thème.
Côté code, les changements relatifs à la personnalisation du thème sont finis, maintenant nous avons besoin d’un thème par défaut ! Vous pourrez remarquer que GIMP 2.99.2 ne liste qu’un thème “Système”, qui utilise donc principalement les couleurs de votre thème GTK système. Il s’agit donc d’une régression par rapport à 2.10 qui proposait des thèmes aux couleurs neutres (clair, obscur et intermédiaire). Nous souhaitons donc réintroduire un thème par défaut avec des variantes clair/obscur ainsi qu’un thème gris-intermédiaire.
Pour rappel, le problème principal des thèmes systèmes est qu’ils couvrent des cas d’usage “bureautiques” alors que le travail graphique nécessite des couleurs neutres, sans teinte, pour ne pas polluer sa perception des couleurs. C’est la raison principale pour laquelle GIMP vient désormais avec un thème neutre et des icônes symboliques.
Bien entendu, les thèmes et icônes colorés sont toujours utilisables. D’ailleurs nous sommes certains que la communauté créera très rapidement de jolis thèmes personnalisés. Une très bonne manière de contribuer à GIMP sans être développeur !
Prise en charge de Wayland
Le portage vers GTK3 devrait théoriquement nous permettre de bénéficier sans rien avoir à faire de la prise en charge de Wayland sous Linux. C’est presque le cas, mais pas tout à fait. Malheureusement, quelques bugs ont déjà été rapportés pour GIMP tournant sous Wayland. Certains d’entre eux sont clairement bloquants pour une publication de GIMP 3 (comme des comportements étranges de l’interface graphique ou d'énormes fuites mémoire). D’autres sont moins sérieux mais quand même gênants, comme celui où l’écran d’accueil est trop grand sur des affichages HiPPI parce que Wayland ne rapporte pas proprement la mise à l’échelle.
À moins que ces problèmes ne soient résolus, nous ne pensons pas pouvoir affirmer que la prise en charge de Wayland nous convient. Nous serons reconnaissants pour tout correctif pour y remédier, qu’ils soient envoyés à GIMP, GTK ou toute partie concernée de la pile technologique. Si l’idée de nous aider vous intéresse, voici la liste de bugs concernant Wayland.
Une prise en charge convenable de Wayland signifie également que quelques fonctionnalités doivent être réimplémentées à travers ce que l’on appelle des portails. Nous avons déjà fait cela pour le greffon de capture d’écran (qui utilise les portails Freedesktop, GNOME et KDE), et il y a également un travail en cours pour corriger la sélection de couleur à l’écran (fonctionne déjà sur KDE, pas encore avec les portails GNOME et Freedesktop; malheureusement Wayland vient avec pas mal de duplication de travail en fonction des bureaux).
Quant au portail des fichiers, c’est probablement quelque chose qui n’arrivera pas pour GIMP 3.0 parce que certaines fonctionnalités de la boîte de dialogue de fichier GTK restent indispensables. Mais ça pourrait être proposé plus tard à l’occasion de la refonte planifiée du mécanisme d’exportation.
Enfin il faut savoir que Wayland a actuellement une prise en charge inexistante de la correction de couleurs, c’est d’ailleurs une très grosse cause de conflit actuellement entre certains utilisateurs de logiciels de graphisme sous Linux et les développeurs de Wayland. Il faut donc savoir que même si GIMP tournait très bien sous Wayland, les serveurs Wayland ne sont pas encore utilisables pour un usage graphique professionnel, et ce au niveau protocolaire.
État : quelques bugs bloquants en particulier requièrent une attention. Les contributions sont bienvenues.
Les « portails » ?
Propos de Jehan extrait du chat de rédaction de la dépêche pour qui veut en savoir plus sur ce que sont les portails :
Les portails sont un changement de paradigme qui vient avec Wayland et les empaquetages comme Flatpak. Il implique de revoir la logique de certaines interactions. On y viendra, on a déjà réfléchi depuis des années à des changements dans le concept d’export notamment qui pourront aller avec ce changement de paradigme.
Les portails sont un concept de « services du bureau Linux » (techniquement simplement un service D-Bus) pour diverses fonctionnalités : au lieu d’accéder directement aux services bas niveau (serveur d’affichage, système de fichiers, etc.), on demande à un service « je veux ça ». En l’occurrence, on demanderait au service « on veut ouvrir un fichier », puis on perd la main et on attend une réponse du service (entre-temps, le service aura probablement montré un sélecteur de fichier à l’utilisateur, lequel aura sélectionné un fichier, mais l’application ne connaît pas le détail).
Ça va avec les nouveaux systèmes de permissions qui font progressivement leur entrée dans Linux. À terme, l’idée est qu’une application ne voit plus aucun fichier, ne peut plus accéder au réseau sans le faire savoir, ne voit pas les autres applications ni ce qu’il y a sur l’écran, etc.
C’est intéressant niveau sécurité mais apporte énormément de limitations. Pour un usage avancé, les possibilités des portails sont encore très très limitées parce que ça permet d’ouvrir un sélecteur de fichier. On ne sait pas lequel. Ça peut en effet être le sélecteur GTK comme celui de Qt, celui de Windows ou de macOS, etc. Donc ça veut dire qu’on ne peut plus personnaliser cette boîte de dialogue.
Typiquement les autres types de portails qui seraient à gérer par une application complexe (telle que GIMP) sont : les captures d’écran (image voire vidéo), la sélection des couleurs à l’écran, les périphériques d’entrée/sortie (imprimantes, scanners, webcams…), la gestion des écrans (une application sous Wayland ne sait plus sa position et n’a plus la possibilité de choisir sa position à l’écran, ni même ne sait combien d’écrans il y a, ou ne connaît les profils de couleurs, ce qui est d’ailleurs un gros problème pour les logiciels graphiques qui ne peuvent être utilisés professionnellement sous Wayland, etc.), l’accès au réseau, la communication avec les autres applications, etc.
Sélectionner plusieurs calques à la fois
Gérer un projet complexe contenant des dizaines ou des centaines de calques est devenu beaucoup plus facile grâce à la possibilité de sélectionner plusieurs calques à la fois. La réalisatrice de dessins animés Aryeom réclamait cette possibilité depuis 2015 et son projet ZeMarmot en a donc pris en charge le développement. Nouvel exemple de la collaboration fructueuse entre artiste et développeur : chaque détail a été précisé après discussion et a d’abord été testé en production.
4 calques sélectionnés, prêts à être déplacés ou transformés en même temps
On peut sélectionner plusieurs calques dans la fenêtre des calques avec les combinaisons de touches classiques (Shift+click pour une série de calques et Ctrl+click pour sélectionner ou désélectionner). On peut réorganiser les calques par série : déplacer, réordonner, supprimer, dupliquer, fusionner, etc. tous les calques sélectionnés d’un coup.
Plusieurs outils fonctionnent sur tous les calques sélectionnés. Par exemple les outils de transformation (déplacement, rotation, échelle, perspective, transformation unifiée…) transformeront tous les calques sélectionnés (en plus des calques liés par l’icône de chaîne). On peut aussi découper plusieurs calques d’un coup ou copier-coller une projection de calques fusionnés. L’outil pipette peut même prendre un mélange de couleurs réparties sur plusieurs calques (similaire à l’option "Échantillonner sur tous les calques" en version partielle, c’est-à-dire sans avoir à masquer les calques non-désirés).
Il ne s’agit que de quelques exemples parce qu’une grosse partie du code est impactée par ce changement : le concept d’un seul calque actif est omniprésent dans les actions. Vous en apprendrez plus en lisant le rapport de développement.
État : bien avancé, mais toujours en cours.
Quelques outils fonctionnent encore en calque unique et doivent être modifiés avant la version finale. Ce faisant, nous casserons probablement des choses, c’est pourquoi nous sortirons d’autres versions de développement. De plus, nous pourrions bientôt étendre la sélection de plusieurs éléments aux chemins et canaux.
Enfin, la peinture et les opérations GEGL (filtres) sont encore limitées aux calques uniques. Permettre de peindre ou de retoucher des pixels sur plusieurs calques à la fois, nécessite probablement des changements d’interface (à concevoir) pour éviter les effets indésirables, comme des opérations trop longues ou qu’on ne pourrait annuler.
Interface de programmation (API) pour les greffons
Nous avons dû briser l’interface de programmation pour les greffons afin d’introduire beaucoup d’améliorations, tout en faisant attention à ne pas briser ce qu’il n’y avait pas lieu d’être.
Porter un greffon constitué d’un seul fichier de GIMP 2.10 à GIMP 3 prend d’habitude entre 5 et 30 minutes. Nous travaillons à l’écriture d’une documentation de portage, qui sera publiée en même temps que GIMP 3.
Si vous êtes un développeur de greffons, une des premières étapes à suivre est de s’assurer que vous n’utilisez pas de fonctions obsolètes. Nous avons compilé une liste de fonctions retirées avec leur remplacement. Vous pouvez déjà effectuer cette partie du portage tout en ciblant les versions GIMP 2.10.x.
API orientée Objets
Parmi les changements notables, nous avons écarté les identifiants d’objets (object IDs) pour utiliser directement des objets. En particulier dans GIMP 3, GimpImage, GimpItem, GimpDrawable, GimpLayer, GimpVectors, GimpChannel et GimpPDB sont des objets (d’autres classes d’objets existent déjà ou pourraient être ajoutées plus tard).
Cela permet une programmation plus sécurisée en ayant des objets typés dont la classe peut facilement être vérifiée, et donc implique des messages d’erreur plus adaptés (avec les IDs, qui sont simplement des nombres entiers, il n’était pas rare d’avoir des bogues bizarres à cause d’IDs incorrectes, compliquant la recherche de bogues).
La programmation objet amène également l’héritage de classes. Typiquement, une GimpLayer est aussi une GimpDrawable, elle-même étant une GimpItem. Cela signifie que vous pouvez utiliser n’importe quelles méthodes des classes parentes et facilement savoir à quelle classe elles appartiennent.
Une conséquence non-C est que cela permet des ponts pour adapter les API à leur propre modèle objet. Ainsi, dupliquer une instance GimpImage nommée par exemple img en Python 3 peut être fait avec l’API assez pythonesque img2 = img.duplicate().
État : le portage objet est quasi terminé. Nous voulons également utiliser la signalisation objet, qui est en cours de réalisation et devrait au final permettre de connecter des gestionnaires de signaux directement aux objets pour gérer des évènements venant du cœur de l’application (chose impossible dans GIMP 2, sauf à lancer des requêtes périodiquement).
Usage de GIO pour la gestion des fichiers
Un autre changement dans l’interface de programmation des greffons (API) est l’usage de GFile pour abstraire les fichiers, c’est-à-dire donc avec GLib/GIO.
Cela peut paraître un peu ennuyeux au premier abord (cela peut ajouter une étape additionnelle de création et de gestion de GFile), néanmoins cela permet une gestion des fichiers plus robuste. En particulier, il n’est plus nécessaire de se préoccuper du codage des chemins d’accès et de conversions (un problème lorsque les développeurs supposent que tout le monde utilise le même codage) et donc moins de chemins erronés et de code non-portable. En outre, on n’a plus à se poser la question des schémas de notation de chemins différents entre systèmes d’exploitations (tels que le caractère de séparation de répertoire ou les notations de système de fichier). Travailler avec des GFile rend la représentation interne d’un fichier transparente, donc l’usage d’un fichier plus robuste.
Un autre avantage majeur est que l’interface obtient automatiquement toutes les capacités des modules GIO installés, tels que le chargement/enregistrement sur des URI distantes (et possiblement à travers des canaux chiffrés comme HTTPS). Cela ouvre donc des possibilités sans code spécifique côté applicatif.
L’usage de GIO pour le traitement de fichier avait déjà été fait dans le code principal de GIMP pour la sortie initiale de GIMP 2.10.0. Nous permettons maintenant aux dévelopeurs de greffons d’en profiter également dans GIMP 3.0.
État: terminé, excepté pour les bindings historiques.
Les bindings nouvelle génération par introspection GObject ont un accès complet à l’interface GLib/GIO et sont donc parfaitement capables de créer des GFile à travers des chemins d’accès et des URIs. Par contre les bindings historiques, tels que script-fu (Scheme), n’ont pas accès à l’API GFile. Nous devons travailler sur ce sujet (un patch existe même déjà mais a besoin de revue de code).
Déclaration des greffons
L’interface de programmation des greffons a connu une refonte majeure dans les fonctions de déclaration du greffon. Cela se fait maintenant en sous-classant une classe GimpPlugIn et en re-définissant certaines méthodes pour lister et documenter les procédures créées par le greffon. Cela permet une déclaration bien plus propre, explicite et évolutive que l’interface précédente, et cela devrait donc aider les développeurs de greffons.
La manière dont les paramètres des procédures de vos greffons sont maintenant gérés a également été standardisée, en particulier en utilisant les propriétés GObject d’un objet de configuration. C’est plus facile à gérer en tant que logique générique. En particulier, le même objet de configuration nous permet de générer de nombreuses fonctionnalités. Par exemple, il aidera à générer des dialogues à la demande pour des greffons qui ne veulent pas tripatouiller du GTK ou un autre toolkit par eux-mêmes. Cela simplifie également et standardise la sauvegarde de paramètres pour des appels ultérieurs ou une même procédure.
Au final, cela fait également partie du travail de fond pour une future fonctionnalité d’enregistrement de macro (très peu probable de la voir dans GIMP 3.0, mais c’est une partie du travail amenant à cette fonctionnalité puisque nous serons capables de sauver de manière fiable les paramètres utilisés lors du lancement des greffons.
État : bien que la partie principale de cette API soit terminée, la version finale nécessite d’autres ajustements, comme la représentation des paramètres qui n’est pas encore figée.
Prise en charge de langages de programmation variés (bindings)
L’interface de programmation (API) est maintenant entièremement introspectée grâce à GObject Introspection. Cela implique que GIMP peut maintenant être scripté avec une large variété de langages informatiques. Voici ceux que nous avons testé à ce jour, et dont nous pouvons donc confirmer la viabilité (en plus de C et C++ bien sûr) :
- Python 3
- JavaScript
- Lua
- Vala
L’une des principales différences avec l’ancienne méthode pour faire des interfaces intermédiaires pour scripter GIMP (par exemple GIMP 2.10 avait une interface Python 2) est que nous ne nécessitons plus de couche logicielle intermédiaire. C’est donc un énorme gain en maintenance et en stabilité.
En outre les interfaces non-C de GIMP 2 se basaient habituellement sur le protocole de communication de GIMP appelé PDB, lequel n’est en fait qu’un sous-ensemble des fonctionnalités de la bibliothèque C libgimp. Au contraire, les nouvelles interfaces sont générées à partir de libgimp même, par conséquent les greffons en Python 3, Javascript, Lua ou Vala (ainsi que toute future prise en charge par introspection) auront les mêmes possibilités d’action que les greffons en C. C’est un nouveau monde qui s’ouvre aux développeurs de greffons GIMP !
Une autre conséquence est que les interfaces résultantes sont globalement les mêmes dans tous ces langages de programmation, aux spécificités de syntaxe près.
Par exemple, si pour trouver l’intersection d’un drawable avec une sélection se fait ainsi en C :
success = gimp_drawable_mask_intersect (drawable, &x, &y, &width, &height);En Javascript, ce sera :
let [ intersect, x, y, width, height ] = drawable.mask_intersect();En Python 3:
intersect, x, y, width, height = drawable.mask_intersect()Un autre exemple sympa est la manière dont les tableaux C avec paramètre additionnel de longueur sont gérés dans les langages qui ont une structure de données appropriée (et en particulier ne nécessitant pas l’information de longueur dans un argument à part).
Ainsi alors que vous copiez les pixels de multiples drawables ainsi en C :
/* Where @drawables is a C array of drawables, and @num_drawables
* indicates the size of this array.
*/
gimp_edit_copy (num_drawables, drawables);En Python 3, vous faites la même chose avec une liste Python, laquelle n’a pas besoin de l’argument num_drawables maintenant redondant avec les possibilités de la structure liste Python :
Gimp.edit_copy([drawable1, drawable2, drawable3])Bonus : non seulement les greffons non-C ont maintenant accès à toutes les fonctions proposées par GIMP, mais ils ont aussi accès à bien d’autres interfaces qui sont utilisées comme dépendances de GIMP. Ainsi un greffon peut utiliser n’importe quelle fonction de GLib/GIO, GTK, Pango, Cairo mais surtout babl et GEGL (ouvrant de nouvelles portes pour la manipulation de pixels et l’accès à une belle liste d’opérations graphiques). C’était probablement une des plus grosses limitations de l’interface Python 2 précédente, laquelle n’avait pas la possibilité de manipuler les pixels avec GEGL.
État : certains des développeurs ont regretté des fonctions spécifiques à l’ancienne interface Python 2, et en particulier la capacité de créer des dialogues simplement (sans utiliser GTK directement). Cette possibilité n’est pas dans GIMP 2.99.2 mais existera bien dans GIMP 3.0. En fait, après la sortie de GIMP 2.99.2, j’ai déjà ré-implémenté cela avec plus de fonctionnalités (c’est-à-dire des moyens de personnaliser l’organisation visuelle des options dans la boîte de dialogue notamment). Ce sera donc disponible dès GIMP 2.99.4 et sera extrêmement plus puissant que ce que l’interface Python 2 proposait.
Mais surtout : ce sera disponible à tous les langages, pas juste Python ou Scheme ! C’est l’un des autres gros avantages d’interfaces générées par introspection. Au lieu d’implémenter des supers fonctionnalités dans chaque couche de langage (similairement mais avec une implémentation et des possibilités différentes), on les fournit sur l’interface de base en C. En conséquence, tout développeur — quel que soit son langage de prédilection — aura accès à toutes les fonctionnalités.
Enfin, notons que Script-fu ne fait pas partie des interfaces générées par introspection (bien qu’il existe des interfaces GObject Introspection pour Scheme, mais nous ne les avons pas encore testées) et fonctionne donc encore avec une couche d’extension supplémentaire, « à l’ancienne », avec toutes les limitations que cela implique. En outre, des problèmes à cause du changement d’interface ont déjà été soulevés (notamment l’impossibilité de créer des GFile comme mentionné plus haut). Nous devrons régler cela d’ici la sortie de GIMP 3.0.
Greffons goat exercise (« promenade de chèvre »)
Pour chacune des interfaces de langages testées, nous avons créé un greffon appelé promenade de chèvre (sic - terme utilisé dans la traduction française officielle), lequel est une démo de création de greffon. C’est comme un Hello World! mais pour GIMP.
NdT : Goat est une blagounette avec GEGL dont l’acronyme alternatif (« Genetically Engineered Goat, Large ») décrit son logo, une chèvre à cinq pattes.
Chaque promenade de chèvre fait exactement la même chose dans son propre langage : elle crée une fenêtre de dialogue avec un label, des boutons et une text view (démo GTK+ et GLib/GIO) ; un des boutons déclenche un filtre modifiant le calque sélectionné (démo GEGL et démo GIMP API) ; tout cela pendant qu’elle montre son propre code source à l’intérieur de la text view (facilitant ainsi l’inspection de code depuis GIMP) et avec un bouton vous envoyant vers le fichier du dépôt (si vous préférez récupérer la dernière version, confortablement dans votre éditeur de code).
Les 5 versions du greffon promenade de chèvre en Python 3, Javascript, Lua, C et Vala
Ces greffons sont assez importants puisque nous prévoyons d’améliorer l’écosystème des greffons avec GIMP 3. Il constitue la première étape de greffons de démonstration auto-documentés (tout en faisant quelque chose d’un peu plus intéressant qu’un simple « Hello World »).
État : le code actuel des promenades de chèvres n’est pas toujours synchronisé avec les API les plus récentes puisque ce sont des éléments en constante évolution. Ils seront mis à jour avant la sortie finale.
Documentation de développement
Nous avons commencé à mettre par écrit de la documentation concernant le développement de greffons dans GIMP 3, et commencerons à publier progressivement quelques didacticiels. Nous espérons même être capable de remettre à flot notre site web pour développeurs qui a doucement sombré depuis de trop nombreuses années. Nous espérons que GIMP 3 viendra redonner un coup de fouet à l’écosystème des greffons de GIMP.
État : encore à un stade précoce, nous souhaitons la bienvenue à plus de contributeurs pour rendre cela possible.
Extensions
Les extensions sont un nouveau format de fichier qui est simplement un regroupement de données (brosses, écrans d’accueil, motifs, dynamiques…) ou de greffons, associés à des méta-données (nom, description, copies d’écran, version, pré-requis…). Le but sera de permettre aux développeurs de greffons de publier leurs travaux sur des dépôts pour que tout le monde puisse chercher des greffons venant de tiers, les installer ou désinstaller, activer ou désactiver, et les mettre à jour directement dans GIMP.
Le menu Edit > Manage Extensions montre la fenêtre principale de dialogue. Dans l’onglet « System Extensions » en particulier, vous noterez « Official Demo Plug-ins » qui est notre première extension. Elle regroupe en fait toutes les greffons Promenades-chèvres dont nous avons parlé plus haut. Si vous le désactivez, vous remarquerez après un redémarrage (pour le moment, vous devez redémarrer GIMP pour en voir les effets) que le menu catégorie Filters > Development > Goat Exercises aura disparu.
Les promenades de chèvres sont elles-mêmes notre première démo d’extension.
Nous reviendrons sur cette fonctionnalité après que nous y aurons travaillé davantage. En particulier, nous fournirons de la documentation sur la manière de créer des extensions. C’est vraiment quelque chose que les créateurs de greffons et de ressources devraient garder en ligne de mire, puisque cela les aidera à partager leurs créations avec d’autres.
État : encore plus de travail à faire du côté de GIMP, particulièrement pour communiquer à propos des dépôts, et beaucoup plus de travail encore pour le dépôt officiel et le site web des extensions.
L’invasion spatiale
"Space invasion" est le nom de code interne du travail initialement entamé en 2018 dont le but était de mettre en place une prise en charge adaptée de l’espace colorimétrique sur l’ensemble du traitement des pixels. Dans les séries de GIMP 2.10, malgré une prise en charge de la gestion des couleurs dans le cœur du logiciel, les profils étaient quelquefois perdus pendant le traitement d’une opération et seulement réintroduits dans le résultat final, ce qui pouvait donner lieu à des valeurs erronées dans certains cas.
Quiconque souhaitant comprendre plus avant ces problématiques peut lire l'article de Øyvind Kolås et en particulier la note de sortie détaillée de GEGL 0.4.6 dans laquelle il explique tout cela très bien.
Quelques améliorations de ce travail ont déjà été progressivement rétro-intégrées à diverses versions de GIMP 2.10.x, mais GIMP 3.0 devrait être la sortie ultime pour laquelle nous espérons régler cela à 100%.
Status : la branche de développement est beaucoup plus avancée sur ce sujet que la série des versions 2.10, mais davantage de travail est nécessaire. Divers aspects de GIMP sont toujours limités aux seules valeurs sRGB que ce soit pour l’affichage ou le traitement.
Cache de rendu
GIMP 3 a maintenant un cache de rendu qui conserve le résultat d’un changement d’échelle, la gestion des couleurs, des filtres d’affichage et des masques de canevas (pour les outils tels que Fuzzy Select). Cela donne une sensation de rapidité de l’interface en comparaison à la version GTK2 de GIMP.
Il y a maintenant également un paramètre Zoom Quality dans Preferences -> Display. Quand il est positionné sur Fast, GIMP fera une interpolation au voisin le plus proche depuis le mipmap de niveau immédiatement supérieur au lieu d’un filtrage linéaire ou fenêtré. Cela donne un coup de pouce léger mais permanent à l’affichage et à l’ensemble des modifications. Nous avons quelques idées pour améliorer cela davantage, comme de remplacer les pixels interpolés rapidement par une interpolation de meilleure qualité (mais plus lente) après un certain temps.
État : fini.
Règles d’import améliorées
L’option de Politique de profil de couleur propose dorénavant un nouveau choix : "Convertir au profil colorimétrique RVB préféré" et l’action par défaut “Convertir” de la fenêtre d’importation convertira l’image au profil préféré (s’il a été défini, autrement on se réfère au profil prédéfini sRGB). La conversion au profil prédéfini sera toujours disponible comme une action secondaire. Si vous voulez toujours travailler avec le même profil donné, vous pouvez ainsi définir ce dernier ainsi que le comportement par défaut du logiciel à l’importation.
De plus, une nouvelle Politique de rotation est proposé dans la fenêtre des Préférences, à côté de la Politique de profil de couleur (à la page Préférences > Importation et exportation d’images) avec 3 options : « Demander ce qu’il faut faire », « Rejeter la méta-donnée sans rotation », et « Effectuer la rotation puis rejeter la méta-donnée ».
Politique de profil de couleur mise à jour et nouvelle Politique de rotation
Les règles de rotation par méta-donnée étaient jusque-là gérées du côté des greffons d’importation, avec des fenêtres de dialogue générées par libgimpui et sauvées dans un parasite global. Toute la logique et l’interface graphique ont été déplacées dans le cœur du logiciel, au côté de la « Politique de profil de couleur ». Ceci implique que les greffons n’ont même plus besoin de gérer cela puisque ça se passera désormais génériquement et automatiquement comme spécifié par l’utilisateur à chaque nouvelle importation.
État : fini.
Curseurs compacts
Le curseur compact fut introduit dans GIMP 2.10.18. Dans la série des 2.10, il a été laissé comme une fonctionnalité optionnelle qui pouvait être désactivée dans la fenêtre de Préférences. Dans GIMP 3, c’est maintenant l’unique choix possible, sans option.
Nouveau curseur compact comme seule et unique option
Remarquez que la couleur bleu clair sur la copie d’écran n’est pas un choix de notre fait : cette couleur est définie par le thème (or comme on le disait, on n’a pas encore de thème spécifique, il s’agit donc d’un thème système quelconque). Ce widget utilise les couleurs par défaut de GtkProgressBar. Elles peuvent donc être ajustées dans un thème personnalisé en changeant les couleurs de GtkProgressBar ou seulement les couleurs de ce widget en particulier (une fois de plus, bienvenue aux contributeurs de thèmes!).
État : fini.
Amélioration continue du code
Pendant que nous portions d’anciennes fonctionnalités et en implémentions de nouvelles, beaucoup de travaux connexes ont été faits sur la structure du code. De nombreuses parties du code principal ont été réorganisées pour une meilleure maintenance.
Bien que tout n’ait pas encore été porté, un travail de fond a été mis en place, tel que l’interface GimpAction pour ajouter une couche d’abstraction aux GtkAction (nous préparant à nous en séparer réellement à échéance, ce qui est une des grosses parties restantes pour la migration vers GTK3).
De nombreuses autres parties sont constamment retravaillées et améliorées au cours d’un travail de fond incessant.
État : la réorganisation du code est une tâche constamment active, l’a toujours été et le sera toujours. Elle ne s’arrêtera jamais vraiment.
Paquets téléchargeables
Flatpak "beta" disponible
Cette version est disponible dans la branche “beta” de notre paquet Flathub officiel, qui est une branche de publication masquée (vous ne trouverez pas cette information sur la page publique sur le site de Flathub). Voici la commande qui vous permettra d’installer GIMP 2.99.2 :
flatpak install --user https://flathub.org/beta-repo/appstream/org.gimp.GIMP.flatpakref
À partir de là, vous pourrez mettre à jour vers de nouvelles versions de développement dès qu’elles seront disponibles par ce biais (si votre bureau intègre Flatpak, il pourra même vérifier automatiquement de lui-même et les proposer).
Il faut noter que Flatpak ne permet qu’une seule branche visible à la fois pour une même application, de sorte que si vous avez installé à la fois les versions stable et de développement avec Flatpak, votre bureau ne montrera que l’un ou l’autre. Pour changer de branche visible, il faut lancer la commande correspondante parmi les deux proposées ci-dessous :
flatpak make-current --user org.gimp.GIMP beta
flatpak make-current --user org.gimp.GIMP stable
Certains ont aussi créé des raccourcis qui lancent explicitement la commande flatpak (ou
run org.gimp.GIMP//betastable respectivement), comme solution de secours pour obtenir des icônes pour les deux versions.
Windows
Comme d’habitude, nous proposons un installateur pour GIMP sous Windows, que vous trouverez sur la page de téléchargement de développement.
Il peut manquer quelques fonctionnalités. En particulier, vous ne trouverez pas d’interface JavaScript sur le paquet Windows en raison de la complexité de certaines dépendances. Nous corrigerons ce souci dans de futures pré-versions en chemin vers GIMP 3.
macOS
Notre empaqueteur pour macOS n’est toujours pas complètement revenu, donc malheureusement nous n’avons pas de paquet macOS officiel. Comme toujours, nous vous rappelons que GIMP est un logiciel libre développé par une communauté. Chacun peut devenir un mainteneur officiel, et avoir plusieurs contributeurs sur la question permet d’assurer une meilleure pérennité.
Si vous êtes intéressé, n’hésitez pas à nous contacter sur notre canal développeur sur IRC : #gimp.
Et ensuite ?
Comme vous le voyez, énormément de choses ont été faites (le fichier NEWS donne bien plus de détails). Le gros du travail a déjà été fait. Ce qui reste maintenant est le peaufinage. Ce n’est cependant pas si simple, car les décisions finales et l’attention aux petits détails sont le plus difficile. Nous voulons publier un GIMP 3 d’envergure, et devons donc être particulièrement méticuleux. Voilà où nous en sommes et c’est pourquoi nous publions cette première version de développement.
Ce rapport de développement détaille assez précisément tout ce qui reste à faire, et vous remarquerez à quel point il suit vraiment de près les changements de GIMP 2.99.2. C’est notamment du côté de l’API — bien que la plupart des utilisateurs ne la voient pas — qu’il faut notamment s’assurer de ne pas faire d’erreur avant publication, car notre API devra rester stable tout au long de la série des 3.x. Une fois que ce sera fait, nous voudrons garder les interfaces de libgimp 3.0.0 inchangées à moins d’une exception (par exemple parce que nous découvrons des bogues qui rendent une fonction inutile). Cela nous prendra du temps.
Il y a certainement d’autres points sur lesquels de l’aide fera la différence, que ce soit dans les greffons, le code, l’interface utilisateur ou l’interface de programmation. C’est pourquoi nous avons besoin de plus de paires d’yeux pour résoudre autant de petits problèmes que possible.
GIMP a 25 ans!
Il y a pas mal d’anniversaires ronds de logiciels libres dernièrement. Pour ne pas déroger à la règle, GIMP vient de fêter ses 25 ans!… un âge dont peu de logiciels encore en activité peuvent se targuer.
“Joyeux 25ᵉ anniversaire GIMP!” par Aryeom, Creative Commons by-sa 4.0
Note: une vidéo accélérée (timelapse) de ce dessin est disponible, avec commentaires audios (et textuels dans des sous-titres notamment français). J’aime particulièrement beaucoup les commentaires, car ils apportent un autre niveau d’implication et de réflexion sur ce qui peut sembler être juste un petit dessin irréfléchi pour beaucoup de gens.
Le fichier source du dessin (format de GIMP XCF, comme d’habitude sous licence Creative Commons by-sa 4.0, vous autorisant à étudier et modifier l’œuvre pour faire une œuvre dérivée!) est disponible sur la page Patreon associée.
Un peu d’historique
En effet, c’est le 21 novembre 1995 qu’un étudiant, Peter Mattis annonce pour la première fois un logiciel appelé « The GIMP » (the General Image Manipulation Program, le “General” deviendra par la suite “GNU” et l’article "the" disparaîtra), et livre un premier code publiquement, développé avec son collègue Spencer Kimball. Notons que les 2 étudiants abandonneront rapidement GIMP (vers 1998), sans vraiment penser à la relève (je pense qu’ils ne s’attendaient pas à l’engouement que cela créerait), qui fut donc majoritairement développé par la communauté depuis.
D’ailleurs dans un article récemment paru dans El Paìs, second plus gros journal papier d’Espagne et journal en ligne le plus lu en langue espagnole, les 2 compères (maintenant beaux-frères) expliquent encore régulièrement utiliser GIMP même s’ils pensent qu’il n’y a probablement plus aucune ligne d’eux dedans de nos jours.
Je ne donne pas ce lien vers cet article au hasard, car il sort des centaines d’articles sur GIMP tous les ans, mais pour celui-ci (sorti il y a quelques jours), la journaliste nous a contactés (équipe actuelle de GIMP) ainsi que vraisemblablement les 2 auteurs originaux, et pour une fois on y trouve un vrai travail de synthèse journalistique (et pas juste du copier-coller de nos propres annonces). C’est appréciable de voir que le vrai journalisme 📰 existe encore! 🙂
Même s’il n’est pas en français, je conseille donc de lire cet article, car il donne un historique avec une vue et des données propres (si vous ne parlez pas espagnol, les traducteurs automatiques sont très performants de nos jours).
Dans les autres petites perles sur les auteurs originels, j’ai aimé cette question finale à Spencer Kimball (à 57:03) dans une interview vidéo récente au sujet de son projet professionnel actuel (une base de donnée distribuée, donc peu de rapport avec du graphisme; apparemment cockroachdb est était libre, les fondamentaux restent se perdent ! NdM: édition du 8 février 2021 en fait CockroachDB est passé en juin 2019 d'une licence libre APLv2 à la licence non-libre Business Source License (BSL), cf Why We're Relicensing CockroachDB). Je n’ai pas écouté l’interview complète, mais je me suis demandé ce que ce dernier considère en effet comme ce dont il est le plus fier. Ça ne manque pas : à la question sur ce dont il est le plus fier dans sa carrière, GIMP reste (et restera peut-être à jamais?) sa plus grande fierté:
GIMP reste stable en favori. Ce n’est même pas que je suis si fier de ce que j’y ai fait. C’est le projet dans son ensemble. Ça fait 27 (sic — note de Jehan: avaient-ils commencé à coder 2 ans avant la première sortie de code ? Pas impossible !) ans. À chaque fois que je le télécharge, ou que j’ai un nouvel ordinateur, il est meilleur que la fois précédente. Il y a constamment des gens que je n’ai jamais rencontrés qui continuent à travailler dessus. Donc je suppose qu’être à l’origine de cela, en tant qu’auteur originel, c’est quelque chose qui me rend fier. Je pense que si ça avait été l’unique chose que j’avais faite dans ma vie, ça aurait été suffisant. Donc : GIMP.
Traduction personnelle d’après l'original:
The GIMP remains a steady favorite to me. It's not even that I'm so proud of what I did on the GIMP. It's the larger project. It's been 27 (sic) years. Every time I download it, I get a new computer, it's better than the last time I downloaded it. There is always people out there I've never met that are working on it. So I guess, being behind them, as the original author, it is something that does make me quite proud and I feel like… if that's all I did in this life, that would be enough. So euh… GIMP.
Merci donc à ces derniers d’avoir démarré ce projet, même si c’était juste pour s’amuser en tant qu’étudiants !
Quoi qu’il en soit, nous y sommes, 25 ans après, des centaines de contributeurs plus tard, du code à foison et des millions d’utilisateurs dans le monde. C’est en effet assez ébouriffant quand on y pense. C’est aussi l’un des rares logiciels de cette envergure qui est resté entièrement communautaire notamment dans son système de développement et de décision (un fait peu connu, je pense, et pourtant l’une des caractéristiques que j’adore chez GIMP et que j’espère qu’on pourra protéger aussi longtemps que possible).
Un logiciel qui fait avancer tout le monde
Ce que j’ai toujours adoré avec GIMP, c’est aussi à quel point ce logiciel a eu un impact positif sur le logiciel libre. Pendant ces 25 ans, que s’est-il donc passé autour de GIMP ?
Le projet a créé la librairie graphique GTK (GIMP Toolkit), laquelle a donné naissance à plusieurs environnements de bureau (tels que GNOME, XFCE et d’autres) et des logiciels à ne plus pouvoir les compter. Cette bibliothèque est même possiblement la raison pour laquelle Qt est finalement devenu libre à son tour (on rappelle que Qt était propriétaire à ses débuts et c’est la raison pour laquelle des développeurs ont initialement extrait GTK du code de GIMP, le renommant au passage GTK+ avant de récemment revenir aux sources en l'appelant à nouveau GTK), afin de ne pas perdre la clientèle de tous les développeurs de logiciels libres, bien que cette supposition restera probablement à jamais spéculation (les décisions réelles d’entreprises étant rarement publiques).
Puis quelques développeurs du milieu de l’industrie du cinéma hollywoodien ont commencé à travailler sur un nouveau moteur graphique, GEGL. 20 ans plus tard, GIMP l’utilise pour ses traitements de pixel principaux et nous continuons à faire évoluer cette machinerie qui s’améliore au fil des jours. Divers autres logiciels utilisent désormais GEGL pour leurs propres traitements graphiques.
GIMP est aussi tellement complet qu’on améliore constamment l’écosystème autour de nous. Par exemple si on regarde mes contributions hors GIMP, on constate ainsi des patchs dans des dizaines de briques importantes du Logiciel Libre, et ce sans compter les centaines de rapports de bugs et aides au diagnostic de bug qui ont aussi abouti à des corrections ou améliorations. La même chose peut se vérifier d’autres développeurs de GIMP (comme notre mainteneur adoré, Mitch).
En outre GIMP est utilisé assez massivement dans les milieux universitaires, des équipes de recherche en traitement d’images notamment. Par exemple l’équipe CNRS du logiciel G'MIC, avec laquelle j’ai travaillé en 2019, a initialement fait un plug-in pour GIMP, faisant de G'MIC une référence en collection de filtres. Je ne pense pas que David Tschumperlé qui lit aussi LinuxFr.org me contredira si je dis que GIMP a aidé à propulser G'MIC.
Nous avons régulièrement des retours d’autres universités qui ont utilisé GIMP dans des ateliers, des formations, parfois dans des projets de design logiciels, d’utilisabilité (plusieurs par le passé, notamment on se souvient de projet dans des universités belge et allemande au moins) ou de graphisme. Par exemple, ces dernières années, une université indienne (KBC North Maharashtra University) a travaillé sur la traduction complète de GIMP en marathi et a organisé des ateliers et une formation autour de GIMP (apparemment certains cours autour de l’usage de GIMP, et d’autres cours sur la localisation logicielle avec des linguistes marathi). Et pour quelques-uns de ces projets dont on a vent, combien d’autres projets dont on a jamais entendu parler ?!
On a même eu parfois des retours de gens de la NASA qui nous disent utiliser GIMP !
Notre logiciel est donc une aide pour tous ces organismes publics ! 🥴
Dans les divers autres sujets trollifères autour de GIMP, notre mascotte de toujours, Wilber, fait aussi régulièrement parler d’elle. Nous rappelons alors aux gens que GIMP est communautaire, que nous aimons bien les personnages marrants et que cela n’est pas antithétique avec le travail de qualité, ni même professionnel. Non nous ne changerons pas pour une interface aseptisée pour faire bien dans les réunions entre managers! 🧑💼🤪
On appréciera aussi que GIMP co-crée en 2006 le Libre Graphics Meeting en extension de ses propres réunions de développeurs annuels pendant ces années-là. En effet les développeurs de l’époque se disent que le graphisme libre devrait rassembler les gens des divers projets et autour plutôt que créer des divisions. Depuis le projet GIMP a participé à chacune des réunions (Aryeom et moi-même n’en avons manqué personnellement aucune depuis 2013, lors de notre entrée dans l’équipe de GIMP), a même co-financé la réunion à de nombreuses reprises (notamment lors des périodes difficiles) et a aidé financièrement divers contributeurs d’autres projets à s’y rendre (notamment ces dernières années, de mémoire, des gens des équipes de MyPaint, darktable, Kdenlive, GTK…). Notre but est encore et toujours d’améliorer l’écosystème du libre dans sa globalité, notamment dans le graphisme et l’audiovisuel.
Toutes ces choses sont des anecdotes que j’apprécie particulièrement dans l’histoire de GIMP (même si je n’ai participé moi-même qu’à une portion de ces faits). J’aime ce côté communautaire et altruiste de GIMP. C’est pour moi exactement l’aspect qui m’attire et pour lequel je m’accroche au logiciel libre (pas tous les projets sont ainsi, loin de là). Ce projet nous a vraiment permis de découvrir un monde particulier duquel nous sommes heureux de faire partie. 💌
Apports de ZeMarmot
Le projet ZeMarmot, que j’ai cofondé avec Aryeom, et qui fut rattaché à l’association LILA, eut bien sûr son impact puisque nous avons commencé à améliorer GIMP sur la base d’un usage réel au quotidien. Notamment, non seulement les fonctionnalités et une meilleure expérience de création nous motivait, mais aussi et toujours la stabilité du logiciel. Lorsque nous avons découvert GIMP en 2012 (on connaissait tous deux déjà de nom, mais pas “réellement”), je n’aurais pas pu conseiller à quelqu’un d’y passer professionnellement (je me rappelle encore de mes premières tentatives avec Aryeom, je pense qu’il nous a fallu 15 minutes pour faire marcher la tablette graphique et 5 minutes pour faire planter GIMP). De nos jours, après le travail accompli, on peut.
D’ailleurs en parallèle, nous avons aussi participé à quelques projets professionnels tiers, uniquement associatifs et pour des causes que nous apprécions (nous ne voulons pas travailler pour des grosses entreprises dont nous n’aimons pas l’impact sur le monde). Par exemple, nous avons fait 2 projets internes pour l’association des Petits Frères des Pauvres (un petit film institutionnel et un jeu de société pour la formation des bénévoles), nous avons aussi entièrement produit la vidéo "What is Peertube?" pour Framasoft, vidéo toujours à ce jour la plus vue et “plussée” de l’instance Peertube de Framasoft, ce qui est assez méta ! D’autres associations nous ont contacté, notamment une association écologique, bien que nous essayons de limiter les projets secondaires pour nous focaliser sur ZeMarmot (mais ce n’est pas toujours évident de refuser tant que ZeMarmot n’est pas viable). Quand je dis nous pour beaucoup de ces projets, j’entends bien sûr surtout Aryeom (elle est alors celle qui fait le gros du travail !). Moi je fais le soutien technique !
En plus de cela, depuis maintenant 3 ans d’affilée, Aryeom donne des cours universitaires avec GIMP pour 2 classes de licences professionnelles (troisième année de licence), dans l’université de Cergy-Pontoise: une classe de retouche d’images pour la licence « Patrimoine et modélisation 3D » et une classe d’illustration numérique pour la licence “Infographie”. Le responsable de licence est très content, d’année en année, prouvant la place incontestable de GIMP dans le monde professionnel (sans compter que nous entendons régulièrement que d’autres universités, entreprises ou organismes publics dans le monde font un usage très courant de GIMP, comme je disais plus haut).
Tous les contacts professionnels nous ont toujours rappelé et ont été contents des résultats. Il nous semble évident que le logiciel libre en général, et GIMP en particulier, est utilisable dans le milieu professionnel et nous le prouvons au quotidien.
Financer le développement de GIMP
Pour conclure, nous vous rappelons que vous pouvez donner au projet et financer personnellement plusieurs développeurs GIMP qui rendent tout cela possible. C’est aussi une façon de renvoyer l’ascenseur et accélérer le développement de GIMP si vous appréciez le projet. Cette page propose 3 manières de donner: le projet ZeMarmot (dont je parle dans le prochain paragraphe en détail), le financement de Øyvind Kolås, le mainteneur de GEGL (notre moteur graphique) et la donation au projet (qui ne peut servir que pour du financement communautaire, donc pour des financements de déplacements aux réunions ou pour du matériel de bénévole typiquement). Seuls les financements d’Øyvind et de ZeMarmot permettent de rémunérer du développement pour GIMP à ce jour.
Pour parler en particulier du financement du projet ZeMarmot dont je fais partie (Liberapay, Patreon, Tipeee ou donations directes à l’association LILA), nous sommes donc responsables d’une grande partie des évolutions de GIMP ces dernières années (je suis d’ailleurs le contributeur le plus actif sur les 2 dernières années, avec plus de 1000 commits rien qu’en 2019 et 2020, et rien qu’en comptant le dépôt principal de GIMP ; et ce sans compter non plus les très nombreux retours d’Aryeom qui font bouger les choses aussi d’une autre manière, moins visible et moins chiffrable). Or notre projet cherche encore et toujours une stabilité financière (surtout après cette année difficile et un licenciement pour raisons économiques de mon précédent emploi !). Cela nous oblige d’ailleurs régulièrement à accepter d’autres emplois (développement pour moi et/ou films ou projets graphiques tiers pour Aryeom, comme j’expliquais plus haut) qui repoussent le développement libre et le projet de film libre d’autant. Imaginez la vitesse à laquelle on pourrait faire avancer les choses, si on pouvait travailler sur GIMP et ZeMarmot à temps plein ?! 😻
C’est pourquoi nous appelons encore à la participation au financement de notre projet ZeMarmot. Mon petit pitch habituel est de considérer cela comme un investissement pour un meilleur monde logiciel (GIMP et logiciel libre !) et audiovisuel (des œuvres audiovisuelles libres !). Donc en espérant que ces raisons vous interpellent aussi… aiderez-vous ZeMarmot et GIMP en cette fin d’année 2020 ? 👍
🥳 Sur cette conclusion, nous vous souhaitons un très bon noël, malgré la situation sanitaire particulière ainsi qu’une année 2021 meilleure que 2020 ! 🎉
Aller plus loin
- Annonce de sortie de GIMP 2.99.2 (84 clics)
- Annonce des 25 ans de GIMP (17 clics)
- Page de donation de GIMP (14 clics)
- Projet ZeMarmot (dont fait partie l’auteur de l’article, développeur majeur de GIMP) (53 clics)
- Dépôt de sources et suivi de bugs (20 clics)
- Dépêche précédente sur LinuxFr (GIMP 2.10.22) (14 clics)
# Chouette dépêche
Posté par Julien Jorge (site web personnel) . Évalué à 10.
Merci pour cette excellente dépêche, merci en particulier à Jehan car c'est toujours un plaisir d'avoir des nouvelles aussi détaillées de GIMP.
À titre personnel j'apprécie en particulier le côté « juste libre » de ce que vous faite avec LILA. On parle régulièrement ici de licences NC et ND, et que « oui c'est de l'art c'est pas pareil que du code ». De votre côté vous faite de l'art et du code, tout est en BY-SA, c'est juste simple. Bravo à vous.
Une petite question technique pour finir : maintenant que la migration vers GTK 3 est terminée, entamez vous la migration vers GTK 4 qui vient de sortir ?
[^] # Re: Chouette dépêche
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Merci!
Elle n'est pas tout à fait terminé. J'ai des cauchemars (c'est pas vrai, c'est juste pour l'image!) rien qu'à l'idée qu'on va devoir passer tout notre code de
GtkActionàGAction(ce n'est pas juste un renommage, il y a des changements de concepts apparemment, mais j'ai pas regardé dans le détail). C'est notre dernier gros chantier pour pouvoir dire que la migration est vraiment finie.C'est pas prévu, mais on ne refuse pas les contributions. Si quelqu'un veut progressivement faire cette migration (dans une branche ou directement dans la branche principale sans casser le code GTK+3), on prendra les patchs.
De manière générale, suivre le toolkit est nécessaire, mais c'est aussi fort peu productif. C'est parfois un peu se battre contre un moulin. Énormément de travail mais pas forcément un résultat à la hauteur du travail.
Donc personnellement je suis pas pressé. Mais rien n'est impossible et on y passera bien un jour… 🙂
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Chouette dépêche
Posté par swilmet . Évalué à 10.
GtkAction (et GtkUIManager) fonctionnent encore en GTK 3, mais ces APIs sont obsolètes. Ça a été rendu obsolète dans GTK 3.10. Pour migrer à GTK 3, pas mal d'applis GNOME sont d'abord passées par GTK 3.0, puis 3.2, etc. Ce n'est que quelques années plus tard que ces applis sont passées aux "headerbar" (au lieu d'une barre de menu et une barre d'outils classique), avec le passage à GAction, GMenu, etc.
Donc, grosso modo, faut pas se sentir obligé de tout passer à GAction pour pouvoir sortir une version stable de GIMP 3. Ça peut être fait pour une version mineure suivante.
Dans tous les cas, j'ai développé une petite bibliothèque appelée Amtk:
Je l'utilise notamment pour migrer GNOME LaTeX progressivement vers GAction (dans cette appli il y a encore un mix de GAction et GtkAction, et de GtkUIManager et Amtk). Bref on peut faire la migration à son aise.
À noter que dans GTK 4, GtkMenu a disparu, c'est GMenu qu'il faut utiliser, ce qui je pense réduit ce qu'il est possible de faire avec (faudrait que je regarde ça plus en détails).
[^] # Re: Chouette dépêche
Posté par Jehan (site web personnel, Mastodon) . Évalué à 9.
Je pense qu'on est tous un peu des perfectionnistes. C'est pas pour dire que c'est impossible que ce que tu proposes soit au final ce qu'on fera, mais franchement voir ces centaines de build warnings à l'heure actuelle (à 90% ou plus autour de code GtkAction, GtkUIManager et consorts, et les autres types de warnings sont tellement noyés au milieu qu'on les voit pas trop et qu'y en a plein des faciles qu'on corrige pas à cause de ça), ça me dérange beaucoup.
Ensuite, chez GIMP, on est super attaché à limiter de casser la compatibilité si possible. Or comme il me semble que la façon dont les actions sont gérées maintenant risque de changer certaines choses, si vraiment le cas, on aimerait éviter de le faire dans une version mineure. En plus vraiment énormément de choses tourne autour des actions dans GIMP.
Pour info, on aime beaucoup la headerbar pour plein de choses et de dialogues, mais on ne prévoit pas de virer le menu principal. GIMP est une application complexe avec énormément de fonctionnalités qui doivent être trouvables et utilisables le plus simplement possible. C'est un logiciel utilisé professionnellement par des millions de gens (dont beaucoup gagnent leur vie au quotidien avec), pas une "app" de téléphone avec 3 filtres pour se mettre des oreilles de lapin. 😃
Donc on a besoin d'un menu accessible.
Par contre, on est possiblement ok pour une headerbar avec un menu normal dedans (pas le "hamburger"). J'ai vu ce concept sur quelques images et ça a l'air sympa. À voir cependant car ça risque de ne plus laisser la place pour le titre avec le nom de l'image active et plein d'info super utile (on utilise ça souvent, ça permet de voir des infos techniques sur son image d'un coup d'œil). À voir/tester.
Ok. On regardera ça aussi à un moment donné évidemment. On aime plein d'évolution dans GTK, mais parfois pour certaines évolutions, on en vient à se demander si on est la seule vraie grosse application complexe par rapport à certains choix. J'espère que c'est pas un de ces choix. 😕
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Chouette dépêche
Posté par gouttegd (site web personnel) . Évalué à 10.
Intéressante remarque, à mettre en relation avec ces propos de Matthias Clasen (développeur GTK) en 2013 selon lesquels GTK n’est explicitement pas conçu pour les « grosses applications comme Gimp ou Inkscape » :
(ce que je trouve assez ironique compte tenu de l’origine de GTK, mais il est évident que les projets évoluent et que le G de GTK ne signifie plus Gimp depuis longtemps.)
[^] # Re: Chouette dépêche
Posté par swilmet . Évalué à 7.
C'est en supposant que les grosses applis ont les moyens de créer des custom widgets pour les trucs qui manquent dans GTK.
Mais ce n'est pas seulement pour les grosses applis, les applis préférant garder une GUI traditionnelle ont de plus en plus de mal à le faire avec les dernières versions de GTK.
Ceci dit, en regardant dans gtk4-demo et en cherchant "menu", il y a plusieurs exemples qui montrent une barre de menu avec GtkPopoverMenuBar : c'est une barre de menu comme avec GTK 3 (plus ou moins), sauf que le style est différent et c'est implémenté avec des "popover". Mais il n'y a apparemment pas de signal émis quand un item de menu est sélectionné/quand la souris passe dessus (ce qui, en GTK 3 ou GTK 2, permet d'afficher des infos en plus, comme le fait GIMP).
Et, je pense que même en GTK 4, Amtk serait utile (si la bibliothèque était portée à GTK 4), notamment pour ne pas dupliquer les informations pour créer les items du menu et les items de la barre d'outils.
[^] # Re: Chouette dépêche
Posté par ff9097 . Évalué à 5.
Il y a quelques années, la migration Gtk vers Qt de subsurface avait fait beaucoup de bruit. Le mainteneur principal avait tenu une conférence à ce sujet où il avait notamment constaté que GTK était développé dans les faits uniquement pour Gnome. Ça a peut être changé depuis mais ce que je lis au dessus ne m'étonne donc pas.
# Efficacité du travail communautaire
Posté par Glandos . Évalué à 7.
Je constate ça sur plein de projets libres : ça avance souvent vachement mieux qu'un produit poussé par une seule entreprise privée. Combien de logiciels grandement utilisé ont été codés sur temps libre, ou en tout cas bénévolement, et ont « rapporté » des millions ?
C'est sûr que les concurrents sont plus avancés, mais au prix de quelle efficacité ?
[^] # Soutenir l’œuf et la poule !
Posté par Space_e_man (site web personnel) . Évalué à 8. Dernière modification le 18 janvier 2021 à 12:55.
J’avais déjà publié un journal à ce sujet, Soutenir l’œuf et la poule !
La collaboration ici entre les deux projets, GIMP et ZeMarmot est quand même particulier je trouve. Et personnellement je ne regrette pas de les soutenir financièrement.
J’utilise moi-même GIMP de manière professionnelle. Lorsque j’investis 1000 € dans GIMP, je peux imaginer d’énormes impacte. Quel impacte réel aurait ce même montant investis (d’une manière ou l’autre) "dans le projet" Adobe Photoshop ?
Là où je veux en venir, c’est que le modèle montre son efficacité indéniable. Et que si nous étions encore beaucoup plus nombreux à utiliser GIMP et d’y investir chacun quelque euros, nous rattraperions très vite la concurrence "privée" avec un logiciel du bien commun, qui nous appartient déjà à tous (que nous l’utilisions ou non).
Et en plus nous aurions un très beau dessin animé pour nos enfants à qui nous souhaitons transmettre l’appréciation du bien commun.
# Joyeux anniversaire GIMP !
Posté par Stéphane ESCAICH (site web personnel) . Évalué à 10.
Voilà, je n'ai pas grand chose à ajouter.
C'est juste que j'adore GIMP même si je ne m'en sers pas tous les jours, c'est un compagnon fidèle, un incontournable.
J'aime également beaucoup les dépêches et les journaux de Jehan.
Longue vie à GIMP.
# Pointeur neutre
Posté par csitt . Évalué à 1.
Bientôt la version 3 et toujours pas de pointeur neutre!
Je viens du monde Windows et j'utilisais Paint Shop Pro. Malgré que cela fait quelques années que j'utilise Gimp maintenant, le pointeur neutre me manque toujours encore.
Bonne fêtes à tous !
[^] # Re: Pointeur neutre
Posté par Anonyme . Évalué à 8. Dernière modification le 23 décembre 2020 à 19:19.
qu'est ce qu'un pointeur neutre ?
PS: Merci à Jehan pour toutes ses news sur GIMP toujours aussi agréables à lire et à l'ensemble des développeurs qui ont permis d'aboutir à ce résultat !
[^] # Re: Pointeur neutre
Posté par csitt . Évalué à 1.
Un pointeur neutre est une simple flèche, dans Inkscape par exemple le premier bouton de la barre d'outils.
[^] # Re: Pointeur neutre
Posté par Anonyme . Évalué à 8.
Autant dans inkscape je vois l'intérêt (d'ailleurs, si je ne me trompe pas, ce pointeur n'est pas neutre puisqu'il permet de sélectionner un objet) autant dans GIMP j'ai du mal à en voir l'utilité: j'ai toujours utilisé l'outil déplacement quand je voulais me balader sur un calque sans faire d'action particulière, donc un pointeur vraiment neutre me semblerait redondant.
[^] # Re: Pointeur neutre
Posté par csitt . Évalué à 5.
Pourquoi s'il était redondant, les principaux logiciels (Paint Shop Pro, Photofiltre, Paint.net, Photo Pos Pro, etc.) sauf PhotoShop en seraient-ils équipés ?
Et finalement pourquoi Inkscape en est-il muni ?
Un pointeur neutre permet par exemple d'ouvrir les menus ou de réaliser certaines actions sans risquer de modifier ou déplacer (dans ton cas) quelque chose dans l'image. En fait tu utilises l'outil de déplacement parce que il n'y a pas de pointeur neutre.
Il se trouve que Gimp a pris PhotoShop comme modèle pour se construire et non un autre logiciel, car dans quel cas il en aurait un. Pour moi qui vient de Paint Shop Pro cela constitue une gène qui ne s'est pas estompée avec les années.
Et finalement pourquoi ne pas faire comme la majorité des logiciels et un mettre un ?
Rien n'obligerait les habitués PhotoShop à l'utiliser.
Je suis persuadé que s'il était présent dans la version 3 la chose serait louée par les commentateurs et constituerait un réel plus pour Gimp.
[^] # Re: Pointeur neutre
Posté par Anonyme . Évalué à 5.
Aucune idée, je connais de nom certains de ces logiciels mais ne les utilise pas.
parce qu'il n'est pas réellement neutre comme je l'explique au-dessus.
Contrairement à un logiciel de dessin vectoriel comme inkscape, un logiciel de dessin bitmap comme GIMP n'a pas de risque de déplacer quoi que ce soit si l'outil de sélection n'a pas défini une zone de sélection auparavant.
oui, mais un vrai pointeur neutre ne me servirait pas plus.
Parce que faire comme la majorité n'est pas une garantie de qualité ?
Je ne sais pas quelle est la raison des développeurs pour ne pas intégrer un vrai pointeur neutre, mais il me semble que c'est une question d'ergonomie qui demande à être justifiée autrement que part l'habitude qu'on pourrait avoir d'un autre outil: la maintenance du code qui le gérera implique forcément un coût qui sera assumé par les développeurs, pas par les utilisateurs.
Je n'ai pas ton don de clairvoyance :)
Par contre, comme toi j'imagine, je suis curieux de savoir si la question s'est posée ou pas aux développeurs dans le cas où, comme tu le dis, il s'agit d'un simple copier-coller non rationalisé de l'interface de PhotoShop, et le cas échéant, quels ont été les arguments allant dans un sens ou l'autre ?
[^] # Re: Pointeur neutre
Posté par csitt . Évalué à 2. Dernière modification le 24 décembre 2020 à 13:20.
Merci pour tout ces arguments, que je ne partage pas intégralement, mais j’apprécie largement tes remarques tant elles sont pertinentes.
Idéalement, il faudrait faire un sondage pour savoir si la chose serait bienvenue.
Dernière question : Add-on il en existe un qui le fasse ?
Bonne fêtes à tous
[^] # Re: Pointeur neutre
Posté par barmic 🦦 . Évalué à 5.
Un ticket c'est fait pour ça. Ça permet de connaître l'opinion des développeurs et de garder les discussions pour l'avenir (si dans l'avenir quelqu'un se repose la question, il pourra le retrouver facilement et si les arguments changent ça pourra être fait en connaissance de cause).
Le bug tracker de gimp est ici. Il y a un label featue qui me semble tout indiqué pour ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# GTK4
Posté par Spack . Évalué à 3.
Ça tombe bien, GTK4 est sorti il y a quelques jours.
Bon bien sur, ça n'impacte pas GTK3 qui reste supporté. Mais je suis curieux de connaître les nouveautés qui pourraient intéresser GIMP.
[^] # Re: GTK4
Posté par cosmocat . Évalué à 5.
La réponse dans ce commentaire ?
https://linuxfr.org/news/25-ans-de-gimp-et-version-de-developpement-2-99-2-premiers-pas-vers-gimp-3#comment-1835224
# Gestion des couleurs dans Wayland
Posté par Spack . Évalué à 4.
Il semble que le travail soit en cours concernant la gestion des couleurs dans Wayland. Espérons que cela progresse rapidement.
[^] # Re: Gestion des couleurs dans Wayland
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 24 décembre 2020 à 01:04.
Oui ça commence tout juste à bouger. Ce qui veut tout de même dire que quoi que ce soit qui soit implémenté ne finira pas sur nos bureaux avant plusieurs années (cela devra être implémenté par les bureaux, par FreeDesktop et par tous les logiciels).
Cependant je crois que la direction choisie ne plaît pas à tous, comme en témoigne cette longue discussion sur le forum de Pixls.us: 2 ans de discussion, plus de 500 messages (dont le dernier il y a une semaine). Pour info, Pixls.us est le site de référence pour la photographie avec des logiciels libres, et beaucoup d'utilisateurs mais aussi des développeurs de certains logiciels d'imagerie y traînent (et en ont d'ailleurs fait leur forum officiel, pour plusieurs de ces logiciels). Le créateur de ce site est un contributeur très connu (et super sympa!), notamment de GIMP (dont il a fait le site web et le maintient depuis 2015).
Ensuite je ne suis pas beaucoup (voire presque pas du tout) la conversation et interviens encore moins, et ce exprès. Je n'apprécie absolument pas le comportement plus que limite (sinon malsain) de certains et je ne veux vraiment pas me mêler à ce brassage de vent. Peut-être que les dévs de Wayland font certains mauvais choix, mais je suis un peu triste que les choses se passent sous forme de conflits et d'insultes (voire des quasi-menaces; certains se sont un peu fait calmer par des admins, et ce à raison; c'est d'autant plus triste quand ça vient parfois de développeurs d'autres logiciels libres aussi) plutôt que constructivement. Dans tous les cas, ça casse toute velléité de rentrer dans la discussion malheureusement. Mais bon, on verra comment les choses évolueront.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Haute densité de pixels = HiDPI
Posté par Cyril Chaboisseau . Évalué à 1. Dernière modification le 23 décembre 2020 à 22:07.
…et non HiPPI
D'ailleurs il y a une page très documentée sur la gestion du HiDPI chez ArchLinux
https://wiki.archlinux.org/index.php/HiDPI#Gimp_2.10
[^] # Re: Haute densité de pixels = HiDPI
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Non. C'est une erreur commune:
La notion de "point" (attention, je ne parle pas du point typographique qui est une unité de mesure, je parle vraiment d'un petit point, physiquement; malheureusement — c'est d'autant plus malheureux car ces 2 notions sont utilisés en imprimerie — en français on n'a que le mot "point" pour exprimer les 2 notions alors que l'anglais a "dot" et "point" donc ils font la différence) n'a pas de sens physique dans l'électronique d'un écran. L'unité d'un écran est le pixel.
On parle de "points par pouce" (DPI) quand on parle de la densité de points imprimés par une imprimante par exemple. Dans ce contexte, le point a un sens physique (l'imprimante peut en effet imprimer un certain nombre de points dans une unité de longueur physique donnée). On pourra d'ailleurs découvrir que les points peuvent même avoir des tailles diverses! C'est vraiment pas le concept du pixel.
Et même encore là, je pourrais commencer à vous parler de comment marche une imprimante, des différents types d'imprimantes (donc comment ça peut éventuellement mettre à mal le concept de densité de points) et de tout ce qu'il peut y avoir derrière ce terme qui rend le concept encore un peu moins évident. On pourrait même discuter du concept de LPI (lines per Inch) pour l'impression en halftone, qui est la base du CMYK, et utilisé en impression offset.
D'ailleurs même pour les fichiers RAW que les marketeux aiment aussi qualifier en points (pour eux, tout est point!), il est techniquement malvenu de dire que ce sont des pixels. Ce sont des mesures physiques en grille. Chaque mesure physique est d'ailleurs dans un canal différent (car les capteurs ne sont pas RGB, donc on a certaines mesures en rouge, d'autres en verts, d'autres en bleu, sur des coordonnées différentes) et c'est pour cela qu'on ne peut pas visualiser un fichier RAW (si un logiciel affiche une image RAW, il aura fait des choix et un traitement quelconques pour générer des pixels, vous ne voyez pas le RAW car par définition les mesures n'ont pas un sens encore; d'ailleurs c'est pour cela qu'on peut sortir des images de toute sorte de lumières et couleurs à partir d'un même RAW principalement basé sur son ressenti artistique sans qu'une version soit plus "vraie" que l'autre puisque les mesures contenus dans le RAW n'ont pas encore de sens colorimétrique; une fois que l'image est transformée en matrice de pixels, là il y a un sens colorimétrique et à ce moment seulement, si 2 visualiseurs d'image montrent une image différente, au moins l'un est dans le faux). Dans ces cas là par exemple, il serait plus juste de parler en SPI ("samples per inch" - mesures par pouce). En RAW, ce terme est peu utilisé, mais il l'est beaucoup pour les scanners.
Ensuite soyons clair, on est habitué au fait que plein de gens font l'erreur et je comprends qu'on fasse l'amalgame. D'ailleurs il est tout à fait naturel d'essayer de faire correspondre un "pixel" à un "point" d'impression lorsque la cible de l'œuvre est l'impression. Néanmoins ce n'est absolument pas une obligation technique! C'est donc un gros "néanmoins". Typiquement on peut vouloir imprimer à plus faible densité de points (sans pour autant changer la taille physique) pour diverses raisons (dont économiser un chouille d'encre, ou simplement parce que l'imprimante ne peut monter suffisamment haut, etc.). D'ailleurs quand vous envoyez une image à un imprimeur, chercher à avoir une image exactement à la densité recommandé est une erreur de débutant qui ne comprend pas les concepts de résolution et d'impression. Typiquement on a eu quelqu'un l'autre jour qui voulait absolument envoyer une image à 300PPI car l'imprimeur lui avait dit qu'il fallait 300DPI. Il avait une image à environ 350PPI. Ça n'avait strictement aucun intérêt d'essayer de redimensionner l'image. Pire cela aurait probablement diminué la qualité de l'impression finale sans raison. Il n'est absolument pas nécessaire de faire une correspondance exacte entre les pixels et les points car il n'y a aucune correspondance sémantique ou logique directe entre pixels de l'image ou de l'écran et points d'impression. Éventuellement une correspondance de simplification, mais c'est tout.
Ce type d'anecdote montre aussi bien que comprendre un minimum la technique et le sens des mots est importants, sinon on se met juste à répéter des termes qu'on ne comprend pas, comme des perroquets. Et forcément on ne peut pas les comprendre car ils ne veulent plus rien dire hors contexte (pourquoi on parle de pixel en numérique? De point en imprimerie? De lignes en offset? Tous ces termes ont un sens et une origine physiques et sont donc logiques; si on les intervertit, on ne peut que s'embrouiller). C'est assez triste de voir même des auteurs de livres ou des profs qui ne comprennent pas de quoi ils parlent sortent des âneries. Puis tant de gens vont juste répéter ces mêmes trucs toute leur vie ou carrière (car même pas mal de pros ne cherchent pas à comprendre). Rien n'est plus triste quand on a un pro qui cherche absolument à mettre une image à 72DPI pour le web, ce qui… n'a juste aucun sens. Mettre une densité pour une image qui n'est faite que pour être vue sur un écran n'a absolument aucun sens. Pour une image faite pour le web, il faut uniquement raisonner en dimensions en pixels. C'est la seule chose qui importe! Mettre 72DPI ou 300DPI ou 10000DPI dans les métadonnées… ne change absolument rien. Niet. Que dalle. Ce mythe a été initialement propagé par Apple dans les années 80, quand ils ont fait des écrans à 72PPI et ont essayé de les faire correspondre à la densité de leurs imprimantes. Franchement un truc totalement ridicule. Ce chiffre est juste resté et pour une raison incompréhensible, les gens ont décidé qu'une photo devait avoir cette densité de pixel (info qui n'est simplement jamais utilisé de nos jours).
Et donc pour conclure, quand on parle de haute densité de pixels à l'écran, on parle donc bien de HiPPI. Le fait que les marketeux qui n'y comprennent pas grand chose se soient emparés des mauvais termes (qui sont alors devenus une sorte de standard pour l'achat) n'est pas la première et ne sera pas la dernière fois. Et de mon côté, ça ne m'empêchera pas d'utiliser les bons termes. 😛
Ensuite j'en fais pas une maladie et si on me dit "DPI" pour parler de densité de pixels, c'est pas moi qui vais reprendre (là j'explique mais c'est particulier car tu m'interpelles sur le sujet, alors… faut bien expliquer!) car je comprends ce que cette personne veut dire. J'ai mieux à faire. Mais j'utilise le terme approprié quand j'écris sur le sujet. Et quiconque s'intéresse un peu à la technique sait qu'utiliser DPI hors imprimerie (par exemple pour qualifier la densité en pixel d'un écran) n'a juste aucun sens.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Haute densité de pixels = HiDPI
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 7.
Wow, merci pour ces précisions, je n'avais jamais réfléchi à ces notions et là ça me paraît beaucoup plus claire !
Je pense d'ailleurs que je fais parti de ces utilisateurs qui ne comprennent pas tout 😅
Je comprends mieux pourquoi il y a un menu pour la taille de l'impression qui ne change rien à la visualisation de l'image sur l'écran, c'est tellement logique maintenant 😂 En plus, je pouvais ne voir aucune différence, même à l'impression si mon imprimante n'a pas un DPI assez élevé.
Ça serait peut être un bon endroit où on pourrait placer une petite aide à l'utilisateur pour l'éduquer un peu.
[^] # Re: Haute densité de pixels = HiDPI
Posté par Dimitri Robert (site web personnel, Mastodon) . Évalué à 3.
Merci Jehan, cette explication est juste parfaite !
Ça me rassure, ça colle à ce que j'enseigne dans la partie théorique de mes formations (hormis sur le RAW, là tu m'apprends des trucs, car je ne pratique pas).
# Gris
Posté par Guillaume Maillard (site web personnel) . Évalué à 4.
Oulala, les gris de l'interface ne sont plus vraiment gris et vont fausser l'affinage colorimétrique des millions d'images :)
Je plaisante bien sur! (faut avoir suivi les autres dépêches pour comprendre…)
Le passage à GTK3 est une belle avancée et le changelog bien costaud.
# Support rust
Posté par benjai . Évalué à -5.
Le support de rust pour les greffons offrirait de la robustesse avec de belles performances.
[^] # Re: Support rust
Posté par claudex . Évalué à 7.
Il y a une interface en C et Rust s'intègre bien avec une interface en C, je ne vois pas bien ce qu'il pourrait y avoir de plus pour supporter des greffons Rust.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Support rust
Posté par xcomcmdr . Évalué à 2.
| de la robustesse
Du coup éviter de devoir utiliser
unsafe, éviter de devoir générer des bindings ?C'est comme utiliser des FFI dans tout langage. Oui c'est possible, mais ça s'intègre mal à la philosophie et au système de types du langage et ça te fait perdre mine de rien pas mal de temps.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Support rust
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Théoriquement c'est déjà possible car notre système de binding utilise GObject Introspection et il y a déjà un système de binding pour Rust. D'ailleurs quelqu'un avait déjà essayé de le faire (c'est aussi celui qui a fait le binding Vala). Je crois qu'il a mis le sujet en pause et ne sais pas s'il compte relancer ce projet.
Dans tous les cas, ce serait bien un binding qui permet d'écrire en Rust mais qui appelerait la
libgimpen C derrière. Vraisemblablement exactement ce que les dévs de Rust appellent du codeunsafe. Et ça, ça changera pas, sauf si on se mettait à avoir un développeur de longue durée qui décidaient d'entièrement réimplémenter lalibgimpen rust et surtout de la maintenir (pas de nous lâcher le code et byebye).Ce serait un boulot bien plus énorme que nos bindings à l'ancienne (qui sont eux même bien plus de travail que les nouveaux bindings grâce à GObject Introspection). Or on l'a vu avec ces anciens bindings. Ils finissent peu (voire pas du tout) maintenus avec le temps, remplis de bugs, avec une logique propre (donc problèmes de cohérence) et avec énormément de fonctionnalités manquantes.
Perso je conseillerais donc à ceux qui veulent un libgimp rust de faire un binding GObject Introspection et d'accepter le
unsafe. Au moins ils auraient un binding facile à maintenir, qui a toutes les fonctionnalités et les corrections de bugs à apporter profiteraient à tous, quelque soit son langage de prédilection. 🙂Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Support rust
Posté par barmic 🦦 . Évalué à 10.
C'est un bot qui génére ces commentaires sur rust ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# 16 bits & EXIF
Posté par harlock974 . Évalué à 1.
Merci Jehan pour cette dépêche, et félicitation pour ce beau travail.
J'utilise Gimp tous les jours, et c'est l'un de mes logiciels préféré. Je ne suis pas au courant des toutes dernières évolutions, puisque j'utilise les versions de distro, qui ont toujours un train de retard, mais il y a deux points qui étaient critiqués par les photographes (enfin, ceux qui se prennent pour des pros et ne jurent que par un logiciel propriétaire très cher dont j'ai oublié le nom) :
Est-ce que ces points ont été étudiés ?
[^] # Re: 16 bits & EXIF
Posté par barmic 🦦 . Évalué à 6.
Je sais pas si 16 bits ça sert à rien mais depuis gimp 2.10 et l'intégration de GEGL il est possible de travailler en 16 ou en 32 bits (GIMP 2.10 roule au GEGL > Haute précision des couleurs). Je crois que gimp a mis du temps à y passer non pas parce que ça n'a pas d'intérêt mais parce qu'ils voulaient le faire via GEGL.
Pour l'exif je ne sais pas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: 16 bits & EXIF
Posté par harlock974 . Évalué à -4.
Pourtant avec Gimp 2.8, quand j'importe un fichier Tiff 16 bits, ça me dit que ce n'est pas pris en charge et que l'image sera convertie en 8 bits.
[^] # Re: 16 bits & EXIF
Posté par Mika Cousin (site web personnel) . Évalué à 3.
2.10 > 2.8 ;-)
[^] # Re: 16 bits & EXIF
Posté par gouttegd (site web personnel) . Évalué à 3.
Ben oui, puisque ça n’a été pris en charge qu’à partir de Gimp 2.10…
[^] # Re: 16 bits & EXIF
Posté par harlock974 . Évalué à 4.
Heu oui pardon j'ai eu une vision arithmétique décimale du numéro de version :)
(auquel cas 2.8 > 2.10)
[^] # Re: 16 bits & EXIF
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 26 décembre 2020 à 09:17.
Sommaire
Comme dit dans d'autres réponses, ces 2 fonctionnalités existent depuis 2.10.0, c'est à dire mi-2018.
En fait il y avait déjà un (mauvais) support des métadonnées dans la série 2.8. On l'a amélioré avec la 2.10.0, où c'est devenu bien mieux (notamment au moins le passage d'import à export vraiment sans perte — du moins je pense/espère) mais pas encore parfait. Ces derniers mois cependant, on a enfin un contributeur qui a pris sur lui pour travailler certains aspects, et comme je travaille en parallèle sur l'amélioration et surtout l'automatisation/généralisation de certains aspects des plug-ins, je travaille avec lui pour améliorer la prise en charge générique de certaines méta-données. Donc ça devrait aller de mieux en mieux au fil des versions.
Je suppose que tu veux dire "16 bits par canal de couleur". Et oui cela existe aussi depuis 2.10.0. On peut même monter à 32-bit par canal.
Par contre non, ça ne sert pas à rien.
Déjà pour l'œil humain, 8-bit n'est pas assez. Selon les recherches, certains estiment entre 10 à 12-bit par canal ce qui est nécessaire pour vraiment avoir une précision suffisante pour l'œil humain (attention, je ne parle pas d'avoir une gamme suffisante pour l'ensemble des couleurs visibles par l'œil, mais d'une gamme suffisante pour que si on rajoutait une couleur entre 2 couleurs adjacentes des gammes habituelles, l'œil humain moyen n'y verrait pas de différence). Ensuite même cela, on peut se dire que c'est inutile car nos écrans sont encore en général en 8-bit (et faire un setup d'écran 10-bit est encore très complexe, car il faut tout le pipeline, de la carte graphique à l'écran, en passant par câbles, OS et logiciels compatibles; ce qui fait que même la plupart des gens qui ont un écran 10-bit l'utilisent en fait en 8-bit sans le savoir). Mais ce n'est pas cela la vraie utilité du > 8-bit à l'heure actuelle.
La plus importante utilité à ce jour est donc comme format de travail. Je vais expliquer (mon explication habituelle qu'on donne aux étudiants). L'imagerie numérique, c'est simplement des maths. Tout filtre, toute transformation, au final c'est juste des additions, soustractions, multiplications, division. Supposons donc 2 couleurs différentes, l'une avec la valeur 3 et l'autre la valeur 2 (avec un stockage des valeurs en entier seulement). Bien que très proche par définition, on voit une subtile différence entre ces 2 couleurs. Maintenant on fait une première opération quelconque qui divise la couleur par 2:
Donc nos 2 couleurs différentes sont maintenant la même! Et pour enfoncer le clou, supposons même une seconde opération où on multiplie par 2:
Là c'est même pire que tout, on a carrêment deux opérations qui auraient dû s'annuler mais qui à la place ont juste fait perdre des couleurs. Ça veut notamment dire que tous les
3de l'image ont d'ailleurs disparu (en fait tous les nombres impairs dans cet exemple), on a vraiment perdu en précision! Et c'est exactement à cause de ce type de problématique qu'on crée du "banding", typiquement plusieurs couleurs proches qui sont devenus la même (typique dans des ciels ou autres dégradés de couleur, naturels ou non).Donc dans certains cas, les bandes de couleurs, c'est bien car 8-bit n'est pas assez et donc on est limité dans le format, mais dans pas mal d'autres cas, même malgré le 8-bit final on aurait pu éviter les bandes de couleurs, mais ces dernières ont été créée par le fait d'avoir travaillé avec un manque de précision.
Ce problème aurait pu être évité même avec simplement le double de précision de travail (9-bit). En effet, dans ce cas, notre valeur 2 aurait été 4 et notre valeur 3 aurait été 6. Donc:
-> Nos deux valeurs sont restées différentes après calculs! Par contre on voit bien qu'on se retrouve dans la situation précédente. Cela signifie bien que si on avait encore divisé par 2, on aurait à nouveau perdu des couleurs. Cela signifie que plus on fait de calculs, plus on risque de perdre en précision! C'est pour cela qu'une haute précision n'est jamais inutile. Plus on prévoit de faire de traitement d'image, plus avoir une autre précision est utile.
Cela n'empêche pas de revenir à 8-bit en toute dernière opération, pour l'export et le fichier partagé au monde (notamment si pour le web, etc.). Il y aura de la perte à ce moment là, mais bien moins de perte que si on avait travaillé en haute précision de couleur. Démontrons le avec le cas d'une division par 4 suivi d'une multiplication par 4 en 8-bit et en 9-bit (multiplication de toutes les valeurs par 2). Notre image a des pixels à 4, 5, 6, et 7 en valeurs. L'original est en 8-bit.
Cas du format de travail aussi en 8-bit
Les 4 couleurs sont devenues la même après le traitement! Grosse perte de qualité!
Cas du format de travail en 9-bit
D'abord transformons nos valeurs dans le format de travail 9-bit:
Maintenant faisons notre traitement:
Maintenant revenons en 8-bit:
Et voilà, on a encore créé un peu perdu en qualité, mais beaucoup moins (on se retrouve avec 2 couleurs différentes au lieu de 4, mais mieux que 1 qui était le cas du travail en 8-bit). Remarquons que si on avait travaillé en 10-bit, on n'aurait perdu aucune couleur! Et encore là c'était des exemples très simples.
Et c'est donc bien pour cela que la haute précision des couleurs est importante, au moins en format de travail. Notons bien qu'on ne demande pas aux gens de savoir les maths exactes de chaque opération, transformation ou filtre. Par contre il faut être conscient qu'au final, on manipule des nombres et donc que toutes ces opérations ne sont rien d'autres que des maths appliquées. Être conscient de ce genre de détails fait partie des nombreux points qui peuvent faire la différence pour être un bon artiste, photographe, retoucheur d'image, etc.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: 16 bits & EXIF
Posté par harlock974 . Évalué à 4.
Superbe explication Jehan, merci beaucoup !
[^] # Re: 16 bits & EXIF
Posté par barmic 🦦 . Évalué à 3.
Juste au cas où pour améliorer ton explication, cette transformation m'a fait tiquer au premier abord. 2 reste 2 en 8, 9, 16, 32 ou 1 millions de bits normalement. Ici les valeurs sont réparties. On pars d'une plage de [0; 256[ et on arrive à [0;512[ on multiplie par 2 pour laisser un espace entre les couleurs. Comme tu le montre il faut retraduire toutes les opérations pour ce format. J'imagine que c'est pour ça qu'avec GEGL vous travaillez exclusivement en 32bits si j'ai bien compris. Comme ça les opérations n'ont pas à être implémentée pour tous les encodages possibles de couleur.
J'ai l'impression que cet exemple montre surtout qu'il faudrait n'appliquer les opérations qu'au moment de l'export et utiliser une résolution des opérations "intelligente". C'est j'imagine très compliqué car les pixels ne sont souvent calculé en groupe. Donc chaque pixel devient non plus 3 valeurs, mais un système de 3 opérations qui sont perpétuellement recalculés pour l'affichage. Ça rend caduque toutes les formes d'optimisations classiques à coup de SIMD par exemple.
Par contre ça me pose une dernière question. Utiliser le codage 9bits que tu décris n'est pas exempte de problème. Si je reprend tes opérations, mais dans l'ordre inverse (et avec d'autres valeurs), sur 8 bits :
Sur 16 bits :
128 en 9bits donc 64bits en 8bits. Ici ce n'est même plus une perte de précision ça a annihilé la moitié de la plage de couleur. Pour gérer ce genre de cas de manière total il faudrait que les entiers soient représentés en taille arbitraire (ou à minima que ce soit le cas lorsque l'on détecte un overflow), mais ça casse encore toute optimisation… Pou mitiger un peu ces problèmes est-ce que la représentation 32bits utilise toute la plage ou est-ce que ça n'utilise pas qu'une partie ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: 16 bits & EXIF
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
En colorimétrie RGB, y a effectivement un min et un max car c'est un espace de couleur relatif (tout comme CMYK). Le min et le max restent le min et le max. Donc effectivement si ta plage change, tu dois simplement mettre à l'échelle tous les nombres. Les nombres en soit n'ont aucun sens colorimétrique. 2 ne veut rien dire. La couleur rouge (ou bleue ou verte) '2', ça n'existe pas. Cette valeur n'a de sens que par rapport à ce min et ce max qui sont définis de manière absolue (donc dans une échelle avec un sens colorimétrique absolue, comme l'espace de couleur CIE XYZ) et par rapport à un TRC (Tone Reproduction Curve) qui va définir comment tu progresses de la valeur min à la valeur max. C'est à ça que servent les profiles de couleurs, qui vont faire un espace de couleur à partir d'un modèle de couleur.
Ensuite y a la question du stockage mais qui est une préoccupation parallèle: typiquement est-ce que tu stockes des entiers ou des flottants? Si tu utilises des entiers sur n bits, ton min est généralement
0et ton max2ⁿ - 1(par exemple[0; 255]sur 8 bits ou[0; 511]sur 9 bits). Si par contre, tu utilises des flottants, tu va généralement juste de 0 à 1.0 quel que soit la taille du flottant.J'utilise des entiers dans mes exemples car c'est plus facile pour faire comprendre. Mais le rouge 255 en 8-bit est le même rouge que le 511 en 9-bit ou que le 1.0 en 16-bit flottant (si on utilise le même espace de couleur, donc les mêmes couleurs primaires).
P.S.: les flottants ont aussi un gros avantage qui est de pouvoir aller sous zéro et au dessus de 1.0. Puisqu'on rappelle que le min et max sont juste un choix arbitraire, les couleurs hors de cette plage sont des couleurs tout à fait valides. Simplement elles ne sont pas autorisées dans l'espace de couleur en cours ("hors gamut"). Mais il est super intéressant de pouvoir les garder jusqu'au bout parce que — qui sait — certains effets ramèneront peut-être la couleur des pixels hors-gamut à l'intérieur. Or supposons qu'on ait tronqué les couleurs plus tôt, ben là encore, on a mis plein de couleurs à la même couleur trop tôt et donc perdu énormément de précision (i.e. bandes de couleurs, etc.). Alors que si on les garde jusqu'au bout, on a une chance de garder la précision (on ne tronque qu'au moment de l'export).
C'est à ça que servent les calques d'effet notamment (dans le contexte de l'édition non-destructive; ce qui est un mauvais terme, d'une part parce que toute édition est destructive et constructive: on détruit et fabrique de nouvelles données; d'autre part parce que le but n'est donc pas de ne pas changer les données mais de les changer le moins possible).
Donc au lieu de modifier les données au dessus de données modifiées, on garde un graphe. Par exemple un graphe vraiment simple et linéaire:
En édition classique, si on n'est pas content de l'image finale, on peut rajouter un effet, puis un autre, puis un autre (et perdre/créer des données à chaque fois). Ou bien on peut annuler les effets, mais si on n'a pas gardé une copie de l'original, c'est un problème. Et potentiellement il faut reproduire les 2 effets alors qu'on voulait en changer qu'un seul (donc perte de temps). En "non-destructif", tu vas juste éditer les paramètres de l'
Effet 1par exemple et le graphe recalcule.Le second truc, c'est effectivement dans certains cas particulier, tu peux même combiner les effets. C'est le cas typique des transformations mathématiques classiques (rotations, redimensionnement, symétries, etc.), qui sont (comme toute personne qui a fait des maths le sait) simplement des multiplications de matrice. Or supposons que les effets 1 et 2 sont tous deux des multiplications de matrice, tu peux les combiner en une matrice unique et ne faire alors qu'une opération (tu en montrerais toujours 2 dans le graphe pour la sémantique, mais si ton système de graphe est suffisamment malin, il peut éventuellement optimiser).
Pourtant en mathématiques, c'est exactement la même chose (associativité), mais pas en informatique. Puisqu'on a vu que chaque opération fait perdre des données. Oui en manipulation raster, une rotation de 30° n'est pas la même chose (et est préférable) à 2 rotations à 15°! On peut même donner l'exemple ultime: une rotation à 90° peut être fait sans perte (cas d'exception!) alors que 2 rotations à 45° ne le sont pas et abîmeront votre image!
Donc bah voilà, tout cela pour dire que ce dont tu parles, c'est ce que les gens appellent l'édition non-destructive et c'est la raison des succès des calques d'effets, ou même en mieux de l'édition par graphe (très en vogue en 3D notamment). Ces choses arriveront dans GIMP aussi. 🙂
Euh… je comprends pas du tout tes maths là. Bon déjà quand on fait des maths en informatique, on perd l'associativité, donc faut mettre des parenthèses (c'est à dire que
(255 / 2) × 2 = 254mais(255 × 2) / 2 = 255en calcul entier, sans perte de précision dans cet ordre!) sinon je comprends pas là où tu veux en venir. Mais surtout, ils sortent d'où tes 128?En supposant que tu essayais de reproduire mes exemples où tu fais la division d'abord. Alors on a:
Mais… je vois pas pour autant ce que tu essayais de prouver. Qu'est-ce qu'on a annihilé? Je ne vois aucun problème particulier dans tes exemples. Et sûrement pas une preuve que coder avec un bit supplémentaire soit plus mauvais pour la précision, bien au contraire.
P.S.: à propos, note que j'utilise 9 bits pour l'exemple car ça permet un exemple simple où tu multiplie ta plage pour 2. Mais je crois pas que quiconque s'amuse à faire des mathématiques informatiques sur 9 bits. C'est plus simple de faire ça sur 16 ou 32-bit (on utilise des octets entiers, car de nos jours, c'est ainsi que sont souvent définis les types pour représenter des nombres). Je suppose que tu as bien compris cela, mais je précise juste au cas où. 🙂
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: 16 bits & EXIF
Posté par Jehan (site web personnel, Mastodon) . Évalué à 8.
Aaaah. Je viens (peut-être?) de comprendre. En fait, tu voulais me parler de l'ordre inverse (tu vois, quand je disais que d'indiquer l'ordre clairement, c'est important!):
En gros, tu me dis que parce qu'on fait un overflow, on tronque à la valeur max, donc la première multiplication ne sert à rien. C'est vrai (sauf que ça fait la valeur 127 à la fin, mais c'est un détail), mais y a plusieurs probs dans ta logique:
(1) Premier problème, et le plus gros: tu ne fais pas la même opération! Pourquoi tu multiplies par 2 dans une plage et par 4 dans l'autre? Oui forcément, pas la même opération, pas la même perte, c'est sûr. Et si tu as cru que c'était la même opération parce que la plage est 2 fois plus grande, alors… non c'est pas comme ça que ça marche! 😛
Si tu dis: je multiplie par 2 toutes les valeurs, ça ne dépend pas de la plage. Pour le prouver, rien de plus simple. Prenons un cas non extrême (sans troncation). Par exemple: 10 (en [0; 255]) = 20 (en [0; 511]).
Selon ta logique, 20 et 80 devraient alors être la même couleur. Or 20 × 2 = 40! (pas 80!) Ton opération n'est pas censée changer en fonction de la plage. Ce n'est pas ainsi que marchent les maths (pour le coup, là ce sont des maths, pas un problème de l'informatique).
Donc ton exemple aurait dû être:
Note qu'on est un peu plus précis avec la plage en 2⁹! CQFD. 🙂
(2) Ensuite tu as tout de même raison que dans ton cas extrême, tu perds quand même énormément de couleurs. Par contre, ce problème n'existe pas en flottant puisque comme je disais, c'est un type qui nous autorise à sortir de la plage [min; max]. C'est pour cela qu'en 16 et 32-bit, on conseille d'ailleurs le stockage flottant.
Ainsi en flottant, ton exemple devient:
Parfait, pas de perte! C'est parce qu'après le filtre 1 (multiplication par 2), on a pu garder une valeur intermédiaire supérieure à la valeur max.
Note: au passage, je sépare tes 2 opérations mathématiques en 2 filtres parce que si ça avait été un seul filtre qui fait 2 opérations mathématiques, même en entier, on aurait pu éviter un tel écueil (suffit de pas faire un code idiot! LOL). Donc pour que ton exemple soit valide, faut supposer que le résultat de la multiplication est une valeur de résultat en sortie de filtre. Seul le travail en nombres flottants te sauve à ce moment là.
(3) Enfin, il faut voir que cela reste des exemples extrêmes que tu nous sors (de même que ceux que je sortais pour simplifier et montrer les problèmes de précision). Attention, extrême ne veut pas dire impossible (tout est possible; si on le pense, on peut le coder) mais un filtre un peu bien fait ne ferait pas juste une bête multiplication. Genre tu veux augmenter la luminosité générale de ton image, tu vas pas juste t'amuser à tout multiplier par un nombre quelconque (et après t'étonner que toutes les valeurs hautes soient tronquées au max!). Tu auras plutôt des filtres qui vont essayer de répartir mieux et plus intelligemment tes valeurs. Ensuite il y aura clairement des valeurs qui vont se perdre, etc. Forcément, si tu essaies de monter globalement les valeurs de ton image, même si un peu plus intelligemment, tu te retrouves forcément avec des couleurs identiques, voire des couleurs qui sortent du gamut (donc tronquées) etc.
Donc ton exemple, bien qu'extrême, reste en plein dans le mille et montre bien ce qu'est l'édition raster. C'est un exemple simpliste donc on perdra jamais autant de valeurs que cela avec de bon filtres (donc on relativise), mais oui il faut garder en tête que c'est bien des maths qui se passent en arrière plan. Et oui, on va perdre des valeurs/données (ou en créer, ce qui n'est pas mieux, c'est synonyme en fait dans ce contexte, perdre et créer), on va potentiellement aller hors-gamut (donc tronquer et encore perdre/créer des données, à part si on est en flottant). Ça fait partie des choses à comprendre pour s'améliorer en édition d'image.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: 16 bits & EXIF
Posté par barmic 🦦 . Évalué à 2.
C'est ça ! (mais l'ordre est indiqué é_è)
C'est toi qui est passé de « je divise par 2 je multiplie par 2 en 8 bits » à « je divise par 4 je multiplie par 4 en 9 bits ».J'ai mal compris ton premier commentaire, comme tu as commencé avec *2/2 et que tu as ensuite fait *4/4 j'ai pensé que tu avais modifié aussi les opérations en changeant de codage.Yep c'est bon j'ai compris.
Tout à fait. Je suis ne mis connaît que très mal en manipulation d'image. C'est purement l'aspect mathématiques (et comprendre son fonctionnement dans la vraie vie) qui m'a titillé. Gimp 2.8 n'avait pas de problème de cet ordre c'est bien que ça n'arrive pas si souvent. Je présume que c'est ce qu'on trouve quand on laisse un paramètre de la fonction mathématiques à l'utilisateur et qu'il s'amuse à aller au bout de la plage de valeur qu'on lui donne, mais là c'est charge à l'utilisateur de correctement utiliser l'outil.
Merci :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: 16 bits & EXIF
Posté par barmic 🦦 . Évalué à 3.
Hum en flottant la précision de tes opérations mathématiques baisse beaucoup. Tu as une approximation qui est faite à chaque opération. Pour ce qui est de la plage, je comprends donc que lorsque l'on utilise les flottants on utilise une toute petite partie on utilise de [0; 1.0] pour représenter les couleurs visibles au sein d'une plage de valeur allant de -126 à 127. Ça évite le problème dont je parlais pour d'écrasement.
D'acc je comprends. J'ai pas compris si ça existe dans gimp ou si ça va exister ?
Euh… Le numérateur se calcul avant, il n'y a pas besoin des parenthèses avec la représentation que j'utilise.
Excuse-moi je me suis dis après coup qu'il falait que je détail et puis j'ai validé trop vite. Je vais utiliser une représentation en ligne pour m'aligner sur ta façon et détailler. On est en 8bits donc avec des valeurs de 0 à 255.
Tu ne peux pas représenter de valeur au dessus de 255 donc je présume que toutes les opérations sont toutes calculées en prenant le minimum entre la résultat et la borne haute et le maximum entre le résultat et la borne basse. Si ça n'est pas le cas c'est que l'overflow est laissé tel quel est ça donne
Par contre il y avait une erreur dans mon calcul ça donne dans les 2 cas 127 et pas 128.
J'ai volontairement inversé les opérations pour dépasser la borne haute sans supposer qu'il s'agissait de la même opération que toi.
Mes exemples visaient à montrer que quelque si ton gammut (si j'ai bien compris) correspond aux bornes de ta représentation toute multiplication va avoir des conséquences problématiques. Tu va overflow ton entier et tomber sur une valeur que ta représentation ne sait pas représenter (je parle bien de l'aspect mathématiques). Ça n'est pas pire en 9 qu'en 8bits. Tu as répondu à cette question en parlant plus haut du codage flottant qui n'utilise qu'une toute petite parti de l'espace pour code le gammut.
Tout à fait c'est la manière de passer du 8 bits à une autre représentation qui m'a intriguée.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Canonisons GIMP !
Posté par AlexTérieur . Évalué à 5.
Un véritable bonheur ce logiciel, qui me suit presque 20 ans, je l'installe partout, même sur des postes où je n'ai pas Linux ;)
Bravo et merci pour les retours et les dépêches hyper complètes de Jehan. C'est aussi un plaisir de te lire.
Et enfin une prise en charge HiPPi ( ;) ) accompagné des -/+ à la place des flèche haut/bas (qui étaient jusque là minuscules) pour les options comme l'opacité. C'était vraiment le problème par le passé.
# Remerciement!
Posté par denissalem (site web personnel) . Évalué à 9.
GIMP est mon logiciel favoris, je l'utilise depuis plus de 10 ans pour réaliser et éditer des photos, faire du graphisme et dessiner des illustrations!
Merci à l'équipe de GIMP pour votre travail!
# A donné !
Posté par antistress (site web personnel) . Évalué à 4.
Bonne année ! :)
# Juste merci
Posté par snurpsss . Évalué à 4.
Merci.
Quand on me demande un logiciel pour la retouche d'image, ou qu'on me demande version piratée de totoshop, il n'y a qu'une seule réponse: the gimp.
Alors un grand merci à tous ceux et celles qui ont contribuées à ce logiciel. Une preuve vivante que le libre à de beau jour devant lui.
Et merci à Jehan pour tout ces détails qui donnent encore plus de saveur à ce programme.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.