David Tschumperlé a écrit 332 commentaires

Travaillant dans l'équipe IMAGE du GREYC, j'avais effectivement des besoins d'outils de traitement / visualisation / exploration d'images en ligne de commande, un peu plus 'génériques' que ce que proposaient les outils existants d'alors (ImageMagick/GraphicsMagick pour ne pas les nommer). Notamment, lorsque l'on commence à vouloir manipuler des images à N canaux (N>4), à valeurs flottantes, et/ou volumiques (et c'est monnaie courante en traitement d'image), ImageMagick et GraphicsMagick ne sont pas adaptés (donc dès qu'on sort du domaine de la photo numérique).

Exemples de traitements 'simples' que je ne pouvais pas faire en ligne de commande :

1. Appliquer un filtre de convolution avec un noyau quelconque sur une image volumique à 32 canaux et à valeurs flottantes (images DT-MRI typiquement).
2. Extraire et visualiser une iso-surface (par exemple une segmentation) d'une image volumique (il y a des programmes qui font ça, mais en ligne de commande, c'est galère).
3. Annuler une plage de fréquence spécifique (dans Fourier) pour détramer certains types d'images.

Avant G'MIC, il fallait donc que je programme spécifiquement un petit code C++ pour ce genre d'opérations (qui devraient être très simples à appliquer dans notre domaine). Et le petit code, une fois qu'il marchait, il était mis dans un coin et il fallait le ressortir, et le ré-adapter quand on rencontrait d'autres cas similaires. A un moment donné, l'idée de créer un framework simple pour éviter cette perte de temps et favoriser la réutilisation a donc naturellement émergée.

Je te conseille d'aller voir les slides de présentation du projet G'MIC, qui décrivent entre autres, les motivations du projet.
Après, le fait d'avoir d'autres interfaces à la ligne de commande (dont le plug-in pour GIMP), c'est plus un effet de bord qu'autre chose, le but premier c'était de faire un outil utilisable en ligne de commande pour appliquer des traitements plus génériques que ce que proposait ImageMagick.

Oui c'est ce que je pense. L'équipe de dev de GIMP a d'ailleurs commencé à transposer tous les anciens plug-ins 'standards' (livrés par défaut avec l'install de GIMP) en noeuds GEGL.
On peut suivre l'avancée des travaux ici : http://wiki.gimp.org/index.php/Hacking:Porting_filters_to_GEGL
Par contre, pour les plug-ins développés par des gens extérieurs (comme nous), il n'y a rien de prévu.

Mais justement pour ce genre de cas, l'inpainting n'est pas vraiment nécessaire.
Il suffit de calculer pour chaque pixel sa valeur médiane dans toutes les frames, et le tour est joué.

Les prochaines versions de GIMP se baseront complètement sur GEGL, une bibliothèque graphique qui a pour particularité d'utiliser des 'arbres d'opérateurs' pour modéliser les pipelines de traitements à appliquer sur les images. Avec ce nouveau système, chaque nouveau filtre est donc censé s'exprimer comme un 'noeud' potentiel de ces arbres.
Du coup, l'API actuelle des plug-ins GIMP va devenir plus ou moins obsolète, et la plupart des plug-ins existants ne fonctionneront probablement plus. De notre côté, si on veut évoluer proprement, on va avoir besoin de recréer une interface complète à partir de zéro pour s'interfacer avec GEGL, ce qui est un très gros boulot. Personnellement, je ne suis pas super motivé par cette perspective purement 'technique' (il n'y aura pas de plus-value réelle en ce qui nous concerne par rapport à la façon dont fonctionne le plug-in actuel), et je ne connais encore personne de motivé pour créer des noeuds GEGL à partir de la libgmic.
Donc pour le moment, il est peu probable que G'MIC puisse être utilisé pour les prochaines versions majeures de GIMP. Mais j'espère me tromper bien entendu !

Pour la vidéo, ça se complique. Si on applique l'inpainting frame par frame, ça ne rend rien, il manque une cohérence temporelle, et ça saute aux yeux en pratique. C'est toute la difficulté de l'inpainting vidéo, et c'est un problème vraiment pas résolu encore. La plupart des papiers sur l'inpainting vidéo montrent encore des résultats où les vidéos ont des fonds fixes…

Non rien de magique (malheureusement!), comme je l'ai expliqué dans ce commentaire du journal correspondant.

Ca c'est effectivement le mystère le plus total. Je vais essayer d'en discuter avec les développeurs de GIMP lors de LGM'2014 à Leipzig. Il est possible en fait que ça puisse ne pas se faire du tout.

En fait la plupart des algorithmes d'Inpainting font exactement ça : ils essayent de copier/coller des bouts d'images connus à l'endroit des zones à reboucher, mais en faisant ça de manière automatique.
ça revient donc bien à utiliser l'outil Clone de GIMP.

Mais ne rêvons pas, l'algorithme ne fait pas ça mieux que l'humain, et il y a des chances qu'en faisant le travail 'à la main', ça donne quelque chose de plus joli (mais faut prendre beaucoup de temps!).
Par exemple, avec des configurations un peu difficiles, aucun algorithme ne peut faire de miracles. Illustration avec l'exemple ci-dessous, où on essaye d'enlever le bateau. Resynthetizer et G'MIC n'arrivent pas à bien joindre les bouts, étant donné qu'il n'existe tout simplement pas de zones copiables depuis l'image d'origine correspondant parfaitement à ce que l'on cherche à reconstruire (notamment à l'intersection mer, ciel, plage à l'horizon).

Oui je me suis aperçu de quelques coquilles après coup.
En particulier, la partie 'immergée' de l'iceberg étant plutôt 'émergée' :)

Si, c'est la commande -plasma qui implémente l'algorithme du Diamond-Square.

Il y a déjà pas mal de commandes existantes pour créer des images, à partir de "rien".
On peut facilement créer une image vide et y ajouter tout un tas de bruits différents (uniforme, gaussien, poissonien, ricien,..), on peut génerer des patterns ou des textures (algorithme diamond-square par exemple), des fractales (Mandelbrot, fonctions itérées), manipuler les images dans l'espace fréquentiel (pour les textures, c'est pas mal aussi). Aussi bien en 2d qu'en 3d (textures animées).
Au niveau des possibilités, je crois qu'il y a ce qu'il faut pour s'amuser.
On peut également dessiner des formes géométriques quelconques (ellipses, polygones, segments, …), et on peut créer des pipelines avec des boucles, des conditions, etc.. Donc là encore, il y a moyen de faire des choses amusantes.

De ce que je vois de libnoise, c'est du bruit de Perlin, et je pense que c'est assez facile à réaliser aussi (si je me rappelle bien, c'est juste des sommes de bruits lissés à différentes échelles). C'est assez proche de ce que donne l'algorithme diamond-square.

Non, aucun problème.

Du point de vue du projet G'MIC, le plug-in pour GIMP est "seulement" une des interfaces disponibles pour manipuler les fonctionnalités de G'MIC (c'est aussi la plus utlisée d'ailleurs). Si on retravaille cette interface particulière, ça ne changera rien pour les autres interfaces qui existent déjà.

A noter que l'intégration d'un plug-in G'MIC pour Krita est en bonne voie, comme l'a décrit Thimothée Giet dans son blog : http://timotheegiet.com/blog/comics/gmic-colorize-comics-working-in-krita.html

Ha, bon il faut qu'on attende un peu alors.

Sauf que ce sera fait de manière générique pour tous les plugins, y aura plus besoin de bidouiller dans ton >coin (ce qui est super, mais comme le fait remarquer Julien Jorge, pas très intégré malheureusement).

Le terme "pas très intégré" me parait un peu exagéré. A priori on ne peut de toute façon pas "intégrer" une fonctionnalité dans un framework qui n'existe pas encore. Heureusement qu'on l'a fait dans notre coin au final. C'est un peu le problème avec GIMP, on a toujours un peu l'impression de devoir attendre les fonctionnalités arriver ;)

C'est probablement ce qu'on va essayer de faire quand on va essayer de mieux s'intégrer à GEGL (si on le fait un jour), mais ce n'est pas évident. Et on risque de perdre un aspect très important du plug-in actuel, qui est sa possibilité de mise à jour automatique des filtres.
Actuellement, lorsque l'on ajoute un filtre à G'MIC, il suffit pour les utilisateurs d'appuyer sur un bouton 'refresh' pour le faire apparaitre dans la liste existante : pas de réinstallation du plug-in, rien à faire, c'est facile. Avec une dissémination des filtres dans les menus, ça va être une autre paire de manches.

Un des gros intérêts de GIMP est notamment son système de plug-ins, qui permet à des développeurs extérieurs au projet de proposer des extensions plus ou moins utiles (comme 'resynthetizer' que tu cites).
Si j'étais un bon vendeur, je te conseillerais notamment de jeter un oeil au super plug-in G'MIC, développé par chez nous, mais malheureusement je n'ai pas ce talent pour refourguer des liens en toute situation :)

Bon c'est un peu vague le concept de "dessin", donc tu imagines bien que selon le style que tu veux simuler, tu auras plus ou moins le choix, et des filtres différents à utiliser.

Mais oui, il y a déjà certains filtres G'MIC permettant de 'convertir' des images en dessins (type crayonnés, ou cartoon, ou contours seuls, etc..).
La page http://gmic.sourceforge.net/gimp.shtml liste une petite partie des filtres disponibles dans le plug-in (+ de 480 aujourd'hui), avec des copies d'écrans, et tu pourras peut-être y trouver quelque chose de proche de ce que tu veux obtenir.

Quelques exemples de rendus de filtres disponibles :

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

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 !