David Tschumperlé a écrit 337 commentaires

Les versions Mac et Windows sont maintenant à jour, avec à la fois les binaires pour le plug-in GIMP, et pour la version ligne de commande.

D'abord comme tout langage de script interprété, tu as un interpréteur qui tourne derrière, et qui analyse le code G'MIC à la volée, donc déjà il y a une perte de performances ici par rapport à un langage compilé.

Ensuite, non, G'MIC n'utilise pas spécifiquement d'instructions propres aux différents processeurs. Il a été pensé pour être multi-plateforme, et je laisse le soin au compilateur d'optimiser le code de la façon dont il le souhaite.

Techniquement je suppose que ça serait possible, car G'MIC possède une fonction de déformation d'image par un champ de déplacement quelconque.
Cela dit, G'MIC n'a pas été conçu pour du temps réel, et j'ai un peu peur que "ca rame", comme on dit, même en passant par des pipes pour les entrées sorties.

Quite à faire un programme dédié, peut-être vaut il mieux programmer quelque chose qui utilise directement une bibliothèque de traitement d'images plus bas niveau (au hasard CImg :) )

Non, j'a fais le ménage dans G'MIC pour enlever pleins de fonctionnalités "inutiles" (toutes les fonctions de traitements pour les types de pixel autres que float, sachant qu'en pratique, on peut toujours revenir en float pour effectuer ces traitements). Du coup, ça enlève la compilation de beaucoup de fonctions (environ 9 fois moins).

Mais il y a quelques problèmes avec l'optimisation dans g++.
Si on enlève les optims, le temps de compil est correct.
J'ai vu que quelqu'un s'était intéressé au problème, pour une ancienne version de G'MIC :

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42175

J'attend un peu de voir ce qui va se passer, mais il semble qu'il y ait des cas ou g++ requiert une quantité de RAM considérable pour essayer d'optimiser des boucles un peu longues (ce qui était le cas dans G'MIC, moins maintenant).

A tracer des cercles de manière précise ? :p

Et si tu comptes ajouter des possibilités de filtrage d'image dans ton logiciel, tu peux regarder du côté de G'MIC qui propose déjà tout pleins de filtres tous faits, intégrable facilement dans ton code (particulièrement si c'est en C++).

http://gmic.sourceforge.net

J'aime bien 'pictor', ca rappelle 'picture' et c'est le nom d'une constellation :

http://en.wikipedia.org/wiki/Pictor

Et en plus, ça sonne bien comme un logiciel des années 80, donc ça pète !

Le site de Stéphane : http://linuxerie.midiblogs.com/

Les imagettes des tigres ont été traités avec G'MIC.
Après pour la disposition et le dessin du logo proprement dit, je crois que ça a été fait avec Inkscape.
C'est cette sympathique personne qui a dessiné ce logo.

J'ai utilisé le filtre 'Enhancement/Anisotropic Smoothing' de G'MIC, avec presque les paramètres par défaut, sauf l'amplitude que j'ai baissé, et le nombre d'itérations que j'ai augmenté (3 ou 4 je sais plus). Ensuite j'ai simplement seuillé le résultat pour obtenir une image noire et blanche (menu Colors/Threshold de GIMP).

Quelque chose comme ça, ça t'intéresse ?

http://www.greyc.ensicaen.fr/~dtschump/livre-0014.png

David.

Disons que c'est pas la première fois que je parle de G'MIC ici sur Linuxfr, et cette version est plus une version de stabilisation qu'une version avec beaucoup de nouvelles choses.

On peut aussi le faire en G'MIC, et justement l'avantage par rapport à ImageMagick, c'est qu'à partir du moment où la fonction peut s'écrire en langage "G'MIC", on peut utiliser la fonction à la fois en ligne de commande et dans le plug-in GIMP, sans avoir rien de plus à coder, ni à recompiler.

Oui ca m'a l'air possible aussi, à partir de plusieurs layers par exemple, G'MIC pourrait les 'fusionner' en une planche contact.
Aurais-tu une image type de ce que tu voudrais obtenir comme effet ?

David.

Oui bonne idée, tout cela ne m'a pas l'air trop compliqué.
En tout cas c'est tout à fait dans les cordes de G'MIC.
Je vais voir ce que je peux faire dans ce sens. Ca permettra de tester une autre propriété de G'MIC, qui est de pouvoir mettre à jour sa liste de filtres via Internet sans avoir à recompiler quoique ce soit :)

David.

Pour la déformation locale, la commande '-warp' devrait faire ton bonheur :

gmic -h warp

Non, ça c'est ta définition du mot "image" :)
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.

Finalement, j'ai fait un petit exemple de code source illustrant la façon d'appeler l'interpréteur G'MIC dans un logiciel tiers. Il vous suffit donc de compiler la bibliothèque G'MIC à partir des source (make lib dans le répertoire gmic/src), puis d'inclure le fichier gmic.h dans votre code, et de linker avec libgmic.so.

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.

En réalité, il faut voir ça de manière un peu plus générique.

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.

Pour répondre rapidement :

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

Non, c'est juste que tu as pas mis la commande gmic qu'il fallait. L'ordre des paramètres a son importance, puisque les commandes G'MIC sont interprétées de gauche à droite.
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.

Bon , j'ai procédé à une petite mise à jour vers la 1.3.2.2, avec deux bugs corrigés et surtout la possibilité de rendre certains filtres 'animés', où le greffon est capable de générer une suite de fichiers ou de layers qui partent d'un jeu de paramètre de départ, vers un jeu de paramètre de fin.

Des copies d'écran de cette nouvelle possibilité sont disponibles à [http://www.flickr.com/photos/90104203@N00/3820657222] et [http://www.flickr.com/photos/90104203@N00/3820657084/].

Un exemple de gif animé généré par ce procédé est visible ici : [http://www.greyc.unicaen.fr/~dtschump/cube3d.gif].

Je suis d'accord, mais tant que possible j'essaie d'avoir une idée la plus précise possible du problème, dans la mesure de mes maigres compétences sur le sujet. De toute façon, il faudra certainement faire les tests que je compte faire, un moment ou un autre, donc autant les faire avant de poster. Je suis quand même pas à une ou deux semaines près non plus (surtout si il faut un an d'attente ensuite :) ), et puis c'est quand même plus respectueux de leur travail à eux.

David.

En fait, j'essaye dans un premier temps de bien comprendre le problème avant effectivement de poster une question sur un forum g++, qui si elle est trop vague ne va pas faire avancer le schmilblick.
J'avais fait un bug report g++ (pour un truc mineur surement facile à corriger) qui a mis plus d'un an avant d'être corrigé, donc je suppose qu'il vaut mieux arriver avec le maximum d'indices pour espérer quelque chose de concret (en même temps je les comprend un peu!)

David.

Oui, c'est même encore pire qu'avant.
La réponse peut paraitre crue, mais c'est malheureusement vrai.

Nous avons fait quelques tests ici pour déterminer la cause, et il s'avère que g++ bouffe une quantité gigantesque de RAM lors de la phase d'optimisation. En supprimant les optimisations '-O0' à la place de '-O3', G'MIC se compile sans problème même avec 512Mo de RAM en un temps tout à fait acceptable (quelques minutes). Il doit y avoir un flag magique à trouver, je vais peut-être essayer avec d'autres compilo (icc) qui m'ont l'air moins gourmand en ressource pour l'optimsation.


David.