David Tschumperlé a écrit 340 commentaires

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

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

Bon ca y'est c'est corrigé. La transparence des GIF va marcher pour la prochaine version.

Le gif animé source n'avait pas de transparence, mais un fond blanc seulement.
Du coup, je me rend compte que G'MIC ne sait apparemment pas lire correctement les GIF avec de la transparence, ce qui est gênant effectivement. Je vais corriger ça pour la prochaine version.

Oui, dans les faits, 'gmic' peut remplacer ImageMagick (pour ma part, je n'utilise quasiment plus les outils fournis avec IM, alors que je le faisais au quotidien auparavant).
IM est quelquefois meilleur sur les entrées-sorties, pour charger/sauver certains formats d'image (le GIF notamment !), mais quand G'MIC n'arrive pas à charger une image en natif, il essaye de toute façon de passer par une conversion via ImageMagick, donc au final c'est transparent pour l'utilisateur. Par contre, au niveau traitements et visualisation proprements dits, je trouve G'MIC bien plus complet.

Mais cela dit, mon avis est probablement biaisé !

Oui normalement G'MIC sait faire ça avec des GIFs (animés ou non).
Exemple :

$ gmic 412.gif -resize 50%,50%,1,3,2 -o resized_412.gif,25
[gmic]-0./ Start G'MIC parser.
[gmic]-0./ Input file '412.gif' at position [0] (32 images [0] = 150x150x1x3, ..,[31] = 150x150x1x3).
[gmic]-32./ Resize images [0,..,31] to 50%x50%x1x3, with moving average interpolation, dirichlet boundary conditions and alignment (0,0,0,0).
[gmic]-32./ Output images [0,..,31] as animated file 'resized_412.gif', with 25 fps.
[gmic]-32./ End G'MIC parser.

Source : 

Résultat : 

Et du coup, rien n'interdit de mettre un effet 'old photo' en passant :

gmic 412.gif -old_photo -resize 50%,50%,1,3,2 -o oldphoto_412.gif,10
[gmic]-0./ Start G'MIC parser.
[gmic]-0./ Input file '412.gif' at position [0] (32 images [0] = 150x150x1x3, ..,[31] = 150x150x1x3).
[gmic]-32./ Apply old photo effect on images [0,..,31].
[gmic]-32./ Resize images [0,..,31] to 50%x50%x1x3, with moving average interpolation, dirichlet boundary conditions and alignment (0,0,0,0).
[gmic]-32./ Output images [0,..,31] as animated file 'oldphoto_412.gif', with 10 fps.
[gmic]-32./ End G'MIC parser.

Résultat : 

toutes les images de sections de télégrammes et d'avatars converties avec un filtre sépia
d'ImageMagick, mais nous avons eu des soucis sur les images comportant de la transparence

Alors qu'il suffit d'utiliser G'MIC et sa commande -sepia, quel dommage ;)
Voire même la commande -oldphoto :

Pour l'année prochaine peut-être ?

Donc si on a la chiasse, ça va plutôt bien finalement !
Ca coule de source !

Utilises-tu Chrome ?
Nous avons un problème avec Chrome pour le switch des images, c'est effectivement un peu lent, par contre sous Firefox ou IE ça turbine.

Sébastien a déjà mis en place quelques améliorations du site, avec :

• La possibilité de pipeliner les traitements : une image de sortie pouvant servir de nouvelle entrée pour un nouveau filtre.
• La possibilité de 'bouger' la preview quand le traitement est en vue locale, afin de voir l'effet d'un filtre à plusieurs endroits différents.
• La taille limite des images passe à 1280 px de haut ou de large.

Je trouve la proposition du commentaire précédente très pertinente, on va voir si c'est possible à faire.

L'algo d'estimation de déplacement de G'MIC est exactement celui là (G'MIC est basé sur CImg..).
Donc à priori, on peut utiliser G'MIC pour l'appeller depuis la ligne de commande.

Oui, il faudrait que je puisse voir le type des données d'entrées, et ce que tu veux en faire exactement. Je pourrais aviser ensuite. Effectivement on peut continuer en e-mail :p

Oui je pense que c'est possible, G'MIC possède des outils d'estimation de déplacement local entre deux images, en 2D et en 3D.

A noter qu'il existe aussi une autre interface a G'MIC : ZArt, développé également par Sébastien Fourey (quel contributeur actif!) permettant de jouer avec les filtres de G'MIC sur les images provenant de la webcam. C'est très intéressant notamment pour faire des démonstrations lives d'opérateurs de traitement d'image à des étudiants, ou lors d'occasions telles que la fête de la science.

Honte à moi pour cet oubli !

Voici une copie d'écran de ZArt en action :

Ce que est important in fine, c'est d'avoir le choix.

Personne n'utilise des outils de la même façon. Pour remplacer une expression dans un fichier texte, je suis de ceux qui trouve que sed est très pratique (je ne me vois pas apprendre perl juste pour faire ça).
De la même manière, quand je vois le plug-in Lua pour GIMP, je suis bien content de pas faire du lua pour traiter mes images. J'écris la même chose en une ligne alors qu'en lua, il en faut 20 (au moins sur l'exemple du screenshot de l'url que je t'ai donné).

Je crois pas que ça soit du gachis d'avoir le choix.

On peut tout à fait enlever la dépendance à libX11, il suffit de compiler en commentant les lignes suivantes dans le Makefile :

X11_CFLAGS = -Dcimg_display=1 -Dcimg_appname=\\\"gmic\\\" -I/usr/X11R6/include #-Dcimg_use_xrandr
X11_LDFLAGS = -L/usr/X11R6/lib -lX11 -lpthread #-lXrandr

Note qu'un plug-in permettant de coder en LUA pour faire des traitements d'images en GIMP existe déjà : http://pippin.gimp.org/gluas/

Le but de G'MIC, ce n'était pas de faire une bibliothèque de traitement d'images accessible depuis un langage de script. C'est plutôt d'essayer de définir un langage de script minimal et surtout concis pour faire des opérations sur les images (et pour ne faire que ça). C'est assez différent dans l'esprit.
Je suis bien conscient que le résultat ne te plait pas trop (voir les précédents journaux sur G'MIC, où tu me poses souvent la même question), mais je le redis, ça n'a pas pour vocation d'être un langage généraliste tel que Python ou Lua. A la limite, on pourrait comparer ça au 'langage' utilisé dans 'sed'. Ca a une fonction bien précise, c'est pas forcément très clair, mais c'est concis et c'est prévu pour faire de la manipulation de données (d'images pour gmic, de texte pour sed).

La libgmic contient l'implémentation de l'interpréteur G'MIC, qui lui même est basé sur CImg (mais aussi sur d'autres choses).

Sur une image c'est généralement possible de faire un calcul distribué pour différentes parties de l'image, c'est là dessus qu'on se base.

On essaye de se mettre tout doucement à OpenMP dans CImg pour multi-threader les opérations.
Je ne suis pas trop spécialiste, mais c'est une solution pas trop intrusive qui a l'air prometteuse.

Quelques remarques, peut-être qu'un modérateur peut corriger :

1. Le lien Thémamap ne fonctionne pas (parenthèse fermante dans l'URL)
2. Le lien sur G'MIC est http://gmic.sourceforge.net, et pas ma page perso.

Merci.

Il y a aussi Photivo : http://photivo.org/photivo/start

qui a l'air pas mal.

Photivo is a free and open source (GPL3) photo processor. It handles your RAW files as well as your bitmap files (TIFF, JPEG, BMP, PNG and many more) in a non-destructive 16 bit processing pipe with gimp workflow integration and batch mode.

Je voulais juste dire qu'il suffit d'installer 'gmic' (la version ligne de commande de G'MIC), pour pouvoir générer de tels rendus dans des scripts ou à partir du shell.

dtschump@nf310:~$ gmic -h rodilius

 gmic : GREYC's Magic Image Converter (Sep 29 2011, 12:19:59).

        Version 1.5.0.4 (beta), Copyright (C) 2008-2011, David Tschumperle 
        (http://gmic.sourceforge.net)

    -rodilius        0<=_amplitude<=100,_0<=thickness<=100,_sharpness>=0,_nb_orientations>0,_offset,_color_mode={ 0=darker | 1=brighter } 

        Apply rodilius (fractalius-like) filter on selected images.
        Default values : 'amplitude=10', 'thickness=10', 'sharpness=300', 'nb_orientations=5', 'offset=0' and 'color_mode=1'.

        Example(s) :  image.jpg --rodilius ,

On voudra éventuellement bidouiller un peu le contraste avant ou après pour mieux faire ressortir l'aspect fibreux du rendu :

gmic image.jpg -rodilius 12,10,300,10 -normalize_local 10,6 -o output.jpg

G'MIC est une alternative aux outils ligne de commande de ImageMagick pour tout ce qui est manipulation d'image (ça fait bien 2 ans que je n'ai plus utilisé 'convert' par exemple).

J'ai 308 filtres car j'ai activé les 'filtres additionnels' (section 'A propos / Additional Filters'). Ces filtres sont proposés et hébergés par des contributeurs extérieurs. G'MIC possède un système d'update assez sympa qui permet en effet à d'autres personnes de proposer leur propres filtres à tout le monde (sous réserve d'activer explicitement une 'source externe'). Cela peut-être des filtres très spécifiques ou en cours de développement (comprendre "à la finition pas toujours top moumoute) que les concepteurs de filtres peuvent tout de même faire partager pour les tester à plus grande échelle. Il y a encore assez peu de développeurs de filtres additionnels, mais j'espère que c'est quelque chose qui va évoluer par la suite.

Oui effectivement, mais Krita se développe de telle façon que son architecture ne va probablement pas proposer d'API simple pour la création de plug-ins externes, ce qui implique que pour ajouter des fonctionnalités telles que celles proposées par G'MIC, il faudrait devenir un contributeur direct du projet Krita, et le rendre peut-être dépendant de G'MIC, ce qui ne me semble pas vraiment souhaitable (ni les développeurs de Krita d'ailleurs, ils utilisent déjà leur propre bibliothèque donc ça ferait des fonctionnalités doublons, et puis cela demanderait un temps important de développement sans être sûr qu'il soit finalement intégré au projet).
Je trouve que le système de plug-in est idéal, car G'MIC forme un ensemble indépendant et complet qu'on peut donc théoriquement utiliser un peu partout (il suffit d'adapter les entrées-sorties des logiciels concernés).
J'avais demandé à tout hasard sur la liste de dev de Krita, mais les quelques liens qu'ils m'ont donné me laisse l'impression que ça n'allait vraiment pas être facile, ni perenne, vu qu'ils sont en train de changer pas mal de choses sur leur architecture.
J'ai essayé aussi de voir si je pouvais pas envisager de faire un plug-in pour Pinta, mais c'est du C#, et c'est pareil , ils n'ont pas vraiment prévu d'API pour faire des plug-ins.