Remerciements pour l'empaquetage et tests.

• [^]Re: Remerciements pour l'empaquetage et tests.

  Posté par David Tschumperlé (page perso, ) le 13/01/2009 à 15:14. (lien). Évalué à 10.

  Et Stéphane, et Jean-Claude, voilà, désolé pour les oublis !

:)

Merci David !

• [^]Re: Merci David !

  Posté par Pierre Jarillon (page perso, ) le 13/01/2009 à 16:55. (lien). Évalué à 6.

  J'ai apprécié Greycstoration à de nombreuses reprises. C'est un logiciel vraiment très performant. Mais j'apprécierai encore plus de le voir intégré dans Gimp, ça évitera des manipulations de fichier supplémentaires.
  
  Merci d'avoir fait et publié cet excellent utilitaire.

  • [^]Re: Merci David !

    Posté par brunus (page perso, ) le 14/01/2009 à 10:03. (lien). Évalué à 3.

    Bonjour Pierre,
    
    De mon coté il est intégré dans Gimp. J'ajoute le plugin certes, mais le résultat est là, je charge mon image et j'ai accès à Greycstoration par le menu des filtres.
    
    Mais là je vais tester G'MIC.

    --
    Engendrer sans chercher à posséder, accomplir sans en revendiquer le mérite, guider sans dominer, telle est la vertu suprême. (attribué à Lǎo Zi, -500 av JC)

Problème de "locale"

• [^]Re: Problème de "locale"

  Posté par David Tschumperlé (page perso, ) le 14/01/2009 à 10:50. (lien). Évalué à 5.

  Voilà le problème est réglé, j'ai remis à jour l'archive sur le site de Sourceforge.
  
  Encore désolé pour les problèmes occasionnés.
  
  David.

  • [^]Re: Problème de "locale"

    Posté par gpe () le 14/01/2009 à 12:01. (lien). Évalué à 1.

    Je me disais bien qu'il y avait un truc qui clochait! Je voulais en parler ici ce matin mais tu as été plus rapide!
    Par contre je vois que maintenant il n'y a plus de paquet .deb de dispo ?

PA-RA-LLELE!

• [^]Re: PA-RA-LLELE!

  Posté par Nicolas Schoonbroodt (Jabber id, ) le 14/01/2009 à 11:51. (lien). Évalué à 4.

  Voir les différentes nouvelles et journaux de sortie de ce logiciel. à chaque fois on en parle ;-)

  • [^]Re: PA-RA-LLELE!

    Posté par jm trivial (page perso, ) le 14/01/2009 à 12:10. (lien). Évalué à 2.

    À tel point qu'une réponse à cette question est présente de longue date dans la FAQ du site internet du projet :
    http://cimg.sourceforge.net/reference/group__cimg__faq.html#(...)

• [^]Re: PA-RA-LLELE!

  Posté par David Tschumperlé (page perso, ) le 14/01/2009 à 12:18. (lien). Évalué à 8.

  Bon ce genre de question revient toujours. Je commence à avoir l'habitude. Je vais te répondre très rapidement sur le pourquoi du comment :
  
  - 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: PA-RA-LLELE!

    Posté par case42 (page perso, ) le 16/01/2009 à 16:50. (lien). Évalué à 4.

    Je te remercie de ta longue réponse, je ne regrette pas d'avoir posé ces question...
    Effectivement, l'argument "parce que templates", et recevable.
    
    Ceci dit j'ai tout de même quelques remarques :)
    
    (bon alors ça se voit pas, mais c'est au moins la 4ieme fois que je reprends ce messages, au fur et a mesure que j'avance dans la compréhension du code...)
    
    Bon pour CImg.h, je rends les armes. Effectivement le coté template fait qu'on ne peut pas y faire grand chose. Mais c'est à la fois sa force et son talon d'achile: je ne connaissais pas CImg.h, mais ce que je sais c'est que si un jour je dois choisir une librairie de manipulation d'image, elle viendra en dernier sur ma liste (sauf si je dois gérer des images dont les éléments sont de type ChuckNorris, la on pourra discuter), parce que les pénalités que j'ai déjà décrites ne sont contrebalancés que dans certains cas très particulier...
    
    Pour gmic.cpp, effectivement je ne vois pas de moyen d'accélérer le projet dans son ensemble, MAIS j'en vois une qui allègera le boulot de compilation pour le développeur, en permettant un semblant de compilation incrémentale (oui parce actuellement, si tu touche à un iota de gmic.cpp ou CImg.h, tu recompile tout du début... )
    
    Je propose de faire des classes "wrapper" autour de CImg
    (je pense que ces wrappers pourront facilement être généré automatiquement par un script dans la chaine de compilation pour chaque type géré par gmic)
    J'en ai fait un bout qui marche, avec juste un constructeur et une méthode, à l'arrache:
    CImgUC.h :
#include "CImg.h"

class CImgUC
{
protected:
#ifdef _CIMG_UC_
cimg_library::CImg<unsigned char> *img;
#else
void *img;
#endif

public:
CImgUC(const char *const filename);
CImgUC& blur(const float sigma, const bool cond=true);
};

CImgUC.cpp
#define _CIMG_UC_
#include "CImgC.h"

CImgUC::CImgUC(const char *const filename)
{
img = new cimg_library::CImg<unsigned char>(filename);
}

CImgUC& CImgUC::blur(const float sigma, const bool cond)
{
img = &img->blur(sigma, cond);
return(*this);
}

    Une fois qu'on a ça, on peut tranquillement compiler un cimg_uc.o contenant cette classe, classe qu'on utilisera dans gmic.cpp , mais comme on masque complètement CImg.h, on a un gros gain à la compilation.
    
    Quelques temps:
    #test.cpp : utilise directement CImg.h
$ time g++ test.cpp -lX11 -lpthread
real 0m5.353s
user 0m5.016s
sys 0m0.320s

#test2.cpp fait la même chose en utilisant la classe CImgUC compilée par CImgC.cpp
$ time g++ -c -o cimgc.o CImgC.cpp
real 0m5.183s
user 0m4.780s
sys 0m0.356s
$ time g++ cimgc.o test2.cpp -lX11 -lpthread
real 0m0.200s
user 0m0.144s
sys 0m0.052s

    
    Voila, en temps que développeur, à a la première compilation ma version est pénalisée... Mais si je change le code de test2.cpp, le temps de compilation du projet total reste à 0.2s au lieu de 5s dans l'autre cas...
    
    J'avais d'autres choses à dire pour soutenir mon argumentaire, mais j'ai plus guère de temps...

Information suplémentaire