Alors, pour être franc, je prévois à court terme de laisser comme ça :), éventuellement d'ajouter des nouvelles traductions ou de corriger deux trois trucs rapides, mais pas de grands bouleversements à l'horizon. Ca m'a (malheureusement) déjà pris beaucoup plus de temps que ce que j'avais prévu, il y a maintenant presque un an, quand j'ai commencé G'MIC.
Donc je répondrais à priori 'non' à toutes tes questions.
Pour les fonctionnalités à mettre en place en priorité, pas grand chose donc, je serais bien intéressé pour creuser du côté de la HDR (mais c'est vraiment pas pour tout de suite).
Disons que je considère 'G'MIC première édition' comme fini maintenant, et j'attend de voir si ca intéresse les gens, et qu'est ce qui les intéresse surtout (plug-in, ligne de commande, possibilité de créer des filtres, intégration de la lib dans d'autres projets, etc... ?)
Si y a des demandes spécifiques intéressantes, ou des contributeurs qui se manifestent, j'aviserais...
Oui, en partie. Ce n'est pas aussi flexible qu'avec la ligne de commande, mais ca commence à marcher. Le filtre concerné s'appelle 'Region inpainting' dans la section 'Enhancement'
A noter qu'après cette version de G'MIC, GREYCstoration ne sera officiellement plus maintenu (en tout cas par moi), ce qui était de toute façon déjà un peu le cas.
Ha ok je viens de retester sur du 64 bits, et effectivement ca marche pas :(
J'ai recompilé, testé et reposté le binaire 64bits, ca devrait marcher maintenant.
Attention de bien récupérer le bon fichier (et pas celui du cache :) )
Dis moi si ca arrange les choses !
Oui c'est une bonne idée, et puis c'est original.
J'ai téléchargé un modèle, ça a l'air possible à première vue. Par contre n'étant pas spécialiste dans le domaine, j'aurais peut-être besoin de plus d'infos. Tu peux détailler les étapes pour créér ces grilles à partir d'une image. Comment c'est fait actuellement ? à la main ?
Niveau perf, a priori tout est fait par le CPU pour le moment. Je laisse le soin au compilateur d'optimiser tout ça avec le GPU si il en est capable (oui, ca devrait être le travail du compilo, enfin à terme c'est surement ce qui va se passer....)
GIMP fournit des données images en mode RGB donc par défaut, c'est le mode RGB qui est utilisé. Par contre, comme G'MIC possède des routines de conversion d'espaces couleurs, il est possible de proposer ponctuellement pour des filtres particuliers de travailler dans un autre espace (ce qui est fait d'ailleurs pour certains filtres notamment traitant la couleur).
A mon avis ca doit être fait de manière ponctuelle, car certains filtres (notamment de déformations géométriques) n'ont aucun intérêt à faire leur calcul en autre chose que RGB.
Heu non, le binaire a été compilé sur une bécane 64 bits, donc ca devrait être bon.
Par contre, je m'aperçois que le dernier lien (pour windows) n'est pas le bon, ca devrait être :
Je viens de rajouter un filtre anti yeux rouges. Pas forcément le meilleur, mais il a l'air de marcher. Il suffit d'updater la liste de filtre dans le plug-in (bouton "Update Filters")
J'ai mis aussi un convertisseur en N&B avec possibilité d'ajouter du grain et de mixer les niveaux de couleurs.
N'étant pas photographe moi-même, je ne connais pas forcément les techniques de retouche de base dans ce domaine. Je suis en discussion avec quelques personnes sur des sites dédiés pour voir un peu de quoi ils auraient besoin et si c'est possible de le faire avec G'MIC.
Très bonne idée, n'hésite pas à contribuer en m'envoyant des paramètres personnalisés, je les intègrerais avec grand plaisir.
Tu peux même essayer aussi d'écrire quelques fonctions personnalisées si tu veux, ça pourra profiter à tout le monde !
Un anti-artefact de compression jpeg : peut-être fait avec GREYCstoration qui est inclus dans G'MIC (filtre "anisotropic smoothing" ou "patch-based smoothing")
Pour le reste, ce sont de bonnes idées, je pense qu'il est possible de les faire sous G'MIC, il faut juste réfléchir un peu et un peu de temps également..
Cela dit, il faudrait que tu définisses le contexte : "Utile" pour toi, et "Utile" pour moi, ca veut à priori pas tout à fait dire la même chose (j'utilise G'MIC assez souvent pour illustrer mes articles et mes slides de recherche, c'est juste pas de la photographie...)
Je reviens de quelques jours de vacances, donc je suis un peu en retard sur le sujet, néanmoins je voudrais faire quelques commentaires :
- Premièrement, j'ai effectivement écrit cet article dans le cadre d'un journal, pas d'une dépêche, d'où le ton un peu plus libre qui est utilisé. Je tiens à préciser que je n'ai pas été sollicité pour faire une version 'dépêche' de ce journal, ni même était prévenu du passage en dépêche. Ca s'est fait en tout cas, je découvre ça aujourd'hui. Je ne critique pas : si je ne voulais pas qu'on réutilise ma prose pour alimenter le site LinuxFR, je n'aurais pas posté un journal sur ce site à la base.
- Secundo, je n'ai jamais dit que GIL c'était nul, bien au contraire. J'ai juste souligné que ce n'était pas facile d'accès. Et ça, je crois pas que tu puisses prétendre le contraire. Comme tu le dis toi-même, il y a des tas de concepts à connaitre pour comprendre et utiliser correctement GIL. Je vais peut-être t'étonner, mais la plupart des spécialistes en TI (que je connais du moins) non seulement se foutent royalement de connaitre ces concepts, mais même s'ils le voulaient, ils n'ont même pas forcément l'expérience nécessaire de 15 ans qu'il faut pour les maitriser en C++.
Alors GIL, c'est bien joli, mais quand je vois le code qu'il faut pondre pour calculer un simple gradient (http://stlab.adobe.com/gil/html/giltutorial.html#ExampleSec)(...) je doute qu'à part les programmeurs de chez Adobe, il y ait beaucoup de monde intéressé pour élaborer des algos génériques non triviaux pouvant se mettre dans GIL.
- Troisièmement, tu m'as l'air d'être le type même de gens dont je dénonce les pensées uniques, quand tu dis :
Voilà, c'est tout. Il faut juste comprendre comment la programmation à base de concepts fonctionne, qui est d'ailleurs la manière recommandée de programmer en C++... (mais bon, peu de personnes la connaissent vraiment, en fait, et tout le temps rejette ce qu'on ne comprend pas)
Typiquement, vous oubliez que la force du C++ c'est justement qu'il est multi-carte, et que c'est un langage qui n'enferme pas le programmeur dans un style de programmation. C'est bien pour ça que ça a un tel succès d'ailleurs. Oui, tu peux faire de la programmation basée concept, ou pas, utiliser des templates, ou pas, etc... Il serait dangeureux de croire qu'il n'y a qu'un style unique permettant de faire du "bon" C++. Regarde juste la diversité des concepts derrière les bibliothèques de traitement d'images en C++ : Entre ITK, VIGRA, GIL, CImg, OLENA, et j'en passe, que de différences !! Et heureusement ! Tout le monde peut s'y retrouver, et choisir la bibliothèque qui convient le mieux à son profil de programmation. Ce qui est important, c'est d'avoir des ponts possibles entre les bibliothèques, c'est tout.
Clairement, CImg a opté pour une certaine facilité d'utilisation. Ce n'est pas ce qui motive les gens derrière GIL. CImg est pratique pour faire du prototypage rapide d'algorithme. Ce n'est pas le cas de GIL. GIL a pleins de qualités mais dans d'autres domaines (grande généricité "potentielle", intégration dans du code existant, etc..)
C'est à l'utilisateur de faire son choix, et CImg participe à élargir le panels d'outils disponibles.
Bon je n'ai pas proposé une dépêche, car CImg ce n'est pas vraiment nouveau, j'en parle depuis un petit moment maintenant.
Pour tester les exemples, le mieux c'est encore d'installer les paquets debian avec les exemples pré-compilés, qui s'installent dans /usr/bin avec le préfixe 'cimg_'.
En particulier, 'cimg_CImg_demo' donne une bonne idée de ce qu'on peut faire.
... et j'en passe (j'ai également 16 coeurs sur cette machine).
La compilation prend alors environ 10 minutes sur un P4, 3Ghz à 16Go de RAM. On n'a pas mis la compilation parallèle par défaut car ca prend effectivement beaucoup de RAM (mais pas pour les raisons que tu invoques). Bref, essaye d'aller dans 'gmic/src' et de lancer 'make -j', ca devrait le faire, y a pas de raison : G'MIC a été prévu pour être compilé en parallèle.
Quant à CImg, sa structure parait bizarre à beaucoup de monde, mais c'est finalement très logique quand on ne fait pas juste survoler le truc : c'est une bibliothèque massivement "template", donc ne pouvant pas se 'pré-compiler' facilement en objets (puisque l'ensemble des fonctions et des types à compiler n'est connue que lors de la compilation du programme l'utilisant). Par ailleurs, pré-compiler toutes les fonctions pour les types les plus courants n'étant pas une bonne idée non plus, étant donné le nombre important de fonctions (qui ne seront pas toutes utilisées de toute facon), et la taille des fichiers objets qui en résulteraient.
Je ne remets pas en cause ce que tu as appris à l'école, mais le cas des bibliothèques template en C++ est un truc un peu particulier de ce point de vue (voir la STL ou Boost).
Pour finir, on pourrait très bien diviser le fichier CImg.h en pleins de petits fichiers. Je ne le fais pour les raisons suivantes :
Ca n'irait pas plus vite à compiler (les classes de CImg étant dépendantes les unes des autres, contrairement à la STL, tous les headers de CImg ainsi divisés seraient nécéssaires à la compilation du projet de toute façon. Il faudrait juste faire 20 includes au lieu d'un seul).
De même ca ne prendrait pas moins de RAM (pour les mêmes raisons).
Ca ne serait pas spécialement plus facile à maintenir (CTRL+S dans Emacs ou n'importe quel IDE C++ digne de ce nom permet d'aller à la définition d'une fonction rapidement, c'est pas un souci. Par ailleurs, le fichier est très bien structuré si tu regardes bien).
Au final, aucun avantage donc à diviser ce fichier, à part faire plaisir à quelques personnes aux préjugés un peu tenaces sur la "beauté" de ce que doit être un code (ce terme revient souvent, ca me fait doucement rigoler).
G'MIC existe grâce à CImg, et à profite de sa généricité. G'MIC peut lire et traiter des images de bool, float, int, etc... Avec à chaque fois des fonctions de traitements spécialisés pour chaque type (un blur d'une image de char ne vas pas avoir besoin de convertir d'abord l'image en float puis la recaster en char). Ce sont des propriétés essentielles au fait que G'MIC soit générique. On ne peut pas avoir le beurre et l'argent du beurre : cette généricité se paye par un temps de compilation un peu plus important que pour des projets plus classiques.
Après j'aurais pu baser G'MIC sur autre chose que CImg, mais bon, moi j'aime bien CImg, c'est pratique à utiliser, c'est beau, c'est top moumoute :), et ca permet de faire pleins de choses en quelques lignes (G'MIC ne fait 'que' 3825 lignes, c'est très faible par rapport au nombre de choses qu'il sait faire).
Après, si tu veux t'amuser, tu peux toujours essayer de décomposer dans tous les sens, si tu gagnes 1/100 de seconde sur le temps de compilation ou sur la RAM utilisée, fais moi signe, ça m'intéresse.
Il s'avère que sur les systèmes dont la langue est le Français, le plug-in a un petit problème. Apparemment, un souci avec les locales C++ qui ne sont pas bien ajustées.
Je travaille sur ce problème, en espérant le corriger aussi vite que possible.
Désolé si vous rencontrez ce problème pour le moment.
Une solution (provisoire) : Passer le système en langue anglaise, et ça doit marcher.
Je tiens également à remercier les joyeux lurons de Linux On Root et de sa mailing list associés, ils ont été très patients et compétents pour l'empaquetage et les tests.
Merci en particulier donc à Claude, Angelo, Jérôme, Christophe et Romain !
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.
Pour le moment, le code est spécialisé uniquement en fonction du type de pixels : unsigned char, short, int, ... Ca ne fait pas une grande différence en temps d'exécution en réalité.
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.
Ton commentaire me fait quand même dire que la "propreté" (ou encore "beauté du code" comme certains disent..) c'est très subjectif...
(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.
[^] # Re: Le futur G'MIC
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche [GIMP] G'MIC évolue et s'internationalise. Évalué à 5.
Donc je répondrais à priori 'non' à toutes tes questions.
Pour les fonctionnalités à mettre en place en priorité, pas grand chose donc, je serais bien intéressé pour creuser du côté de la HDR (mais c'est vraiment pas pour tout de suite).
Disons que je considère 'G'MIC première édition' comme fini maintenant, et j'attend de voir si ca intéresse les gens, et qu'est ce qui les intéresse surtout (plug-in, ligne de commande, possibilité de créer des filtres, intégration de la lib dans d'autres projets, etc... ?)
Si y a des demandes spécifiques intéressantes, ou des contributeurs qui se manifestent, j'aviserais...
[^] # Re: inpainting ?
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche [GIMP] G'MIC évolue et s'internationalise. Évalué à 4.
A noter qu'après cette version de G'MIC, GREYCstoration ne sera officiellement plus maintenu (en tout cas par moi), ce qui était de toute façon déjà un peu le cas.
[^] # Re: Révision de la redevance audiovisuelle
Posté par David Tschumperlé (site web personnel) . En réponse au journal [ après-HADOPI] : Le pire est à venir.. Évalué à 8.
[^] # Re: ça marche pas
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche [GIMP] G'MIC évolue et s'internationalise. Évalué à 1.
45899c67184b71034e7c5763b33091d7 gmic4gimp_linux64.zip
Par contre, je viens de tester ici, sur une debian 64bits, et ça roule.
Je comprend pas trop d'où vient le souci donc...
[^] # Re: ça marche pas
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche [GIMP] G'MIC évolue et s'internationalise. Évalué à 6.
J'ai recompilé, testé et reposté le binaire 64bits, ca devrait marcher maintenant.
Attention de bien récupérer le bon fichier (et pas celui du cache :) )
Dis moi si ca arrange les choses !
Et merci pour le test !
David.
[^] # Re: Proposition "point de croix" pour nos grand-mères
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche [GIMP] G'MIC évolue et s'internationalise. Évalué à 7.
J'ai téléchargé un modèle, ça a l'air possible à première vue. Par contre n'étant pas spécialiste dans le domaine, j'aurais peut-être besoin de plus d'infos. Tu peux détailler les étapes pour créér ces grilles à partir d'une image. Comment c'est fait actuellement ? à la main ?
[^] # Re: ça marche pas
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche [GIMP] G'MIC évolue et s'internationalise. Évalué à 7.
As-tu une erreur qui s'affiche si tu lances 'gimp' depuis la ligne de commande ?
Est-ce que GIMP se lance ? Est-ce que tu as l'entrée 'Filtres/G'MIC pour GIMP', comme dans le screenshot :
http://gmic.sourceforge.net/album/slides/Screenshot-Chlo.jpg(...)
Quel distro ? quel architecture ? Tout ça quoi...
[^] # Re: Impressionnant !
Posté par David Tschumperlé (site web personnel) . En réponse au journal [GIMP] G'MIC évolue et s'internationalise. Évalué à 1.
GIMP fournit des données images en mode RGB donc par défaut, c'est le mode RGB qui est utilisé. Par contre, comme G'MIC possède des routines de conversion d'espaces couleurs, il est possible de proposer ponctuellement pour des filtres particuliers de travailler dans un autre espace (ce qui est fait d'ailleurs pour certains filtres notamment traitant la couleur).
A mon avis ca doit être fait de manière ponctuelle, car certains filtres (notamment de déformations géométriques) n'ont aucun intérêt à faire leur calcul en autre chose que RGB.
# Version Catalane
Posté par David Tschumperlé (site web personnel) . En réponse au journal [GIMP] G'MIC évolue et s'internationalise. Évalué à 2.
[^] # Re: 64/32?
Posté par David Tschumperlé (site web personnel) . En réponse au journal [Gimp et traitement d'image] Sortie de G'MIC 1.3.1.2. Évalué à 2.
Par contre, je m'aperçois que le dernier lien (pour windows) n'est pas le bon, ca devrait être :
http://downloads.sourceforge.net/gmic/gmic4gimp_win32.zip
David.
[^] # Re: Filtre utile ?
Posté par David Tschumperlé (site web personnel) . En réponse au journal [Gimp et traitement d'image] Sortie de G'MIC 1.3.1.2. Évalué à 4.
J'ai mis aussi un convertisseur en N&B avec possibilité d'ajouter du grain et de mixer les niveaux de couleurs.
N'étant pas photographe moi-même, je ne connais pas forcément les techniques de retouche de base dans ce domaine. Je suis en discussion avec quelques personnes sur des sites dédiés pour voir un peu de quoi ils auraient besoin et si c'est possible de le faire avec G'MIC.
David.
[^] # Re: Filtre utile ?
Posté par David Tschumperlé (site web personnel) . En réponse au journal [Gimp et traitement d'image] Sortie de G'MIC 1.3.1.2. Évalué à 4.
Tu peux même essayer aussi d'écrire quelques fonctions personnalisées si tu veux, ça pourra profiter à tout le monde !
David.
[^] # Re: Filtre utile ?
Posté par David Tschumperlé (site web personnel) . En réponse au journal [Gimp et traitement d'image] Sortie de G'MIC 1.3.1.2. Évalué à 6.
Pour le reste, ce sont de bonnes idées, je pense qu'il est possible de les faire sous G'MIC, il faut juste réfléchir un peu et un peu de temps également..
Cela dit, il faudrait que tu définisses le contexte : "Utile" pour toi, et "Utile" pour moi, ca veut à priori pas tout à fait dire la même chose (j'utilise G'MIC assez souvent pour illustrer mes articles et mes slides de recherche, c'est juste pas de la photographie...)
[^] # Re: Commentaire personel
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche Sortie de CImg 1.3.0. Évalué à 2.
- Premièrement, j'ai effectivement écrit cet article dans le cadre d'un journal, pas d'une dépêche, d'où le ton un peu plus libre qui est utilisé. Je tiens à préciser que je n'ai pas été sollicité pour faire une version 'dépêche' de ce journal, ni même était prévenu du passage en dépêche. Ca s'est fait en tout cas, je découvre ça aujourd'hui. Je ne critique pas : si je ne voulais pas qu'on réutilise ma prose pour alimenter le site LinuxFR, je n'aurais pas posté un journal sur ce site à la base.
- Secundo, je n'ai jamais dit que GIL c'était nul, bien au contraire. J'ai juste souligné que ce n'était pas facile d'accès. Et ça, je crois pas que tu puisses prétendre le contraire. Comme tu le dis toi-même, il y a des tas de concepts à connaitre pour comprendre et utiliser correctement GIL. Je vais peut-être t'étonner, mais la plupart des spécialistes en TI (que je connais du moins) non seulement se foutent royalement de connaitre ces concepts, mais même s'ils le voulaient, ils n'ont même pas forcément l'expérience nécessaire de 15 ans qu'il faut pour les maitriser en C++.
Alors GIL, c'est bien joli, mais quand je vois le code qu'il faut pondre pour calculer un simple gradient (http://stlab.adobe.com/gil/html/giltutorial.html#ExampleSec)(...) je doute qu'à part les programmeurs de chez Adobe, il y ait beaucoup de monde intéressé pour élaborer des algos génériques non triviaux pouvant se mettre dans GIL.
- Troisièmement, tu m'as l'air d'être le type même de gens dont je dénonce les pensées uniques, quand tu dis :
Voilà, c'est tout. Il faut juste comprendre comment la programmation à base de concepts fonctionne, qui est d'ailleurs la manière recommandée de programmer en C++... (mais bon, peu de personnes la connaissent vraiment, en fait, et tout le temps rejette ce qu'on ne comprend pas)
Typiquement, vous oubliez que la force du C++ c'est justement qu'il est multi-carte, et que c'est un langage qui n'enferme pas le programmeur dans un style de programmation. C'est bien pour ça que ça a un tel succès d'ailleurs. Oui, tu peux faire de la programmation basée concept, ou pas, utiliser des templates, ou pas, etc... Il serait dangeureux de croire qu'il n'y a qu'un style unique permettant de faire du "bon" C++. Regarde juste la diversité des concepts derrière les bibliothèques de traitement d'images en C++ : Entre ITK, VIGRA, GIL, CImg, OLENA, et j'en passe, que de différences !! Et heureusement ! Tout le monde peut s'y retrouver, et choisir la bibliothèque qui convient le mieux à son profil de programmation. Ce qui est important, c'est d'avoir des ponts possibles entre les bibliothèques, c'est tout.
Clairement, CImg a opté pour une certaine facilité d'utilisation. Ce n'est pas ce qui motive les gens derrière GIL. CImg est pratique pour faire du prototypage rapide d'algorithme. Ce n'est pas le cas de GIL. GIL a pleins de qualités mais dans d'autres domaines (grande généricité "potentielle", intégration dans du code existant, etc..)
C'est à l'utilisateur de faire son choix, et CImg participe à élargir le panels d'outils disponibles.
David.
[^] # Re: En dépêche ?
Posté par David Tschumperlé (site web personnel) . En réponse au journal [Traitement d'image] Sortie de CImg 1.3.0. Évalué à 5.
Pour tester les exemples, le mieux c'est encore d'installer les paquets debian avec les exemples pré-compilés, qui s'installent dans /usr/bin avec le préfixe 'cimg_'.
En particulier, 'cimg_CImg_demo' donne une bonne idée de ce qu'on peut faire.
David.
[^] # Re: GMIC
Posté par David Tschumperlé (site web personnel) . En réponse au message Automatisation de réduction d'image. Évalué à 1.
[^] # Re: GMIC
Posté par David Tschumperlé (site web personnel) . En réponse au message Automatisation de réduction d'image. Évalué à 3.
gmic image.jpg --dimensions --[1] 450 -if @\{1,1\} -+[1] 450 -/[1] @\{1,1\} -*[1] 450 -r[0] @\{1,0,1\},1,100%,2 -endif -k[0] -o output.jpg
David.
[^] # Re: PA-RA-LLELE!
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche Traitement d'images : Quand G'MIC 1.3.0 s'invite dans GIMP. Évalué à 8.
- D'abord, G'MIC se compile très bien en parallèle, je le fais comme ça chez moi :
dtschump@gemino:~/work/src/gmic/src$ make -j
make "CFLAGS+=-Dcimg_display=1 -I/usr/X11R6/include" "LDFLAGS+=-L/usr/X11R6/lib -lX11 -lpthread -lswscale" "STRIP_EXE=1" gmic
g++ -o gmic4gimp.o -c gmic.cpp -Dgmic_minimal -Dcimg_display=0 -Wall -W -O3 -ffast-math -fno-tree-pre -Dcimg_use_fftw3
make "CFLAGS+=-Dcimg_display=1 -I/usr/X11R6/include" "LDFLAGS+=-L/usr/X11R6/lib -lX11 -lpthread" "STRIP_EXE=1" gmic
make[1]: Entering directory `/users2/prof/dtschump/work/src/gmic/src'
g++ -o gmic_bool.o -c gmic.cpp -Dgmic_separate_compilation -Dgmic_bool -Dcimg_display=1 -I/usr/X11R6/include -Wall -W -O3 -ffast-math -fno-tree-pre -Dcimg_use_xshm -Dcimg_use_xrandr -Dcimg_use_png -Dcimg_use_jpeg -Dcimg_use_tiff -I/usr/include/ffmpeg -Dcimg_use_ffmpeg -Dcimg_use_zlib -Dcimg_use_magick -Dcimg_use_fftw3
g++ -o gmic_uchar.o -c gmic.cpp -Dgmic_separate_compilation -Dgmic_uchar -Dcimg_display=1 -I/usr/X11R6/include -Wall -W -O3 -ffast-math -fno-tree-pre -Dcimg_use_xshm -Dcimg_use_xrandr -Dcimg_use_png -Dcimg_use_jpeg -Dcimg_use_tiff -I/usr/include/ffmpeg -Dcimg_use_ffmpeg -Dcimg_use_zlib -Dcimg_use_magick -Dcimg_use_fftw3
g++ -o gmic_char.o -c gmic.cpp -Dgmic_separate_compilation -Dgmic_char -Dcimg_display=1 -I/usr/X11R6/include -Wall -W -O3 -ffast-math -fno-tree-pre -Dcimg_use_xshm -Dcimg_use_xrandr -Dcimg_use_png -Dcimg_use_jpeg -Dcimg_use_tiff -I/usr/include/ffmpeg -Dcimg_use_ffmpeg -Dcimg_use_zlib -Dcimg_use_magick -Dcimg_use_fftw3
... et j'en passe (j'ai également 16 coeurs sur cette machine).
La compilation prend alors environ 10 minutes sur un P4, 3Ghz à 16Go de RAM. On n'a pas mis la compilation parallèle par défaut car ca prend effectivement beaucoup de RAM (mais pas pour les raisons que tu invoques). Bref, essaye d'aller dans 'gmic/src' et de lancer 'make -j', ca devrait le faire, y a pas de raison : G'MIC a été prévu pour être compilé en parallèle.
Quant à CImg, sa structure parait bizarre à beaucoup de monde, mais c'est finalement très logique quand on ne fait pas juste survoler le truc : c'est une bibliothèque massivement "template", donc ne pouvant pas se 'pré-compiler' facilement en objets (puisque l'ensemble des fonctions et des types à compiler n'est connue que lors de la compilation du programme l'utilisant). Par ailleurs, pré-compiler toutes les fonctions pour les types les plus courants n'étant pas une bonne idée non plus, étant donné le nombre important de fonctions (qui ne seront pas toutes utilisées de toute facon), et la taille des fichiers objets qui en résulteraient.
Je ne remets pas en cause ce que tu as appris à l'école, mais le cas des bibliothèques template en C++ est un truc un peu particulier de ce point de vue (voir la STL ou Boost).
Pour finir, on pourrait très bien diviser le fichier CImg.h en pleins de petits fichiers. Je ne le fais pour les raisons suivantes :
Ca n'irait pas plus vite à compiler (les classes de CImg étant dépendantes les unes des autres, contrairement à la STL, tous les headers de CImg ainsi divisés seraient nécéssaires à la compilation du projet de toute façon. Il faudrait juste faire 20 includes au lieu d'un seul).
De même ca ne prendrait pas moins de RAM (pour les mêmes raisons).
Ca ne serait pas spécialement plus facile à maintenir (CTRL+S dans Emacs ou n'importe quel IDE C++ digne de ce nom permet d'aller à la définition d'une fonction rapidement, c'est pas un souci. Par ailleurs, le fichier est très bien structuré si tu regardes bien).
Au final, aucun avantage donc à diviser ce fichier, à part faire plaisir à quelques personnes aux préjugés un peu tenaces sur la "beauté" de ce que doit être un code (ce terme revient souvent, ca me fait doucement rigoler).
G'MIC existe grâce à CImg, et à profite de sa généricité. G'MIC peut lire et traiter des images de bool, float, int, etc... Avec à chaque fois des fonctions de traitements spécialisés pour chaque type (un blur d'une image de char ne vas pas avoir besoin de convertir d'abord l'image en float puis la recaster en char). Ce sont des propriétés essentielles au fait que G'MIC soit générique. On ne peut pas avoir le beurre et l'argent du beurre : cette généricité se paye par un temps de compilation un peu plus important que pour des projets plus classiques.
Après j'aurais pu baser G'MIC sur autre chose que CImg, mais bon, moi j'aime bien CImg, c'est pratique à utiliser, c'est beau, c'est top moumoute :), et ca permet de faire pleins de choses en quelques lignes (G'MIC ne fait 'que' 3825 lignes, c'est très faible par rapport au nombre de choses qu'il sait faire).
Après, si tu veux t'amuser, tu peux toujours essayer de décomposer dans tous les sens, si tu gagnes 1/100 de seconde sur le temps de compilation ou sur la RAM utilisée, fais moi signe, ça m'intéresse.
David.
[^] # Re: Problème de "locale"
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche Traitement d'images : Quand G'MIC 1.3.0 s'invite dans GIMP. Évalué à 5.
Encore désolé pour les problèmes occasionnés.
David.
# Problème de "locale"
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche Traitement d'images : Quand G'MIC 1.3.0 s'invite dans GIMP. Évalué à 3.
Je travaille sur ce problème, en espérant le corriger aussi vite que possible.
Désolé si vous rencontrez ce problème pour le moment.
Une solution (provisoire) : Passer le système en langue anglaise, et ça doit marcher.
[^] # Re: Remerciements pour l'empaquetage et tests.
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche Traitement d'images : Quand G'MIC 1.3.0 s'invite dans GIMP. Évalué à 10.
# Remerciements pour l'empaquetage et tests.
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche Traitement d'images : Quand G'MIC 1.3.0 s'invite dans GIMP. Évalué à 10.
Merci en particulier donc à Claude, Angelo, Jérôme, Christophe et Romain !
[^] # Re: Merci
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC 1.0.0 : Un outil extensible pour le traitement d'images.. É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: Super!
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC 1.0.0 : Un outil extensible pour le traitement d'images.. É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.
[^] # Re: Merci
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC 1.0.0 : Un outil extensible pour le traitement d'images.. É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.