L'équipe de développement de G'MIC est heureuse de vous annoncer la sortie d'une nouvelle version de G'MIC (GREYC's Magic for Image Computing), estampillée 1.5.5.1. La dernière dépêche sur ce logiciel date d'octobre 2012, et nous proposons donc ici un récapitulatif rapide des avancées du logiciel depuis ces six derniers mois (soit l'équivalent de huit nouvelles versions sorties, c'est un projet actif !).
G'MIC est un framework libre et multi-plateforme pour le traitement d'images, développé dans l'équipe IMAGE du laboratoire GREYC (UMR CNRS 6072), depuis août 2008. Il propose des outils de manipulation d'images, via différentes interfaces : en ligne de commande (binaire gmic), avec un greffon pour GIMP (gmic-gimp), directement en ligne (page web G'MIC Online), avec une interface QT/webcam (logiciel ZArt), ou encore via une bibliothèque C++ ( libgmic ) intégrable dans tout programme libre. G'MIC sait manipuler aussi bien les images couleurs standards, que les images volumiques (3D), les séquences d'images, les images multi-spectrales, les images à valeurs flottantes, etc. Il est basé principalement sur la bibliothèque C++ CImg, développée dans la même équipe.
Nouveautés
Depuis la version 1.5.2.0, plusieurs fonctionnalités ont été ajoutées.
Seules quelques unes des plus "visuelles" sont illustrées ici, ce qui correspond au final à un sous-ensemble assez mince du travail qui a été réalisé sur l'ensemble du logiciel et de ses différentes interfaces, mais c'est ce qui rend aussi cette dépêche pas trop rébarbative !
Ces versions successives ont ajouté, en vrac :
G'MIC dispose maintenant d'une page d'actualités Google+, où vous pouvez suivre au jour le jour les avancées et les nouveautés du logiciel.
Un nouveau filtre Inpaint [patch-based] permet de reconstruire de manière automatique des régions manquantes dans des images, par combinaison de copier-coller/fondus intelligents de morceaux d'images (patchs) situés autour de la zone à remplir. Ce filtre permet d'obtenir des résultats de reconstruction parfois impressionnants, comme sur les exemples ci-dessous :
D'autres résultats d'inpainting réalisés avec ce nouvel algorithme sont disponibles sur cette page. Nous pouvons remercier Maxime Daisy, étudiant qui a réalisé une première implémentation de l'algorithme durant son stage de Master que nous avons pu reprendre en l'améliorant/optimisant encore un peu (on est content de l'avoir gardé en thèse :) ). Cet algorithme permet d'obtenir des résultats souvent meilleurs que ceux obtenus avec Resynthetizer, autre greffon pour GIMP proposant un algorithme similaire de reconstruction.
- Un nouveau filtre Recolorize qui permet de recoloriser facilement et rapidement une image en niveau de gris. L'idée est d'ajouter un layer transparent contenant de petites taches de couleurs au dessus de l'image, le filtre se chargeant ensuite de propager les couleurs de ces sources sur toute l'image, en prenant en compte au mieux la géométrie de l'image (par détection des contours notamment). Quelques exemples ci-dessous :
- Un effet Freaky Details permettant de rehausser les détails d'une image, intéressant pour obtenir des effets de photos 'hyper-réalistes'. Ce filtre a été réalisé en collaboration avec Patrick David, un photographe américain passionné d'open-source.
- Un filtre Weave, permettant de dessiner un entracement de fibres sur une image. GIMP dispose déjà d'un filtre similaire, mais celui de G'MIC permet de rendre des fibres courbes, texturées, et orientées suivant plusieurs angles différents.
- Une version améliorée de la commande de rendu d'ombres projetées sous une image, qui permet notamment de générer des ombres courbes, comme sous l'exemple ci-dessous.
- Un nouveau filtre Lava, qui permet de générer des effets de lave en fusion sur l'image.
- Un nouveau filtre Raindrop qui permet de générer des effets 'gouttes d'eau' sur l'image.
- Un nouveau filtre Poster edge, qui permet de générer des contours de type cartoon sur une image. Ce filtre m'avait été demandé par David Revoy, sympathique illustrateur Toulousain qui fait des merveilles avec des logiciels libres (allez voir sa page!). David a en particulier écrit une page détaillée décrivant l'utilisation de ce filtre.
- Un nouveau filtre Symmetrize permettant de rendre une image symétrique selon n'importe quel axe.
- Une interface de démonstration pour illustrer la quantification d'images couleurs a été ajoutée. Elle permet de faire mieux faire comprendre les méthodes de clustering qui se cachent derrière les techniques de quantification (k-means et median-cut notamment). Cette interface permet de visualiser et de modifier interactivement l'image quantifiée, le cube couleur, et la colormap associée à la quantification.
Le futur
G'MIC est en développement constant et rapide depuis août 2008, et arrive à une maturité certaine. Outre le développement de ce logiciel, nos efforts vont se porter également sur sa promotion et l'écriture de doc et de tutoriels pour mieux utiliser toutes ces possibilités. G'MIC a déjà été présenté au FOSDEM'2013, et nous avons une présentation prévue à la conférence LGM'2013 (Libre Graphics Meeting).
Tout cela nécessite bien sûr une multiplication des efforts, et toute aide sur ce projet est donc bienvenue ! J'en profite pour remercier les déjà nombreux contributeurs qui ont cru en ce projet, et qui ont aidé d'une manière ou d'une autre à son développement et à sa visibilité.
N'hésitez donc pas à le tester !
À dans six mois, pour une prochaine dépêche !
Aller plus loin
- Le projet G'MIC (909 clics)
- Dépêche précédente sur G'MIC (version 1.5.2.0). (181 clics)
# Hésitation ...
Posté par Philippe Poumaroux (site web personnel) . Évalué à 10.
… entre félicitations, bravo ou merci ? En fait, les 3 !
Bonne continuation
# Ah ... Lenna
Posté par bentix . Évalué à 10.
Je suis toujours autant amusé de voir que Lenna est encore si souvent en traitement d'image :)
En tout cas félicitations pour le projet, c'est une belle réussite !
[^] # Re: Ah ... Lenna
Posté par ariasuni . Évalué à 1.
Merci, je cherchais le nom!
En fait c'est comme le Hello World ou le Lorem Ipsum, c'est devenu un «standard»!
Écrit en Bépo selon l’orthographe de 1990
# Deux questions
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
A ma connaissance, gmic n'était pas parallélisé. Si c'est toujours le cas, y-a t'il quelques choses de prévu ? En effet, les images sont de plus en plus grosses (les calculateurs aussi). On a dans mon laboratoire (UMR aussi) par exemple un appareil photo qui prends du 80 million de pixel, une image raw fait 500Mo… Ca commence à faire quand on en a des milliers à traiter.
Sinon, je sais que les chercheurs qui m'entourent sont intéressé par deux choses. La reconstruction 3D via des vues 2D prises sur un tomographe et la PIV qui consiste à reconstruire un champ de vitesse ou de déformation via deux images prises à deux instants proches. Il y a aussi la PIV 3D ou on généralise la 2D avec plus d'image mais il faut que tout suive derrière (temps calculs, stockage, analyse…). Je pense que gmic a tout les atouts qu'il faut pour pouvoir répondre à ces questions.
[^] # Re: Deux questions
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10. Dernière modification le 30 mars 2013 à 21:59.
Dans de tels cas, pourquoi s'éreinter à paralléliser l'implémentation, alors qu'il suffit de balancer des tâches simultanément ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Deux questions
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
C'est ce que l'on fait. Mais sur les machines de calcul, les scheduleurs n'aiment pas toujours quand tu leur balances 50000 job d'un coup ;-) En fait, le soucis est ailleurs, si tu veux travailler sur des champs 3D à partir de N image en tranche (type tomographe), le traitement est très lourd. Les copains d'à coté ont une machine avec 3 cartes TESLA pour faire les traitements…
La nouvelle carte Intel Xeon Phi est très proche d'un processeur Xeon classique. Normalement, Intel devait gérer OpenMP de manière transparente sur cette carte (ce qui n'est pas le cas de Nvidia il me semble). Si on veut faire de l'imagerie type temps réel (médical) ou sur des images à grandes résolutions (80millions de pixel en 14 bits), il faut, à mon sens, que le moteur interne puisse être parallèle. Depuis quelques années, c'est le fait d'améliorer la parallélisation qui permet de continuer à monter en performance.
[^] # Re: Deux questions
Posté par ckyl . Évalué à 10.
Qui peut se faire au niveau de la tâche elle même ou du job ;)
Le réponse qu'on t'a faite était très juste. Si par nature tu as un parallélisme au niveau du job et que tu cherches à maximiser la bande passante, cas que tu décrivais initialement, il ne faut pas aller chercher les emmerdes à le faire au niveau de la tâche. Tu fais de l' embarrassingly parallel. Si ton scheduler tient pas 50000 tâches, change le, fixe le ou fait une pauvre glue producteur-consommateur autour. C'est la bonne solution. Pas de complexifier le métier, introduire des bugs et se taper un speedup sous-linéaire alors qu'il pourrait l'être.
Cela dit, comme souvent, on ne peut pas te contredire car tu passes du coq à l'âne: De "J'ai 50000 images indépendantes que j'ai pris avec mon gros kiki et je veux minimiser le temps de traitement total" à "J'ai une tâche qui demande du parallélisme et je veux du temps réel".
[^] # Re: Deux questions
Posté par mackwic . Évalué à 2.
Cette réponse est inutilement agressive.
Shocking !
[^] # Re: Deux questions
Posté par ckyl . Évalué à 2.
Il n'y a absolument rien d'agressif dans ma pensée et je l'espère dans mon message.
Par contre je me permet en plus de souligner que dans beaucoup de ses discussions ca part dans tout les sens sans aucune cohérence ce qui empêche d'avoir tout discours ou pensée constructive, ce qui est pourtant le but.
[^] # Re: Deux questions
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je ne sais si tu avais vu mon smiley.
Je ne suis pas sur le serveur de bogue du logiciel ni sur une liste de discussion "pro" mais sur dlfp alors j'avoue ne pas toujours me relire et laisser le fils de l'eau se faire. Il faut bien des espaces de liberté.
Cela étant dis, il y a des traitements longs, je me souviens des premières versions de greystoration par exemple ou le traitement d'une seule image prenait un temps fou ! Si tu veux faire de la PIV sur un champs de vitesse, il faut comparer deux images deux à deux afin d'avoir le déplacement des points. A ce que j'ai compris (ne suis pas du tout un spécialiste du domaine), cela se fait en général par la recherche dans une fenêtre autour de chaque point, plus des interpolations entre point sinon le résultat n'est pas bon… On sais que dès qu'on cherche une notion de vitesse ou d'accélération, deux points dans le temps donne un résultat parfois faible et qu'il vaut mieux travailler sur trois ou 5 points temporels (donc 3 ou 5 images…). Mais plus ton schéma est complexe, plus il est long en temps (surtout qu'il y a tous les cas particuliers sur les bords). Alors avec la 3D…
Il y a aussi un domaine intéressant dans le montage vidéo. Dès que l'on veut faire des effets, on a en général un moteur qui donne un premier résultat proche rapidement pour voir si cela convient puis on lance le montage proprement dis qui peux mettre des heures a se faire. Si le coeur de ton processus de traitement d'image n'est pas parallèle, tu ne vas pas monter vite ton film.
Bref, il y a tout plein de raison d'avoir un coeur parallèle de nos jours…
[^] # Re: Deux questions
Posté par ckyl . Évalué à 5.
Il y en a autant que de ne pas en avoir ou d'avoir une approche plus maline qu'avoir un coeur parallèle. L'important est de savoir où couper.
Je ne parle pas du tout de GMIC, je connais trop mal le domaine pour donner un quelconque avis. Mais c'est typiquement le genre de chose assez complexe à faire au niveau d'une lib par ce que tu introduis une complexité folle avec des perfs pas toujours au rendez vous. A ce niveau t'as pas assez d'infos pour faire des choses intéligentes. En règle général plus le client/appli à la main sur le parallelisme plus c'est bon pour les perfs et simple pour tout le monde. Du coup tu exposes des primitives de bases dont le client fera ce qu'il veut.
Maintenant je ne disais pas plus qu'il vaut mieux ne pas illustrer une telle demande avec un premier praragraphe incohérent qui brouille le message. Les gens te font des réponses censées à partir de ce que tu écris..
[^] # Re: Deux questions
Posté par JoeltheLion (site web personnel) . Évalué à 4.
Pour le médical et le 3D en général, regarde ITK, c'est déjà parallélisé et assez efficace.
Je ne sais pas trop ce que valent les fonctionnalités pour GPU par contre.
Je pense que c'était une boutade, mais j'ai deux mots pour toi: batch manager :)
[^] # Re: Deux questions
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Évidement c'était une boutade. Il est facile de paralléliser des centaines de job identiques (sauf du coté des IO !). Évidement on utilise un batch manager mais essayes de lui faire manger 50000 jobs d'un coup, il y en a qui n'aime pas… Mais bon, cela se résout assez facilement au final.
Il n'empêche que j'ai vu un exposé présentant des performances en IO sur HDF5 entre la version classique et la version asynchrone (et //) impressionnante. C'est un sujet pas facile mais dès qu'on est sur un grand nombre de coeur et des données de taille importante, ne pas en tenir compte peut être très pénalisant. Je ne sais pas si gmic pourrait s'inspirer de ce genre d'API.
[^] # Re: Deux questions
Posté par freejeff . Évalué à 1.
Bonjour,
ITK n'est pas parallélisée sur toutes ses fonctionnalités et loin de là, il y a par exemple la tâche lourde du recalage d'images qui n'est pas du tout parallélisée.
Il n'y a pas à ma connaissances de bibliothèques en analyse d'images qui permettent d'avoir un niveau d'abstraction simple pour le non informaticien professionnel et parallèle.
Il est tout à fait possible de faire du parallèle avec cimg par exemple et openmp. Nous le faisons au labo (UMR aussi …).
[^] # Re: Deux questions
Posté par JoeltheLion (site web personnel) . Évalué à 0.
Bien sûr que le recalage est parallélisé dans ITK, je l'utilise tous les jours. Avant d'écrire n'importe quoi, il faut parfois se renseigner.
[^] # Re: Deux questions
Posté par claudex . Évalué à 7.
Vous faites un concours de l'affirmation non sourcée ?
« 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: Deux questions
Posté par JoeltheLion (site web personnel) . Évalué à 0.
Non, il raconte n'importe quoi, je le dis.
N'importe qui peut vérifier en 5 minutes, pas besoin de connaître ITK: http://lmgtfy.com/?q=itk+multi-thread
[^] # Re: Deux questions
Posté par freejeff . Évalué à 1.
Bonjour,
Je ne comprends pas Votre agressivité.
Ce que j'ai dit c'est que le traitement des toutes les tâches n'est pas parallélisé dans ITK.
Par exemple lorsque l'on fait du recalage d'images avec un algorithme de descente de type gradient stochastique le temps principale se passe dans les itérations, celles-ci ne sont pas parallélisées, il ne serait pas trop difficile de le faire.
De plus le "solver" du système ne tourne que sur un cœur, et ce temps peut être assez long.
S'il est vrai que je n'ai pas fait tous les tests avec ITK4, j'avais vraiment essayé avec ITK3.
De plus ITK est une bibliothèque difficile à faire évoluer pour un non informaticien car tout est encapsulé, alors qu'il est facile avec CIMG de créer ses propres classes utilisant des opérateurs mathématiques aussi complexe que l'on souhaite, ce qui est plus adapté à ce que l'on fait. Nous avons ainsi pu implémenter toutes les boucles critiques en OpenMP ce qui nous permet de bien exploiter notre HPC (on aurait pu faire encore mieux en MPI !). Nous faisons de la métrologie, il n'est donc pas vraiment acceptable pour nous de ne pas utiliser tous les échantillons (random sampler). Nous devons donc prévoir un système permettant de gérer les données issues d'un micro-tomographe ce qui peut aller jusqu'à 4000x4000x4000 en ne sous échantillonnant pas.
Alors certes on aurait pu tout faire avec ITK, mais cette bibliothèque ne semblait pas la plus adaptée pour pouvoir permettre à des non-informaticiens de la faire évoluer.
J'utilise ITK tous les jours au travers d'Elastix et en suis satisfait, mais ça ne correspond pas à tous les besoins. Pour le cas spécifique des du recalage d'images sur des gros volumes sans sous-échantillonnage ce n'est pas adapté. Et nous n'avons pas le niveau pour la faire évoluer.
Encore une fois il est fort dommage de s'énerver de la sorte. Si j'ai fait une erreur je suis prêt à le reconnaître, mais dans ce cas donnez moi quelque chose à me mettre sous la dent comme un lien, plutôt de m'accuser d'incompétence, c'est n'est pas des manières.
Cordialement,
# Pas d'image en https
Posté par Axone . Évalué à 1.
Bonjour,
Je ne vois pas les images incluses dans la dépêche quand je suis en https, alors qu'en http, je les vois. Je crois me souvenir qu'il y avait une manip pour corriger cela. Laquelle était-ce ?
[^] # Re: Pas d'image en https
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
cf http://linuxfr.org/aide#aide-imgcertificatssl
# A propos de doc
Posté par zonder . Évalué à 3.
La doc est passée en wiki, c'est mieux et je pense que ça méritait d'être dit.
C'est tout.
# GEGL
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
Bonjour,
les filtres GMIC sont-ils aussi développés en parallèle avec une implémentation GEGL pour être prêt quand GIMP 2.10 sortira?
GEGL est pour moi une avancée majeure dans GIMP, en particulier car cette librairie permettra dans un second temps de travailler totalement sans perte à partir d'images sources (même si je pense que la 2.10 ne permettra pas cela immédiatement car cela demande une interface adaptée). Et pour moi, c'est une fonctionnalité énorme.
Sinon ça a vraiment l'air cool. J'essaierai. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GEGL
Posté par David Tschumperlé (site web personnel) . Évalué à 5.
Non, il n'y a rien de prévu pour le moment pour l'interfaçage avec GEGL. On cherche quelqu'un qui pourrait s'y coller pour tout dire. Et on espère, en attendant, que l'équipe de développeurs de GIMP va garder une couche de compatibilité pour faire tourner tous les 'anciens' plug-ins (mais c'est très mal barré à priori, ce qui est dommage, quand je vois le nombre de plug-ins existants qui vont devenir obsolètes).
[^] # Re: GEGL
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
Salut,
en même temps, le but ne sera pas d'avoir deux systèmes en parallèle, mais bien d'avoir un système qui remplacera l'autre. Pour toi, à l'heure actuelle puisque tu développes activement tes filtres, cela fait du travail en double. Mais une fois que la 2.10 sera sortie, tu n'auras plus que du GEGL à développer (à moins que tu ne prévois de continuer à supporter les vieilles versions de GIMP, même pour les nouveaux développements?).
Enfin es-tu sûr que les anciens plug-ins de filtres ne pourront plus tourner? Tu as demandé à l'équipe? Parce qu'à l'heure actuelle par exemple, dans l'arbre de développement, on a un mix de plugin vieux style et de filtres GEGL par exemple. Et je vois pas trop de raison pour qu'on casse la compatibilité avec un plug-in tiers qui cherchera à modifier directement une image, même si bien entendu on déconseillera de tels plug-ins. On porte tous les plug-ins "officiels" (ceux fournis dans le dépôt avec GIMP lui-même), mais je suis pas sûr qu'on va chercher explicitement à casser un plug-in tier non à jour. Ensuite je peux me tromper.
Mais dans tous les cas, je vois pas pourquoi il serait intéressant de s'attacher à l'ancien système. GEGL est gagnant-gagnant pour tout le monde: les développeurs de plug-in, les développeurs GIMP, et surtout les utilisateurs!
En tous cas, je vois que tu seras au Libre Graphics Meeting. J'assisterai à ta conf. :-)
Et tu auras l'occasion de discuter de vive voix avec le reste de l'équipe GIMP là-bas pour mettre un peu plus au clair. Mais encore une fois, tu peux déjà demander. On traîne sur IRC (enfin moi pas trop, mais les plus gros contributeurs y passent leur journée) et ça répond plutôt aimablement aux gens polis.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GEGL
Posté par David Tschumperlé (site web personnel) . Évalué à 6.
En fait, ça marche de manière un peu différente de ce que tu pourrais penser :
G'MIC définit son propre langage de script pour l'implémentation de filtres et d'effets, et je n'utilise donc que très peu l'API de GIMP en réalité (juste pour les entrées-sorties entre le plug-in et GIMP).
Tous les filtres et commandes G'MIC existants sont implémentés dans ce langage de script G'MIC.
Ca me permet de proposer exactement les mêmes fonctionnalités sur plusieurs interfaces différentes sans dépendre des langages/bibliothèques propres à chaque interface, et surtout sans avoir à refaire tout le travail pour chaque interface (ça serait impossible à maintenir !). De même, si j'implémente de nouveaux filtres, il est très facile pour moi de les rendre disponible tout de suite sur chaque interface.
Le plug-in GIMP n'est qu'une interface G'MIC parmi d'autre.
Par contre, c'est la réalisation de cette interface proprement dite a quand même demandé beaucoup de boulot, notamment du côté du GUI (c'est du GTK2).
En théorie, on n'aurait pas à utiliser vraiment beaucoup de fonctionnalités de GEGL si on veut 'porter' le plug-in G'MIC existant pour les prochaines versions de GIMP, excepté les fonctions d'entrées sorties de GEGL pour passer les données images et les paramètres des filtres à G'MIC (et vice-versa).
Mais d'après ce que j'ai compris de GEGL, c'est qu'il va falloir idéalement créer des "noeuds" correspondants à des opérateurs différents, et c'est là que le bât blesse. Car cette approche n'est pas du tout adaptée pour l'interfaçage avec des bibliothèques (comme G'MIC) qui proposent elles-même plusieurs filtres différents (des centaines ici!): on pourrait créer des centaines de noeuds différents pour chaque fonctionnalité, mais c'est pas très pratique, probablement pas optimisé en occupation mémoire, et on perd l'intérêt du plug-in actuel qui est de pouvoir se mettre à jour de manière automatique, en permettant par exemple l'ajout de nouveaux filtres automatiquement via le réseau, sans avoir à réinstaller quoique ce soit). Bref, le plug-in G'MIC c'est une sorte de 'meta-plug-in' et c'est un peu dommage d'être obligé de le "casser" pour le porter pour GEGL (on va rien gagner, et on perd la centralisation des filtres). Je pense que 'Mathmap', qui est un autre 'meta-plug-in' pour GIMP est un peu dans le même cas.
Et puis de mon point de vue, ça veut dire qu'il faut de toute façon redévelopper toute une interface GEGL pour G'MIC en repartant de zéro (pas les filtres, mais tout le reste !). Vraiment pas très sexy comme perspective, surtout qu'on gagnera pas grand chose.
J'avais discuté un peu avec les dev GIMP sur IRC, et ils m'avaient pas du tout assuré que les plug-ins actuels pourraient continuer à fonctionner (ce que je traduis par 'ça va probablement pêter'). Notamment le dev de GEGL, qui m'a pas semblé du tout aimable malgré ma politesse légendaire (il m'a bien fait comprendre assez vite qu'il exécrait le C++, et que CImg c'était de la merde, fin de la discussion).
[^] # Re: GEGL
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
Salut,
je vois. Si tu veux vraiment avoir tout en un comme maintenant, ne pourrais-tu faire un unique filtre GEGL dont le nom du filtre vraiment utilisé est un des paramètres du filtre unique GEGL?
Ceci dit, même si je comprends ton idée, du point de vue utilisateur, n'est-ce pas mieux que tous les filtres soient bien intégrés dans l'interface de GIMP, plutôt qu'imposer une UI intermédiaire pour choisir un filtre de la collection? Il y en a beaucoup — et c'est bien! — donc il faut simplement les organiser par genre (menu, sous-menu, etc.) ou autre.
En tous les cas, pour la problématique humaine, les relations ne sont pas toujours parfaites, que ce soit en proprio ou en Libre. Mais c'est pour cela que je parlais de politesse. Selon moi la meilleure façon de contribuer est de toujours rester poli et agréable toi-même, même si tu as l'impression de rencontrer des murs, des résistances, et même des paroles dures voire stupides, et simplement de persister. De temps en temps, tu reviens à la charge, toujours aimable.
Ton software a l'air plutôt bon, et ils ne peuvent que voir cela et ce que des centaines de filtres supplémentaires de qualité peuvent apporter à GIMP. Je suis sûr qu'il y a moyen de l'intégrer sainement à GIMP comme filtre GEGL, ou bien qu'on en trouvera un.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GEGL
Posté par David Tschumperlé (site web personnel) . Évalué à 7.
Merci pour ta réponse.
J'espère aussi pouvoir intégrer un jour G'MIC comme filtre GEGL. Mais je pense attendre une release de GIMP un peu stable pour voir comment ça peut se faire de la meilleure manière possible, et pour ne pas me lancer dans quelque chose qui risque d'être cassé 1 ou 2 mois après. Créer une nouvelle interface pour GEGL va être un sacré boulot, donc autant attendre que tout ça soit bien stable.
L'intégration des filtres directement dans l'interface de GIMP serait effectivement la bonne approche, mais il faudrait aussi trouver un moyen d'autoriser des updates de filtres via Internet, c'est quand même super pratique pour l'utilisateur. Et ça, je ne crois pas que ça soit prévu dans le prochain GIMP. J'avais essayé avec le système actuel de faire un unique plug-in qui permettrait de créer plusieurs filtres en une fois dans les menus, mais ça n'était pas possible (un plug-in ne peut être associé qu'à une entrée de menu actuellement).
Pour finir, c'est quand même dommage d'obtenir des réponses un peu dures de certains développeurs de GIMP, alors qu'on veut mettre de la bonne volonté et proposer de nouvelles choses (ok en C++, et alors ? :) ). Je ne suis pas le premier à avoir ce genre de feedbacks un peu limite de la part des dev de GIMP, et ça donne plutôt envie de se tourner vers des logiciels certes moins utilisés, mais tout aussi prometteurs, où les développeurs sont manifestement plus civilisés et prennent moins la grosse tête (Krita en est un bon exemple).
[^] # Re: GEGL
Posté par MichaelMure (site web personnel) . Évalué à 2.
Ce que j'ai constaté, c'est que GIMP étant un logiciel très connu, il attire énormément de trolleurs, volontaire ou non. Il suffit de voir les multiples (au moins 10) threads de mails (specimen à 100+ ici) sur l'export de GIMP. Comme l'équipe est relativement limité, ça use parfois …
Cela dit, si la tache de réaliser un meta-op GEGL pour interfacer G'MIC n'est pas insurmontable, je ne serai pas trop étonné de le voir codé pendant le LGM. Pippin est la personne a qui tu dois parler.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.