David Tschumperlé a écrit 332 commentaires

J'ai fait un petit test rapide d'application du filtre sur une vidéo :

https://youtu.be/wMISHmr5Slc

J'ai utilisé les paramètres par défaut, et la version de gmic en ligne de commande, compilée avec le support d'OpenCV, avec la commande:

$ gmic w apply_video big_buck_bunny_720p_stereo.ogg,\"cl_comic 0,2,0,1,1,15,15,1,10,20,6,2,0,0,0,0,0,0,50,50\",2000,4000,1,bbb.jpg

La commande crée un ensemble de 2000 frames que je transforme ensuite en vidéo (avec ffmpeg par exemple).
Ce n'est pas très user-friendly, mais ça donne une idée du résultat possible sur une vidéo (et disons le aussi, c'est assez long à calculer !).

Au nom de l'équipe de développement de G'MIC, je voulais remercier chaleureusement cli345 (alias Claude), d'abord pour ce chouette filtre (et tous les autres qu'il a fait et dont il n'a pas parlé ici !), et aussi pour cette dépêche très détaillée.

Le code de ce filtre est arrivé de manière tout à fait inattendue, et ça a été une sacré bonne surprise pour nous. Ce n'est pas souvent qu'on reçoit des contributions sympas comme ça, qui ont l'air de tomber du ciel :)

Donc merci encore Claude !

C'est pas tellement la tête qu'il nous casse, pour rester poli.

Merci pour le compliment.

• Concernant la traduction de la documentation : oui, ça serait chouette d'avoir des traductions en français ou dans d'autres langues. Mais ça représente un travail énorme (la doc en format .pdf fait 659 pages…).

• Pour la fenêtre d'acceptation des cookies : je l'ai enlevé. À ma connaissance nous n'utilisons plus de système qui génère des cookies. On utilisait Statcounter pour avoir des statistiques de visite, mais ce service ne fonctionne plus depuis un moment.

Bonjour,
Question très intéressante, merci.

Pour les avantages d'une licence libre, en plus de l'idée scientifiquement satisfaisante de construire un bien commun numérique, on a pu apprécier le fait d'avoir un nombre d'utilisateurs qui a augmenté assez vite, dès le départ du projet (plus lié à l'aspect "gratuit" qu'à l'aspect "libre" surement). Et ça a donc été intéressant d'avoir assez vite des retours qui ont permis de perfectionner / déboguer le logiciel, probablement plus rapidement qu'avec une licence fermée. Et bien sûr, comme tout projet libre, la possibilité d'avoir pleins de petites contributions extérieures ponctuelles sur le code, le packaging, la documentation, des dérivations intéressantes (plug-ins OpenFX et greffon pour hôtes supportant l'API 8bf notamment), etc. G'MIC reste cependant un "petit" projet avec peu de développeurs réguliers (on est deux à assurer le développement du plus gros des nouvelles fonctionnalités).

Pour la part inédite propre à la recherche, je maintiens une page des publications scientifiques associées aux algorithmes originaux que nous avons développés, issus de nos travaux de recherche et qui ont été intégrés à G'MIC : https://gmic.eu/reference/scientific_publications.html
Vous pouvez cliquer sur les liens pour lire les publications (au format .pdf).

En ce qui concerne la communication autour du projet : c'est globalement difficile d'être visible :) L'écriture d'une dépêche comme celle-ci m'a demandé 6 jours de travail, quasiment à 100%, donc je ne peux pas me permettre de faire ce genre de choses très souvent. Je comprends que les projets libres ne puissent pas forcément investir beaucoup de temps sur l'aspect communication.

D'accord, je me disais aussi qu'avec une méthode d'inpainting basée sur du Navier-Stokes (l'algo d'OpenCV), les résultats paraissaient quand même un peu trop propres :)

Par ailleurs, j'aime beaucoup G'MIC, c'est un superbe logiciel.

C'est gentil ça ! Merci.

Bonjour,
Oui, actuellement il existe plusieurs filtres d'inpainting dans G'MIC.

Je pensais que la nouveauté avec Lama-cleaner, c'était d'utiliser des techniques d'inpainting basées réseaux de neurones, mais d'après la page, ça utiliserait un vieil algo par défaut dans OpenCV. Je n'en suis pas sûr quand même, car j'ai vu de très beaux résultats de reconstruction avec ce plug-in, donc il faudrait quand même creuser un peu la chose.

A noter également que le pionner des algos d'inpainting (capable de reconstruire des textures) dans un logiciel de retouche d'images , ça doit être Resynthetizer, qui marche encore très bien a priori : https://github.com/bootchk/resynthesizer

Texte également rédigé à l'aide de ChatGPT (et corrigé par mes soins) :

G'MIC est un outil de traitement d'images en ligne de commande qui propose une large gamme de filtres et d'effets pour traiter et modifier des images. Il peut être utilisé en ligne de commande, mais aussi via une interface graphique, avec un plug-in disponible pour des logiciels comme GIMP ou Krita.

Voici quelques exemples d'utilisation de G'MIC en ligne de commande :

• Appliquer un effet de flou gaussien sur une image : gmic image.jpg -blur 3
• Appliquer un effet de flou médian sur une image : gmic image.jpg -median 3
• Appliquer un effet de dessin au crayon sur une image : gmic image.jpg -pencilbw 0.3
• Fusionner plusieurs images en une seule : gmic image1.jpg image2.jpg blend alpha,0.5 -o output.jpg
• Appliquer une correction de couleur sur une image : gmic image.jpg -adjust_colors 20,20

Il existe de nombreux autres filtres et effets disponibles dans G'MIC, qui peuvent être consultés dans la documentation en ligne ou en utilisant la commande gmic -help pour obtenir une liste complète des options disponibles.

Fin de l'été,
Reine enterrée,
Poireaux à planter.

Ce n'est pas parce que l'on est pas coiffeur que l'on ne peut pas critiquer une coiffure, ou critiquer une maison, si l'on n'est pas maçon

Comme je l'ai déjà écrit, tout le monde peut évidemment avoir son avis.
Mais la pertinence d'un avis est à moduler en fonction de l'expérience de la personne qui le formule dans le domaine concerné. Mon avis sur les coupes de cheveux, j'espère bien qu'aucun coiffeur n'en tiendra jamais compte.

L'utilisabilité d'un logiciel et les principes d'ergonomie existent aussi pour les langages et ne se limitent pas aux IHM (principe de moindre surprise, principe de moindre mémorisation, nom prononçable,…).

A ce stade, plutôt que nous commentions ad vitam æternam, et si tu as le temps pendant les vacances de fin d'année, essaye de te mettre au langage G'MIC pour des problématiques de traitement d'images, compare avec l'existant pour faire le même genre de tâches, et peut-être changeras-tu d'avis ? (ou pas…).
Pour ma part, étant en vacances, je m'arrêterai là.
Bonnes fêtes à tout le monde.

Je pense que tu es dans le cas ultime ou le langage est adapté au hardcore user les plus extrêmes : les créateurs du langage.

Si tu prends l'exemple de sed : les millions de gens qui utilisent sed de temps en temps ne sont pas tous les créateurs du langage associé, ni des hardcore users (loin de là!). Pour autant, c'est tellement plus pratique d'utiliser sed pour faire un remplacement rapide de texte dans un fichier, que de dégainer n'importe quoi d'autre…

Ces utilisateurs là (je m'inclus dedans) ont juste pris le temps de regarder comment combler un besoin spécifique avec sed, et ça marche pour eux. A la limite, il y a même pas besoin de comprendre la syntaxe en profondeur, mais c'est pas grave, ça fait le taf efficacement. Et on se doute qu'on peut faire des choses très complexes avec.

python, java, ocaml, rust, C, golang, Javascript, il y a plein de possibilités. Si gmic était une lib pour Python, il aurait 100x plus d'utilisateurs, c'est sûr (et je n'aime pas python).

Le langage G'MIC rajoute une de ces possibilités dans ta liste (et si tu as lu la dépêche, tu as vu qu'il y a un début de binding G'MIC pour Python qui existe maintenant).

Un langage informatique a toujours plusieurs niveaux d'utilisation et plusieurs niveaux d'utilisateurs. C'est illusoire d'avoir un avis tranché et pertinent sur un langage de programmation sans être passé par toutes les catégories d'utilisateurs (impossible dans les faits). En général, il vaut mieux faire confiance aux créateurs du langage, qui ont réfléchi à la question plus longuement.

Perso, il ne me viendrait pas à l'idée de décréter que SQL c'est mal, parce que je comprend pas facilement ce qui se passe lorsque je lis une requête. Ca serait vraiment naïf de ma part (ou pédant au choix). Au contraire, je me dis plutôt que si des gens qui sont experts en BDD ont élaboré le langage de cette façon, c'est surement qu'il y a une bonne raison (que je ne suis pas apte à comprendre, avec le niveau en BDD que j'ai).

Après, évidemment rien n'empêche d'avoir son propre avis.
Mais connaissant bien le domaine du traitement d'image, les syntaxes d'ImageMagick/GraphicsMagick ou de G'MIC sont tout à fait justifiables, pour l'usage pour lesquels ils ont été créés.

J'ai un raisonnement différent : si dans l'histoire de l'informatique, des langages jugés "peu lisibles" ont été créés, existent depuis des dizaines et des dizaines d'années, et continuent à être utilisés, c'est pas juste parce que les auteurs de ces langages sont pas doués et n'ont pas compris qu'un langage de programmation, ça devait être "lisible" et "verbeux".

C'est plus probablement parce que de tels langages ont des avantages tels (concision, rapidité, facilité d'interprétation, et j'en passe …) que l'inconvénient du peu de lisibilité (et encore, vu par le prisme du non-initié) passe clairement au second plan.

Ayant pratiqué le traitement d'images en C++ depuis plus de 20 ans, je peux affirmer que programmer en langage G'MIC me fait gagner un facteur de temps d'au moins x10 sur le développement de prototypes et de nouveaux algorithmes, par rapport au C++ (et je pratique régulièrement les deux). Et apparemment, la maintenance et l'évolution de l'ensemble du code écrit en langage G'MIC n'a pas vraiment posé de problèmes depuis le début du projet, en 2008 (et cela, malgré le fait que les spécifications du langage ont changé entre temps!). Je ne souhaiterais vraiment pas être obligé de réécrire ces algos de manière équivalente en C++, ça me semblerait vraiment lourd, chronophage et peu pratique. Je peux même affirmer que si tous les filtres de G'MIC avait été écrit en C++, il y en aurait probablement 2 ou 3 fois moins disponibles.

Par ailleurs, je pense que quelqu'un de motivé, qui a un intérêt à utiliser ce type de langages métiers n'aura pas forcément plus de difficulté qu'avec un autre langage. Comme je l'ai écrit tout à l'heure, il suffit d'avoir la volonté de s'y mettre et l'ouverture d'esprit pour accepter un paradigme de programmation un peu différent. Avec un peu d'expérience, tout langage devient lisible pour celui qui le maîtrise un tant soit peu. C'est valable pour tous les langages cités précédemment (ajoutons l'ASM en passant, ayant commencé le Z80 assez jeune, sur Amstrad CPC, j'ai eu aussi une expérience similaire pour ce "langage"). On ne peut pas attendre que tous les langages ressemblent au Basic Python (ça serait d'une tristesse!).

La lisibilité d'un langage, ça peut être bien. Mais prendre cette propriété seule pour juger du niveau d'aboutissement ou de la praticité d'un langage, c'est vraiment pas une bonne idée (pour pas dire que c'est foireux).

Je suis le projet depuis longtemps, je l'ai utilisé à l'époque où c'était encore un énorme .h de 6 Mo.

Non, G'MIC n'a jamais été un gros .h de 6 Mo. Tu veux parler de CImg peut-être ? Ce n'est pas du tout le même projet.

C'est une "A quite naive way of doing" an histogramme. Qui comprend ce que fait le code d'un coup d'oeil ?!

Je ne sais pas où tu as pris cet exemple, mais il est obsolète.
Aujourd'hui, on l'écrirait de manière équivalente, plutôt comme ça :

my_histogram :
256 eval.. ++i[#-1,i]


Tu vas me dire que ce n'est pas tellement plus clair. Et je serai d'accord.
Mais il faut bien comprendre que le but du langage G'MIC n'a jamais été d'être lisible, mais juste efficace et concis (ce dernier point n'étant pas forcément toujours compatible avec la clarté de lecture de code).

En encore, ce "problème" se pose si, en tant que développeur, tu souhaites implémenter tes propres algorithmes de traitement personnalisés en langage G'MIC. Ca concerne au final assez peu de monde.
Si, en tant qu'utilisateur de gmic en ligne de commande, tu souhaites juste utiliser les algorithmes existants, alors tu vas écrire des pipelines de commandes, beaucoup plus simples (pour l'exemple de l'histogramme ci-dessus, il faudrait juste utiliser la commande histogram :) ).

Le langage G'MIC est un langage métier, très différent des langages "classiques" généralistes. Il a été imaginé pour créer des pipelines potentiellement complexes de traitement d'images, pas pour initier des gens à la programmation.
C'est un peu comme si tu me disais que la syntaxe de sed n'est pas lisible pour le traitement des chaines de caractères : c'est vrai, c'est pas lisible, mais c'est concis et efficace. Et c'est utilisé par des milliers (millions) de personnes.
Par ailleurs, si tu regardes du côté de la "concurrence" (ImageMagick), c'est exactement pareil (voir les exemples d'utilisation sur leur site : https://legacy.imagemagick.org/Usage/thumbnails/ ). Illisible pour le néophyte.

J'imagine qu'on pourrait trouver plein d'autres exemples, avec l'utilisation de langages métiers très spécialisés dans leur domaine. Tiens au hasard, le SQL, j'ai jamais réussi à comprendre des requêtes de plus de deux lignes. C'est normal, c'est comme tout, il faudrait juste s'y mettre (mais je n'en ai jamais eu besoin pour ma part).

Pour ceux qui auraient besoin de se mettre au langage G'MIC, on a des pages de référence et de tutoriels pour cela. Quelques développeurs s'y sont mis et proposent aujourd'hui des filtres personnalisés pour G'MIC.

Mais je dirais que dans notre projet, on veut permettre surtout à des utilisateurs d'accéder facilement à des ensembles de filtres et de traitements d'images, plutôt que de rallier des développeurs à l'utilisation du langage G'MIC.
On ne vise pas majoritairement le public des développeurs.

Pour markdown je ne suis pas sûr de comprendre, la traduction markdown → html est faite dans gmic et pas dans une étape de construction ?

La commande gmd2html de G'MIC permet de convertir du texte en format Markdown sous la forme de pages HTML. Elle peut s'utiliser comme ceci par exemple :

$ gmic it monfichier.gmd gmd2html 0 ot output.html

où monfichier.gmd est un fichier en format G'MIC Markdown.
C'est d'ailleurs comme ceci que les pages de tutoriel et de la documentation de référence sont générés par le script de build de G'MIC.

De la même manière, la commande gmd2ascii permet de convertir le texte en Markdown sous la forme de texte ASCII (éventuellement coloré) pour affichage de l'aide sur le terminal. C'est typiquement ce qui est utilisé quand on demande l'aide à partir du terminal :

$ gmic -h

(aide globale), ou

$ gmic -h blur

(aide pour une commande particulière).

Comme le parseur Markdown est maintenant directement intégré dans G'MIC, il peut être utilisé à la volée pour générer la doc pour l'affichage sur le terminal. C'est très pratique.

Merci pour le retour sympathique.

Petite question : les filtres sont pour la plupart algorithmiques, doit-on s'attendre à plus de filtre à base de réseau neuronal ?

Oui, on va essayer d'aller vers plus de filtres à base de réseau, c'était le but du développement de nn_lib.

C'est assez difficile d'apporter une réponse générale, car cela dépend vraiment des filtres. Quelquefois, un filtre né de l'implémentation stricte d'un papier, d'autres fois, c'est juste inspiré par des lectures de papier, et d'autre fois encore, c'est le fait d'avoir eu le temps de tester rapidement des idées originales.

Deux justifications :
- La version d'avant était la 2.9.9, et on garde les numéros de version sur 3 chiffres.
- Et comme on savait qu'on allait passer de la 2.9.9 à la 3.0.0, et que la 2.9.9 marchait bien, on a du coup prit le temps pour soigner particulièrement cette version 3.0.0, ce qui en fait effectivement une version majeure :)

G'MIC est de toute façon un logiciel qui évolue constamment avec des sorties fréquentes (environ une tous les deux mois je dirais).

On pouvait s'attendre à cette question :)
Il y a plusieurs raisons :

• Pour nn_lib:

  1. En ce qui me concerne : Se plonger dans l'algorithmique des réseaux de neurones permet de bien comprendre tous les détails et astuces d'implémentation pour que ces réseaux fonctionnent en pratique. C'est très instructif et intellectuellement très profitable quand on fait en parallèle de la recherche dans le domaine du traitement d'images (ce qui est mon cas).
  2. En ce qui concerne l'utilisateur : les bibliothèques existantes d'apprentissage machine sont assez grosses en taille, pour ne pas dire énormes. Par ailleurs, il y avait déjà quasiment tout ce qu'il fallait comme fonctionnalités de base en traitement d'images dans G'MIC (convolutions, redimensionnement d'images, etc.), pour que le travail demandé puisse être vu comme suffisamment incrémental pour ne pas nécessiter de réintégrer toute une bibliothèque, qui aurait doublé beaucoup de fonctionnalités déjà existantes. La réalité, c'est qu'à l'heure actuelle, toutes les fonctions de la bibliothèque nn_lib tiennent en seulement 164 lignes de code G'MIC. C'est très (très!) peu et ça n'alourdit donc aucunement la taille du projet (attention, je ne dis pas que ces 164 lignes ont été simples à écrire :) ).
  3. Le projet G'MIC a l'intention de rester relativement léger, et donc n'a pas vocation à utiliser de "gros" réseaux de neurones (qui peuvent occuper plusieurs centaines de Mo voire plusieurs Go chacuns…), donc être obligé d'utiliser une bibliothèque externe énorme pour gérer de petits réseaux n'a pas un intérêt fou. Les différents réseaux utilisés pour le débruitage tiennent chacun dans moins de 300 Ko par exemple.

• Pour le moteur Markdown:

Au départ, nous utilisions un moteur Markdown classique pour générer les pages de documentation, mais on s'est aperçu assez vite qu'on avait des besoins spécifiques que ne proposait pas le Markdown classique. Et écrire un parseur/générateur Markdown n'est pas très difficile. Là encore, ça a été écrit en langage G'MIC, en un peu plus de 1000 lignes, donc en pratique ça prend très peu de place mémoire (moins de 100Ko) par rapport à la solution d'avoir à intégrer une bibliothèque Markdown (et une n-ième dépendance…). Ca prend un peu plus de temps à développer, c'est sûr, mais c'est avantageux au final.

La réponse :

Øyvind "pippin" Kolås @ok · 16 hours ago
Maintainer
For naming parameters that end up in a UI I think "boundary conditions" is similarly obscure to "abyss policy". "Edge" and "handling" are more basic words in english and understandable by a wider group of people than "boundary conditions".

Pas tellement étonné de la réponse (connaissant un peu le personnage ;) ).

Par contre, je suis un peu plus étonné de la justification donnée. Je pensais (vraiment) que GEGL (qui veut dire pour rappel "GEneric Graphical Library") était une bibliothèque de programmation "générique" pour la manipulation et le traitement des images (en tout cas, c'est comme ça qu'elle est présentée sur l'article wikipedia dédié).

Apparemment, c'est donc plutôt une bibliothèque de traitement d'images destinée à être appelée uniquement depuis des interfaces graphiques ? C'est pas très vendeur :)
Et si ce n'est pas le cas (ce que je crois), pourquoi les noms des paramètres des fonctions devraient être forcément les mêmes que les noms des widgets que l'on présente à l'utilisateur d'une UI ?
On peut imaginer avoir plusieurs niveaux de spécialisation des termes utilisés en fonction du public auquel on s'adresse. Il y a des chances pour qu'un développeur utilisant GEGL soit en moyenne un peu plus calé en traitement d'images (et connaisse donc les termes classiques boundary_conditions ou border_conditions) qu'un utilisateur de l'interface de GIMP.

Mais bon, j'admets que je chipote un peu :)

A noter que l'installation de GIMP 2.10.28 sous Windows "casse" la compatibilité avec le greffon G'MIC (en dernière version stable 2.9.9). La "faute" a des changements de versions de fichiers .dll fournis avec le nouvel installeur de GIMP (mais on peut aussi comprendre qu'ils mettent à jour aussi ces fichiers dès qu'ils peuvent). Ces problèmes de .dll ont déjà eu lieu dans le passé. C'est assez pénible les .dll sous Windows :)

Nous avons réussi à mettre en place un installeur de G'MIC en version de développement (3.0.0_pre), qui fonctionne néanmoins avec GIMP 2.10.28. Mais ça reste une version en développement, qui peut évoluer et pas forcément à conseiller pour la stabilité.

En passant, petite suggestion mineure :

• distance-transform : nouveau paramètre edge_handling permettant de choisir comment traiter les zones hors-image (au-dessus ou sous le palier ; c’est-à-dire infiniment blanc ou noir respectivement) pour le calcul de distance. (par woob)

En traitement d'images, je crois que tout le monde appellerait ça boundary_conditions, c'est le terme générique pour définir la façon dont on traite les bords dans tous les opérateurs de traitement d'images. C'est du coup un peu dommage de ne pas utiliser les termes classiques du domaine, notamment dans une bibliothèque de gestion/traitement d'images…

De mon point de vue, ce ne sont pas les logiciels qui sont professionnels, mais les personnes.

Tellement vrai!

Corrolaire : Les personnes affirmant qu'un logiciel n'est pas "professionnel" s'avèrent souvent être des amateurs peu compétents dans leur domaine.

Cet argument de logiciel "non-professionnel" est malheureusement très fréquemment brandi par les partisans du logiciel non libre, quand on fréquente les forums généralistes en graphisme ou photographie.

Bonjour,

J'ai eu des besoins similaires il y a de cela quelques années (22 ans pour être précis…), et j'avais alors commencé l'écriture d'une "petite" bibliothèque C++ pour le traitement des images : CImg, qui a l'air de pouvoir faire ce que vous proposez (et même un peu plus ☺, mais depuis le temps, ce n'est pas forcément étonnant).
Cette bibliothèque existe encore et je continue d'ailleurs à la maintenir activement.
N'hésitez pas à y jeter un œil, peut-être vous y trouverez un intérêt ? (la version 2.9.9 vient justement de sortir il y a quelques heures).

Ce qui est amusant, c'est que faire exactement l'inverse de tes recettes est sans doute la voie la plus rapide pour devenir homme ou femme politique.

Aux dernières nouvelles, les plug-ins tiers de GIMP ne fonctionnent pas sous Glimpse.
J'imagine qu'ils ont aussi dû renommer les fonctions de l'API de plug-in de GIMP pour mettre du '_glimpse' un peu partout, et que ça a pêté la compatibilité ?

En tout cas, pas de plug-in G'MIC dans Glimpse, et ça enlève aussi beaucoup de son intérêt :)

Je tiens encore à remercier l'équipe de LinuxFR pour cette sympathique attention. J'essaierai d'écrire une dépêche plus courte la prochaine fois, pour faciliter le travail de relecture :)

(désolé pour mon commentaire un peu "bateau", mais néanmoins sincère).