Evolutions de GIMP

Mumu · Mars 11, 2010, 12:59:01

Bonjour à toutes et tous,

Savez-vous quels sont les évolutions prévues pour les futurs versions de GIMP ? Un rapide coup d'oeil sur le site, coup d'oeil fatigué certe, ne m'a pas permis de le savoir...

Bref, va-t-on bientôt avoir la gestion des couleurs autrement qu'en 8 bit ? J'avoue que c'est surtout ce que j'attends le plus.

Va-ton bientôt avoir des calques de réglage ?

Votre avis ?

Franciscus Corvinus · Mars 12, 2010, 00:55:17

http://www.gimp.org/docs/userfaq.html#Future
http://www.gimpusers.com/tutorials/gimp-2-8-new-features.html

Je pense que ce que tu attends viendra dans la version 2.10/3.0, ce qui risque de prendre du temps. Si tu cherches un freeware, il y en a d'autres qui peuvent te satisfaire. Il faudrait que je recherche le nom, mais je sais qu'il y en a un qui fonctionne en 16 bits par couleur.

cptcv · Mars 12, 2010, 11:53:28

Tu as Krita qui gère le 16 bits mais perso je le trouve très lent.
http://www.koffice.org/krita/

Mumu · Mars 12, 2010, 13:11:19

Merci pour vos réponses. En fait je ne cherche pas tellement à changer de logiciel, je suis maintenant bien habitué à GIMP, mais surtout à savoir quand auront lieu ces évolutions...

Il ne me reste plus qu'à attendre

tout en continuant à utiliser les possibilités actuelles.

cptcv · Mars 12, 2010, 13:52:36

Ce qui est dommage avec Gimp c'est que manifestement les dev ne jugent pas le 16 bits comme important et que du coup beaucoup de monde se sont mis à chercher des solutions alternatives et ont abandonné Gimp. Perso je l'utilise de moins en moins à cause de cela.
Pour le traitement de mes photos je suis passé à Bibble bien qu'il soit proprio.

Franciscus Corvinus · Mars 12, 2010, 15:24:29

Oui, le 16 bit est un sujet sulfureux, et il doit etre tres difficile pour les developerus de Gimp de trancher: d'une part les utilisateurs le demandent a cors et a cris; d'autre part les demonstrations de sa vrai utilite sont la plupart du temps soit insuffisantes, soit completement foireuses.

Merci pour Krita, c'est bien ca que j'avais en tete.

cptcv · Mars 12, 2010, 16:55:42

Citation de: Franciscus Corvinus le Mars 12, 2010, 15:24:29
Oui, le 16 bit est un sujet sulfureux, et il doit etre tres difficile pour les developerus de Gimp de trancher: d'une part les utilisateurs le demandent a cors et a cris; d'autre part les demonstrations de sa vrai utilite sont la plupart du temps soit insuffisantes, soit completement foireuses.

Merci pour Krita, c'est bien ca que j'avais en tete.

Ce message le montre bien: https://lists.xcf.berkeley.edu/lists/gimp-developer/2009-December/023935.html.

De mon point de vue je me fous des nouvelles fonctionnalités vu que de toute façon tant que le support du 16 bits n'est pas là je ne les utiliserai pas ...

faro63 · Mars 12, 2010, 23:01:54

Citation de: cptcv le Mars 12, 2010, 13:52:36
Ce qui est dommage avec Gimp c'est que manifestement les dev ne jugent pas le 16 bits comme important et que du coup beaucoup de monde se sont mis à chercher des solutions alternatives et ont abandonné Gimp. Perso je l'utilise de moins en moins à cause de cela.
Pour le traitement de mes photos je suis passé à Bibble bien qu'il soit proprio.

Tu vois bien que toi aussi tu utilises du libre et du proprio quand c'est mieux (confère le fil NX2 sur Linux) ...

cptcv · Mars 13, 2010, 03:31:57

Citation de: faro63 le Mars 12, 2010, 23:01:54
Tu vois bien que toi aussi tu utilises du libre et du proprio quand c'est mieux (confère le fil NX2 sur Linux) ...

Là faut dire qu'ils me gavent tellement, ça fait au moins 5 ans que "tout le monde" leur réclame le support du 16 bits et qu'ils ont toujours une bonne raison pour repousser à la version suivante que ça m'a gonflé et j'ai craqué.

faro63 · Mars 13, 2010, 08:06:59

Je pense que c'est un peu la "limite" du libre , mais quand les éditeurs de proprio proposent (et n'imposent pas) une offre plus étoffée techniquement, bon il ne faut se mettre une barrière idéologique .... Je reste néanmoins admiratif du boulot des gars qui arrivent a faire du 100 % libre comme Stougard... et puis le libre même s'il y a des lenteurs dans l'évolution, globalement il a bien progressé depuis sa naissance alors même si on rencontre quelques carences, c'est quand même une belle réalisation...

Matou · Mars 13, 2010, 15:45:01

Bonjour,

Effectivement la demande des photographes pour pouvoir traiter des images 16 bits dans Gimp est très forte. Cela semble maintenant prévu pour la version 3.0, mais les fondations sont posées dans la version 2.8 avec l'utilisation d'une librairie interne de traitement d'image nommée GECL.
En gros, cela reflète le fait que le codage initial de Gimp supposait que les images seraient toujours en 8 bits par couleurs, et même en RVB. Quand on fait ce genre d'hypothèse, il est très difficile de les modifier. C'est pour cela que le support des 16 bits par canal a été sans cesse repoussé.
Oui, c'est dommage.
Pour le moment, la prochaine version est la 2.8, qui apportera semble t'il principalement :
- le groupage de calques,
- la rotation/inclinaison/allongement des brosses,
- l'édition des textes dans leur calque (et non pas dans une fenêtre séparée),
- l'ajout de libellés aux "ressources" (brosses, textures...).
La version 3.0 devrait arriver dans environ un an. Oui, c'est long et en plus le passé rend prudent quant aux annonces.
Une variante de Gimp existe, qui corrige le manque du 16 bits : il s'agit de Cinepaint. Malheureusement, c'est une vieille copie de Gimp maintenue par un développeur isolé, avec un rythme d'évolution lent.
Le logiciel Krita est censé gérer les couleurs sur 16 bits, mais je ne l'ai pas utilisé.

Pour le moment, je me contente de Gimp 2.4 sur Linux, et une plus vieille version sur Windows. Ces versions dépassent déjà mes capacités, je ne peux donc pas écrire pour les experts, je ne fait que résumer ce que j'ai trouvé rapidement sur Internet.

cptcv · Mars 15, 2010, 11:13:24

Citation de: Matou le Mars 13, 2010, 15:45:01
Bonjour,

Effectivement la demande des photographes pour pouvoir traiter des images 16 bits dans Gimp est très forte. Cela semble maintenant prévu pour la version 3.0, mais les fondations sont posées dans la version 2.8 avec l'utilisation d'une librairie interne de traitement d'image nommée GECL.

GECL est déjà utilisé dans la 2.6, il devait permettre d'avoir le support du 16 bits dans la 2.8. Maintenant ils nous disent que se sera dans la 3.0 et dans un 1 an, ils nous diront que ça sera pour la 3.2 ...

Citation de: faro63 le Mars 13, 2010, 08:06:59
Je pense que c'est un peu la "limite" du libre

Non pas vraiment car rien n'empêche quelqu'un de décider de forker alors qu'avec du proprio quand l'éditeur ne veut pas t'es coincé...

Lictor · Mars 16, 2010, 15:02:29

Citation de: faro63 le Mars 13, 2010, 08:06:59
Je pense que c'est un peu la "limite" du libre

Non, c'est une limite du libre quand 1/ il est en position de monopole 2/ il est géré par une équipe déconnectée des utilisateurs et de leurs besoins.
Sur d'autres projets Open Source, notamment pour tout ce qui est outil de développement, les choses vont normalement extrêmement vite. Sauf que dans ces cas, il y a une vraie concurrence entre approches Open Source (et proprio d'ailleurs) et qu'en plus, les équipes de développement n'ont pas de distance par rapport aux besoins des utilisateurs...

C'est pour ça que pour moi, l'intérêt du libre diminue avec l'éloignement du coeur de cible: les serveurs et les outils de développement. Adobe peut se payer des photographes et graphistes pour faire les études d'ergonomie et de besoins, je ne suis même pas certain qu'un projet comme Gimp ait des photographes ou graphistes à plein temps...

faro63 · Mars 16, 2010, 20:18:05

Citation de: Lictor le Mars 16, 2010, 15:02:29
Non, c'est une limite du libre quand 1/ il est en position de monopole 2/ il est géré par une équipe déconnectée des utilisateurs et de leurs besoins.
Sur d'autres projets Open Source, notamment pour tout ce qui est outil de développement, les choses vont normalement extrêmement vite. Sauf que dans ces cas, il y a une vraie concurrence entre approches Open Source (et proprio d'ailleurs) et qu'en plus, les équipes de développement n'ont pas de distance par rapport aux besoins des utilisateurs...

C'est pour ça que pour moi, l'intérêt du libre diminue avec l'éloignement du coeur de cible: les serveurs et les outils de développement. Adobe peut se payer des photographes et graphistes pour faire les études d'ergonomie et de besoins, je ne suis même pas certain qu'un projet comme Gimp ait des photographes ou graphistes à plein temps...

J'avais mis le mot limite entre guillemets car je ne sais pas comment qualifier ce que justement tu expliques... Je ne sais pas si le coeur de l'open source c'est les serveurs et le développement, quand on lit les déclaration de Marc Shuttleworth , la cible c'est bien l'OS complet avec les utilitaires de base pour les pays ayant peu de ressource, et l'arrêt des pratiques commerciales monopolistiques de MS. Bon, maintenant plus on pousse techniquement les applications, moins cela concerne la majorité des utilisateurs, cela me parait normal.
Alors effectivement les développements deviennent moins rapides car il y a de - en - de personnes qui s'y collent. Je ne sais pas si nous pouvons y contribuer, (moi je suis chimiste de formation), et même être un bon béta-testeur pour des applications poussées comme Gimp 16 Bits , je ne pense pas que je puisse être réellement utile , dommage

reder · Mars 18, 2010, 17:20:22

Citation de: Matou le Mars 13, 2010, 15:45:01
En gros, cela reflète le fait que le codage initial de Gimp supposait que les images seraient toujours en 8 bits par couleurs, et même en RVB. Quand on fait ce genre d'hypothèse, il est très difficile de les modifier. C'est pour cela que le support des 16 bits par canal a été sans cesse repoussé.

A mon avis ils sont en plus partis sur une mauvaise base technique, à savoir choisir de le faire en C. Il pouvait y avoir (à l'époque) une motivation de facilité de portage, mais comme ça ne tournait que sous linux, c'était un mauvais argument.

Du coup ils se sont retrouvés avec un langage qui ne favorise ni la généricité ni la virtualisation des fonctions.

Les fonctions virtuelles sont "possibles" mais pas franchement pratiques (c'est un peu opaque en C). Et si on doit descendre au niveau du pixel (qu'il soit en niveau de gris, RVB, 8 bits, 16 bits ou n'importe quoi d'autre) ça impacte méchamment les performances. Il vaut mieux faire du générique.

La généricité (les templates du C++ par exemple) est impossible en C. Il faut programmer un générateur de code (c'est ce qui est fait par exemple dans FFTW à partir de Caml pour les connaisseurs), et ça devient lourd.

Ceci n'étant pas pour minimiser le travail qui a été fait, et qui est énorme, mais pour tenter d'expliquer les raisons d'une fonctionnalité qui se fait attendre...

LeRentier · Mars 18, 2010, 18:02:04

À ma connaissance, les deux initiateurs du projet GIMP, voulaient juste créer un programme de manipulation d'images qui marchait.
En 1995, quand ils ont débuté sur ce projet, à Berkeley, Photoshop en était à la version 3 et ils voulaient faire simple mais efficace afin de ne pas tomber dans le "vaporware", quitte à améliorer leur produit pas à pas.
Chemin faisant, ils se rendaient compte qu'il fallait créer les outils de base qui manquaient et ils sont à l'origine de choses tels que GTK et XFC.
Les deux compères travaillent maintenant pour Google je crois et d'autres ont pris la relève pour faire évoluer GIMP.

Je viens de vérifier qu'il y a un accès à l'historique de GIMP sur le site officiel.

cptcv · Mars 18, 2010, 18:06:45

Citation de: reder le Mars 18, 2010, 17:20:22
A mon avis ils sont en plus partis sur une mauvaise base technique, à savoir choisir de le faire en C. Il pouvait y avoir (à l'époque) une motivation de facilité de portage, mais comme ça ne tournait que sous linux, c'était un mauvais argument.

Du coup ils se sont retrouvés avec un langage qui ne favorise ni la généricité ni la virtualisation des fonctions.

Les fonctions virtuelles sont "possibles" mais pas franchement pratiques (c'est un peu opaque en C). Et si on doit descendre au niveau du pixel (qu'il soit en niveau de gris, RVB, 8 bits, 16 bits ou n'importe quoi d'autre) ça impacte méchamment les performances. Il vaut mieux faire du générique.

Je me gourre peut-être (n'étant pas spécialiste en C++) mais les fonctions virtuelles me semblent reposer sur ce que l'on appelle le "dynamic binding", non? Et franchement le dynamic binding ça se fait en C depuis bien longtemps ...
Le seul truc c'est que la couche que génère le compilo C++ c'est à toi de la faire. Après je ne vois pas trop de différence...

Citation de: reder le Mars 18, 2010, 17:20:22
La généricité (les templates du C++ par exemple) est impossible en C. Il faut programmer un générateur de code (c'est ce qui est fait par exemple dans FFTW à partir de Caml pour les connaisseurs), et ça devient lourd.

Il me semble bien que la généricité existe en C, c'est ce que l'on appelle les fonctions variadic, non?

chewan · Mars 19, 2010, 03:10:48

Pour le 16 bits sous Gimp, je tiens juste à préciser que le fameux Cinepaint est un fork de Gimp rendu public en 2002.

Cinepaint fut crée car Gimp ne supportait pas les modes supérieures à 8 bits, nécessaire au format cinéma.

L'auteur après avoir tenté en vain de pousser Gimp vers des formats supérieur à 8 bits, de guerre lasse, fut obligé de créer une branche.

Maintenant en 2010, Gimp ne supporte toujours les formats 16 bits ou HDR, cinepaint lui le fait depuis 8 ans...

Donc bon, Gimp et le 16 bits, en 2020 ?

Quand à la base technique, C ou C++ cela n'importe pas vraiment si les api sont bien pensées.

reder · Mars 19, 2010, 11:47:40

Citation de: cptcv le Mars 18, 2010, 18:06:45
Je me gourre peut-être (n'étant pas spécialiste en C++) mais les fonctions virtuelles me semblent reposer sur ce que l'on appelle le "dynamic binding", non? Et franchement le dynamic binding ça se fait en C depuis bien longtemps ...
Le seul truc c'est que la couche que génère le compilo C++ c'est à toi de la faire. Après je ne vois pas trop de différence...

Effectivement c'est à toi de stocker la table des fonctions virtuelles (d'ailleurs initialement le C++ était "réécrit en C"). Personnellement je considère que cela allège déjà le boulot du développeur de n'avoir pas à le faire (sans parler du RAII, etc)

Citation
Il me semble bien que la généricité existe en C, c'est ce que l'on appelle les fonctions variadic, non?

Euh d'après moi il s'agit des fonctions avec un nombre de paramètres variables. La généricité en C, c'est void* partout, à la rigueur, donc ça n'existe pas à ma connaissance.

reder · Mars 19, 2010, 12:02:38

Citation de: chewan le Mars 19, 2010, 03:10:48
Quand à la base technique, C ou C++ cela n'importe pas vraiment si les api sont bien pensées.

Oui et non. Si ton architecture est mal foutue, tu auras une grosse migraine en C, mais un énorme cauchemar en C++.

Par contre, la programmation générique (stl et boost) apporte de vrais gains (en temps de développement et même en performance) et surtout en flexibilité (mais cela dépend du problème qui t'es posé) et même en débug (tu inspectes des vrais types et pas des void* qui représentent va savoir quoi) . Là où tu paies ce gain (rien n'est gratuit en ce bas monde) c'est quand tu dois inspecter des messages d'erreur de compilation de plusieurs lignes (voir pages).

Dans le cas de Gimp, changer de disons type_8bits en type_generique, avec les fonctions disons "put_pixel" directement inlinées, et tous (ou presque) tes algorithmes de traitement disponibles automatiquement ou à faible coût, c'est tout simplement impensable en C. Donc on en serait pas là en 2010.

cptcv · Mars 19, 2010, 13:41:48

Citation de: reder le Mars 19, 2010, 11:47:40
Euh d'après moi il s'agit des fonctions avec un nombre de paramètres variables. La généricité en C, c'est void* partout, à la rigueur, donc ça n'existe pas à ma connaissance.

Pour moi la généricité c'est ne pas avoir à se préoccuper du nombre et du type des arguments. Le variadic me semble bien répondre à cela, non?

cptcv · Mars 19, 2010, 13:50:51

Citation de: reder le Mars 19, 2010, 12:02:38
Oui et non. Si ton architecture est mal foutue, tu auras une grosse migraine en C, mais un énorme cauchemar en C++.

Par contre, la programmation générique (stl et boost) apporte de vrais gains (en temps de développement et même en performance) et

En performance? Faut voir par rapport à quoi on compare. Plus c'est générique et moins c'est performant par rapport à du spécifique.

Citation
Dans le cas de Gimp, changer de disons type_8bits en type_generique, avec les fonctions disons "put_pixel" directement inlinées, et tous (ou presque) tes algorithmes de traitement disponibles automatiquement ou à faible coût, c'est tout simplement impensable en C.

C'est pourtant ce qu'ils font en passant à GEGL. En fait si j'ai bien compris ils attendent que GEGL implémente tout ce que Gimp. Quand ça sera fait ils basculeront complétement sur GEGL et donc en 32 bits partout. Et GEGL est écrit en C sauf erreur? Donc impensable en C...

reder · Mars 19, 2010, 14:55:05

Citation de: cptcv le Mars 19, 2010, 13:50:51
Pour moi la généricité c'est ne pas avoir à se préoccuper du nombre et du type des arguments. Le variadic me semble bien répondre à cela, non?

Non, lis ceci : http://en.wikipedia.org/wiki/Generic_programming

Citation
En performance? Faut voir par rapport à quoi on compare. Plus c'est générique et moins c'est performant par rapport à du spécifique.

Non, parce qu'en fonction des types, le compilateur va optimiser (éventuellement avec un peu d'aide) en fonction du type que tu lui passes. Donc tu fais mieux qu'un void*, et au pire tu as toujours la possibilité de spécialiser.

Citation
C'est pourtant ce qu'ils font en passant à GEGL. En fait si j'ai bien compris ils attendent que GEGL implémente tout ce que Gimp. Quand ça sera fait ils basculeront complétement sur GEGL et donc en 32 bits partout. Et GEGL est écrit en C sauf erreur? Donc impensable en C...

Sauf que GEGL, ça fait un bout de temps que c'est mergé dans Gimp et qu'on ne voit rien venir, sauf le soleil qui poudroie.
Et que oui, GEGL, c'est écrit en C, et qu'il aurait sans doute été plus simple de prendre la GIL qui existait déjà.

Encore une guerre de religion qui a plombé un projet libre...

LeRentier · Mars 19, 2010, 15:10:16

Une remise sur l'établi avec ré-écriture complète pourrait aider à accoucher d'une version qui gère les 16 bits ou plus, peut paraitre attractive mais, il ne faut pas torpiller le bon fonctionnement de la multitude de plugins et autres outils qui "causent avec".

De plus, passer de C ou C++ à autre chose implique que cette 'autre chose' soit reconnue comme stable et bénéficiant d'équipes de support fiables.

Peut-être faudra-t-il que l'équipe Gimp passe par un appel de fonds spécifique sur on cahier de charges publié, pour attirer des talents et pondre une version qui tue.

cptcv · Mars 19, 2010, 15:29:26

Citation de: reder le Mars 19, 2010, 14:55:05
Non, lis ceci : http://en.wikipedia.org/wiki/Generic_programming

http://fr.wikipedia.org/wiki/G%C3%A9n%C3%A9ricit%C3%A9 La version française confirme que le variadic est bien de la généricité...

Citation
Non, parce qu'en fonction des types, le compilateur va optimiser (éventuellement avec un peu d'aide) en fonction du type que tu lui passes. Donc tu fais mieux qu'un void*,

Pour moi un void ce n'est pas du spécifique...

Citation
Sauf que GEGL, ça fait un bout de temps que c'est mergé dans Gimp et qu'on ne voit rien venir, sauf le soleil qui poudroie.

Oui mais l'inverse n'est pas vrai. Et si j'ai bien compris tant que ce n'est pas une bijection, Gimp restera en 8 bits...

Citation
Et que oui, GEGL, c'est écrit en C, et qu'il aurait sans doute été plus simple de prendre la GIL qui existait déjà.

Encore une guerre de religion qui a plombé un projet libre...

Pour moi la diversité n'est pas nuisible. Sinon on aurait un seul OS, un seul navigateur, un seul logiciel de retouche, etc.

Et puis GIL est apparue en 2006 alors que les fondements de GEGL semblent remonter à 2000 ...