GIMP 2.10 roule au GEGL

167
29
avr.
2018
Graphisme/photo

Après six années de développement, une nouvelle version stable de GIMP est sortie le 27 avril 2018 vers 17 h. C’est un jalon important dans l’évolution de cet outil de création d’images, à de nombreux égards…
Wilber, la mascotte de GIMP
En particulier, cette sortie se démarque par une refonte totale du moteur de traitement d’image, basé désormais entièrement sur GEGL, comme nous l’évoquerons dans la deuxième partie de la dépêche…

Citons aussi :

  • l’amélioration des fonctions de peinture numérique, notamment avec la possibilité d’utiliser les brosses MyPaint, la peinture symétrique, la rotation et inversion du canevas, etc. ;
  • la gestion des métadonnées ;
  • de nouveaux thèmes, notamment un thème sombre par défaut, un nouvel ensemble d’icônes symboliques, ainsi qu’un ensemble d’icônes couleur vectorielles ;
  • l’ajout de plusieurs nouveaux outils — notamment en résultat de trois années de Google Summer of Code ;
  • une palette des formats de fichiers pris en charge plus large et plus complète…

Sommaire

Conséquences directes de GEGL

De loin, GEGL est la nouveauté majeure, qui explique la longue attente depuis la sortie de GIMP 2.8. Cette bibliothèque, en cours de développement depuis 2000, est née du projet GIMP dans l’optique de remplacer un jour son moteur. Malgré des débuts d’intégration dès GIMP 2.6 (outil GEGL expérimental), puis 2.8 (projection de calques utilisant GEGL), c’est seulement après la sortie de la version 2.8 que son intégration a été accélérée.

La majeure partie du code existant de traitement d’image a donc été retirée en faveur de l’usage de cette bibliothèque externe. Cette séparation signifie que GIMP est désormais davantage une interface graphique autour de GEGL. Une majeure partie des traitements sur les pixels est faite si possible à l’aide de cette bibliothèque (certaines fonctionnalités, telles que la peinture, sont encore implémentées directement dans GIMP pour des raisons de performance) et est donc utilisable par d’autres projets, ce qui est extrêmement intéressant pour tout le monde.

Plusieurs projets utilisant GEGL comme base sont ainsi déjà en cours de développement, fonctionnalité ou back‐end supplémentaire. Nous en avions parlé lors de la sortie de GEGL 0.3.0 ou encore lors de la sortie de la version 3.20 de l’environnement de bureau GNOME et de son application intégrée nommée Photos.

Prévisualisation sur canevas

Désormais, le résultat d’un traitement (par exemple, un changement de luminosité, de contraste ou un filtre ; bref, presque tout traitement passant par une boîte de dialogue) est directement visible sur l’image avant de l’appliquer, ce qui rend la prévisualisation beaucoup plus pratique.

Il est aussi possible de scinder la vue horizontalement ou verticalement, avec une partie prévisualisant l’effet et une autre partie affichant le canevas original, comme un « rideau » de prévisualisation qui peut être déplacé à la souris.

Rideau de prévisualisation

Traitement de très grandes images

Un des points forts de GEGL est sa gestion intelligente des tampons, permettant à l’utilisateur d’allouer une partie seulement de sa mémoire à GIMP, mais également de travailler sur des images plus grandes que la mémoire disponible. Un tampon GEGL est une matrice de dalles, chacune pouvant avoir un stockage différent en arrière-plan.

Haute précision des couleurs

Une autre fonctionnalité majeure apportée par GEGL est sa prise en charge de diverses profondeurs de couleur dont GIMP tire désormais profit. En particulier, cela signifie que GIMP n’est plus limité à travailler sur des images à 8 bits par composante couleur. GIMP peut désormais travailler sur des images 8, 16 ou 32 bits, en nombre entier ou flottant (le format natif de GEGL est maintenant en 32 bits flottants), et avec codage linéaire ou correction gamma, au choix de l’utilisateur depuis le menu Image → Précision.

Accélération : OpenCL et multi‐thread

À travers l’usage de GEGL, GIMP sait désormais tirer parti d’OpenCL, ce qui lui permet d’utiliser bien mieux les possibilités d’un ordinateur moderne et de ses multiples processeurs (processeur central, processeur graphique, circuit logique programmable, etc.).

Au fil des années cependant, nous avons pu rencontrer des plantages (venant de pilotes graphiques bogués), des « glitches » graphiques (notamment avec les pilotes NVIDIA), ou des implémentations peu performantes (en particulier avec Beignet, pour les cartes Intel). Par conséquent, OpenCL est désactivé par défaut (l’option peut être activée dans les préférences).

En revanche, un important travail a été fait pour rendre les opérations GEGL multi‐tâches afin d’utiliser au mieux les processeurs modernes, comme les multi‐cœurs. Dernièrement, GIMP lui‐même est devenu multi‐tâches, ce qui a été utilisé notamment pour séparer le traitement de la peinture et l’affichage.

Prise en charge améliorée de formats d’image

Puisque la gestion des images passe désormais entièrement par GEGL, cela signifie aussi que GIMP peut profiter davantage de certaines fonctionnalités avancées, en particulier de la possibilité qu’ont certains formats de stocker aussi différentes profondeurs de couleur. Ainsi, GIMP peut désormais charger et sauvegarder des PNG 8 ou 16 bits, du TIFF ou du PSD jusqu’à 32 bits, et du FITS jusqu’à 64 bits par composante.

Les gestions des formats OpenEXR, RGBE (pour l’imagerie à grande gamme dynamique (HDR)), WebP (notamment avec les fonctionnalités d’animation) et HGT ont aussi été ajoutées.

De nombreux formats d’images ont également été améliorés. On peut citer le format PSD de Photoshop, dont la prise en charge est devenue bien meilleure (même si toujours incomplète).

Prise en charge des métadonnées

GIMP a amélioré sa prise en charge des métadonnées qui n’étaient pas gérables dans la version précédente, en utilisant gexiv2, une bibliothèque de liaison (wrapper) GObject autour de la bibliothèque de gestion des métadonnées Exiv2. Les métadonnées prises en charge par Exiv2 sont à ce jour les standards EXIF, IPTC et XMP :

  • les métadonnées au format EXIF contiennent notamment des données techniques sur les conditions de prise de vue : date, heure, coordonnées GPS, réglages de l’appareil (ouverture, temps de pose, etc.), mais aussi des informations sur le matériel utilisé ;
  • les métadonnées au format IPTC ou à celui, plus récent, XMP, contiennent des informations plus génériques relatives à l’image en tant que médium d’information, comme une description, un titre, un lieu (sous forme compréhensible par l’humain, soit la ville, le pays…), une licence d’utilisation et un copyright, une citation de sources, etc.

gexiv2 est devenu un projet GNOME à l’occasion de son intégration dans GIMP, lui donnant une visibilité et une pérennité accrue (voir ce billet retraçant l’histoire de cette bibliothèque).

Puisque les métadonnées peuvent contenir des données privées parfois très sensibles (telles que nom, adresse de courriel et même coordonnées GPS !), il est possible de ne pas les exporter et un choix par défaut peut être configuré dans les préférences (lequel peut être outrepassé par format ou simplement par fichier).

Accès aux fichiers par GIO

Les accès aux fichiers ont été tous portés vers l’interface abstraite et de haut niveau GIO, plutôt que les interfaces bas niveau de traitement de fichier local.

Cela permet de ne plus considérer un fichier comme nécessairement local, surtout dans un monde dorénavant fortement connecté où il devient de plus en plus courant de vouloir travailler sur des fichiers distants. GIO permet ainsi, par exemple, d’ouvrir une image sur un serveur FTP distant ou sur votre cloud (OwnCloud…) de manière transparente, sans avoir à transférer l’image au préalable (et même à la sauver si l’accès distant permet aussi l’écriture).

Compatibilité descendante

Gestion de LZMA2 et compression interne DEFLATE

GIMP 2.8 proposait de compresser ses images sous les formats hybrides .xcf.gz (gzip) et .xcf.bz2 (bzip2), deux des formats de compression les plus répandus du monde libre. La version 2.10 apporte la compression LZMA2 (.xcf.xz), bien plus efficace, qui fait son chemin pour remplacer les deux précédents algorithmes un peu partout, et les dépendances de compression sont devenues obligatoires (tout utilisateur de GIMP 2.10 ou supérieur pourra désormais ouvrir vos fichiers .xcf.(gz|bz2|xz)). Il s’agit cependant seulement de compression du fichier complet comme un conteneur.

Il faut savoir que les données sont également compressées au niveau des dalles. Jusqu’à maintenant, l’algorithme basique RLE était utilisé, GIMP 2.10 peut le remplacer par DEFLATE de zlib, permettant des fichiers bien plus petits. Cette compression n’est cependant pas utilisée par défaut, car plus lente, mais reste sélectionnable au moment de sauvegarder son fichier.

Par ailleurs, la compression au niveau des dalles peut permettre d’outrepasser certaines limitations (liées au système d’exploitation ou au système de fichiers par exemple) dans le traitement de documents très volumineux.

Interface applicative

GIMP n’est pas seulement un puissant logiciel de traitement et de création d’images. C’est aussi une plate‐forme évoluée pour les développeurs de greffons.

GIMP 2.10 continue dans la lignée de la version 2. Utilisant une API stable, tout greffon existant devrait donc continuer de fonctionner. Néanmoins, les interfaces historiques de traitement de pixels de l’API de GIMP seront déconseillées au profit du traitement par l’API GEGL. Les développeurs tiers de filtres sont ainsi encouragés à convertir leurs greffons sous la forme d’opérations GEGL, ce qui leur ouvrira également le monde de l’édition non destructrice, de la haute profondeur de couleur, de la prévisualisation instantanée, ainsi que de nombreux autres avantages inhérents à GEGL.

Outils

Partage de brosses avec MyPaint

MyPaint a un système de brosses différent de celui de GIMP, avec ses avantages et inconvénients. Dans tous les cas, il est intéressant pour les utilisateurs de GIMP de pouvoir utiliser ce système de brosses alternatif. C’est pourquoi il a été décidé d’intégrer les brosses de MyPaint dans GIMP. C’est probablement un des changements majeurs pour de nombreux peintres qui préféraient MyPaint à GIMP.
brosses MyPaint dans GIMP
MyPaint avait déjà sa bibliothèque libmypaint et a clairement fait la séparation avec son dépôt principal en avril 2014 pour mettre en avant ce genre de possibilité avec son moteur de brosses.

Outil de transformation unifié

Conséquence du Google Summer of Code 2012 (wiki), cet outil permet le redimensionnement, le déplacement, la rotation et la perspective, le tout dans un seul outil.
Outil de transformation unifié

Notez que les anciens outils de transformation, pour chacune de ces fonctionnalités séparées, n’ont pas été supprimés à cette occasion. En effet, le nouvel outil est basé sur un concept de transformation au jugé uniquement, et l’utilisation des outils dédiés est toujours nécessaire lorsque vous souhaitez effectuer une transformation précise, avec des chiffres (angle, nombre de pixels, etc.). Il s’agit d’un choix du concepteur Peter Sikking (section GIMP de son journal Web), qui a écrit la spécification de l’outil.

Outil de transformation « Warp »

Un autre résultat du Google Summer of Code, 2011 cette fois (wiki), l’outil de « warp » (démonstration en vidéo, billet du développeur) permet de « tordre » l’image directement sur le canevas. Cette fonctionnalité existait en fait déjà sous la forme du greffon iWarp, qui a maintenant été rendu obsolète en faveur de cet outil. En effet, le greffon ne permettait pas de travailler aisément sur une image, contrairement à un outil qui donne la possibilité de voir directement un effet sur le canevas et d’éditer ou annuler à chaque étape.

Extrait d’une vidéo de démo de peinture en miroir (vers 2 min 45) montrant une utilisation de l’outil Warp pour simuler l’eau (note : l’interface est désormais bien différente depuis cette vidéo) :
Outil de transformation « Warp » de GIMP

Outil de transformation par poignée

Un autre outil de transformation a été intégré : l’outil de transformation par poignée, qui permet de placer des poignées librement sur le canevas et de transformer l’image en fonction du nombre de poignées. Une poignée permet de déplacer l’image. Deux poignées permettent d’exécuter une rotation ou un redimensionnement en conservant les proportions. Trois poignées permettent un cisaillement ou un redimensionnement sans conserver les proportions. Enfin, quatre poignées permettent un changement de perspective. Une vidéo de démonstration est disponible.
Les personnes habituées aux interfaces tactiles pourront se retrouver en terrain familier.

Outil de sélection de premier plan

L’outil de sélection de premier plan manquait de précision et n’avait notamment pas de notion de sélection partielle d’un pixel, par exemple dans le cas de fibres (cheveux…) ou de textures semi‐transparentes, auquel cas un même pixel peut contenir partiellement du premier et de l’arrière‐plan.

Le nouvel outil est désormais basé sur des algorithmes de matting théoriquement plus évolués, portés sur GEGL.

Peinture en miroir, dalles et rotation

Il est désormais possible de peindre en miroir dans GIMP, relativement à un axe horizontal, vertical et à un point. Il est aussi possible de peindre en « dalles », copiant un trait en une série similaire à intervalles réguliers (translation) ou encore en rotations multiples autour d’un centre (style « mandalas »).

Peinture en miroir

Cette fonctionnalité est disponible pour tous les outils de peinture de GIMP. Plus de détails et une vidéo disponible sur un billet de journal de bord. L’image animée au‐dessus est extraite de ladite vidéo, dessinée par l’artiste Aryeom.

Outils encore dans le bac à sable

Deux outils résultant de Google Summer of Code (2011 et 2013) n’ont malheureusement pas pu faire partie de la version stable. Il s’agit de l’outil de clonage sans raccord (démonstration en vidéo, section correspondante du journal du développeur) et de l’outil de déformation N‐Point (démonstration en vidéo, billet du développeur). Ces deux outils sont en effet dans le bac à sable à cause de leur état non satisfaisant, soit extrêmement lent, voire bogué ou conduisant à des plantages. Les développeurs souhaitant contribuer pour finaliser ces outils sont les bienvenus !

Pour tester ces outils, lancez GIMP avec l’option --show-playground, puis cochez les options dans les préférences. Il convient de rappeler que ces outils ne sont pas conseillés pour de la production et peuvent même faire planter GIMP, vous faisant ainsi perdre des données non sauvegardées.

Interface graphique

Tableau de bord

Un tableau de bord fait son apparition permettant de suivre l’évolution de l’utilisation du processeur, le cache et l’espace d’échange mémoire (swap) occupé.

Mode fenêtre unique par défaut

Si GIMP 2.8 avait rajouté le mode fenêtre unique, celui‐ci restait une option à sélectionner, ce que beaucoup d’utilisateurs occasionnels ne savaient pas et n’utilisaient donc jamais. Ce mode étant finalement d’autant plus utile pour ces utilisateurs, afin de ne pas les perturber, il s’agit donc du nouveau mode de fenêtrage par défaut.

Le mode multi‐fenêtre existe toujours et est désormais activable comme l’était auparavant le mode fenêtre unique.

Verrouillage des transformations

Les calques peuvent désormais être verrouillés pour être préservés contre toute transformation accidentelle (déplacement, rotation, etc.).

Rotation et retournement du canevas

Il est désormais possible de faire pivoter le canevas, ainsi que de le faire se retourner horizontalement ou verticalement. Il ne s’agit pas d’opérations sur les pixels (donc notamment pas d’une rotation d’image ni d’un miroir), mais uniquement d’une rotation d’affichage. Certains peintres utilisent en effet la rotation pour peindre avec leur tablette en diagonale (comme certains écrivent sur une feuille en diagonale) tout en orientant l’image sur l’écran à l’identique, ce qui permet d’atteindre plus aisément certaines zones du canevas.

Le retournement est également beaucoup utilisé par les peintres pour vérifier les problèmes de perspective, de symétrie et de proportions. Dessiner trop longtemps sur le même dessin entraîne en effet parfois une habitude de l’esprit, qui ne se rend plus compte de certaines erreurs autrement évidentes. Retourner régulièrement le canevas permet aux peintres numériques de « rafraîchir » leur cerveau en chamboulant son attente comme si une nouvelle image lui était soumise et, ainsi, de découvrir et corriger les erreurs.

Thèmes d’icônes et nouveaux thèmes d’icônes symboliques

Les icônes ne sont désormais plus inclues dans les thèmes, mais sont fournies dans des thèmes d’icônes, indépendamment. GIMP sera désormais fourni avec des thèmes d’icônes symboliques et un thème d’icônes vectorielles couleur, en addition du thème couleur historique.

Thème d’icônes symboliques de GIMP

Cela fait suite aux efforts du projet GNOME pour proposer des alternatives symboliques aux icônes couleur classiques.

Tailles d’icônes

Les icônes des outils étaient de 16 × 16 pixels et 22 × 22 pixels. Nous utilisons seulement des multiples de 16 et 24 pour les nouvelles icônes, suivant ainsi l’évolution de GNOME et GTK+.

En outre, plutôt que de proposer un thème particulier « petites icônes » (thème Small qui disparaît), il devient désormais possible d’outrepasser les tailles des icônes de n’importe quel thème (officiel, comme personnalisé) dans les préférences, pour peu que le thème d’icônes propose une taille adéquate (ou une version vectorielle). Cela permettra notamment d’utiliser GIMP sur des écrans à haute densité de pixels (HiDPI).

Redéfinir tailles d’icônes

Nouveaux thèmes

Trois nouveaux thèmes font leur apparition, dans diverses nuances de gris (un thème clair, un thème gris intermédiaire, et un thème sombre), en plus du thème Système.
Nouveaux thèmes

Recherches d’actions

GIMP possède désormais une recherche‐et‐activation des actions. Par défaut, l’entrée de recherche correspond à /. Cela permet, par exemple, de rechercher des filtres par mot‐clef présent dans le nom ou la description du filtre, plutôt que par les menus et sous‐menus. Mais cela ne se limite pas aux filtres, ni même aux menus. Toute action présente dans GIMP (c’est‐à‐dire une opération à laquelle on peut assigner un raccourci clavier) peut être recherchée et activée par cette nouvelle fonctionnalité.

Recherche d’action

On peut ainsi rechercher des outils ou fonctions disponibles, mais présents dans aucun menu. Cela pondère notamment le fait qu’il y ait plus d’actions que de raccourcis techniquement possibles (sans compter la mémorisation quasi‐impossible si l’on devait se rappeler un raccourci par action !). Et puis, qui n’avait jamais cherché une fonctionnalité dans les menus qu’on avait déjà utilisé des semaines auparavant, mais qu’on est incapable de retrouver en moins de dix minutes de tripatouillage dans les menus et sous‐menus ?

Notons que l’outil prend en compte la localisation (on peut ainsi chercher dans la langue de l’interface, par exemple en français).

Position des onglets modifiable

Il est désormais possible de placer la barre des onglets, dans le mode à fenêtre unique, de n’importe quel côté (haut, bas, gauche ou droite).

Capture d’écran avec onglets à gauche

Traitement d’images en ligne de commande

Tout d’abord, il est à noter que GIMP n’est pas forcément adapté à du traitement d’image en ligne de commande, en particulier sur de multiples images. Il existe des logiciels véritablement dédiés à ce type de traitement dit « batch », comme ImageMagick, lesquels pourraient être plus pratiques d’utilisation et aussi plus efficaces.

Plus proche de GIMP, G’MIC possède aussi une interface en ligne de commande, et l’on peut même utiliser tout simplement GEGL, qui est doté d’un binaire capable d’enchaîner des opérations sur des images directement depuis la ligne de commande. Ainsi, inverser les couleurs d’une image PNG avec GEGL puis convertir en JPEG est aussi simple que :

```bash
$ gegl source.png -o dest.jpg -- gegl:invert-gamma
```

Néanmoins, de nombreuses personnes continuent à utiliser GIMP pour du traitement d’image en ligne de commande, notamment par habitude ou par connaissance de l’API de GIMP (la même que pour les greffons). Donc, pour ne pas oublier ces personnes, deux fonctionnalités petites mais très attendues ont été ajoutées :

  • lorsqu’une instance GIMP tourne déjà, les commandes batch sont exécutées sur cette instance existante ;
  • une nouvelle macro with-files permet désormais d’exécuter une même suite de commandes sur une liste d’images. Ainsi, voici comment inverser les couleurs de toutes les images PNG contenues dans un répertoire donné :

    $ gimp -i -b '(with-files "*.png" (gimp-invert layer) \
                   (gimp-file-save 1 image layer \
                   (string-append basename ".jpg") \
                   (string-append basename ".jpg") ))'

Peinture

Historique des couleurs utilisées

Il existe désormais une palette automatique des couleurs récemment utilisées. En outre, le dock des couleurs d’avant plan et d’arrière‐plan affiche les douze couleurs les plus récentes de ladite palette.
Historique des couleurs

Nouveaux modes de fusion des calques

Historiquement, GIMP travaillait en espace de couleur perceptuel, ce qui est en train de changer grâce à la haute profondeur de couleur. Pour toute profondeur plus grande que 8 bits par canal, travailler en espace linéaire est bien plus efficace. Nous avons donc créé une nouvelle collection de modes en espace linéaire. De nombreux modes de calque ont ainsi été nouvellement implémentés.

Bien entendu, toute image XCF d’une version précédente sera parfaitement migrée. C’est‐à‐dire que tout ancien XCF aura le rendu attendu, une fois chargé dans une version de GIMP, et ce, à jamais (si un XCF à un rendu différent, alors cela est à considérer comme un bogue).

Lier la taille de la brosse au zoom

Une nouvelle option est disponible pour tout outil utilisant le moteur de brosses de GIMP : il est désormais possible de lier la taille de la brosse au niveau de zoom (« Lock brush size to zoom »), et pas uniquement à sa taille en pixels.
Ainsi, en zoomant davantage, votre brosse rapetissera d’autant, et inversement, de sorte qu’elle aura toujours la même taille sur l’écran (mais pas la même taille en pixel sur le canevas).

Gestion des couleurs

GIMP 2.10 apporte de nombreuses améliorations sur la gestion des couleurs. Notamment, GIMP est passé du moteur LCMS v1 à v2, ajoutant au passage la prise en charge de ICC v4, mais aussi une meilleure fidélité de conversion entre des profondeurs de couleur différentes. Nous avons en fait même déjà commencé le travail pour remplacer LCMS par babl, notamment pour la conversion entre profils de couleur quand cela est possible. La librairie babl est en effet extrêmement plus rapide que LCMS.

GIMP gérait historiquement les profils de couleur à l’aide d’un module. Celui‐ci a été retiré en faveur d’une implémentation interne et complète, interagissant sur l’ensemble de l’interface. Par exemple, il y a maintenant une prise en charge de la copie d’une image sur une autre avec des profils différents, impliquant une conversion pour garder la fidélité des couleurs.

Les images en niveau de gris peuvent désormais aussi être munies d’un profil de couleur, et plus seulement les images RVB.

Enfin, l’interaction utilisateur avec les profils a été revue, rendant la gestion de profils sur les images (assignation, suppression, conversion…) plus simple et compréhensible.
Métadonnées d’un profil de couleur visible dans le sélecteur de fichiers

Emplacement standardisé des fichiers de configuration

Les fichiers de configuration ont été déplacés dans une arborescence plus appropriée sur chaque plate‐forme :

  • Windows : %APPDATA%/GIMP/{GIMP_APP_VERSION} ;
  • macOS : NSApplicationSupportDirectory/GIMP/{GIMP_APP_VERSION} ;
  • tous les autres UNIX : $XDG_CONFIG_HOME/GIMP/{GIMP_APP_VERSION}.

Il est à noter sur nos systèmes d’exploitation libres en particulier, que GIMP adopte désormais la spécification XDG. Cependant, seul $XDG_CONFIG_HOME est pris en charge pour le moment. En particulier, nous ne séparons pas avec $XDG_CACHE_HOME (en revanche, GEGL utilise ce dernier), ni $XDG_DATA_HOME.

Les anciens fichiers de configuration seront immédiatement migrés, et convertis si nécessaire (ce dernier point étant aussi une nouveauté), lors du premier lancement de GIMP 2.10.

Multi‐plate‐forme

GIMP est multi‐plate‐forme et, bien que l’on sache qu’il tourne aussi sous BSD ou Solaris, par exemple, les plates‐formes qui connaissent le plus de succès sont bien entendu GNU/Linux, Windows et macOS. GNU/Linux a le moins de problèmes, car quasiment tous les développeurs l’utilisent comme système d’exploitation principal.

macOS rencontre un peu d’amour de la la part contributeurs par intermittence. Cela fait déjà un moment que GIMP fonctionne avec une interface graphique native. Il faut pour cela compiler GTK+ avec le quartz en arrière‐plan à la place de X11 (surtout que X11 n’est plus fourni par défaut avec macOS). L’intégration est désormais portée plus loin avec des migrations d’API Carbon vers Cocoa, ainsi que des changements d’interface graphique pour suivre les règles de macOS (notamment au niveau menu, barre des tâches, etc.).

Windows est toujours le vilain petit canard malheureusement, bien qu’il s’agisse probablement de la masse la plus importante des utilisateurs. Un appel à l’aide de développeurs Windows avait d’ailleurs été lancé, il y a quelques années, sans grand succès. L’appel tient toujours.

Et après ?

GIMP 3.0

GIMP 3.0, la version majeure qui succédera à 2.10, sera aussi la promesse d’un futur radieux. Il s’agira encore une fois d’une refonte en profondeur. Si GIMP 2.10 refondait le moteur avec GEGL, GIMP 3.0 refondra l’interface graphique avec GTK+ 3.0.
Notons que la migration directe à GTK+ 4 a aussi été évoquée, bien que rien n’ait été formellement décidé à ce sujet pour l’instant.
Qu’est‐ce qu’une migration à GTK+ 3.0 apporterait ?

Meilleure prise en charge des dispositifs de pointage

Les utilisateurs avancés utilisent souvent des dispositifs de pointage particuliers, comme les tablettes graphiques. GTK+ 2 avait une prise en charge assez aléatoire, surtout sous Windows où beaucoup de cas de tablettes non fonctionnelles nous étaient rapportées. Cela devrait être beaucoup mieux avec GTK+ 3.

Le branchement à chaud de périphériques USB, parfois chaotique, a été amélioré avec XInput 2. Et, bien sûr, les fonctionnalités digitales devraient pouvoir être implémentées bien plus facilement (zoom ou rotation du canevas en glissant les doigts, etc.).

Gestion des très hautes densités d’affichage

De plus en plus de gens, en particulier parmi les professionnels de l’image, travaillent avec des écrans à très haute résolution ou très haute densité de pixels (HiDPI, Retina display…). Un travail a été fait sur GIMP 2.10, notamment en auto‐détectant la densité de l’écran et en permettant de configurer des icônes de grande taille. Mais ces améliorations restent superficielles, tenant plus de la rustine que de la prise en charge en profondeur.

GIMP 3.0 devrait bien mieux prendre en charge de tels écrans et permettre aux gens de travailler efficacement avec une telle configuration.

Wayland

GDK a un back‐end Wayland disponible pour GTK+ 3. GIMP pourra donc devenir une application native Wayland. Wayland pourrait d’ailleurs apporter de nouveaux usages, tels que le dessin multi‐pointeur, ainsi que le lancement d’actions par les boutons des tablettes graphiques.

Thèmes améliorés

Les thèmes GTK+ 3 sont de type « CSS » et permettent notamment des variantes de thèmes (comme les variantes obscures). Cela sera beaucoup plus propre et standard que de créer de nouveaux thèmes à l’infini.

Contributions accrues à GTK+

L’un des principaux problèmes de l’utilisation de GTK+ 2 est que celui‐ci ne peut plus évoluer. GTK+ 2 accepte des corrections de bogues, mais pas de nouvelles fonctionnalités. C’est donc un blocage majeur pour l’évolution de GIMP dès que nous souhaitons une fonctionnalité qui touche la bibliothèque graphique (toolkit).

Le passage à GTK+ 3 signifie donc que les évolutions d’interface seront enfin libérées, puisqu’il sera désormais permis de contribuer des fonctionnalités de fond à GTK+ au besoin. Et réciproquement, cela signifie que GTK+ pourra à nouveau profiter du développement de GIMP, puisque nos contributions à GTK+ étaient forcément limitées.

Traitement d’image non destructif

Nous expliquions déjà dans la nouvelle sur GEGL que le traitement en graphe signifie que le traitement d’image non destructif sera bientôt possible. Il ne sera plus question d’appliquer un effet, puis de voir, annuler, puis le refaire avec des paramètres différents, et ainsi de suite. Vous pourrez appliquer un effet, puis, plus tard, simplement en changer les paramètres. Vous pourrez même supprimer l’effet et retrouver l’image originelle.

Malheureusement, cela n’est pas présent dans GIMP 2.10 car l’interface graphique n’a pas encore été spécifiée. Le traitement d’image est donc de fait toujours destructif, pour le moment. C’est cependant une des futures étapes majeures de GIMP, actuellement prévu pour GIMP 3.2, bien que cela puisse arriver avant (ou après) en fonction des priorités des contributeurs.

Amélioration globale de l’interface

J’ai récemment créé une liste de discussion sur l’interface graphique de GIMP, et repris en main nos discussions et spécifications sur le sujet, notamment autour du wiki associé. Mon but à terme est d’améliorer drastiquement l’expérience utilisateur, même si je ne me fais pas d’idées sur le fait que cela prendra plusieurs années. Travail en cours…

Amélioration de la plate‐forme d’intégration

La plate‐forme d’intégration s’était améliorée, mais elle connaît beaucoup de problèmes ces dernières années (et malheureusement nous n’avons plus vraiment d’administrateur avec du temps libre parmi nous). Idéalement, à chaque commit, le code est compilé et testé (tests unitaires) et des messages d’erreur sont envoyés sur les canaux de communication (IRC notamment) pour avertir de tout problème. Mais notre plate‐forme n’est plus du tout fiable. À une époque, nous avions aussi des « nightly builds » pour les utilisateurs friands de nouveautés et qui aiment le risque, mais cela n’existe plus depuis quelques années.

Nous aimerions ajouter aussi des constructions et tests pour macOS et Windows dans notre intégration. Ce qui est en discussion régulière, mais n’est toujours pas fait (et ne risque pas d’arriver de sitôt si l’on n’arrive même pas à stabiliser les constructions pour GNU/Linux), et ce, pour les mêmes raisons que pour le code : l’absence de contributeurs macOS et Windows.

En d’autres termes, les contributeurs qui s’intéressent à ces aspects du développement logiciel sont les bienvenus !

Politique de publication

Je pense que peu de monde est vraiment satisfait de la politique de sortie de GIMP. Cela inclut aussi les développeurs, ne croyez pas le contraire. En effet, les versions majeures se font attendre des années et les corrections de bogues des mois, car on est coincé dans le système à l’ancienne de publications majeures et mineures où il faut attendre la stabilité de tout un tas de fonctionnalités. Or, certaines d’entre elles pourraient être prêtes et publiées depuis des années, mais doivent attendre la stabilité d’autres points.
GIMP: It’s done when it’s done
C’est pourquoi j’ai lancé l’idée, lors du Libre Graphics Meeting 2014 à Leipzig, de changer notre politique de publication pour adopter le système plus récent, dit de « sorties rapides », qu’ont adopté par exemple les navigateurs ces dernières années. Bien sûr, outre l’aspect « commercial » de numérotation rapide que les gens pourraient reprocher (nous ne prévoyons pas de copier cela à ce jour), je pense bien voir là une solution à l’absence de visibilité sur les développements. Au lieu de voir une publication majeure comme un « gros » changement qui a beaucoup de fonctionnalités et une publication mineure comme seulement des corrections, on pourrait simplement voir une publication comme « quelque chose de prêt », sans discrimination. On devrait pouvoir être capable de sortir une version rapidement, même si c’est pour une ou deux corrections de bogue (que l’on juge suffisamment importantes pour ne pas faire patienter les gens), ni devoir attendre dix fonctionnalités quand une est déjà prête.

Après des années de pression interne, cette politique a été adoptée par étape. Nous avons ainsi annoncé, il y a un an, que nous autoriserons de nouvelles fonctionnalités lors de publications mineures 2.10.x. Néanmoins, elles seront forcément limitées aux fonctionnalités peu « invasives » (au niveau du code).

Sous GNU/Linux !

Sur nos systèmes GNU/Linux préférés, les logiciels sont historiquement empaquetés par les diverses distributions. Néanmoins, cela a quelques inconvénients, entre autres parce que les mises à jour sont souvent en retard. Et, pire, les distributions dites « stables » ne vont mettre à jour que les versions mineures. Comme nous avons déjà manqué quelques « gels » de distributions, on ne verra donc pas GIMP 2.10 sur Fedora avant au moins six mois, et vraisemblablement pas sur la dernière LTS d’Ubuntu (sortie la veille de la sortie de GIMP 2.10 et supportée jusqu’en 2023) ! Sans même parler de Debian stable…

N. B. : C’est déjà disponible dans unstable.

Ce type de gestion de versions commence à changer dernièrement, avec les dépôts privés (PPA pour Ubuntu, Copr pour Fedora…) et aussi avec les paquets extra‐distributions (Flatpak, Snap, AppImage…).

GIMP est ainsi disponible dans un paquet officiel Flatpak, hébergé sur Flathub. Cliquez le lien et, si votre distribution est suffisamment moderne, elle vous proposera d’installer GIMP.
C’est moi‐même qui maintient ce paquet, et il est officiellement pris en charge par le projet GIMP. Il fonctionne bien, malgré quelques limitations (et même quelques pertes de fonctionnalités à cause du modèle de sécurité et autres limitations actuelles du format). Ainsi, vous pouvez d’ores et déjà installer GIMP 2.10.0 en un clic, là, maintenant, tout de suite ! Et, bonus, vous bénéficierez directement de toute mise à jour future ! :-D

GIMP est aussi disponible dans des paquets tiers pour les divers autres systèmes. Je tiens cependant à rappeler que ces paquets ne sont pas créés par nous. Cela signifie qu’en cas de bogues, nous vous demandons de vous assurer que ceux‐ci ne proviennent pas du paquetage et de les rapporter d’abord à l’empaqueteur. En outre, on ne peut en assurer ni la qualité ni la conformité, et surtout la sécurité (c’est‐à‐dire si aucun code malveillant n’a pu être ajouté). C’est pour cette raison que je ne donne pas de liens mais ces paquets sont simples à trouver.

On nous a souvent accusé de privilégier Windows, car on ne proposait pas de binaires GNU/Linux (ce qui était simplement la norme jusqu’il y a peu : laisser les distributions s’en occuper). On notera que désormais, la version GNU/Linux est la première à sortir, presque immédiatement après l’annonce de la version stable (alors que l’installeur Windows a mis deux jours et le paquet macOS n’est pas sorti) ! Il ne s’agit d’ailleurs pas d’un coup de chance : cette situation est faite pour durer ! En tant que mainteneur du Flatpak, je prévois de ne jamais laisser passer plus de quelques heures avant la sortie du binaire (en fait, même pour cette sortie, le binaire n’a été retardé que parce que j’ai été forcé de lancer la compilation cinq fois d’affilée à cause de divers contretemps ; autrement, j’espérais pouvoir sortir le Flatpak en même temps que l’annonce).

Liste non exhaustive

Vous noterez que les notes de sortie de GIMP 2.10.0 ne listent pas exactement les mêmes changements que le présent article (alors même que j’ai contribué massivement à écrire les deux documents, ainsi qu’une majeure partie des implémentations de fonctionnalités). En fait, le nombre de nouvelles fonctionnalités ou de changements dans GIMP 2.10.0 est tellement énorme que personne n’a même essayé de les compter.

Le fichier NEWS est un peu plus complet, bien qu’il ne soit pas exhaustif non plus (je viens par exemple de me rendre compte qu’au moins une des fonctionnalités de cet article avait été oubliée dans NEWS et ce n’est probablement pas la seule).

Il fallait faire des choix de fonctionnalités à citer, qu’on espère pertinents, mais dans tous les cas, ce qualificatif dépendra fortement de chacun. Je vous laisse donc découvrir les autres nouveautés vous‐même en croisant les articles.

GIMPez bien !

Le tour des fonctionnalités est terminé. Notons qu’il s’agit en fait d’un survol extrêmement succinct des nouveautés de GIMP 2.10.0 qui représentent véritablement un énorme bond en avant depuis la version 2.8.
Pour plus de détail de diverses fonctionnalités, je peux conseiller de lire les annonces (en anglais) des diverses versions de développement, ainsi que des candidates de sortie, donnant une vision plus incrémentale du développement :

Dans tous les cas, je vous souhaite beaucoup de plaisir à GIMPer toutes vos images, que ce soient des œuvres d’art originales ou de simples photos de vacances à retoucher. :-D

Épilogue : ZeMarmot et le développement de GIMP

Je souhaitais également rappeler que notre studio associatif, LILA, est un contributeur majeur de GIMP (je suis le second plus gros contributeur de GIMP 2.10, après le mainteneur ; et même plus gros contributeur des six derniers mois).
Notre but est de promouvoir l’art libre et les logiciels libres créatifs au niveau professionnel. Nos projets ont donc pour but à terme de rémunérer des créateurs qui utilisent des logiciels libres et partagent leurs créations. En particulier, nous produisons le film d’animation ZeMarmot.

Ma priorité dans la contribution de GIMP est donc d’en faire un outil de qualité professionnel (ce que j’estime qu’il est dorénavant, bien qu’il puisse encore être énormément amélioré). Cela signifie qu’il doit être fiable et stable (avant même de nous lancer dans ZeMarmot, mes contributions initiales étaient dues à l’existence de plantages trop fréquents de GIMP, que j’ai corrigés depuis), puis qu’il doit bénéficier de nouvelles fonctionnalités pour les usages avancés (ce que je fais aussi).

Si vous appréciez GIMP et notre travail pour l’améliorer, nous vous encourageons donc à contribuer financièrement. Vos dons rémunèreront aussi bien le développement de GIMP que la création du film (lequel peut servir de vitrine pour le logiciel libre, tout en étant une véritable œuvre et pas seulement une démo technique). Les donations sont possibles sur Liberapay, Tipeee, Patreon ou autres (que ce soit par virement, chèque, Paypal, bitcoin…).
C’est un moyen de contribuer à l’amélioration constante de ce fabuleux logiciel.

Ze End


N. D. M. : Jehan est aussi un important contributeur à LinuxFr.org, fournissant dépêches de qualité, journaux copieux et commentaires pertinents. Grâce à lui, nous sommes régulièrement informés, avec constance et précision, sur le développement de GIMP, les logiciels d’animation et le monde du traitement d’images. Quelques‐uns de ses articles sont mentionnés dans la dépêche, beaucoup manquent. Vous pouvez les retrouver en suivant son pseudo ou l’étiquette gimp. En voici un florilège pour découvrir certaines nouveautés oubliées dans la dépêche :

Aller plus loin

  • # C’est malin…

    Posté par  (site web personnel) . Évalué à 10.

    C’est malin de faire une dépêche aussi longue, le temps que je la lise GIMP 3.0 est déjà sorti…

    Blague (pas drôle) à part, merci à Jehan et aux 41 contributeurs (!) pour la dépêche, à tous les développeurs de GIMP pour cette release, et encore à Jehan pour le flatpak.

    Ah, et juste pour mettre en avant une nouveauté qui pour moi est cruciale mais qui est presque perdue dans toutes les infos de cette dépêche :

    GIMP peut désormais travailler sur des images 8, 16 ou 32 bits

    (Mais il y a tellement de nouveautés que j’imagine que chacun va avoir « sa » nouveauté préférée…)

    • [^] # Re: C’est malin…

      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 03 mai 2018 à 17:15.

      Cette dépêche est exemplaire. Bravo, on tient pour moi une des dépêches de l’année. ;)

      • [^] # Re: C’est malin…

        Posté par  . Évalué à 10.

        Effectivement, je ne sais pas à quoi carburent les graphistes ou bien si c'est les vapeurs de qu'il y a dans leur encre, mais les dépêches de Jehan et celles de David Tschumperlé (G'MIC) sont toujours un régal (sans présumer de celles des autres, bien sûr, je me régale également avec celles de Goffi, par exemple.)

        Merci pour cette dépêche passionnante. Merci pour ta participation à GIMP. Merci pour avoir participé à l'accélération de la sortie des versions stables. Merci à toi et à Aryeom pour ZeMarmot. Enfin, merci pour tout !

  • # Intégration

    Posté par  . Évalué à 9.

    Non seulement la sortie de Gimp 2.10 est une formidable nouvelle, mais cette dépêche en elle-même est formidable ! Merci à Jehan et aux 41 autres contributeurs d'avoir fourni autant d'informations et de précisions !

    C'est intéressant que cette dépêche mentionne la plateforme d'intégration, car je me posais justement récemment la question. Blender, par exemple, possède tout un tas de nightly builds qui font le bonheur de la communauté, car n'importe quel utilisateur peut télécharger la dernière version pour essayer les dernières nouveautés. Ça marche d'autant mieux que Blender n'a même pas besoin d'être installé pour pouvoir être utilisé (il suffit de décompresser l'archive quelque part et de lancer blender[.exe])…

    Bref, quel est le process actuel en ce qui concerne Gimp ? Quelle solution utilisez-vous ? Où est-ce que ça bloque ? Est-ce que tout ça est documenté quelque part ?

    • [^] # Re: Intégration

      Posté par  (site web personnel) . Évalué à 2.

      Où est-ce que ça bloque ?

      gtk ?

    • [^] # Re: Intégration

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      Où est-ce que ça bloque ?

      Comme je le disais dans la dépêche, tout simplement les contributeurs! Enfin ce ne sont pas les contributeurs qui bloquent, mais le fait que les contributeurs manquent.
      En gros, les choses vont pas se faire tout seul, on a besoin de gens.

      Pour répondre un peu sur les questions techniques: on a un serveur de build avec Jenkins. Parfois les builds cassent, de façon normale car par exemple on a augmenté une dépendance de version. Ça c'est pas gênant. Le problème, c'est que quand ça arrive, l'admin de cette instance Jenkins met parfois des semaines avant de corriger (et donc on se retrouve sans build check automatique pendant plusieurs semaines). Des fois, les builds cassent sans vraiment qu'on sache pourquoi aussi. Et parfois le serveur entier disparaît. Par exemple maintenant, le serveur est mort. On sait pas pourquoi et le contributeur répond pas.

      Ensuite soyons clair: il n'y a aucun reproche envers le contributeur. Il est bénévole, comme nous tous (même ceux qui, comme moi, essaient d'en vivre, on est clairement principalement bénévole à cause du manque de financement) et a déjà fait plus que beaucoup. Et surtout chacun ses priorités. On ne peut pas lui demander d'être constamment réactif. Simplement le fait est que nous avons une plateforme d'intégration continue dont nous ne pouvons pas dépendre avec confiance.

      Conclusion: on veut des contributeurs. :-)

      Est-ce que tout ça est documenté quelque part ?

      Ne pas demander aux développeurs. Règle n°1 de la contribution: ne pas attendre qu'on vous dise quoi faire. Le faire et nous expliquer pourquoi ce que vous avez fait est bien. Et si vous avez l'air de savoir ce que vous faites, on vous dira "cool, ça a l'air bien". On prend.
      Beaucoup de contributeurs veulent être pris par la main, mais en vrai on n'en sait pas forcément plus que vous (et notamment pour les plateformes d'intégration continue, on sait pas grand chose). Le logiciel libre est une leçon d'indépendance. :-)

      Bon ensuite, il me semble que l'admin de notre CI actuel a mis une documentation sur son process actuel, quelque part dans un dépôt git ailleurs. Mais franchement, c'était une erreur car je saurais même pas te dire où c'est.
      Faut pousser les trucs dans le dépôt git de GIMP (ou un autre dépôt à côté, hébergé au même endroit, donc facile à trouver, si y a vraiment beaucoup).

      Ça marche d'autant mieux que Blender n'a même pas besoin d'être installé pour pouvoir être utilisé (il suffit de décompresser l'archive quelque part et de lancer blender[.exe])…

      Très franchement, je n'aime pas ces tarballs de binaires. Blender fait ça, Firefox fait ça… Mais quand j'installe un logiciel, je veux une intégration à mon bureau! Je veux pouvoir lancer l'application en cherchant dans mon overview/menu, je peux pouvoir double-cliquer sur mes fichiers .blend pour lancer Blender, etc. En gros avec un fichier desktop installé au bon endroit. Bon je peux créer un tel fichier manuellement et le placer au bon endroit, mais justement idéalement je veux que ce soit fait à l'installation.
      Aussi je veux pas avoir à me demander "où mettre ce répertoire"? Sans compter la mise à jour à la main, à chaque fois. C'est vraiment pas pratique ce type de non-installeur. :-/

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Intégration

        Posté par  (site web personnel) . Évalué à 10. Dernière modification le 01 mai 2018 à 07:04.

        A propos d'intégration au bureau : le Flatpak place un menu qui ne diffère que très peu de celui installé avec le paquet Gimp de la distribution. Du coup, pas facile de savoir sur lequel cliquer pour lancer Gimp 2.10.

        N'ayant pas de proposition (qui me semble) valide je n'envoie pas de requête. Xdg propose d'afficher les noms et les descriptions, mais pas les versions. Ce qui va poser des problèmes avec la multiplication des flatpak. C'est donc plutôt chez FreeDesktop qu'il faudrait proposer une entrée "version", et qui soit utilisable pour affichage dans l'intégration de menus. Aujourd'hui ce n'est pas le cas et du coup ça donne ça : deux Gimp impossible à identifier

        ps : cette version 2.10 est hallucinante de vitesse (mes tests classiques : ouvrir une image plus grande que la quantité de ram de mon ordi), merci, merci, merci & merci

        • [^] # Re: Intégration

          Posté par  (site web personnel) . Évalué à 3.

          Pour le paquet flatpak Pitivi, il y a les versions stables et dév
          Cette dernière affiche "(Rolling) Pitivi" pour la distinguer
          Bon, c'est pas tout à fait le même use case, mais voilà

        • [^] # Re: Intégration

          Posté par  (site web personnel, Mastodon) . Évalué à 10.

          le Flatpak place un menu qui ne diffère que très peu

          En fait la raison pour laquelle tu as deux versions dans ton menu, c'est que nous avons changé l'identifiant appdata de GIMP pour suivre l'évolution du standard. Donc ton système considère les 2 GIMP que tu as installé comme différents. Mais à terme, tu ne peux avoir qu'un GIMP visible! En fait il ne peux y avoir qu'un lanceur visible par application.

          J'en suis le premier attristé, car au début, moi aussi je pensais qu'on pourrait avoir plusieurs GIMP d'installés. En fait c'est le cas: flatpak permet d'installer plusieurs versions d'un même logiciel. Et en particulier, j'ai 3 versions installées: org.gimp.GIMP/x86_64/dev, org.gimp.GIMP/x86_64/stable et org.gimp.GIMP/x86_64/master. Mais un seul est visible (dans les menus, overview, etc.).

          Il s'agit de la version "courante". Il est possible de changer la version courante par la ligne de commande. Par exemple, pour avoir la version stable en tant que version courante:

          flatpak make-current --user org.gimp.GIMP/x86_64/stable
          

          Ainsi maintenant ton overview lancera la version stable par défaut.

          Tu peux lancer une version "non courante" aussi par la ligne de commande:

          flatpak run org.gimp.GIMP/x86_64/dev
          

          La seule solution qui permettrait de voir tous les GIMP installés serait de leur donner à chacun un identifiant différent.
          Une meilleure solution serait que les GUIs de lancement se mettent à jour, et proposent (par exemple avec un menu contextuel en clic droit) de choisir quel version de l'application lancer, quand plusieurs sont installées.

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: Intégration

          Posté par  . Évalué à 3.

          Sans remettre en cause la pertinence de ton commentaire on voit bien lequel est lequel, il y a l’ancien est le nouvel icône.

      • [^] # Re: Intégration

        Posté par  (site web personnel, Mastodon) . Évalué à 9.

        Et vous n'avez pas la possibilité d'utiliser l'infrastructure de GNOME, qui semble correctement administrée ?

        • [^] # Re: Intégration

          Posté par  (site web personnel, Mastodon) . Évalué à 8. Dernière modification le 02 mai 2018 à 20:54.

          J'avais déjà demandé, notamment pour avoir un flatpak nightly. De mémoire, on m'avait répondu que cela prend déjà tellement de temps de compiler tous les projets GNOME (ou quelque chose du genre) que ce n'était pas sûr. Mais en même temps, l'histoire commune entre GIMP et GNOME est si importante qu'on m'a aussi dit que ce serait peut-être possible de faire une exception. À voir donc…

          Depuis je n'ai cependant pas ré-insisté (cad pas re-demandé). Je n'ai simplement pas le temps. En plus je ne veux pas me retrouver à administrer la CI de GIMP. Ce qui m'intéresse, c'est juste d'avoir des tests de flatpak. Et encore, même ça j'en donnerais volontiers la maintenance (ou la co-maintenance) à quelqu'un qui a les compétences et le temps.

          Donc c'est peut-être possible, oui. Si y a un projet non-GNOME qui pourrait bénéficier d'une exception, ce serait bien GIMP! Mais franchement j'aimerais bien que quelqu'un d'autre s'en occupe. À ce rythme, je vais finir en burnout sinon.

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

          • [^] # Re: Intégration

            Posté par  . Évalué à 6.

            Je n'utilise pas spécialement Gimp, mais je vais regarder ce weekend pour avoir une VM qui build gimp à partir du git (peut-être pas les flatpak tout de suite. Une chose à la fois).

            « 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: Intégration

        Posté par  . Évalué à 6.

        Merci pour ta réponse détaillée !

        Par exemple maintenant, le serveur est mort. On sait pas pourquoi et le contributeur répond pas.

        Comme le demande Okki dans un autre commentaire, y'aurait pas moyen d'avoir une instance hébergée par la fondation Gnome ? Ça permettrait peut-être au moins de s'assurer que l'instance Jenkins est toujours dispo.

        Ne pas demander aux développeurs. Règle n°1 de la contribution: ne pas attendre qu'on vous dise quoi faire. Le faire et nous expliquer pourquoi ce que vous avez fait est bien. Et si vous avez l'air de savoir ce que vous faites, on vous dira "cool, ça a l'air bien". On prend.

        Je comprends bien, mais si je me lance dans la construction d'un serveur de build, que ça me prend plein de temps, que j'arrive avec mon truc et que vous me répondez « ah bah pourquoi t'as fait ça ? On a déjà un serveur de build ici… », ça ne va pas me motiver des masses :)

        Très franchement, je n'aime pas ces tarballs de binaires. Blender fait ça, Firefox fait ça… Mais quand j'installe un logiciel, je veux une intégration à mon bureau! Je veux pouvoir lancer l'application en cherchant dans mon overview/menu, je peux pouvoir double-cliquer sur mes fichiers .blend pour lancer Blender, etc. En gros avec un fichier desktop installé au bon endroit.

        Entièrement d'accord avec toi. En ce qui concerne Blender, je pense qu'ils laissent les différentes distributions s'occuper de livrer une version de Blender dans leurs repos. La disponibilité de la dernière version est très pratique pour la communauté d'utilisateurs. On peut par exemple voir plein de vidéos sur Youtube d'utilisateurs qui testent une fonctionnalité qui n'est pas encore sortie ou qui proposent un tutorial en utilisant une version beta/RC, ce qui leur permet de finaliser leur vidéo avant la sortie de la version finale de Blender et ainsi d'être synchro dans ce qu'ils proposent :)

        • [^] # Re: Intégration

          Posté par  (site web personnel) . Évalué à 10.

          Je comprends bien, mais si je me lance dans la construction d'un serveur de build, que ça me prend plein de temps, que j'arrive avec mon truc et que vous me répondez « ah bah pourquoi t'as fait ça ? On a déjà un serveur de build ici… », ça ne va pas me motiver des masses :)

          Perso, quand je contribue à des projets libres, je fais en général comme ça :

          • Pour des petits trucs, je fais et je propose ensuite (en sachant que de temps en temps, c'est refusé parce que ça ne rentre pas dans les plans du ou des mainteneurs).
          • Pour des contributions plus conséquentes, j'en parle avant : ça peut être un mail ou une entrée dans un outil de suivi. Je dis ce que je compte faire, comment et dans quels délais. J'indique que je suis prêt à en discuter si des personnes ont un peu de temps à y consacrer.
        • [^] # Re: Intégration

          Posté par  (site web personnel, Mastodon) . Évalué à 10.

          Je comprends bien, mais si je me lance dans la construction d'un serveur de build, que ça me prend plein de temps, que j'arrive avec mon truc et que vous me répondez « ah bah pourquoi t'as fait ça ? On a déjà un serveur de build ici… », ça ne va pas me motiver des masses :)

          En l'occurrence, on en a un, mais on n'en a pas, alors…
          Ensuite ce que tu dis est le lot quotidien d'un contributeur de logiciel libre. On a tous des exemples de patchs qui n'ont pas été intégrés (pour une raison ou une autre, parfois bonnes, c'est à dire patch refusé; parfois mauvaises, par exemple pour un projet semi-mort et notre patch n'a même pas été revu). Et pas seulement des patchs faits en quelques heures, parfois des patchs qui t'ont pris quelques jours!
          Faut savoir relativiser. Ce n'est jamais agréable de ne pas avoir son travail intégré mais c'est pas la fin du monde. La vérité est que si personne ne prenait ce risque, les logiciels libres n'existeraient tout simplement pas! C'est aussi simple que ça. Les auteurs originels ne feraient jamais cette première version bugguée (de peur qu'elle ne soit pas utilisée). Les contributeurs suivants ne feraient jamais de patch (de peur qu'il ne soit pas intégré), etc.

          Alors oui, c'est bien de prendre la température un peu avant pour quelque chose d'un peu conséquent. Vaut mieux pas bosser sur un truc que les dévs principaux sont justement en train de faire en même temps, ou autre. Mais bon là, la température, je viens de te la donner: elle est froide (ou peut-être tiède, voir plus bas)!

          Le truc, c'est qu'à un moment donné, faut faire un pas en avant. Faut avoir la foi en ce qu'on fait, et commencer à bosser en y croyant. Le problème, c'est que si tu savais combien de personnes viennent nous voir en nous disant être géniaux, de super dévs pros (limite ils veulent nous donner un CV, etc. dont on n'a rien à faire), puis ils nous font "bon je peux travailler sur quoi?" Réponse: "ce que tu veux, regarde bugzilla, y a plein de bugs". Puis on n'entend plus parler d'eux.
          Ce qu'il faut bien comprendre, c'est qu'on peut pas expliquer tout à tout le monde, sinon on ferait plus rien (et GIMP serait mort depuis des années). Dans 90% du temps, c'est une perte de temps plus qu'autre chose. Je veux pas paraître méchant envers les contributeurs, ce n'est absolument pas mon but! Et franchement chez GIMP, on essaie d'être le plus ouvert et bienveillant possible. Mais il y a un fait qui est que GIMP est un très gros logiciel, très complexe, et dont beaucoup de code est basé sur des concepts complexes (modèles de couleur, composition et mélange de pixels, des algos mathématiques pris de papiers universitaires ou sources diverses, du code multi-threadé, OpenCL, GObject, etc. etc. etc.). Et beaucoup de développeurs sont simplement submergés. J'adorerais pouvoir aider chacun personnellement, mais il me faudrait plusieurs vies. Déjà que je suis presque pas payé pour mon code (clin d'œil vous pouvez aider clin d'œil), alors si en plus je dois faire le prof pas payé…

          Donc clairement les gens actifs, compétents et avec de la bouteille partent avec un certain avantage. Franchement la CI, je connais les principes, mais j'ai jamais mis ça en place moi-même et ça m'intéresse pas de le faire si je peux m'en passer. On préfère clairement des gens qui savent ce qu'ils font et nous diront "c'est comme ça que c'est le mieux", pas des débutants qui veulent apprendre et espère qu'on soit leur prof.
          Attention, je dis pas qu'on peut pas nous-même être en désaccord et donc on peut discuter. Je suis souvent en désaccord avec d'autres contributeurs, on en discute plus ou moins calmement (en restant purement technique), puis on essaie de trouver des terrains d'entente. En gros, une discussion technique entre personnes compétentes. Pas une relation prof-élève. Faut voir ça du bon côté: on cherche des égaux pas des subalternes ni des esclaves!

          Bon ceci étant dit, on discute avec un gars qui fait un paquet AppImage et qui utilise Travis: https://github.com/aferrero2707/gimp-appimage/issues/9
          Il nous parle aussi de CI pour Windows et macOS, ce qui nous intéresse. Donc on verra où ça va mener. Et peut-être que ça va aboutir quelque part avec lui.

          D'ailleurs petite remarque. On savait que cette personne faisait un paquet AppImage depuis pas mal de mois déjà. Mais il n'est jamais vraiment venu nous voir pour en discuter sur IRC (enfin pas à ma connaissance), ou mieux faire un rapport de bug pour venir expliquer comment il pourrait contribuer, avec un patch (ses scripts de build) et un plan détaillé qui montre qu'il sait ce qu'il fait. Au final, c'est moi qui me déplace sur son système de bug et qui essaie d'avoir des infos sur comment on peut collaborer. Mais franchement j'aime pas ça. J'ai fait des patchs pour des dizaines de projets. Jamais je n'ai fait les trucs dans mon coin en espérant qu'ils viennent à moi. C'est moi qui vais à eux. On peut pas juste "chasser le contributeur". On ferait ça, on aurait le temps de faire rien d'autre (pour un résultat bien moins bon). Là je fais une exception, mais bon je dois dire que ça m'amuse pas plus que ça (comme je l'ai expliqué à rallonge ci-dessus).

          Conclusion: faites le premier pas! Ça ne veut pas dire qu'on vous aime pas et qu'on ne veut pas se bouger les fesses. On fait tous ça! On fait tous constamment le premier pas, et c'est pour ça que le logiciel libre avance.
          C'est juste que l'inverse serait impossible et aucun logiciel ne pourrait jamais être écrit. Tout simplement.

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

          • [^] # Re: Intégration

            Posté par  (site web personnel) . Évalué à 8.

            Le truc, c'est qu'à un moment donné, faut faire un pas en avant. Faut avoir la foi en ce qu'on fait, et commencer à bosser en y croyant.

            ★ réponse ★ cinq ★ étoiles ★ ! ★

            "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: Intégration

            Posté par  (site web personnel) . Évalué à 3.

            C'est le genre de commentaire que l'on devrait mettre en affiche sur ce site, github, et d'autres espaces ouvert aux contributeurs.

      • [^] # Re: Intégration

        Posté par  . Évalué à 6.

        Pour répondre un peu sur les questions techniques: on a un serveur de build avec Jenkins. Parfois les builds cassent, de façon normale car par exemple on a augmenté une dépendance de version. Ça c'est pas gênant. Le problème, c'est que quand ça arrive, l'admin de cette instance Jenkins met parfois des semaines avant de corriger (et donc on se retrouve sans build check automatique pendant plusieurs semaines). Des fois, les builds cassent sans vraiment qu'on sache pourquoi aussi. Et parfois le serveur entier disparaît. Par exemple maintenant, le serveur est mort. On sait pas pourquoi et le contributeur répond pas.

        Wow ! C'est vraiment dommage quand on peut utiliser gitlab qui a une CI aux petits ognons pour ça. Toi développeur, tu contrôle l'intégration continue via un fichier dans tes sources (du coup le build de la dernière version et celui d'avant fonctionne encore) et d'avoir un runner où tu veux (sur ta machine si tu veux, qui peut être dispo 1h/jour si tu veux).

        Une fois qu'on a commencé à s'en servir, après des années de jenkins, on ne peut plus vraiment revenir en arrière.

        • [^] # Re: Intégration

          Posté par  (site web personnel, Mastodon) . Évalué à 6.

          Bon ensuite ça fait quelques années qu'on a le serveur Jenkins (et aussi des années que c'est administré à moitié). Donc ça précède (peut-être?) la CI avec gitlab.

          Aussi on n'utilise pas (encore) gitlab, mais on va y migrer très bientôt. Maintenant que GIMP 2.10 est sorti, je dirais que d'ici un mois au plus (le temps de nous laisser souffler un peu… bon je dis ça mais on a déjà commencé à bosser sur la branche GTK+3 à vitesse grand-V), on aura migré sur le gitlab de GNOME. Si ça inclut un CI interne, j'imagine qu'on pourra y passer.

          Enfin bon je suis un peu dans le flou en ce qui concerne la CI (on l'est tous un peu).

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

          • [^] # Re: Intégration

            Posté par  . Évalué à 5.

            Si vous passez à gitlab n'hésite pas à me contacter si tu veux mettre en place la CI qui va avec. Je peux pas m'engager sur le fait de vous fournir une instance de runner, mais mettre en place la configuration et jouer ça sur vos serveur (ou ponctuellement sur vos machines perso) ça devrait pas être trop compliqué :)

  • # Merci !

    Posté par  (Mastodon) . Évalué à 7.

    Merci ! Pour la dépêche, et surtout pour le logiciel…

  • # flatpak

    Posté par  (site web personnel) . Évalué à 6.

    Merci pour la super dépêche et ton travail sur GIMP !

    GIMP est ainsi disponible dans un paquet officiel flatpak. […] Il fonctionne bien, malgré quelques limitations (et même pertes de fonctionnalités à cause du modèle de sécurité et autres limitations actuelles du format).

    Tu peux nous en dire plus à ce sujet ?

    • [^] # Re: flatpak

      Posté par  . Évalué à 7.

      Qu'est-ce que c'est la différence avec un .exe ?

      Est-ce que c'est un binaire qui embarque 5Gio de librairies qu'on a déjà installé sur sa machine grâce au système de paquets ?

      • [^] # Re: flatpak

        Posté par  . Évalué à 9.

        Est-ce que c'est un binaire qui embarque 5Gio de librairies qu'on a déjà installé sur sa machine grâce au système de paquets ?

        Oui, c'est le but (même si une certaine mutualisation est possible).

        « 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: flatpak

      Posté par  . Évalué à 3.

      Tu peux nous en dire plus à ce sujet ?

      Il suffit d'essayer. Pour ma part, j'ai eu des comportements erratiques avec des fenêtres de sélection de fichiers, et plus de GMic plugins…

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: flatpak

        Posté par  . Évalué à 1.

        Il manque peut être l'accès à certains répertoires système

  • # traitement d'image non-destructif

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Nous expliquions déjà dans la nouvelle sur GEGL que le traitement en graphe signifie que le traitement d'image non-destructif sera bientôt possible.

    Ouaaah. Ça fait des années que j'attends ça ! Je n'ai jamais compris pourquoi ça n'avait jamais été une priorité pour les développeurs de Gimp, alors que c'est ce genre de fonctionnalité manquante qui empêchent clairement de se passer de Photoshop.

    • [^] # Re: traitement d'image non-destructif

      Posté par  (site web personnel) . Évalué à 8.

      Cela consomme énormément de mémoire, car chaque étape ou presque garde une copie intermédiaire du traitement, darktable était parfois dur à utiliser par exemple, à cause de ça.

      "La première sécurité est la liberté"

      • [^] # Re: traitement d'image non-destructif

        Posté par  . Évalué à 2.

        Cela consomme énormément de mémoire, car chaque étape ou presque garde une copie intermédiaire du traitement

        C'est déjà le cas puisque, par souci de sécurité, on a tendance à garder beaucoup étapes intermédiaires. Et puis, cela pourrait être une option à activer selon la quantité de mémoire dispo sur la machine…

        Poster une information ne signifie pas nécessairement adhésion

      • [^] # Re: traitement d'image non-destructif

        Posté par  (site web personnel) . Évalué à 3.

        Certes mais un pote à moi utilisait régulièrement en 2001 un filtre de déformation dynamique sur Toshop. Donc ça me semble techniquement jouable ; mais oui il faut sûrement éviter de le faire de manière naïve.

        Mais ça demande du temps de développement ; et Toshop en 2001 avait probablement nécessité plus d'années*hommes que Gimp en 2018.

    • [^] # Re: traitement d'image non-destructif

      Posté par  (site web personnel) . Évalué à 10.

      Regarde le temps qu'il a fallu pour développer GEGL et tu as ta réponse ;)

  • # Paquet ArchLinux/Manjaro

    Posté par  (site web personnel) . Évalué à 9.

    J'en profite pour contribuer, pour ceux désireux de tester sous ArchLinux/Manjaro, voilà un joli MakePKG :

    https://pastebin.com/CQq6VGyK

  • # Gimp-2.10 et Digikam

    Posté par  . Évalué à 2.

    Digikam (dont 4.9) ne peut pas afficher les vignettes des fichiers .xcf créés au nouveau format par Gimp-2.10, et ce depuis les versions Gimp 2.9. La faute incombe à Kimageformats (5.45 chez moi) qui ne prend pas en charge le nouveau format .xcf. Ce bug est signalé plusieurs fois depuis 2 ans ici et certainement ailleurs. Je constate qu'il est question de .xcf dans la préparation du futur Kimageformats-5.8 . Je suppose que le problème va bientôt pouvoir être résolu…

    Poster une information ne signifie pas nécessairement adhésion

  • # GUI ?

    Posté par  (site web personnel) . Évalué à 9.

    Je sais que la GUI de gimp est un éternel débats, très très chiant pour les dev. Entre les utilisateurs qui veulent du Photophop like, du GIMP canal historique, un truc simple ou un truc moderne, personne ne sera d'accord.

    Mais est-ce qu'il serait possible de modulariser la GUI ? La séparer du reste ? Ainsi on pourrait voir des mod de gimps simplifié, pour ceux qui mélange tout (calques/image/canevas), et certains pourraient expérimenter sans vous casser les pieds. On pourrait imaginer des mods orienté retouche photo et d'autres orientés dessins.

    "La première sécurité est la liberté"

    • [^] # Re: GUI ?

      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 30 avril 2018 à 18:31.

      C'est un peu ce qui se passe avec cette version, avec le moteur GEGL d'un côté, et GIMP qui est une interface de l'autre.
      Pitivi a fait de même il y a qqes temps, en créant un moteur indépendant basé sur GStreamer (GStreamer Editing Services) et en se rebasant dessus. De ce moment Pitivi s'est allégé de 20000 lignes de code et est devenu une interface.

  • # Feature request

    Posté par  . Évalué à 3.

    Dans la boîte de dialogue d’ouverture de fichier, le raccourcis « ctrl+L » ne fonctionne pas, c’est bête. Dans gnome, il permet de taper/coller un chemin de fichier, d’habitude.

    • [^] # Re: Feature request

      Posté par  . Évalué à 3.

      C'est probablement un problème d'intégration dû à flatpak.

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Feature request

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Dans la boîte de dialogue d’ouverture de fichier, le raccourcis « ctrl+L » ne fonctionne pas, c’est bête.

        Ben ici ça marche™. Pour info, on utilise la widget de base de GTK+. Donc on a vraiment le même comportement que toute appli GNOME et en fait même si on voulait, on pourrait pas retirer/ajouter ce type de fonctionnalité (sans implémenter notre propre widget d'ouverture de fichier, ce qu'on prévoit pas de faire).

        Tu serais pas dans le "Search" ou "Recently Used" par hasard? Dans ces emplacements, ctrl-l ne fonctionne pas. Mais dans tous les autres, ça a l'air de fonctionner sans problème (enfin pour moi).

        C'est probablement un problème d'intégration dû à flatpak.

        Faut pas tout mettre sur le dos de flatpak. Chez moi, ça marche très bien, que ce soit GIMP empaqueté dans un flatpak ou non.

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: Feature request

          Posté par  . Évalué à 2.

          Tu serais pas dans le "Search" ou "Recently Used" par hasard?

          Bien vu c’est exactement ça /o. C’est con ça a cassé mon rythme et surtout l’intuition selon laquelle si tu tapes un chemin enraciné, il devrait « marcher » quel que soit l’endroit ou tu peux t’en servir. Et surtout chez moi la boîte s’ouvre systématiquement sur le « récemment utilisé » donc il ne fonctionne pas à l’ouverture. Direction chez gtk alors… /o\

          • [^] # Re: Feature request

            Posté par  (site web personnel, Mastodon) . Évalué à 3.

            Sans doute une limitation dû à GTK+ 2, parce que je viens de tester avec d'autres applications en GTK+ 3 et ça fonctionne bien dans Récents ou Autres emplacements, par exemple.

        • [^] # Re: Feature request

          Posté par  . Évalué à 5.

          Je viens de tester le flatpak, ça fonctionne mais j'ai GIMP en anglais alors que l'interface m'indique langue du système et même en sélectionnant French et en redémarrant je reste en anglais

  • # Interface framework Qt ??

    Posté par  . Évalué à -1.

    Bonjour,
    je sais qu'historiquement c'est Gtk, mais puisqu'il y a des soucis avec Gtk, notamment sous windows, cela ne vaudrait pas le coup de faire comme beaucoup et de passser sous Qt en C++/QML ?
    Après je suppose que cela représente beaucoup de travail aussi.
    Bonne fin de journée

    • [^] # Re: Interface framework Qt ??

      Posté par  (site web personnel) . Évalué à 5.

      C'est original, d'habitude on demande de passer sous rust : https://www.reddit.com/r/rust/comments/62gzio/psa_please_stop_asking_other_projects_to_convert/

      D'après l'article c'est plutôt gtk3 qui est prévu. Et apparemment cela corrigerait les soucis de dispositifs de pointage sous windows.

    • [^] # Re: Interface framework Qt ??

      Posté par  (site web personnel) . Évalué à 10.

      S : Il y a ces rumeurs, comme quoi l’interface graphique pourrait utiliser Python et le cœur, le C.
      M : Python pour l’interface utilisateur. N’importe quoi ! Pourquoi ça ?
      S : Ça fait partie des discussions que nous avons eues.
      M : Oui, mais par le passé certains voulaient utiliser JavaScript. L’année d’avant c’était Java, encore un an avant c’était ceci et l’année suivante cela. Maintenant ils ont tous disparu.
      De tous ceux qui disaient « Je veux utiliser ceci ou cela » et « C’est vraiment de la merde, utilisons JavaScript », aucun ne fait encore partie du projet, donc…

      https://linuxfr.org/news/entretien-avec-michael-natterer-mainteneur-de-gimp

      ;)

    • [^] # Re: Interface framework Qt ??

      Posté par  . Évalué à 9.

      C'est amusant cette manie de vouloir changer quand il y a des problèmes plutôt que de chercher à résoudre les problèmes …

      • [^] # Re: Interface framework Qt ??

        Posté par  . Évalué à 6. Dernière modification le 02 mai 2018 à 10:07.

        En meme temps changer pour quelque chose qui resou le probleme et bien c'est peut etre aussi une bonne idee si le but est de resoudre le probleme :)

        Par contre dans le cas de The Gimp j'ai comme un "leger" doute sur la faisabilite de se detacher de GTK… N'oublions pas que a la base GTK veut dire Gimp ToolKit et non pas Gnome ToolKit…

        Par consequent ca doit etre bien imbrique dans le code les commandes GTK et sortir de ce toolkit voudrait probablement dire une re-ecriture quasi totale. Alors oui le fait que maintenant GEGL soit le coeur pourrait aider a cela mais je pense que GTK est encore au coeur de pas mal de chose de The Gimp.

        • [^] # Re: Interface framework Qt ??

          Posté par  . Évalué à 4.

          Si ça se trouve ils ont crées gegl juste pour faire taire les trolls de ce genre. Le but était de résoudre un bug social (enfin une requête de fonctionnalité : « je veux pouvoir répondre un message standardisé : la procédure est de coder un tap tem une interface dans ta paire « langage/toolkit » préférée au dessus de gegl aux demandes de ce type ». Il en aurait résulté des possibilités techniques intéressantes uniquement par effet de bord.

        • [^] # Re: Interface framework Qt ??

          Posté par  . Évalué à 0.

          En meme temps changer pour quelque chose qui resou le probleme et bien c'est peut etre aussi une bonne idee si le but est de resoudre le probleme :)

          Oui mais là c'est un peu comme changer de maison parce que tu as une vitre cassée … ;)

  • # Parfait ! Enfin, on va pouvoir virer les logiciels propriétaires !

    Posté par  . Évalué à 4.

    MERCI à tous les développeurs et contributeurs pour ce travail. GEGL, c'est la possibilité de travailler en 16bits. C'est LA fonctionnalité qui cantonnait GIMP à des travaux amateurs pour la retouche photo (effet peigne et tout et tout). Le passage à GEGL et donc au 16bit par canal va enfin permettre de donner à GIMP la place qu'il mérite.

    C'est énorme.

    Merci, merci, merci

  • # Gimp pas encore sous Gtk3

    Posté par  . Évalué à 9.

    Je trouve ça rigolo que Gimp ne soit pas encore sous Gtk3 quand on sait que Gtk c'est the "Gimp toolkit" !

    Pour l'histoire, si je me souviens bien, Gnome est sorti à l'époque juste après KDE (qui voulait être un CDE aka Common Desktop Environment libre) mais qui se basait sur Qt de trolltech, qui a l'époque avait une licence commerciale (avec droit d'utilisation pour un projet libre). Du coup Gnome est sorti un peu en réaction et le toolkit sélectionné était celui de Gimp, qui pour son interface avait créé ce toolkit.

    Tout ça pour dire que les enfants, ben ils sont ingrats envers leurs parents :-P

  • # Petit bug sur la depèche

    Posté par  (site web personnel) . Évalué à 1. Dernière modification le 03 mai 2018 à 12:50.

    la section sur les brosses MyPaint est en double ^

    edit: … ah bein non plus maintenant

  • # Configuration minimale

    Posté par  (site web personnel) . Évalué à 1.

    J'aimerai faire un atelier de découverte de GIMP, avec des machines anciennes (du genre P4, 1Gio de RAM…) car c'est ce dont je dispose, en plus des éventuelles machines possédées par les participants. J'y ai installé Debian avec LXDE.

    Apparemment le nouveau GIMP gèrerait mieux la mémoire, pensez vous qu'il serait judicieux d'utiliser cette version (flatpak) pour mon usage?

    Un LUG en Lorraine : https://enunclic-cappel.fr

    • [^] # Re: Configuration minimale

      Posté par  (site web personnel) . Évalué à 0.

      Quand j'ai lu la dépêche, pour moi clairement Gimp va reposer sur des architectures modernes, et commencer boiter sur des plus anciennes.
      Par exemple créer des threads utilise des ressources, car ta CPU au simple coeur va passer du temps à switcher entre eux.
      Idem avec l'utilisation de ressources matérielles….

      Bon mais s'il existe un paquet précompilée pour ta machine (ou si tu souhaites le compiler) ça vaut le coup d'essayer, car en effet c'est plus intéressant un atelier découverte avec un outil récent.

    • [^] # Re: Configuration minimale

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Même si ça part d'un bon sentiment, je ne suis pas certain que ce soit une bonne idée. Récemment, je suis tombé sur une vidéo YouTube montrant la dernière Fedora avec GNOME 3.28. Tout y était incroyablement lent. La moindre action prenait des plombes. À tel point que le démonstrateur se demandait régulièrement si ses actions étaient prises en compte, avant de se remettre à cliquer… et de voir les opérations se réaliser plusieurs fois à l'arrivée.

      J'ai tout de même trouvé le courage d'aller jusqu'au bout de la vidéo, avant de jeter un œil aux commentaires pour apprendre que l'auteur de la vidéo possédait une très vieille machine. Le souci, c'est que la plupart des gens n'iront pas jusque là et garderont une mauvaise image de ces projets qu'ils ne connaissent pas.

      Pour pouvoir faire une démo dans de bonnes conditions et que les participants ne s’exaspèrent pas de longues attentes, il faut une machine récente avec un bon processeur, suffisamment de RAM pour que ça ne swap jamais, un SSD…

      Faut vraiment que ça réponde au tac-o-tac, que la démo soit fluide et fonctionnelle.

    • [^] # Re: Configuration minimale

      Posté par  (site web personnel, Mastodon) . Évalué à 7.

      Je peux pas vraiment te dire. Comme dit Selso plus haut, un logiciel plus rapide sur des machines rapides (car capable d'utiliser le multi-cœur ou les cartes graphiques, etc.) ne veut pas forcément dire que c'est plus rapide sur des machines lentes.

      Quant à l'utilisation plus intelligente de mémoire, cela ne signifie pas nécessairement plus rapide. Notamment pouvoir travailler sur des images plus grandes que la mémoire, cela veut dire que GIMP/GEGL est capable de swapper en partie une image. C'est très probablement plus rapide que laisser l'OS swapper (car on swappe pas toute l'image). Mais swapper, c'est toujours lent. Même si tu swappes sur du SSD, ça reste incomparablement lent par rapport à du travail en mémoire.

      Y a aussi plein de choses qui améliorent la rapidité "apparente". Par exemple si tu zoomes, les changements seront appliqués d'abord sur la partie d'image visible à l'écran, etc. Mais il n'empêche que si ta machine est lente, y a pas de magie.

      En outre certaines choses sont plus rapides, et d'autres plus lentes. Des retours qu'on a, beaucoup de traitements de pixels (effets) sont incroyablement boostés. Mais y a des exceptions et certains trucs sont lents, voire plus lents qu'avant. La peinture notamment est un peu plus lente. Mais en même temps, la peinture dans GIMP 2.10 fait 1000 fois plus de choses par rapport à 2.8. Les algos de peinture dans GIMP 2.8 étaient très naïfs et simples. Dans 2.10, on fait les choses convenablement, en ce qui concerne le blending/compositing, la gestion des couleurs, etc. Donc en fait GIMP 2.10 est plus rapide mais le sentiment finale est que c'est plus lent car ça fait maintenant les choses comme il faut.

      Y a une vérité qui est que le traitement d'image est un processus complexe et lent, aussi bien niveau processeur qu'utilisation mémoire. En plus y a l'évolution des usages. Alors que y a quelques années, on travaillait en 800x600, de nos jours, on fait du 4K ou plus. Sans parler des fous furieux qui travaillent sur support physiques avec des dimensions de fous furieux.

      Conclusion: faut que t'essaies et tu vois si ça va bien pour tes usages. Personne peut vraiment te répondre car c'est du cas par cas! :-)

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Configuration minimale

        Posté par  (site web personnel) . Évalué à 1.

        Merci Jehan et autres pour vos réponses, je vais donc essayer!
        Pour les exercices, j'ai déjà prévu de ne pas utiliser d'image trop grande, pour éviter de gaspiller de la RAM: c'est vraiment pour de la découverte, pas pour travailler de gros projets.

        Un LUG en Lorraine : https://enunclic-cappel.fr

    • [^] # Re: Configuration minimale

      Posté par  . Évalué à 1.

      Dans l'ensemble, cette version n'est pas mal… mais sa lenteur est horrible. Ouvrir ou exporter une image sont des actions devenues très lentes. Ça risque de repousser de nombreux utilisateurs. Presque sept secondes quand on clique sur exporter (après avoir indiqué le nom et l'extension) pour que s'affiche les options d'exportation, c'est très, très long. La 2.8 ne me posait pas de problème et je n'ai pas la possibilité de racheter un processeur ou un ordinateur pour utiliser Gimp. C'est vraiment dommage. J'espère que ce sera amélioré dans les prochaines versions.

      • [^] # Re: Configuration minimale

        Posté par  (site web personnel, Mastodon) . Évalué à 5.

        Quel OS? En particulier s'agit-il de Windows ou macOS?

        Il y a des problèmes connus sous Windows avec plusieurs fenêtres, et notamment les fenêtres d'options d'export en effet.
        La cause de ce problème sont de "faux lecteurs de disquette" que Windows s'amuse à créer (pourquoi?! Sérieux pourquoi?) et qui sont super lents d'accès. Encore 7 secondes, tu t'en sors bien. Certains rapportent des temps d'ouverture de certains dialogues de l'ordre de la minute!
        Le contournement du problème est de désactiver les faux lecteurs de disquette dans le Panneau de Contrôle (de toutes façons, à quoi servent ces faux lecteurs? Personne ne semble savoir!).

        Si tu es sous macOS, on a aussi eu un rapport de bug similaire (mais c'est bien moins fréquent) de quelqu'un pour qui cela prenait (comme toi) presque 10 secondes. Dans son cas, le problème venait de 1,5GB de polices qui semblent être parsées (lentement!) quand on ouvre certaines boîtes de dialogue (ce qui en soit est déjà bizarre et ne devrait pas se produire).

        J'espère que ce sera amélioré dans les prochaines versions.

        Mais le vrai de vrai problème, c'est (encore une fois) qu'on n'a pas de développeurs sur ces OS! On aimerait bien que les développeurs Windows et macOS se prennent un peu en main pour une fois, et qu'au lieu de nous dire que notre logiciel marche pas, ils contribuent de leur temps.
        Donc amélioré dans les prochaines versions? Pas impossible, mais là tel que c'est parti, ces bugs peuvent aussi bien rester pendant super longtemps (alors qu'ils sont sûrement simples à corriger, ce qui est d'autant plus ridicule).

        Bon peut-être que ton problème se produit en fait sous Linux, auquel cas on veut bien un rapport de bug détaillé (de mémoire, il me semble qu'on n'a jamais eu quiconque qui nous a rapporté un tel problème sous Linux. Ici ces boîtes de dialogue s'ouvrent instantanément par exemple).

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: Configuration minimale

          Posté par  . Évalué à 0. Dernière modification le 04 mai 2018 à 21:38.

          Le contournement du problème est de désactiver les faux lecteurs de disquette dans le Panneau de Contrôle (de toutes façons, à quoi servent ces faux lecteurs? Personne ne semble savoir!).

          C'est en effet très surprenant. Je n'ai jamais eu ce problème, que ce soit sous XP, Seven, ou Windows 10 (oui j'utilise GIMP sur les trois).

          Après avoir vu le bug, il semble que la vaste majorité n'ai pas ce problème, mais que certains utilisateurs ont des lecteurs de disquettes virtuels.

          D'autres sources sur la page semblent indiquer que c'est la faute du BIOS (option pour émuler un lecteur de disquette… Pourquoi ?!).

          M'est avis que un logiciel populaire est coupable, mais comme d'habitude (habitude notée même chez Microsoft, notamment sur le blog de Raymond Chen qui parle souvent de rétrocompatibilité), c'est Windows qu'on blâme. ;-)

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Configuration minimale

            Posté par  (site web personnel, Mastodon) . Évalué à 3.

            Après avoir vu le bug, il semble que la vaste majorité n'ai pas ce problème, mais que certains utilisateurs ont des lecteurs de disquettes virtuels.

            Oui bien sûr, ce n'est pas un problème universel. Si c'est ce que mon message laissait entendre, je l'ai mal exprimé. Par contre, ce problème est relativement fréquent car on nous l'a rapporté à diverses reprises (or on sait bien que le pourcentage qui rapporte les erreurs est faible; un bug rapporté une dizaine de fois par exemple serait plutôt courant déjà). Mais "fréquent" pourrait aussi bien signifier 1 personne sur 100 par exemple (ce qui serait déjà beaucoup rapporté au nombre de personnes sous Windows).

            M'est avis que un logiciel populaire est coupable, mais comme d'habitude (habitude notée même chez Microsoft, notamment sur le blog de Raymond Chen qui parle souvent de rétrocompatibilité), c'est Windows qu'on blâme. ;-)

            Je pense que personne n'a blâmé Windows, ni ici, ni dans le rapport de bug. Affirmer cela dans ce fil de discussion me semble être tout autant une déformation de la pensée que le fait de blâmer Windows dès qu'un problème se produit. ;P

            Le problème pourrait en effet tout à fait être créé par un programme populaire dispo sous Windows. Et en effet quelqu'un a noté avoir trouvé une option dans son BIOS également. On pourrait donc s'imaginer que ce même problème pourrait se produire sous d'autres OS, mais à ce jour, il ne nous a été remonté que par des gens sous Windows. Ça pourrait dire par exemple que seul Windows fait quelque chose avec cette option du BIOS (je suis pas expert mais j'ai l'impression que beaucoup de développement BIOS/UEFI sont poussés par Microsoft) qui est une fonctionnalité additionnelle proposée seulement sous cet OS? Que le problème viendrait de l'API Windows pour lister/lire les périphériques qui ne gèrerait pas bien ces "faux périphériques" (donc ces faux périphériques existeraient aussi dans les autres OS mais ne ralentiraient pas les programmes)? Autre chose? Aucune idée. Dans tous les cas, personne n'a "blâmé" Windows. Et même s'il s'avérait que le bug viendrait bien de Windows même, je blâmerais pas Windows (ou plutôt ses développeurs). Tous les programmes ont des bugs, on fait tous des erreurs. Y a vraiment rien ni personne à blâmer dans le contexte de ce bug.

            Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

            • [^] # Re: Configuration minimale

              Posté par  . Évalué à 0.

              Merci de t'être penché sur mes problèmes, Jehan. Je suis sous Windows 7 64 bits. Je suis allé vérifié pour le lecteur de disquette, mais je n'en ai pas. Pour le Bios, je ne suis pas assez connaisseur, mais je n'ai rien vu qui évoque floppy ou disquette. Peut-être mon ordi n'est pas assez puissant non plus (pour ça que j'espère qu'il y aura de l'amélioration à l'avenir - je ne suis pas développeur). Au début, j'avais pensé à GEGL, mais ce n'est peut-être par ça. Tampis, je prendrais mon mal en patience.

              Ça, c'est pour les points négatifs. Pour les points positifs, il y en a quelques-uns qui m'ont agréablement surpris, comme le fait qu'il ne soit plus nécessaire de relancer le logiciel pour voir les changements de thèmes, par exemple, ou encore la possibilité d'éclater la vue. Je trouve également que c'est plus facile maintenant de coloriser une photo.

              Juste pour info: j'ai eu plantage de Gimp, parce que je faisais plusieurs trucs en même temps (des tests). La récupération des images (il y en avait plusieurs d'ouvertes et aucune n'était sauvegardée) a parfaitement fonctionné.

              Par contre, j'aurai une question toute bête: dans la 2.8, j'avais pu mettre des éléments comme teinte-saturation, par exemple, comme bouton dans les outils (dans le panel où il y a le crayon, le pinceau, etc). Cette possibilité a-t-elle été retirée? Je n'arrive pas à les remettre.

              • [^] # Re: Configuration minimale

                Posté par  (site web personnel, Mastodon) . Évalué à 3.

                La récupération des images (il y en avait plusieurs d'ouvertes et aucune n'était sauvegardée) a parfaitement fonctionné.

                Cool. C'est moi qui ai implémenté cette fonctionnalité. Heureux de voir que ça sert (et c'est pas la première fois qu'un retour de succès me parvient!). :-)

                j'ai eu plantage de Gimp, parce que je faisais plusieurs trucs en même temps (des tests).

                Ceci dit, même si je suis content de lire que la récupération a fonctionné, si y a eu un crash, ce serait bien de le corriger. As-tu une méthode de reproduction du crash?

                dans la 2.8, j'avais pu mettre des éléments comme teinte-saturation, par exemple, comme bouton dans les outils (dans le panel où il y a le crayon, le pinceau, etc). Cette possibilité a-t-elle été retirée? Je n'arrive pas à les remettre.

                En fait la fonctionnalité existe toujours, mais elle est dorénavant implémentée comme une opération GEGL. En fait c'est le cas de la plupart des opérations de couleur. Par conséquent, en particulier, ce ne sont plus des "outils" donc on ne peut plus les mettre dans la boîte à outil.
                Mais la fonctionnalité existe toujours (menu "Couleurs").

                Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

                • [^] # Re: Configuration minimale

                  Posté par  . Évalué à 1.

                  C'est dommage que l'on ne puisse plus mettre certaines fonctions comme bouton. C'était vraiment pratique. Au prochain crash, je ferai savoir ce qu'il en est. Je ne me souviens plus de ce qu'indiquait le message.

  • # le genre d'outil qu'il faudrait ailleurs

    Posté par  (site web personnel) . Évalué à -1.

    Pouaaaah !! Tous ces changements !!

    Il y en a une un peu gadget qui devrait également équiper de série notre navigateur préféré :

    Un tableau de bord fait son apparition permettant de suivre l'évolution de l'utilisation du CPU, le cache et le swap occupé.

    Trop souvent je vois Firefox consommer des ressources sans vraiment comprendre la raison.

  • # Gimp et RAW

    Posté par  . Évalué à 2.

    Bonjour,
    Ne sachant pas trop où m'adresser, je me suis inscrit ici.

    Mon Gimp tourne sur une debian ainsi que Darktable. Depuis la version 2.9 GIMP est capable d'ouvrir des fichier RAW via Dartktable/rawtherapee.

    Ne pouvant pas installer une version plus recente de GIMP sur la debian stretch, j'utilise donc flatpak….mais dans les preferences le greffon darktable n'apparait pas…Et evidement ça ne fonctionne pas.

    cela pourrait il venir de flatpak ?

    Merci

    • [^] # Re: Gimp et RAW

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Cela vient de flatpak. Ce n'est pas un bug mais bien une limitation du modèle de sandbox. Tout simplement GIMP cherche darktable dans le $PATH et ne le trouve pas (comme attendu sinon ce serait un bug!).
      La solution serait probablement de communiquer par dbus, ce qui a d'autres problematiques.

      Je prévois un article sur mon expérience flatpak+GIMP listant notamment les diverses limitations connues du paquet.

      La seule solution à ce jour si cette fonctionnalité t'est indispensable, c'est d'attendre un paquet de ta distrib (méthode d'installation recommandée à ce jour mais avec les problèmes de timing connus), un paquet tiers (problèmes de support) ou de compiler.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Gimp et RAW

        Posté par  . Évalué à 3. Dernière modification le 04 mai 2018 à 23:41.

        La seule solution à ce jour si cette fonctionnalité t'est indispensable, c'est d'attendre un paquet de ta distrib (méthode d'installation recommandée à ce jour mais avec les problèmes de timing connus), un paquet tiers (problèmes de support) ou de compiler.

        On peut installer le gimp qui est dans les dépôts unstable sur debian stable, ça marche très bien, je l'ai fait.
        Il faut rajouter les dépôts sid main et contrib dans debian.list, installer gimp et liblcms2-2_2.9-1__amd64.deb (gimp amène une demi-douzaine de dépendances avec lui), puis retirer les dépôts sid

        Gimp s'installe même si on n'installe pas libcms2, mais il ne démarre pas.

      • [^] # Re: Gimp et RAW

        Posté par  (site web personnel) . Évalué à 0.

        Salut,

        J'aime pas du tout les Flatpack et compagnie :(

        Bien entendu que les problèmes concerne l'intégration avec le reste :(

        C'est comme Avidemux, quel tristesse de voir une boite à outils si précieuse péricliter, notamment sous la forme d'une appImage mal intégrée :(

        Pour GIMP, j'utilise avec un système GNU Ubuntu, le PPA otto-kesselgulasch/gimp-edge et jusqu'à présent, j'avais droit aux "dernières" versions de développement, 2.9. Pourquoi n'ai-je pas "droit" par ce biais à une 2.10 ? :(

        Quand j'en ai les moyens, je donne un peu d'argent à Lila pour soutenir le projet GIMP (et ZeMarmot !)… J'en profite pour encourager les développeurs à garder en tête l'usage des systèmes de paquetage prévus par les distributions. Et je croise les doigts pour que ces systèmes survivent à la "mode" des Flatpack, appImage, Snap et cie :/

        • [^] # Re: Gimp et RAW

          Posté par  (site web personnel, Mastodon) . Évalué à 10.

          Salut,

          Pour GIMP, j'utilise avec un système GNU Ubuntu, le PPA otto-kesselgulasch/gimp-edge et jusqu'à présent, j'avais droit aux "dernières" versions de développement, 2.9. Pourquoi n'ai-je pas "droit" par ce biais à une 2.10 ? :(

          Aucune idée! Nous (l'équipe qui développe GIMP) ne sommes pas les mainteneurs de ce PPA, n'avons aucun contrôle dessus (et n'en avons jamais eu). On est conscient que c'est confus pour les gens de l'extérieur, mais on ne peut être tenu pour responsable s'il n'est pas mis à jour. :P
          C'est un peu l'une des bases du logiciel libre: n'importe qui peut redistribuer le logiciel.
          Par contre bien entendu, lorsque ce n'est pas nous qui redistribuons, nous ne donnons aucune garantie (en particulier on ne peut pas vérifier comment c'est construit et si y a pas eu "d'ajouts").

          Quand j'en ai les moyens, je donne un peu d'argent à Lila pour soutenir le projet GIMP (et ZeMarmot !)…

          Je sais bien. ;-)
          Merci beaucoup! :-)
          D'ailleurs j'ai un email de réponse en retard pour toi, si ma mémoire est bonne. En fait depuis quelques semaines (depuis la RC1 et ça a explosé encore plus avec la sortie de GIMP), ma boîte email est devenue folle et se remplit à vitesse grand-V (c'était déjà le cas avant, mais je ne pensais pas que ça pouvait être pire). J'ai plein d'emails en retard. :-/ Désolé, j'essaierai de répondre (de manière générale, j'essaie de répondre à tout, mais c'est pas facile).

          J'en profite pour encourager les développeurs à garder en tête l'usage des systèmes de paquetage prévus par les distributions.

          Alors comme je l'ai dit à plusieurs reprises sur divers canaux de communications: flatpak n'est pas notre canal de distribution du logiciel conseillé! La méthode conseillée est toujours les "paquets de la distribution". C'est écrit sur la page de téléchargement:

          The flatpak build is very new and therefore may have shortcomings. It's very likely your Unix-like system distribution already comes with a GIMP package. It is the preferred method of installing GIMP, as the distribution maintainers take care of all the dependencies and bug fix updates. Nevertheless, note that many distros decide to pin a specific version of GIMP to their releases, whereas our flatpak will follow GIMP releases closely.

          Flatpak a plusieurs avantages sur ces paquets, mais eux ont l'avantage d'avoir toutes les fonctionnalités! Tant qu'on perdra des fonctionnalités avec le paquet flatpak, on ne pourra pas dire que c'est la "méthode d'installation conseillée".
          Par contre oui on voit juste un gros bouton flatpak et cela peut faire croire que c'est la méthode conseillée, mais c'est uniquement car par définition on ne peut pas faire de gros bouton pour votre distribution!

          Et je croise les doigts pour que ces systèmes survivent à la "mode" des Flatpack, appImage, Snap et cie :/

          Cela ne dépend absolument pas de nous. Nous sommes comme tout le monde et sommes ceux qui suivent. Les gens veulent des Flatpak/Snap/AppImage et au bout d'un moment je me suis laissé aller à choisir un des systèmes. Pourquoi Flatpak plutôt qu'un autre? Il m'a paru plus intéressant à long terme, mais mon choix a été superficiel, soyons clair. Je crois qu'en réalité, on ne pourra pas savoir lequel sera le plus répandu, sauf à avoir une boule de cristal. Par contre maintenir cela me prend du temps et je ne vais pas maintenir un autre système, ça c'est certain.
          Quand aux systèmes classiques, survivront-ils? Je le pense, mais encore une fois, cela n'a rien à voir avec nous. Que les RPM/DEB ou autre systèmes de paquets survivent ou non n'est, n'a jamais été et ne sera probablement jamais aucunement de la responsabilité des dévs GIMP.

          Pour tout dire, c'est super dur d'être au milieu de tout ça. On se fait insulter de tous les côtés. Quand on n'avait aucun paquet indépendant (on disait aux gens juste "regardez les paquets de la distribution"), on se faisait attaquer régulièrement par les linuxiens ("vous vous en foutez des gens sous Linux, on est des citoyens de seconde zone, etc."), alors même que GIMP sous Linux est 100 fois plus stable que sous tous les autres OS et que nous sommes quasi-tous sous Linux nous-même!
          Donc on en choisit un (flatpak, ça aurait pu être un autre, mais c'est comme ça), maintenant l'un des premiers commentaires mécontents que j'ai lu (sur reddit, je crois?) c'était un gars sous Windows qui se plaignait car l'installateur Windows était pas encore sorti (alors que le flatpak si, en premier, pour la première fois!) et disait qu'on considérait les gens sous Windows comme des citoyens de seconde zone (y a comme un air de déjà-vu!) et qu'il avait décidé de ne plus jamais utiliser GIMP!
          Au passage, sur Twitter, on s'est fait accusé de vouloir diviser la communauté car on utilisait pas Snap.
          Et les partisans AppImage nous poussent de plus en plus également. Etc. Etc.

          Dans tous les cas, on gagne jamais et quoiqu'on fasse, on est des méchants. :-/
          La vérité, c'est que si quelqu'un contribuait un Snap ou un AppImage en processus upstream, on les accepterait. Si quelqu'un voulait faire un PPA "officiel", mais pareil avec processus bien défini et transparent, on serait pour. Le truc c'est que les gens qui font ces paquets divers viennent jamais nous voir.
          Quant aux installeurs Windows et paquets macOS, si on avait des contributeurs qui voudraient les maintenir et les sortir en temps et en heure, on les accueillerait les bras grands ouverts. Là aussi y a même des gens extérieurs qui font des paquets plus rapidement que nous mais ils ne sont pas intéressés par faire le paquet officiel (ils préfèrent faire un paquet tiers, pour une raison ou une autre).

          De notre côté, on fait comme on peut. Et au passage, on se fait accuser de tous les maux. Notamment celui d'être responsable si les systèmes de paquets classiques venaient à disparaître, semblerait-il. :P

          Bon je veux pas paraître aigri, et en plus tu es un gros contributeur de ZeMarmot, donc je sais bien que tu ne penses pas cela ainsi. C'est juste un sujet si sensible qu'on entend 10 fois par jour. Ça devient dur et très fatigant. On fait ce qu'on peut, au maximum, mais y a toujours des gens pour pas aimer, et certains (pas toi, bien sûr) sont même très virulents, ce qui rend le sujet d'autant plus sensibles quand d'autres, plus posés (donc toi), en sont mécontents. Or comme je m'empêche de répondre à ceux qui abordent le sujet violemment ("don't feed the troll"), ben c'est les gens posés qui se prennent la grosses explication, laquelle déballe des jours de frustration emmagasinée! Désolé pour ça!

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

          • [^] # Re: Gimp et RAW

            Posté par  (site web personnel) . Évalué à 2.

            Du coup, c'est moi qui suis désolé de te mobiliser à écrire à ce point sur le sujet :( Tas bien mieux à faire j'imagine :)

            Je vous remercie pour le Flatpak qui permet en effet de rapidement installer et utiliser une version récente sous différents systèmes GNU/Linux.

            Jehan, j'apprécie tout ton travail, et ta méthode, ZeMarmot et tout et tout :) Qu'il n'y ai aucun doute là dessus ! No stress donc, par rapport à mon courriel. Pour tout dire, je l'ai même écrit alors que j'ignorais la sortie 9.10 et ton annonce ici-même :d..

            Le message doit s'adresser à d'autres, que je souhaite donc encourager ;)

          • [^] # Re: Gimp et RAW

            Posté par  . Évalué à 10.

            J'imagine que pour quelques hargneux qui se font entendre, il y en a des milliers qui vous sont reconnaissants pour l'hénaurme travail fourni mais qu'on n'entend pas. C'est évidemment dommage que ce soit justement ces misérables unités qu'on entend et qui donc te mettent à juste raison dans un état d'énervement que tu ne mérites pas de connaître.

            Donc, au nom de tous les anonymes qui profitent du gigantesque travail de l'équipe complète de Gimp-ZeMarmot-GEGL etc., acceptez nos remerciements dont le niveau ne peut être rendu par écrit. (et à titre personnel, j'ai fait une modeste contribution à ZeM).

            Il paraît assez évident que le plus important est que la nouvelle version existe, avec ses centaines de nouveautés et améliorations ; le système de paquetage suit au rythme qu'il doit suivre, la version (empaquetée) finira bien par arriver sur notre bureau, par un moyen ou par un autre : Gimp est un acteur majeur dans le monde du libre ET dans celui du graphisme, il est évident qu'il apparaîtra tôt ou tard où il doit apparaître.

            Mince, vous faites à une poignée d'individus un logiciel qui se situe dans la même cour de récré que Toshop et ses centaines (ou plus ?) de concepteurs payés. Et y en a qui trouvent ça insuffisant ? Gomme-les d'un trait rageur de l'outil "erase" et contemple le nouveau calque ainsi assaini. ;-)

        • [^] # Re: Gimp et RAW

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Flatpak est un projet encore jeune, qui possède bien évidemment des lacunes. Et comme on peut le constater, que la version Flatpak de GIMP ne puisse pas accéder à darktable ou RawTherapee pour l'import des fichiers RAW est vraiment ennuyeux.

          Mais au fil des versions, la technologie s'améliore. Faut se dire qu'un jour, ça sera parfaitement au point, et que ça sera réellement une grande avancée pour les utilisateurs et les développeurs.

  • # Question sur Gimp-2.10 et openraster

    Posté par  . Évalué à 1.

    Avec Gimp-2.10 , l'utilisation (lecture écriture) du format .ora (openraster) pour remplacer .xcf est elle sûre? J'ai fait des tests, cela semble marcher mais il faudrait voir sur un plus long terme.

    Poster une information ne signifie pas nécessairement adhésion

    • [^] # Re: Question sur Gimp-2.10 et openraster

      Posté par  (site web personnel, Mastodon) . Évalué à 7.

      Rien ne peut remplacer XCF. Ce format est fait pour être au plus proche des fonctionnalités de GIMP. Par conséquent, il contient des fonctionnalités qu'on ne trouve probablement dans aucun autre format. Et dans tous les cas, il n'existe aucun format qui possède toutes les fonctionnalités présentes dans XCF (bon peut-être TIFF, je sais pas, mais ce format est juste une sorte de fourre-tout qui a 10000 fonctionnalités mais aucun logiciel probablement pour tout implémenter :P).

      OpenRaster est donc un format d'échange qui a pour but de contenir le plus de fonctionnalités possibles des divers logiciels qui le poussent (dont GIMP), ou au moins toutes les fonctionnalités communes, mais à ce jour il en possède encore très peu. Un jour peut-être, je dis pas…
      Par exemple, OpenRaster à l'heure actuelle ne peut monter qu'à 16-bit par canal.

      En outre la standardisation a été au point mort depuis quelques années car la personne qui la menait était un peu aux abonnés absents dernièrement. Y a quelques semaines, pendant LGM, y a eu une réunion, à la suite de quoi, un fork a été fait. D'un côté, je n'aime pas beaucoup l'idée car cela peut s'apparenter à une prise de pouvoir, mais bon en même temps, au bout d'un moment, si on n'a pas de réponse, faut bien faire quelque chose. Donc pour l'instant, je soutiens ce revirement.
      Notons qu'il n'y a aucun conflit avec le mainteneur précédent, c'est juste qu'il n'est plus actif sur le sujet.
      En conséquence le format OpenRaster lui-même a très peu évolué depuis plusieurs années.

      Je suggère donc de rester en XCF comme format de travail interne. Mais oui, exporter en ORA pour continuer le travail sur un autre logiciel est une bonne idée (ce format est fait pour ça).

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Question sur Gimp-2.10 et openraster

        Posté par  . Évalué à 2.

        Merci pour toutes ces informations bien utiles. En tant qu'utilisateur de Digikam et de Gimp-2.10, je m'intéresse au format .ora parce que le nouveau format .xcf n'est pas supporté actuellement par kimageformats, programme qui permet d'afficher les vignettes dans Digikam. Pour résumer, actuellement, Digikam affiche les vignettes .ora mais pas celles des .xcf créés avec Gimp-2.10. C'est un vrai problème, j'utilise donc .ora pour visionner mes .xcf dans Digikam en attendant une évolution de kimageformats. Donc création de deux fichiers pour une image (!). Cela fait un moment (presque 2 ans) que les nouveaux .xcf, depuis Gimp-2.9, posent un problème à Digikam. J'ai cherché de la doc sur le net concernant le nouvau format .xcf, je n'ai pas trouvé grand chose. Si quelqu'un a un lien, je suis preneur…

        Poster une information ne signifie pas nécessairement adhésion

        • [^] # Re: Question sur Gimp-2.10 et openraster

          Posté par  (site web personnel, Mastodon) . Évalué à 5.

          Salut

          Cela fait un moment (presque 2 ans) que les nouveaux .xcf, depuis Gimp-2.9, posent un problème à Digikam.

          Bon les XCF produits par 2.9, par nature, ce sont des XCFs expérimentaux (même si on a continué à suivre un processus assez strict d'incrémentation des versions et de compatibilité pendant le développement, ce qui explique qu'on passe de XCF v3 dans GIMP 2.8 à XCF v13 dans 2.10). Donc on s'attendait pas à ce que qui que ce soit cherche à implémenter une cible mouvante.

          J'ai cherché de la doc sur le net concernant le nouvau format .xcf

          Ben c'était dans le dépôt de GIMP, tout simplement, même si c'était pas à jour.
          J'ai passé une bonne partie de la journée d'hier et d'aujourd'hui à la mettre à jour. Et je pense que c'est plutôt à jour maintenant: https://git.gnome.org/browse/gimp/log/devel-docs/xcf.txt

          Bon je sais bien que tu es au courant, car j'ai vu ton message sur le suivi de bug KDE, mais c'est surtout pour l'annoncer plus publiquement si d'autres veulent essayer d'implémenter XCF.
          S'il y a encore des manques, erreurs dans ce document, ne pas hésiter à ouvrir un rapport de bug dans l'outil de suivi de GIMP.

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

          • [^] # Re: Question sur Gimp-2.10 et openraster

            Posté par  . Évalué à 2.

            Bon les XCF produits par 2.9, par nature, ce sont des XCFs expérimentaux (même si on a continué à suivre un processus assez strict d'incrémentation des versions et de compatibilité pendant le développement, ce qui explique qu'on passe de XCF v3 dans GIMP 2.8 à XCF v13 dans 2.10). Donc on s'attendait pas à ce que qui que ce soit cherche à implémenter une cible mouvante.

            On comprend mieux maintenant pourquoi les dev de Kimageformats étaient dans l'expectative depuis deux ans concernant la prise en charge des nouveaux XCF. Merci pour cette mise à jour de la documentation et tout ton travail sur Gimp.

            Poster une information ne signifie pas nécessairement adhésion

  • # Quid de la conversion du RVB au CMJN

    Posté par  (site web personnel) . Évalué à 1.

    Bonsoir,

    Je suis un aficionados de GIMP ; je soutiens ce logiciel graphique et j'aimerai d'ailleurs que son financement ressemble à Thunderbird ou eelo (projet smarthpone de Gaël Duval [concepteur de la suite Mandrake (mandriva)]) .
    Je suis un travailleur (informaticien, musicien, gestionnaire administratif, comptable et homme de ménage) acharné et n'ai donc pas beaucoup de temps pour l'écris et la lecture. Je ne prend que ce qui m'intéresse.
    Gimp m'intéresse au plus au point à tout les niveaux. Dans cet article, peut-être un peu trop long pour le peu de temps que j'ai à y consacrer, je n'ai pas vu mention du problème au niveau impression professionnel ; c'est à dire la conversion du RVB au CMJN.

    Un point crucial, enfin, il me semble.

    Vive GIMP \m/ (_) \m/

    Pas besoin d'être un pro pour aider la communauté Débiane : utilisez simplement apt-p2p

    • [^] # Re: Quid de la conversion du RVB au CMJN

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      GIMP 2.10 peut faire du softproofing en paramétrant un profil colorimétrique de sortie (qui peut être du CMYK). Mais le format interne reste à ce jour du RGB seulement.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Quid de la conversion du RVB au CMJN

      Posté par  (site web personnel) . Évalué à 4.

      À une époque, les développeurs de GIMP expliquaient (à mon souvenir) que les formules mathématiques de conversion RGB / CMJN étaient verrouillées par des brevets logiciels (à l'instar des GIF et autres MPEG trucs) :( À tel point qu'il était illégale de fournir un logiciel libre qui permettrait de manipuler les pixels en CMJN :(

      Ensuite, bien pratique le fait de pouvoir s'en passer donc :)

      Je n'ai pas le temps de retrouver ça mais il y a des articles très techniques et détaillés qui expliquent pourquoi il n'est pas forcément pertinent de travailler les photos et autres images matricielles (constituées de pixels) en CMJN ou (“CMYK” en anglais).

      En effet, les photos ou scann' sont en RVB (ou “RGB“ en anglais) de manière naturelle du fait des capteurs de numérisation. Toute la richesse de l'information est donc en RVB et peut très bien le rester…

      CMJN est propre au système d'impression. Cela dépend de chaque imprimante, offset ou autre, des encres, du papier, des réglages, du type de lumière avec laquelle le support sera ensuite visionné (lumière du jour, extérieur, ou d’intérieur, allogène dans une galerie ?).

      La gestion des couleurs, permet globalement déjà de nous aider à ne pas trop sortir du gamut d'impression, en fonction d'un profil, propre à une imprimante par exemple. Nous évitons ainsi les vert "fluot" par exemple.

      Pour le document à transmettre à l'imprimeur, de nos jour, le fichier peut très bien être en RGB. Sinon, pour la quadri', personnellement j'utilise Scribus…

      Cf. → https://linuxfr.org/users/space_e_man/journaux/scribus-pour-notre-journal-oxygene

  • # Difficultés avec des scripts

    Posté par  (site web personnel) . Évalué à 1.

    Bonjour,

    Ayant tout juste installé la bestiole, je l'explore en ce moment et suis ravie des nouvelles fonctions que je découvre au fur et à mesure.
    J'essaie par contre des scripts ajoutés (Eg, FX Foundry et un autre pack d'effets et filtres) et avec certains j'obtiens des messages d'erreur.

    Message 1

    Message 2

    Message 3

    Message 4

    Pour autant le filtre s'applique, du moins il a l'air, mais il me faut revenir sur l'étape précédente dans l'historique pour qu'il s'affiche.
    J'ai changé la place des fichiers des scripts, dans le Home ou à la racine (à partir de usr ou de app que j'ai dû créer) mais rien n'y fait.
    Y aurait-il quelque chose à faire en particulier pour régler ce souci ?
    Merci.

    Ubuntu 16.04.4

  • # GIMP 2.10 lenteur sous windows

    Posté par  . Évalué à 2.

    Bonjour,

    Je vous signale beaucoup de lenteur sous GIMP2.10 notamment pour la retouche des masques, la sélection par zones, la sélection des images ouvertes, le chargement et l'enregistrement des fichiers, etc…

    Ma configuration est Windows 7 pro 64 bits, processeur Intel i7 8 cœurs, 16 Go de mémoire, disque dur SSD de 512 Go, carte graphique AMD radeon.

    désolé mais il va falloir que je repasse sous la 2.8.22

    En attendant je peux toujours faire des tests si vous le souhaitez.

    Cordialement

  • # Hall-edge-mask-sharpen.scm

    Posté par  (site web personnel) . Évalué à 2.

    Et là, c'est le drame !
    Le script génial d'amélioration des images que j'utilise depuis des années ne fonctionne plus avec cette version de GIMP.

    J'ai beau essayer de trouver un substitut en passant par Filtres -> Améliorations -> Renforcer la netteté je n'obtiens rien de vraiment efficace et sans prise de tête comme pouvait l'être mon bon vieux smart sharpening :-(

    • [^] # Re: Hall-edge-mask-sharpen.scm

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Rapport de bug ouvert juste maintenant: https://bugzilla.gnome.org/show_bug.cgi?id=796368

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Hall-edge-mask-sharpen.scm

        Posté par  (site web personnel) . Évalué à 3.

        10000000 mercis !

        • [^] # Re: Hall-edge-mask-sharpen.scm

          Posté par  (site web personnel, Mastodon) . Évalué à 10.

          Bon bah voilà, le diagnostic est fait. Ce script utilisait des constantes de GIMP 1.x (ça aurait été du 2.x, GIMP aurait assuré la compatibilité), qui étaient dépréciées depuis longtemps. Les gens qui l'ont écrit ont eu plus de 15 ans pour mettre à jour leur script. On peut difficilement dire qu'on leur a pas donné le temps avant de virer les APIs dépréciées. :p

          Ensuite tu peux toujours essayer de mettre à jour le script. C'est peut-être pas trop dur.

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

          • [^] # Re: Hall-edge-mask-sharpen.scm

            Posté par  (site web personnel, Mastodon) . Évalué à 8.

            Ah patrick_g, pour pas te laisser dans la mouise tout seul, Mitch donnait aussi la référence au fichier auquel te référer pour porter tout seul ton script. Tu as vu?

            Reference: gimp-2.8: libgimp/gimpcompat.h

            Et je te donne un lien: https://gitlab.gnome.org/GNOME/gimp/blob/gimp-2-8/libgimp/gimpcompat.h
            Et j'ai même testé (en me référant donc au dit fichier): il suffit de remplacer "WHITE-MASK" par "ADD-WHITE-MASK" (ligne 94) puis "VALUE-LUT" par "HISTOGRAM-VALUE" (ligne 118).
            Et ton script marche (testé et approuvé sur une image floue).

            D'où l'utilité de bien lire les réponses sur les rapports de bug. Notre but n'est pas de laisser les gens dans la merde. :-)
            Je précise car je me suis soudainement dit que ce n'avait peut-être pas été clair qu'on donnait la solution pour réparer soi-même le problème.

            Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.