Je vous propose ici un petit point sur l'avancement du projet G'MIC, pouvant être utile aux traiteurs d'images de tout poil (c'est du moins ce que j'espère). La version 1.3.2.8 de ce projet (qui a débuté à l'été 2008) est en effet disponible depuis hier.
G'MIC est développé dans l'équipe IMAGE du laboratoire de recherche GREYC de l'ENSICAEN, à Caen/France.
Le présent :
G'MIC définit un langage de script simple, permettant d'élaborer des pipelines relativement complexes et génériques de traitements d'images. L'interpréteur de ce langage (le langage G'MIC donc) est distribué sous forme d'une bibliothèque libre (sous licence CeCILL) utilisable librement par des logiciels tiers. Deux programmes utilisant cet interpréteur sont déjà disponibles et distribués avec celui-ci :
- D'une part, l'exécutable gmic permettant d'appeler les fonctions de G'MIC en ligne de commande.
- D'autre part, le greffon gmic_gimp pour GIMP, qui ajoute un nombre important de filtres et d'effets à ce fameux logiciel libre de retouche d'images (en particulier des filtres utiles pour le lissage et le débruitage, mais pas uniquement !).
Contrairement à convert, G'MIC ne se veut pas un expert des entrées/sorties/conversions entre formats d'images. Mais alors, me direz vous, quels sont ses points forts ? Je vous propose ici d'en illustrer quelques uns, en spécifiant pour chaque exemple, la commande gmic utilisée (la version ligne de commande de l'interpréteur G'MIC), ainsi qu'une copie d'écran du résultat correspondant. J'espère ainsi vous donner tout d'abord une vue d'ensemble des capacités de G'MIC, et ensuite l'envie d'aller découvrir ce petit langage, et/ou les outils distribués avec. Peut-être même aurez vous envie d'intégrer certaines de ses possibilités dans votre propre logiciel de traitement d'images, si vous êtes développeur. La plupart de ces possibilités se retrouvent (ou peuvent potentiellement se retrouver) dans le greffon pour GIMP, qui est en fait une partie visible d'un iceberg qui est peut-être plus gros qu'on pourrait le penser au premier abord.
- Tout d'abord, G'MIC possède des modules de visualisation intégrés assez utiles. C'est une première différence avec convert, qui gère la visualisation de manière séparée, avec l'exécutable display, que je trouve personnellement moins pratique :
- Visualiser une image 2D/3D quelconque et pouvoir naviguer/zoomer dedans : gmic lena.jpg (capture 2D) (capture 3D)
- Visualiser une courbe 1D : gmic -plot "'cos(x)%sin(x*2)'" (capture)
- Visualiser une élevation 3D d'une image 2D : gmic -elevation3d "'30*sin(x*y)^2'",-4,-4,4,4 (capture)
- Visualiser un objet 3D, en format .off, ce qui permet d'avoir une alternative au vieillissant mais néanmoins utile Geomview: gmic eros.off (capture)
- Visualiser une caractéristique classique d'une image ou d'une liste d'image, ici les 2 composantes du gradient : gmic lena.jpg -gradient -d (capture)
A l'usage, ces possibilités de visualisation intégrées sont très pratiques, et rapides à appeler, notamment car elles permettent d'appréhender correctement des données images à valeur flottantes (dernier cas par exemple). Utile aussi, lorsque l'on veut débugguer un script G'MIC en cours de développement.
- Un des autres avantage de G'MIC est son grand nombre de filtres/effets prédéfinis, et surtout son évolutivité dans ce domaine : il est possible d'ajouter ses propres effets personnalisés, chaque effet étant écrit dans le langage de script G'MIC.
Beaucoup d'exemples de filtres/effets ainsi que leurs commandes associées sont illustrés sur la galerie d'exemples de G'MIC. Ce qui est potentiellement intéressant, c'est que tout logiciel intégrant l'interpréteur G'MIC pourra bénéficier de l'arrivée de nouveaux filtres d'images écrits dans ce langage, sans même avoir besoin de recompiler quoique ce soit.
- L'utilisation de G'MIC a également un grand intérêt lorsque l'on veut générer des images 2D/3D synthétiques ou des surfaces maillés en 3D, par exemple pour tester ou comparer les performances d'algorithmes de traitement d'images en développement. Ceci est possible, d'une part car G'MIC possède un évaluateur d'expressions mathématiques, et d'autre part, car il est capable de dessiner un certain nombre de choses dans des images (polygones, splines, texte, etc...).
- Générer une forme géométrique bruitée à partir d'une formule implicite : gmic 256,256,1,1,"X=x-w/2;Y=y-h/2;sqrt(abs(X)^2+abs(Y)^2.2)+20*?" -t 50% (capture)
- La même chose pour une image volumique, avec visualisation de l'interface correspondante sous forme d'une surface maillée : gmic 128,128,128,1,"X=x-w/2;Y=y-h/2;Z=z-d/2;sqrt(abs(X)^2+abs(Y)^2.2+abs(Z)^2)+10*?" -t 30% -blur 1 -isosurface3d 50% (capture)
- On se rend compte assez vite qu'en ajoutant des boucles ou des tests, on peut obtenir des pipelines de génération d'images ou d'objets relativement complexes, et ce, from scratch. Par exemple : gmic -repeat 20 -torus3d 15,2 -col3d[-1] "{?(60,255)},{?(60,255)},{?(60,255)}" -*3d[-1] 0.5,1 -if "{@{>,-1}%2}" -rot3d[-1] 0,1,0,90 -endif -+3d[-1] 70 -+3d -rot3d 0,0,1,18 -done
(capture)
- G'MIC est intéressant également, car il permet de créer des fenêtres tout en gérant les évènements utilisateurs associés (souris, clavier, ...), et ce, depuis la version 1.3.2.8. Ainsi, il est possible d'écrire des scripts en G'MIC où l'utilisateur a un contrôle visuel sur le traitement d'image qu'il effectue. Trois petits scripts existent déjà et illustrent cette possibilité :
- Un petit éditeur de courbes fermées splines : gmic -x_spline (capture)
- Une démo "Fish-Eye" où l'utilisateur peut zoomer sur une partie de l'image de manière interactive : gmic -x_fish_eye (capture)
- Un explorateur de fractales Mandelbrot/Julia modeste mais fonctionnel : gmic -x_mandelbrot (capture)
A noter que ces exemples ne sont pas des Easter Eggs, dans le sens où ce ne sont pas des fonctionnalités cachées, qui seraient codées "en dur" dans G'MIC. Les sources de ces scripts sont disponibles, dans le fichier des scripts reconnus par défaut, mais ils sont tout à fait modifiables et améliorables par quiconque intéressé pour ce faire (je ne les ai pas copiés/collés ici, ils sont un peu plus complexe, vous vous en doutez). On pourrait même à terme imaginer créer de petits jeux en scripts G'MIC, même si le but premier du langage n'est évidemment pas celui-ci.
Le langage G'MIC est maintenant stable et fonctionnel. J'ai récemment proposé un projet pour étudiants dont le but serait d'enrichir la base des filtres disponibles, afin de les intégrer rapidement dans le greffon pour GIMP, qui est aujourd'hui la partie de G'MIC la plus utilisée à ma connaissance. Je parcours souvent des forums spécifiques à la retouche photo numérique, et je vois bien qu'il y a encore pleins de processus/effets faits "à la main" qu'on pourrait automatiser avec G'MIC.
Dans un futur plus lointain, j'aimerais voir l'interpréteur G'MIC se retrouver dans d'autres logiciels libres liés au traitement d'image. J'ai essayé de vous montrer que ses possibilités sont assez étendues, et je suis sûr que cela pourrait avoir une utilité dans pas mal de produits traitant aussi bien d'images 2D que 3D. Depuis la dernière version 1.3.2.8, l'interpréteur G'MIC peut se compiler sous forme d'une bibliothèque dynamique (C++) indépendante, et l'API a été simplifiée au maximum pour faciliter son insertion dans d'autres projets. Il est donc à priori facile de bénéficier très rapidement de tous les filtres de G'MIC déjà disponibles dans vos propres programmes (cela inclus bien évidemment, les filtres de débruitage d'image GREYCstoration).
Par ailleurs, les possibilités du greffon G'MIC sont maintenant utilisables dans les script-fu de GIMP, ce qui ouvre encore de nouvelles possibilités pour les scripteurs fous habitués au Scheme.
J'ai essayé de vous montrer par ce long journal que G'MIC a des fonctionnalités intéressantes, a une architecture ouverte, et essaie de faire passer encore un peu plus le libre dans le domaine du traitement d'image. N'hésitez donc pas à le tester et éventuellement à l'intégrer dans vos propres réalisations libres ! Si vous avez des interrogations, vous pouvez aussi me contacter, éventuellement lors de ce séminaire, ou laisser un commentaire à la suite de ce journal.
Sur ce, bon appétit !
# Erreur 403 sur les captures
Posté par Ontologia (site web personnel) . Évalué à 2.
http://www.greyc.ensicaen.fr/~dtschump/lfr/splines.jpg
http://www.greyc.ensicaen.fr/~dtschump/lfr/eros.jpg
Etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Erreur 403 sur les captures
Posté par Donk . Évalué à 2.
# intéressant !
Posté par Graveen . Évalué à 2.
Je dois avouer que je ne vois pas dans G'MIC une raison de migrer et de refaire toutes mes lignes de commande; j'aurais cependant été conscient de cet outil, j'aurais certainement essayé de l'évaluer. Peut-être lorsque j'aurais souffé un peu, et que la motivation pour me refaire un petit apprentissage syntaxique et fonctionnel sera là ?
Longue vie à G'MIC !
[^] # Re: intéressant !
Posté par ZeroHeure (site web personnel) . Évalué à 2.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Problème de (non) prise en compte du gamma?
Posté par drakmaniso . Évalué à 7.
J'étais justement en train de lire un article très intéressant sur les problèmes de la gestion du gamma dans les logiciels de traitement d'image:
http://www.4p8.com/eric.brasseur/gamma.html
(en l'occurrence il ne parle que des algorithmes de redimensionnement, mais le problème est plus vaste; article découvert via le wiki de Blender)
Dans cet article il donne une image (le jpeg du Dalai Lama) qui, une fois redimensionnée de 50% dans la quasi totalité des logiciels, donne un résultat erroné (soit tout gris, ou bien couleurs complètement fausses). L'image est un cas extrême, spécialement conçu pour mettre en évidence le problème, sur une cas réel l'erreur est plus discrète mais bien présente.
J'ai donc essayé avec gmic:
gmic gamma_dalai_lama_gray.jpg -r 50%,50% -o out.pngEt le résultat est faux (image verte). J'ai essayé les différents types d'interpolations, j'obtiens la plupart du temps un dalai lama vert, un carré gris avec la "moving average interpolation", et un dalai rose avec la "grid interpolation".
Pour info, Gimp donne un carré gris avec tous les types d'interpolation, et un dalai lama vert sans interpolation. Firefox donne aussi un carré tout gris. Par contre GEGL devrait gérer la chose correctement (pas testé).
Mes questions:
- Ai-je loupé quelque chose? Une option pour prendre en compte le gamma de l'image lors des transformations?
- Pourquoi une telle différence par rapport à Gimp? (il me semble que l'interpolation ne devrait jamais donner un dalai lama vert?)
- Dans la version testée (1.3.2.0, sous windows pour le moment), je n'ai trouvé aucune option pour appliquer une corection de gamma, qui aurait permis de linéariser l'espace de couleur avant de faire la transformation, puis de la remettre en gamma 2.2. Pourtant cette fonction est documentée sur le site web?
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par drakmaniso . Évalué à 4.
Du coup j'ai essayé d'installer gmic sur une ubuntu 9.04, l'installation du .deb se déroule correctement mais à l'exécution il lui manque libMagick++.so.10. Un petit problème de dépendances dans le package, apparement. Un petit lien symbolique pas joli du tout permet de lancer gmic sans partir à la chasse à la bibliothèque.
Premier constat, le résultat est toujours le même sous linux avec la dernière version.
Ensuite, j'ai essayé de "linéariser" l'espace de couleur avec la commande suivante:
gmic -apply_gamma 0.4545 gamma_dalai_lama_gray.jpg -r 50%,50% -apply_gamma 2.2 -o out2.png...mais je n'obtiens toujours pas le résultat escompté. Peut-être parce qu'il faudrait en plus passer sur une précision supérieure? Ou bien ai-je fait une erreur dans le choix des commandes?
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par drakmaniso . Évalué à 2.
Je viens de faire quelques tests avec le "concurrent" ImageMagick. La ligne de commande recommandée sur le site cité plus haut:
convert gamma_dalai_lama_gray.jpg -depth 16 -gamma 0.4545 -scale 50% -gamma 2.2 out3.png...fourni bel est bien le resultat escompté (un beau dalai lama en couleur, un peu délavé).
Pour voir si la différence était due au passage en précision 16 bits, j'ai supprimé la conversion:
convert gamma_dalai_lama_gray.jpg -gamma 0.4545 -scale 50% -gamma 2.2 out4.png...est le résultat est toujours correct.
Donc soit j'utilise mal gmic, soit il y a une subtilité qui m'a complètement échappé, soit il y a un problème dans l'une des fonctions utilisées de gmic...
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par David Tschumperlé (site web personnel) . Évalué à 5.
Si tu écris :
gmic gamma_dalai_lama_gray.jpg -apply_gamma 0.4545 -r 50%,50%,1,3,2 -apply_gamma 2.2
Tu obtiens quelque chose qui a l 'air correct.
David.
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par drakmaniso . Évalué à 2.
Mais ce n'est pas juste une question d'ordre, car la ligne de commande:
gmic gamma_dalai_lama_gray.jpg -apply_gamma 0.4545 -r 50%,50% -apply_gamma 2.2 -o out6.png...fourni également un résultat erroné.
C'est la dernière option de ta commande resize le ",2" qui semble faire la différence. (Elle n'est pas documentée en détail dans l'aide, il est juste dit que cela concerne le centre, je suppose le centre de l'interpolation.)
Ne serait-il pas pertinent de faire travailler gmic en espace de couleur linéaire? La plupart des logiciels de traitement d'image semblent prendre cette direction. Cela éviterait bien des complications...
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par David Tschumperlé (site web personnel) . Évalué à 9.
G'MIC n'a aucune notion de l'espace couleur du fichier que tu lui donnes en entrée, ni de celui que tu veux utiliser en réalité. Tu lui donnes une image couleur codée en RGB non linéaire, mais lui il s'en fiche un peu, il traite les canaux comme des canaux de données brutes, il voit juste qu'il y a 3 canaux dans le fichier que tu lui donnes. Pire encore, il n'a aucune raison même de croire que ce que tu lui donnes à manger est une image couleur, ca pourrait être aussi bien une image a 128 canaux correspondant à des longueurs d'ondes différentes (image satellite par exemple), lui, il va appliquer l'algorithme qu'on lui demande d'appliquer sans prendre de décisions derrière ton dos (et c'est heureux d'ailleurs !). Il ne va donc jamais prendre la décision tout seul d'appliquer un gamma automatiquement avant de redimensionner, puis de réappliquer le gamma inverse. Si quelqu'un utilises un PNG pour stocker des infos à 3 canaux ne correspondant pas à des couleurs, il a surement pas envie de voir un gamma s'appliquer automatiquement sur ses données quand il fait un redimensionnement ! Il risque de pas comprendre pourquoi il obtient un résultat qu'il n'attendait pas.
Peut-être que la plupart des logiciels de traitement d'images prennent ce genre de décision tout seul, mais à mon sens, c'est une erreur, *sauf* si ils ne se spécialisent que dans le traitement d'images couleurs évidemment (ce qui n'est pas du tout le cas de G'MIC, je le répète).
Si tu veux considérer des transformations spécifiques à la couleur, il faut soit le faire explicitement (ce que tu as fait), soit créer une fonction G'MIC qui va implémenter ton pipeline spécifique, si c'est toujours le même, en lui donnant un nom explicite pour bien faire voir que c'est un traitement propre à des images couleurs. Ici ca serait facile, ca s'écrirait en une ligne.
Pour ta question sur le 'resize', le mode d'interpolation par défaut est le '1' (c'est à dire, le plus proche voisin), ce qui dans ton cas explique le problème, même en appliquant le gamma, puisque le voisinage du pixel le plus proche n'est pas pris en compte. Si comme moi tu spécifie un mode d'interpolation '2' (c'est-à-dire les fenêtres coulissantes), qui prend en compte le voisinage, ca va mieux D'autres choix sont possibles et devraient donner des résultats satisfaisants dans ton cas.
Par ailleurs, je reviens sur ton premier post ou tu disais que tu obtenais une interpolation "fausse" (ce qui est aussi sous-entendu dans la page web que tu donnes en lien). Pour moi, une interpolation "fausse", ca veut rien dire. D'un point de vue mathématiques, l'interpolation te donne un résultat prédictif par l'algorithme qui est utilisé derrière. Dans la page que tu donnes, l'image présentée du Dalai-lama a été dégradée artificiellement pour que justement les techniques d'interpolations les plus classiques donnent un résultat visuellement mauvais (pour un être humain s'entend). Ca veut pas dire que ces interpolations sont plus fausses qu'autre chose ! Le fait d'appliquer tes gammas va résoudre ton problème pour cette image particulière, mais je peux très bien te générer une autre image synthétiquement à partir du même Daila-Lama, qui va donner un résultat d'interpolation pas satisfaisant (visuellement) avec ta méthode (il suffit d'appliquer le gamma inverse avant).
Pour conclure, je pense que je préfère largement avoir une idée de ce que fait mon algo sans qu'on me cache quelque chose (des transformations gamma que j'aurais pas souhaité par exemple). Je préfère dire explicitement à un programme (en l'occurence 'gmic') ce qu'il doit faire, plutôt qu'être obligé de comprendre et de réparer d'éventuels dégats qui se seraient produit par des actions que je n'aurais pas prévus.
Et justement, avec G'MIC, tu peux définir des propres pipelines pour traiter tes données, ca tombe bien.
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par drakmaniso . Évalué à 2.
De plus le nom de l'application est alors trompeur: par "image", on désigne la plupart du temps un document destiné à être visualisé, pas une image satellite. Or, la quasi-totalité de ces documents est encodé dans un espace de couleur non linéaire (gamma 2.2 étant un standard); et quand ce n'est pas le cas, il s'agit la plupart du temps d'un format spécifique aisément reconnaissable, ou bien le gamma est spécifié dans les méta-données.
En ce qui concerne l'image du Dalaï Lama, je ne suis pas d'accord, mais parce que je me place d'un point de vue "artiste". Le gamma standard est non-linéaire, donc cette image est parfaitement représentative d'une utilisation courante. Elle exacerbe le problème, mais elle n'est en aucun cas trafiquée pour le créer. Il suffit de surfer sur n'importe quel site dédié aux arts graphiques numériques pour voir que la prise en compte du gamma est une étape clef de la production d'images. Et que de nombreux outils compliquent la tâche là où ils pourraient la simplifier (c'est de moins en moins vrai).
L'exemple du plugin Gimp est flagrant: il va donner pour certaines opérations un résultat (légèrement) erroné, puisqu'un artiste ne vas pas travailler sur une image linéarisée (elle s'afficherait alors de façon incorrecte). Le plugin au moins devrait travailler en espace linéaire, surtout que Gimp connait la notion d'espace de couleur, il n'y a donc pas d'ambiguïté de ce côté-là.
Encore une fois je comprends l'orientation "scientifique" du projet, mais il y a déjà pas mal d'outils dans ce domaine. Un outil adapté à la création aurait été novateur.
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par David Tschumperlé (site web personnel) . Évalué à 4.
Moi j'en ai certainement une autre, je me place peut-être plus du côté 'mathématique' et 'signal'. Je ne vois pas en quoi une image satellitaire à 128 canaux ou bien une image médicale volumique provenant d'une IRM seraient moins une image que des images couleurs 2D "classiques". Le domaine du traitement d'image est assez vaste pour qu'on ne choisisse pas des raccourcis trop rapides (dans le sens pas assez générique à tout type d'image) dans les algos que l'on implémente.
D'autant plus que ce que tu me dis sur les gammas n'est absolument pas incompatible avec l'utilisation de G'MIC. Si on veut rajouter un gamma avant et un après, on peut le faire ! Il n'y a pas vraiment de problèmes non ? c'est parce que c'est plus long à écrire ?
Rien n'empêche techniquement d'appliquer par exemple tes gammas dans tous les filtres du plug-in GIMP.
Si tu as des briques élémentaires de base permettant de faire certaines opérations, rien n'empêche de les combiner (c'est même conseillé, et c'est un peu le but dans G'MIC justement). Au contraire, moi je n'aimerais vraiment pas voir qu'un outil fasse des opérations dans mon dos auquel je ne m'attend pas.
Question de point de vue.
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par drakmaniso . Évalué à 1.
Quand à spécifier les corrections gamma à chaque utilisation, cela devient vite très lourd, et peut dans certains cas générer des pertes si la précision n'est pas suffisante (comme dans gimp). Ce n'est pas pour rien qu'un standard est apparu pour cela (même Apple a fini par y venir), et que les logiciels "de création" commencent à prendre en compte l'espace de couleur dans leurs opérations.
Enfin, je continue de penser que, au moins dans le cas des images dont le gamma est stocké dans les métadonnées, le logiciel devrait prendre en compte cette information.
En tout cas, bonne continuation.
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par BAud (site web personnel) . Évalué à 3.
dans la logique Unix, faire une chose et le faire bien ;-)
tu peux faire
- un alias gmic-artist_image qui rajoute ce qu'il faut systématiquement
- ou dans une optique d'utilisation par Gimp (ou Krita), c'est le logiciel appelant qui a connaissance de la nature du traitement qui positionnera des paramètres par défaut (en fonction d'infos sur l'image voire permettra de les changer pour un contrôle fin).
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par freejeff . Évalué à 3.
Comme David te l'a expliqué tu peux faire une fonction qui applique le gamma le gamma que tu as défini, son logiciel est assez modulaire pour le faire en une ligne !
Personnellement si j'utilise son algorithme pour faire de la thermographie (chose que j'envisage), je serais très mécontent qu'un non linéarité soit appliquée sans mon concentement !!
Il faut accepter que des personnes utilisent les logiciels d'une manière que tu n'avais pas initialement prévue.
Une question pour David, peux tu utiliser ton programme pour déformer une image et si oui, peux tu choisir un noyau d'interpolation pour les déplacement locaux sub pixel ?
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par drakmaniso . Évalué à 2.
Je regrette que la présentation du projet ne soit pas plus explicite de ce côté là.
(Et non, ce n'est pas parce qu'un outil peut tout faire, qu'il est approprié pour tout. L'ergonomie a toujours existé, y compris dans le monde unix: la présence de nombreuses variations autour d'outils fonctionnellement équivalents en est bel exemple.)
Pour information, la spécification du PNG est très claire sur le sujet du gamma:
http://www.w3.org/TR/PNG/#13Decoder-gamma-handling
En théorie, si des informations satellites ou de thermographie sont encodées en PNG, elles devraient explicitement notifier dans les métadonnées un gamma de 1.0 (encodage linéaire).
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par PegaseYa . Évalué à 0.
Et puis, perso, je n'aime pas trop qu'on dise du traitement d'image que c'est du traitement du signal...je trouve ça différent: dans le traitement d'image, il y a des notions de morphologie, de topologie (pour ne citer que ça) qui ne se retrouvent pas de le traitement du signal (sous-entendu 1D).
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par Larry Cow . Évalué à 5.
Pourquoi un tel sous-entendu?
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par PegaseYa . Évalué à -1.
ce que je voulais dire, c'est qu'une image est plus qu'un signal à plusieurs dimensions, et qu'on n'a pas tout à fait les mêmes approches pour traiter des images et des signaux.
bon, c'est aussi parce que j'aime bien dire du mal du traitement du signal :D
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par PegaseYa . Évalué à 2.
ex: la topologie, c'est adapté pour les images 2D, voir 3D, par pour les signaux classiques (1D) ni même pour la multimodalité, qui n'est somme toute qu'une concaténation d'images.
[^] # Re: Problème de (non) prise en compte du gamma?
Posté par David Tschumperlé (site web personnel) . Évalué à 2.
gmic -h warp
# Que de bonnes choses !
Posté par brunus (site web personnel) . Évalué à 1.
Effectivement l'utilisation de G'MIC en ligne de commande ou peut être embarqué dans une de nos applications (une chaine éditorial libre) peut vraiment nous intéresser.
Pour le moment nous utilisons convert et parfois GM (GraphicsMagick) pour sa rapidité, mais il y a encore des opérations très lentes.
J'ai parcouru la doc de G'MIC et je vais faire des tests, mais cela m'intéresserai de savoir si il me permettra de réaliser les opérations suivantes :
- Prendre une image PNG RGBA, l'aplatir sur un fond blanc (ça je suppose que ça peut être un compose avec le tracé d'un rectangle blanc, ou une fonction flatten comme dans convert, et je crois avoir vu un truc comme ça dans la doc).
- Calculer une palette minimale pour cette image (et non pas prendre un paramètre de nbr de couleurs), par exemple passer en palette indexée sur 8 niveaux pour une image qui ne contient que deux teintes, ou choisir 128 couleurs si la population de teintes semble pouvoir le permettre.
- Sauvegarder en PNG optimisé, à l'instar de convert, qui choisit le meilleur profil de sauvegarde pour les PNG (PNG 32, 34 ou 8 bits si on est passé en palette indéxée)
Nous réalisons ces opérations (et bien d'autres) avec convert dans le cadre de notre chaîne éditoriale, mais ce bon vieux convert est très lent et peu évolutif...si nous pouvions nous en passer, ce serait le pied !
Autre question, est ce que G'MIC est capable ou sera capable de traiter des format RAW ? (ça c'est pour moi perso qui suis un grand débutant en photo numérique et qui a besoin de faire pas mal de traitement pour obtenir des images montrables ;-) )
Merci d'avance si tu peux prendre le temps de m'aiguiller un peu, mais de toutes façon, j'ajoute le test profond de G'MIC su ma todolist.
@+
[^] # Re: Que de bonnes choses !
Posté par David Tschumperlé (site web personnel) . Évalué à 3.
- Composer un RGBA sur un fond blanc : gmic image_rgba.png -i[0] 100%,100%,1,3,255 -compose_rgba devrait faire l'affaire.
- Calculer une palette minimale. A priori rien encore pour faire ça dans G'MIC. Faudrait des algos de clustering.
- Sauver en PNG optimisé : rien non plus. Comme je l'ai dit, G'MIC est assez basique en ce qui concerne les entrées-sorties, notamment les particularités des formats d'images. Pour ce travail, convert est le meilleur, sans aucun doute.
# Intégration de G'MIC dans un logiciel tiers
Posté par David Tschumperlé (site web personnel) . Évalué à 5.
Pour gérer les données d'images d'entrées et de sortie, je vous invite à regarder plus précisement ce code source exemple : http://gmic.cvs.sourceforge.net/viewvc/gmic/gmic/src/gmic_us(...) . C'est du C++, est comme vous pouvez le voir, c'est extrêmement simple d'utilisation.
J'espère que ça donnera envie à certains d'aller voir de plus près.
David.
[^] # Re: Intégration de G'MIC dans un logiciel tiers
Posté par steckdenis (site web personnel) . Évalué à 9.
Tout d'abord, toutes mes félicitations pour ce programme. Je ne l'ai pas encore utilisé, mais vu ce qu'il sait faire (le truc avec le sinus en 3D), je suis certain qu'il servira à vraiment plein de monde.
Krita, l'éditeur d'images bitmap de la suite KOffice de KDE, a également pour vocation d'être très avancé technologiquement (il gère les profils de couleurs à 8, 16 et 32-bit depuis des lustres, alors que GIMP a encore du mal). Vu que G'MIC a l'air facile à intégrer, je te propose de faire un petit tours sur le forum de Krita ( http://forum.kde.org/viewforum.php?f=136 ), pour proposer l'intégration de G'MIC dedans.
C'est justement ce genre de choses qu'ils aiment, et qui apporterait d'un coup une énorme suite de fonctionnalités au programme. Ils pourraient même s'en donner à coeur joie et nous coder un joli éditeur de script G'MIC avec aperçu :) !
Et pour finir, c'est justement la bonne période. KOffice vient de recevoir l'aide de Nokia et d'une autre entreprise (j'ai cru entendre parler de 32 développeurs en plus, mais franchement, je ne suis absolument pas certain de cette information), et KOffice 2.1 sortira bientôt. Ils sont donc en phase de stabilisation, en ont marre de corriger des bugs, et attendent de très bonnes idées pour Krita 2.2, surtout quand le travail est déjà fait comme ici.
J'espère franchement pouvoir utiliser une telle merveille dans Krita dans quelques mois. Chapeau bas.
# Plug-in Gimp très pratique
Posté par Mehdi Yousfi-Monod (site web personnel) . Évalué à 1.
Je viens d'essayer la version plug-in Gimp, et je suis ravi de voir la quantité, la variété et la qualité des filtres proposées.
Nombre d'entre eux me faisaient défaut sous Gimp (et je ne suis certainement pas le seul dans ce cas).
Dans mes premiers tests, le paramétrage proposé pour chaque filtre a été suffisamment complet et intuitif pour obtenir l'effet escompté (et même de bons effets inattendus en jouant un peu).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.