Je suis heureux de vous annoncer la sortie de G'MIC 1.0.0.
G'MIC (GREYC' Magic Image Converter) est un outil de manipulation d'images en ligne de commande, un peu à la sauce ImageMagick , mais avec quelques particularités originales. Il a fait l'objet d'une dépêche ici même, il y a quelques mois.
Il est disponible à l'adresse : http://gmic.sourceforge.net
Les habituels screenshots de démonstration sont ici : http://gmic.sourceforge.net/gallery.shtml
Pour résumer très rapidement, c'est un exécutable qui est capable de lire un ou plusieurs fichiers images, qui stocke les données pixels en mémoire, et qui peut interpréter un certain nombre de commandes permettant de visualiser / traiter / combiner / convertir ces images. L'ordre de traitement se fait dans l'ordre d'apparition des options ('commandes' G'MIC) sur la ligne de commande, et un grand nombre de traitements de base est disponible (opérations arithmétiques, filtrage, FFT, visu 3D, conversion de bases de couleurs, transformations géométriques simples, etc...).
Un point original de G'MIC est sa possibilité de lire à l'exécution un fichier de macros (tel que celui ci) qui permet d'étendre les commandes disponibles reconnues, simplement en les substituant par une série de commandes G'MIC de base. La grande nouveauté de la version 1.0.0 réside justement dans l'amélioration des possibilités d'écriture de macros. On peut en particulier maintenant écrire des macros à paramètres, ainsi que des opérations simples entre paramètres de macros.
Il est intéressant de remarquer qu'au final, de nombreux effets et filtres "classiques" de traitement d'image (tels que ceux présents dans GIMP par exemple) peuvent s'écrire comme des macros G'MIC, et ceci sans avoir à recompiler quoique ce soit, et surtout de manière très concise (en général, moins de 10 lignes suffisent pour la plupart des effets).
Par exemple, si on prend l'effet bien connu de l'effet Spread, il s'écrit en macro G'MIC comme :
# Spread pixel values.
#---------------------
#? spread : 'dx=3,dy=dx,dz=0' : Spread last image pixel values randomly along x,y and z.
spread :
-e "Spread pixel values of the last image with amplitudes ($(1=3),$(2=$1),$(3=0))."
-v- -t float 100%x100%x100%x1x3 -noise[-3] $1,0 -noise[-2] $2,0
-noise[-1] $3,0 -a[-3--1] v -warp[-2] [-1]x1,1 -rm[-1] -v+
De ce point de vue, on peut donc aussi voir G'MIC comme un interpréteur d'un langage spécifique de création de filtres/d'effets sur des images : un utilisateur peut facilement écrire ses propres macros pour créer des traitements personnalisés, et éventuellement les partager avec d'autres. La page de démonstration du site montre quelques exemples de l'application de commandes de base et de macros sur une même image originale. Comme on le voit, beaucoup de choses sont permises et sont possibles.
G'MIC se veut donc avant tout un outil de traitement d'images extensible, et qui ne requiert pas de connaissances techniques très poussées pour être utilisé et étoffé en fonction de ses besoins. Une documentation plus complète que "gmic -h" devrait voir le jour un de ces quatres jeudis :)
Si le traitement d'image vous intéresse, je vous invite à le tester chez vous et à faire remonter vos problèmes et vos idées. Les paquets 1.0.0 devraient être dispos sous peu dans le dépôt prévu à cet effet, pour les distributions courantes, grâce au travail acharné des gentils et compétents contributeurs de Linux On The Root !, je les bénis jusqu'à la 10ème génération pour leur aide précieuse ! Des paquets expérimentaux mais normalement fonctionnels de la version 1.0.0 sont déjà dispos pour Ubuntu 8.04 et 8.10 sur le site de Sourceforge.
G'MIC est développé principalement dans l'équipe IMAGE du laboratoire GREYC (CNRS) de Caen.
Et maintenant une petite digression personnelle...
Mon rêve : Un plug-in GIMP (utilisant G'MIC) qui s'auto-update
On voit que G'MIC est capable d'interpréter un fichier de macros (un simple fichier texte) qui lui donne la possibilité de définir des filtres/effets personnalisés applicables sur des images. Le gros avantage, c'est qu'un tel fichier texte ne pèse que quelques Ko, mais peut définir des filtres/effets relativement complexes.
On voit donc que si on disposait d'un plug-in GIMP dont le seul but serait d'appeler G'MIC et de récupérer l'image résultat pour le remettre dans GIMP, ca serait très chouette, car ce plug-in pourrait très facilement se mettre à jour automatiquement via Internet, et disposer d'une base de filtres/d'effets importante qui pourrait évoluer (et se corriger/s'améliorer) de manière très rapide, puisqu'aucune recompilation de code ou ré-installation ne serait nécéssaire : il suffirait de mettre à jour un bête fichier texte.
En deux mots, un plug-in extensible sans trop de maintenance nécessaire.
La grosse difficulté ici serait de faire en sorte que le plug-in soit capable de générer les interfaces graphiques permettant de régler les paramètres de chaque filtre de manière dynamique, en utilisant des informations qui seraient contenues dans le fichier texte de macros : nombre de paramètres, types des paramètres, etc..
Ceci est théoriquement possible, puisqu'on peut déjà insérer des commentaires dans les fichiers de macros de G'MIC : il suffirait donc d'écrire des commentaires destinés à ce plug-in. Par contre, je ne sais pas trop procéder. Quel langage pouvez vous conseiller ?
Stéphane a déjà écrit une petite maquette de plug-in GIMP en python capable d'appeler G'MIC pour appliquer un filtre à une image chargée dans GIMP, mais il manque encore cet aspect 'dynamique' qui serait vraiment un plus je pense. Je pense que Stéphane est OK pour partager sa maquette pour ceux qui seraient tentés de jeter un oeil.
Si vous l'idée vous parait bonne et que vous avez des connaissances techniques dans ce domaine, ça m'intéresse énormément. Si vous trouvez l'idée débile, ça peut être intéressant aussi par ailleurs. N'hésitez pas à me contacter dans tous les cas (sauf pour les insultes, merci, j'ai déjà donné :) )
En particulier, je pense que l'actuel plug-in GIMP disponible qui a été fait pour GREYCstoration (logiciel de débruitage d'images dont je suis également l'auteur) pourrait fusionner avec celui de G'MIC, car l'algorithme de GREYCstoration est inclus dans G'MIC. Il me semble qu'il serait par exemple intéressant de définir des macros qui correspondraient à différents profils d'utilisation de GREYCstoration pour définir différents types de débruitage, un peu comme si on avait des profils de bruit ou d'appareils photos avec des réglages de 'paramètres optimaux' à proposer.
Voila, c'est tout pour cette fois, merci de votre attention et bonne soirée à vous.
David.
# Rhaaa
Posté par plic . Évalué à 10.
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Re: Rhaaa
Posté par David Tschumperlé (site web personnel) . Évalué à 2.
David.
[^] # Re: Rhaaa
Posté par BAud (site web personnel) . Évalué à 5.
En plus, j'avais fait rajouter une catégorie "science" qui ne demande qu'à être peuplée et qui s'applique bien àmha (le logo est plus joli que celui de Audiovisuel :D) ou sinon celle de la catégorie dédiée à Gimp.
# Détecter des formes
Posté par freejeff . Évalué à 1.
Je profite de ton annonce pour me permettre de te poser une petite question pratique.
Je cherche à reconnaître des disques dans une images, je me demandais si je pouvais envisager d'utiliser G'MIC pour faire cela, à l'heure actuelle j'utilise imagej, mais je suis obligé de binariser l'image, et l'algorithme à du mal lorsque les cerles ne sont pas parfait ....
J'aimerais pouvoir détecter un cerlce, paramétré par son rayon et son centre, ou une ellipse dont le pramétrage reste à définir. Il y a des cas ou j'aimerais considérer une forme plus complexe ou plusieurs cercles sont collés. J'aurais bien des idées, mais n'étant pas un spécialiste de la "segmenntation" j'ai peur de mal m'y prendre, de plus ton programme à l'air bien adapté pour faire ce genre de choses.
Aurais-tu (oi ou quelqu'un d'autre) quelques pistes pour résoudre ce problème qui me parait complexe mais qui doit être assez simple pour les gens de l'analyse d'image ?
[^] # Re: Détecter des formes
Posté par David Tschumperlé (site web personnel) . Évalué à 4.
Dans ton problème particulier, tout dépend du type d'images et du type d'informations qui va caractériser tes disques : est-ce qu'ils ont une couleur particulière, et ce qu'ils peuvent être en perspective, est-ce qu'ils sont sur un fond fixe connu ? un fond uniforme ? une taille connue ? etc..
Suivant les critères que tu va définir pour caractériser tes objets, tu vas avoir besoin de méthodes plus ou moins compliquées pour récupérer leur position : du simple seuillage couleur, de la transformée de Hough circulaire (peut marcher pour les cercles collés en particulier), de la segmentation par contours actifs (ou régions actives), ou un mix de tout ça, avec la prise en compte de tous les a-priori que tu connais..
Je crois pas qu'on puisse dire qu'une méthode va mieux marcher qu'une autre tant que tu n'auras pas défini précisement ces a-priori là.
David.
[^] # Re: Détecter des formes
Posté par djibb (site web personnel) . Évalué à 4.
def select_star(self): """select a star in the field. Star choosen is the best correlation with predefined star""" self.star_ref=Star_Ref(self) try : champ = self.dic[self.star.number] #picture shown except KeyError : champ = self.star.image champ,X,Y = self.qimage2numpy(champ) #make a numpy array from image #initialise la liste des coeff b =champ.shape champ.shape = X,Y #tout se joue ici : self.star_ref.data est le tableau qui contient ma forme de référence(pour toi : ellipse, carré, cercle..ce que tu veux) list_correl=self.iter_correl(champ,0,0, 200,200,6,self.star_ref.data) #regarde plus bas la fonction for i in arange(0,len(list_correl)): list_correl[i]=abs(list_correl[i]) max_correl = max(list_correl) index_max = list_correl.index(max(list_correl)) largeur_matrice = sqrt(len(list_correl)) #petit trafic pour trouver le centre de l'ellipse X_centre = int(index_max/largeur_matrice)+10 Y_centre = index_max-(X_centre-10)*largeur_matrice +10 if max_correl>0.65: #je considère que si c'est plus petit que 0.65...c'est pas la même forme params = self.correl(list_correl,champ) self.star.centre_abs = (Y_centre, X_centre) #tu t'en fous #tu t'en fous height, center_x, center_y, width_x, width_y = params #tu t'en fous width = (width_x+ width_y)/2 #tu t'en fous self.star.fwhm = 2.355*width #tu t'en fous self.star.width = width #tu t'en fous self.ui.label_fwhm.setText(self.tr("FWHM = "+str("%.0f") % self.star.fwhm + "px")) #tu t'en fous self.expose_Capture("actual", self.star.image, self.star.number) #tu t'en fous a=star_draw(self.ui.label_actual_pic, self.star) #tu t'en fous #print "show star" #tu t'en fous self.stars_picture.append(a) #tu t'en fous a.show() else : self.ui.label_fwhm.setText(self.tr("No Star detected")) def iter_correl(self,champ,x_begin,y_begin, x_end,y_end, pas,ref): list_correl=[] # je découpe mon image en faisant passer ma forme de base dessus. j'itère pas sur tous les pixels. for i in arange(x_begin,x_end): if i+21<(x_end-x_begin) : # for j in arange(y_begin,y_end): if j+21<y_end-y_begin : if i*j%pas == 0 : champ_crop = champ[i:i+21,j:j+21] b=champ_crop.copy() try : b.shape=(1,21*21) y2=b a = corrcoef(ref,y2) #le calcul se fait ici !!! list_correl.append(a[0,1]) except ValueError: print i,j else : list_correl.append(0) return list_correlsi ça peut t'aider... Note : les include : from pylab import * note : si quelqu'un veut optimiser ça je prends ;)[^] # Re: Détecter des formes
Posté par freejeff . Évalué à 1.
# Merci
Posté par beagf (site web personnel) . Évalué à 2.
Bon boulot, même si comme toujours je suis pas un grand fan de tes convention de codage et que je reste simple utilisateur. Chacun ses goûts et je préfère que tu continu de maintenir et faire évoluer G'MIC et CImg.
Par contre pour ce qui est du Plug-in pour Gimp, l'idée me semble loin d'être si pertinente que ça. Gimp dispose déjà de toute une mécanique interne de traitement d'image. Toutes ces fonctions sont disponible pour l'écriture de script en Scheme, Python et il me semble avoir vu au moins un début de Lua. Bref de quoi faire tout ce que tu dis beaucoup plus simplement, et surtout de manière plus éfficace étant donné qu'il n'y a pas à transférer les données d'un programme à l'autre.
Bien sûr, il ne dispose pas de certaines fonction géniales de CImg et G'MIC, mais à mon avis ils serait bien plus intéressant de porter ces fonction dans Gimp et donc de bénéficier aussi de tous ce dont dispose Gimp.
Surtout avec la migration GEGL qui offre à ce niveau une souplesse de traitement géniale. Un portage des fonction de G'MIC sous la forme de node GEGL serait mon rêve...
Ça permetrait en plus de profiter des buffers et de la gestion colorimetrique de GEGL, de toutes ses fonctions bas niveau et de toutes la puissance de G'MIC.
Après je comprend que c'est difficile, étant donné les différence d'architecture interne c'est plus une réécriture qu'un portage, mais j'ai le droit de rêver...
D'un point de vue plus terre à terre, à mon avis une meilleure solution qu'un plugins resterait quand même des nodes pour GEGL qui appellent les différentes fonctions de G'MIC pour les cas ou l'on en utilise qu'une à la fois, et un node à qui l'on donne une macro G'MIC pour les cas ou l'on fait une petite chaine de traitement. (afin d'éviter les milliers de transfert...)
Au final ça permetrait d'utiliser toutes les fonction de G'MIC dans GEGL, dans le future Gimp et donc dans ses cripts et plugins, ainsi que dans tout autre outils qui utilisera GEGL. (et ça me simplifiera la vie un max....)
Promis, quand j'aurrais finit ma rédaction de thèse et que j'aurais un peu plus de temps je regarde ça sérieusement.
[^] # Re: Merci
Posté par David Tschumperlé (site web personnel) . Évalué à 4.
Bref de quoi faire tout ce que tu dis beaucoup plus simplement, et surtout de manière plus éfficace étant donné qu'il n'y a pas à transférer les données d'un programme à l'autre.
Pour ma part, je ne suis pas sûr que je serais plus efficace en python qu'en macros G'MIC, comme tu le dis au début, chacun son point de vue et ses connaissances :)
Je peux te dire par contre qu'écrire un filtre en G'MIC peut se faire *très rapidement* si on connait un peu la syntaxe (j'ai du en écrire une dizaine rien que ce matin, en m'inspirant des filtres existants pour GIMP).
Par ailleurs, avec un collègue (que je salue) nous avons déjà travaillé sur l'intégration des fonctionnalités de G'MIC dans son logiciel de visu / traitement de volumes 3D : http://qvox.sourceforge.net (QVOX) et le transfert des données n'est clairement pas un problème pour les performances, étant donné que tout peux se faire en passant par des pipes (G'MIC peut lire et écrire des images en entrée et sortie standard). Et pourtant, dans notre cas, nous transférons des images voiumiques à valeurs flottantes, donc à priori des données beaucoup imposantes que les images 2D couleurs qu'on peut avoir dans GIMP.
David.
[^] # Re: Merci
Posté par beagf (site web personnel) . Évalué à 2.
Je ne critique absolument pas ce que tu fais. Bien au contraire... J'utilise G'MIC justement pour du traitement d'image : c'est simple, efficace et léger. J'adore GreycStoration, même si je l'utilise moins depuis que j'ai cracker pour une licence noise ninja. (petite parenthèses d'ailleurs, j'ai cracker pour NN par ce que GreyStoration à pour moi deux inconvénients, le reglage des paramètres est assez obscure, et il est parfois relativement lent... et quand j'ai 200 photos d'un spectacle à développer je manque de temps pour les réglages.)
Donc je disais que je ne critique pas ton travail, c'est juste que je suis un peu maniaque quand on parle de code... et oui, désolé, on ne se refait pas. Et en plus je préfère que ce soit les autres qui changent leurs méthodes que moi ;-)
Gimp 2.4 c'est déjà un truc gros et lourd, il est dur de rentrer dedans et l'interface pour les scripts est à mon avis mal faite. Donc pour cette version à mon avis ta solution est la meilleure.
Pour les futures versions 3.0 et plus, il y aurra par contre un coeur bien plus propre et simple : GEGL, et rendre disponibles les fonction de G'MIC sous forme de node GEGL permettrait de tout utiliser de manière uniforme. L'API est simple et il y a plein de manière de l'exposé pour fire des scripts. Que ce soit un binding direct et donc des script complexes mais puissants, ou juste sous la forme du séquence de noeuds à créer et appliquer, ce qui reviens exactement au même que tes macro sous forme de paramètres.
Cela permet en plus de faire de simples nodes qui appelle G'MIC comme un programme externe et donc d'avoir un truc utilisable rapidement. Et si il y a un motivé aussi maniaque du code que moi, de porter les fonctions de G'MIC directement dans GEGL sans passer par l'appli externe. Les choses pouvant se faire progressivement.
La partie mise à jour automatique est, je pense complètement indépendante et devrais être dispo aussi bien pour les scripts G'MIC que pour les ScriptFu et autres, ça pourrait être fait avec avec un système tels que les dépots de packets des distrib, et un update automatique avec un cron.
[^] # Re: Merci
Posté par David Tschumperlé (site web personnel) . Évalué à 5.
(en passant, si GREYCstoration est lent sur des grosses images, c'est uniquement du à la complexité "théorique" de l'algorithme. Je crois pas que le code puisse être remis en cause de quelque manière que ce soit. Je te propose de reprogrammer le même algo, dans le même langage (C++) , je doute très fort que tu obtiennes un gain de performance significatif, aussi 'bon' programmeur que tu soit... )
Plus généralement, avoir un exécutable indépendant qui fait une tâche bien définie et qui peut être appelé à partir d'autres programmes (plug-in GIMP ou autre) avec des transferts de données par fichiers (ou par pipes), je trouve ça loin d'être sale (je crois pas être le seul, puisque c'est quand même l'une des bases de fonctionnement du système GNU/Linux). De plus :
(1) Ca a le gros avantage de réduire la difficulté du travail d'intération, donc la maintenance globale du logiciel 'appelant'. Chaque brique étant indépendante au maximum l'une de l'autre.
(2) Par conséquent, ca assure une plus grande pérenité au travail réalisé : si je m'amuse à interfacer G'MIC avec GEGL (qui est loin loin d'être un boulot trivial), et que dans 5 ans, GIMP se met au C++, et décide d'utiliser une autre lib (comme GIL, ou CImg , soyons fou :) ), mon utilisation de G'MIC sous GIMP est condamné, à moins de refaire un coûteux travail d'intégration avec une nouvelle lib. Au contraire, l'exécutable sera toujours fonctionnel lui (puisque conçu de manière 'self-contained' dès le départ).
L'expérience que nous avons tenté avec l'intégration de G'MIC dans QVOX de cette façon (G'MIC appelé par Q-VOX, avec transfert des données par pipes) me conforte dans cette idée. J'en viens presque à regretter que l'actuel plug-in de GREYCstoration n'ait pas été concu de cette manière dès le départ : Le passage à GIMP 3.0 risque d'être fatal au plug-in GREYCstoration, et je trouve ça bien dommage, car l'exécutable en ligne de commande à priori continuera d'être fonctionnel.
La "perte" de performance, dûe aux entrées sorties qu'il faut réaliser pour faire le pont entre GIMP et G'MIC (ou GREYCstoration) est minime, et de toute façon négligeable par rapport au temps d'exécution de l'algorithme lui-même.
David.
[^] # Re: Merci
Posté par beagf (site web personnel) . Évalué à 2.
Je ne prétend pas être un un bon programmeur, loin de là... J'avais jetter un coup d'oeil aux papiers que tu as publier sur le sujet, et.... ce sera pour plus tard...
Ma remarque sur la lenteur de GreycStoration n'était pas une critique, mais une constatation. D'un point de vue objectif, actuellement, vu les photos pour lesquelles j'en aurais besoin, je ne peut pas me permettre d'utiliser GreycStoration systématiquement.
Et je le regrette, même si ce n'est pas de ta faute, mais du à l'algo lui-même. De la même manière que je regrette qu'il pleuve les jours où je veut tondre la pelouse : on ne peut rien y faire, mais ça nous embette quand même ;-)
GreycStoration m'a permis quand même de récupérer des photos très bruitées ou NoiseNinja n'était pas suffisant, la seule chose c'est qu'il faut avoir un peu de temps devant soit et jouer avec les paramètres.
Après il faudrais peut-être que je change mon matos, mais j'ai pas trop les moyens pour le moment ;-)
Plus généralement, avoir un exécutable indépendant qui fait une tâche bien définie et qui peut être appelé à partir d'autres programmes (plug-in GIMP ou autre) avec des transferts de données par fichiers (ou par pipes), je trouve ça loin d'être sale (je crois pas être le seul, puisque c'est quand même l'une des bases de fonctionnement du système GNU/Linux). De plus :
(1) Ca a le gros avantage de réduire la difficulté du travail d'intération, donc la maintenance globale du logiciel 'appelant'. Chaque brique étant indépendante au maximum l'une de l'autre.
J'aime la philosophie des outils unix, et les utilisent beaucoup. Il y a quand même une différence, c'est qu'ils sont prévus pour être utilisés en flux, alors que dans ce cas ce sont des échanges.
Si l'on souhaite écrire un script pour gimp qui alterne les traitement classique de Gimp et ceux de G'MIC, il va y avoir de nombreux allez-retours entre les deux.
Mais dans tous les cas, c'est principalement une affaire de goûts. Je ne fait que donner mon point de vue.
(2) Par conséquent, ca assure une plus grande pérenité au travail réalisé : si je m'amuse à interfacer G'MIC avec GEGL (qui est loin loin d'être un boulot trivial), et que dans 5 ans, GIMP se met au C++, et décide d'utiliser une autre lib (comme GIL, ou CImg , soyons fou :) ), mon utilisation de G'MIC sous GIMP est condamné, à moins de refaire un coûteux travail d'intégration avec une nouvelle lib. Au contraire, l'exécutable sera toujours fonctionnel lui (puisque conçu de manière 'self-contained' dès le départ).
Je ne te demande pas de le faire ;-) Je ne faisait que décrire mon rêve en tant qu'utilisateur. Dans tous les cas, je crois même que je préfère que tu continue de le faire comme maintenant, au moins je suis à peu près sûr qu'il va continuer à évoluer, pour mon plus grand plaisir.
Le passage à GIMP 3.0 risque d'être fatal au plug-in GREYCstoration, et je trouve ça bien dommage, car l'exécutable en ligne de commande à priori continuera d'être fonctionnel.
J'en suis beaucoup moins sûr que toi. Le passage à GEGL va permettre le traitement des photos 16bits dans Gimp (12bits dans mon cas) et donc sa prinipale limitation actuelle dans le dévellopement des fichiers RAW va être supprimée. Gimp 3.0 sera donc un très bon outils je pense pour ce genre de boulot, et au moins pour moi un plugins GreycStoration sera presque indispensable.
Écrire un node pour GEGL qui se contente d'appeler un programme externe est relativement simple, de même que la gestion des paramètres.
Donc, si personne ne le fais avant, il y a de fortes chance pour que moi je le fasse quand un Gimp basé sur Gegl sera utilisable. (pas la 2.6 qui, même si elle utilise Gegl, ne permet de manipuler les nodes dans l'interface)
[^] # Re: Merci
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
- chaque programe est indépendant. Il est plus facile a débogguer
- les programmes peuvent dans des langages différents
- il est facile de remplacer les pipes par des netcat et d'avoir une couche réseau...
Avec un peu de Perl, on arrive ainsi a faire des choses vraiment intéressante qui n'était pas du tout prévu par les différents programmes à la base. Par exemple, j'avais fait un hyperviseur en Perl qui me pilotait le programme de calcul ainsi que le post-traitement. Ainsi, je récupérait les images en cours de calcul pour monter un petit film, le tout sans garder un seul résultat intermédiaire et en modifiant quasiment que très peu les programmes originels.
[^] # Re: Merci
Posté par beagf (site web personnel) . Évalué à 2.
Typiquement, lorsque un problème peut être diviser en plusieurs petites tâches à appliquer en séquence sur les données et que ces données sont traîtées en flux, c'est génial.
En plus, vu la quantité de tels outils déjà disponible, le plus souvent ça économise un max de temps, et sur une machine multi-processeur ça te donne un parallélisme gratuit. Les pipes ont beaucoup d'avantage pour traîter ce genre de données.
Mais dans le cas ou tu travaille sur toutes les données d'un coup, donc en gros : tout charger en mémoire, faire le calcul et sortir tout le résultat d'un coup, c'est déjà moins intéressant. Chacun de tes programmes doit attendre que le précédent ait finit tout son travail et écrit son résultat avant de pouvoir commencer à son tour à tout charger en mémoire et faire son propre boulot.
Dans ce cas les pipes ne servent qu'a éviter les fichiers temporaires.
Il reste l'avantage d'avoir des plus petits programmes réutilisable, mais un plus gros programme avec des options pour choisir la tâche à éffectuer sera plus intéressant car il permet de factoriser le code. De plus si tu peut lui d'appliquer plusieurs opération en séquence, il n'a pas besoin de recharger les données à chaque fois.
C'est le principe justement de G'MIC : Il n'y a pas un programme séparé pour chaque traitement et une utilisation avec des pipes. Il y a un gros programme et on lui donne la séquence d'opérations à appliquer.
Imagine le temps que mettrait certains des scripts fournis si il fallait transférer l'image entre chacun des traitements... Pour une photo en haute résolution avec les cannaux codés sur 16bits, ça fait un sacré ralentissement.
Pour l'intégration dans Gimp, il y a en gros deux possibilitées :
- Soit on intègre G'MIC c'est-à-dire que l'on automatise la séquence : sauvegarder, lancer G'MIC manuellement, charger ;
- Soit on intègre les fonctions de G'MIC et donc chaque fonction de G'MIC devient une fonction de Gimp.
Il me semble assez évident que, d'un point de vue utilisateur, la deuxième solution est plus puissante. Elle permet de mélanger les différentes fonctions sans se poser de questions. Mais elle est bien plus complèxes à implémenter et maintenir.
La première, par contre, à l'avantage d'être relativement simple à coder et maintenir. Bien sûr, on peut effectuer plein de petits appels et obtenir la même souplesse que dans le deuxième cas, mais c'est au prix d'un aller-retour de l'image à chaque appel.
Dans le cas ou l'on demande à G'MIC d'effectuer toute une série d'opérations, le temps de transfert est négligeable. Mais si l'on souhaite faire d'autre traitements avec Gimp, entre chaque fonction de G'MIC, ce temps de transfert est surement bien plus important.
[^] # Re: Merci
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Il faut donc voir les points suivants :
- combien de temps est perdus dans le chargement déchargement dans G'MIC
- combien de temps je passe à interfacé mon code C++ (G'MIC) avec le code C (Gimp), sachant que le C++ et le C ne font pas toujours bon ménage si on commence à trop vouloir mélanger...
- combien de temps je vais gagner à passer par des appels système ?
- combien de temps mon algorithme de calcul pourra être réduit dans le futur.
Dans les cas de calculs longs avec des temps de transfert court et s'il n'y a pas a court terme de moyen de diminuer le temps de calcul, le passage par pipe est une bonne solution alliant souplesse, modularité, indépendance, maintenance.
Dans mon cas à moi, le code était en fortran 90, le post-traitement en C++ et l'hyperviseur en Perl. Faire parler tout cela via des pipes m'a permis d'avoir une grande souplesse de développement, de perdre des poullièmes de secondes et d'avoir des modules complémentement indépendant tant que le langage dans le pipe suivait une certaine convention.
Je crois qu'avec G'MIC, on est aussi dans cette problématique pour le moment. Rien n'empêche une fois que tout marche bien et que c'est utilisé par pleins de personne, de remplacer les pipes par des appels à des bibliothèques standardisés.
[^] # Re: Merci
Posté par David Tschumperlé (site web personnel) . Évalué à 2.
Je crois qu'avec G'MIC, on est aussi dans cette problématique pour le moment. Rien n'empêche une fois que tout marche bien et que c'est utilisé par pleins de personne, de remplacer les pipes par des appels à des bibliothèques standardisés.
Oui je crois aussi que c'est ça le but pour le moment : avoir un plug-in fonctionnel le plus rapidement possible qui puisse être utilisé. Par la suite, on espère que ça motivera éventuellement des gens avec des connaissances plus spécifiques pour améliorer / re-intégrer G'MIC dans GIMP ou d'autres plateformes d'ailleurs.
[^] # Re: Merci
Posté par beagf (site web personnel) . Évalué à 2.
Pour G'MIC, à mon avis, c'est complètement différent car la majorité des fonctions qu'il propose sont très rapides sur les images gérées par Gimp. J'ai pas testé sur des images volumétrique par exemple, mais c'est un peu hors de propos pour Gimp.
Ce qui peut rendre les traitement long, c'est l'utilisation de longue macro qui demandent à G'MIC d'appliquer de nombreux éffets les uns à la suite des autres.
En poussant la philosophie des pipes à font, G'MIC aurrait été codé sous la forme de dizaines de tout petit programmes applicant un seul filtre, et on les enchainerais avec des pipes.
Tu aurrait par exemple un programme gmic_noise, un gmic_sqrt... Le problème c'est que toutes ces opérations sont très rapides et au final le coût d'un fork plus du transfert de données serait très largement superieur au coût du vrai traitement.
C'est, à mon avis, une des raisons qui fait que G'MIC est un programme unique. Il est capable de faire plein d'opérations rapides et de les enchainées tout seul sans pipe. Mais il peut aussi être piper avec d'autres programmes pour faire ce qu'il ne sait pas faire.
[^] # Re: Merci
Posté par benoar . Évalué à 1.
[^] # Re: Merci
Posté par beagf (site web personnel) . Évalué à 2.
Et, non, je n'ai pas "cracker" ce logiciel. J'ai payer la licence.
[^] # Re: Merci
Posté par benoar . Évalué à 2.
# Super!
Posté par ʭ ☯ . Évalué à 3.
Ainsi, à tâtons, on tend vers ce qu'on veut. Je crois que les Photoshop very facile font ça...
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Super!
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Super!
Posté par David Tschumperlé (site web personnel) . Évalué à 2.
En ce qui concerne le plug-in, on commence à avoir quelques résultats d'interaction avec GIMP, ca avance assez bien. J'ai bon espoir pour la suite.
David.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.