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 ...

reder · Mars 19, 2010, 16:07:14

Citation de: cptcv le Mars 19, 2010, 15:29:26
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é...

Vue la longueur et la précision de la version française comparée à l'anglaise...
Ceci dit, pourquoi pas, mais il s'agit dans ce cas de traiter de manière automatisée un nombre connu de paramètres de type inconnu.

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

Sauf qu'il y a eu dans le libre une énorme dissipation d'énergie entre programmes concurrents et semblables. Il ne doit pas y avoir un seul exemple de programme libre qui n'ait pas connu sa guerre de religion.
gcc/egcs (guerre pour une fois propice)
emacs/xemacs
gnome/kde
git/monotone
etc...

Du coup en 2010 par exemple le desktop linux je suis désolé mais c'est moche et incommode à côté d'un w7 ou osX, alors qu'en 1997 un fwm n'était pas pire qu'un windows 95.

Et dans le cas de gimp, qui n'a vraiment jamais connu de concurrent pour le coup, il s'est plombé tout seul avec son interface exotique (c'est quoi toutes ces fenêtres qui se baladent un peu partout ?) et il faut le dire l'absence de support du 16 bits. Même si la nécessité en est discutable, tu n'as pas acheté un d3x à 8000€ ou un coolscan 9000 à 3000€ pour retraiter en 8bits (ça serait comme aller faire le plein de la Ferrari chez auchan)

cptcv · Mars 19, 2010, 17:01:45

Citation de: reder le Mars 19, 2010, 16:07:14
Vue la longueur et la précision de la version française comparée à l'anglaise...
Ceci dit, pourquoi pas, mais il s'agit dans ce cas de traiter de manière automatisée un nombre connu de paramètres de type inconnu.

Non le variadic c'est un nombre inconnu de paramètres de types inconnus

Citation
Sauf qu'il y a eu dans le libre une énorme dissipation d'énergie entre programmes concurrents et semblables. Il ne doit pas y avoir un seul exemple de programme libre qui n'ait pas connu sa guerre de religion.
gcc/egcs (guerre pour une fois propice)
emacs/xemacs
gnome/kde
git/monotone
etc...

Ce n'est pas le libre qui est en cause. C'est l'informatique dans son ensemble qui est comme ça... Mac/PC, Excel/Lotus, Flash/silverlight, Netscape/IE, etc.

Le monde de la photo n'est pas mieux: Canon/Nikon, etc.

Citation
Du coup en 2010 par exemple le desktop linux je suis désolé mais c'est moche et incommode à côté d'un w7 ou osX, alors qu'en 1997 un fwm n'était pas pire qu'un windows 95.

Oui enfin bon les goûts et les couleurs... Perso windows vista ou 7 je n'aime pas je trouve ça moche.

reder · Mars 19, 2010, 17:38:39

Citation de: cptcv le Mars 19, 2010, 17:01:45
Non le variadic c'est un nombre inconnu de paramètres de types inconnus

Je parlais du probleme 8bits/16bits/CMJN/etc

Citation
Ce n'est pas le libre qui est en cause. C'est l'informatique dans son ensemble qui est comme ça... Mac/PC, Excel/Lotus, Flash/silverlight, Netscape/IE, etc.

Dans le cas du libre (du free plutôt), il y a tout de même un problème d'allocation optimale des ressources. On bosse tout de même uniquement pour la gloire, les candidats ne sont pas si nombreux et font ça sur leur temps libre. Si en plus ils se partagent en projets concurrents qui passent leur temps à s'injurier....

Citation
Oui enfin bon les goûts et les couleurs... Perso windows vista ou 7 je n'aime pas je trouve ça moche.

Mouais de base il n'y a pas pire que le brun d'ubuntu...
Par contre l'intégration générale ou l'explorateur de fichiers c'est toujours pas au niveau...

cptcv · Mars 19, 2010, 19:21:33

Citation de: reder le Mars 19, 2010, 17:38:39
Je parlais du probleme 8bits/16bits/CMJN/etc

ah ok.

Citation
Dans le cas du libre (du free plutôt), il y a tout de même un problème d'allocation optimale des ressources. On bosse tout de même uniquement pour la gloire, les candidats ne sont pas si nombreux et font ça sur leur temps libre. Si en plus ils se partagent en projets concurrents qui passent leur temps à s'injurier....

Pour la gloire, faut voir! Il y a pas mal de salariés également... C'est peut-être ce qui manque à Gimp d'ailleurs. Une structure derrière comme peut avoir le noyau, OpenOffice, Mozilla, etc.

Citation
Mouais de base il n'y a pas pire que le brun d'ubuntu...

Je n'utilise pas Ubuntu...

Citation
Par contre l'intégration générale ou l'explorateur de fichiers c'est toujours pas au niveau...

C'est à dire?

faro63 · Mars 19, 2010, 22:40:12

Citation de: cptcv le Mars 19, 2010, 19:21:33
Je n'utilise pas Ubuntu...

CPTV, tu sembles être informaticien de métier, quelle distrib utilises-tu ?

cptcv · Mars 19, 2010, 23:30:07

J'utilise une Debian en version testing.

kevlar · Juin 21, 2010, 11:48:10

Pour répondre à un grand nombre de remarques lues ici :
- Gimp est fondé sur GTk, qui a toujours codé en interne les couleurs en 16 bits par plan (chaque composante R V B a une valeur sur 16 bits, qui va de 0 à 65535)
- Gimp est codé en C, mais un grand nombre de plugins sont en Python.
- Krita (projet Kde, donc QT) gère le 16 bits, mais il n'est pas au niveau de Gimp
- il est très facile en lisant le mode d'emploi d'avoir Gimp avec une seule palette contenant tous les outils.
- enfin, il existe depuis quelques années un projet payant, 'Pixel'.

cptcv · Juillet 24, 2010, 14:11:12

Toujours pas de support du 32 bits ?

Mumu · Août 02, 2010, 13:48:24

Suite à une remarque de mon tireur, je me suis aperçu que lorsque j'enregistrais un fichier en format jpg, GIMP n'y indiquait pas l'espace colorimétrique (dans les données exif il me semble).

Je n'ai pas l'impression que cela soit prévu de pouvoir l'indiquer dans la fenêtre d'enregistrement du jpg... à moins que ma version de gimp soit trop ancienne.

Quand est-il de la votre ? Avez-vous ce problème ? Comment faire pour l'indiquer à par la suite ?