Je voudrais vous présenter G'MIC, un nouvel outil libre de manipulation d'images en ligne de commande. C'est la suite logique d'INRCAST que je vous avais présenté il n'y a pas si longtemps dans ce journal. INRCAST avait des limitations dans sa structure même, qui le rendait un peu fouilli à utiliser (un tas d'options éparses pas toujours intuitives à se rappeler).
Pendant ces vacances, je me suis donc attelé à la tâche et j'ai tout réécrit "from scratch". Ca donne G'MIC qui est beaucoup plus souple, et du coup qui permet tout un tas de choses intéressantes pour la manipulation d'images.
On peut bien sûr charger, sauver, convertir, comme la plupart des outils 'philosophiquement équivalents' (comme ImageMagick ou GraphicsMagick). Mais G'MIC permet surtout la modification des images : décomposition, filtrage, déformation, etc..
L'autre originalité est le fait qu'il traite les images de façon typée, et par liste (donc plusieurs images peuvent être chargées et manipulées indépendamment, comme si on avait des calques numérotés). On peut appliquer des commandes groupées ou sur une seule image, et enchaîner des commandes dans un ordre prédéfini. Ca définit presque un petit langage de programmation simple de traitement d'images.
Bref, G'MIC est un outil à la fois jeune, mais (je pense) abouti, car il répond à des besoins qu'on a eu ici ou là, dans l'équipe IMAGE du laboratoire GREYC ou je travaille (je vous laisse deviner sur quel thème de recherche on travaille :) ). Je me permets donc d'en parler ici, ça vous intéressera peut-être..
Pour l'anecdote, le nom G'MIC a été choisi pour trois raisons amusantes :
- "G'MIC", c'est "CIMG" à l'envers. G'MIC a été programmé en effet en utilisant CImg, une bibliothèque C++ de traitement d'images générique, et peut-être vu comme une sorte d'interface en ligne de commande de pas mal de fonctionnalités de CImg.
- "G'MIC" ca peut se prononcer (si on va vite) "Gimmick", ce qui sonne quand même pas mal pour un outil de type {Image,Graphics}Magick.
- "G'MIC" veut dire "GREYC's Magick Image Converter", et c'est pas complètement débile !
Voila !
Si ca vous intéresse, je vous laisse découvrir cet outil, il y a quelques screenshots de ce qu'on peut faire avec sur le site principal. Et si vraiment ca vous botte, je cherche de l'aide pour compiler/packager çà pour des architectures et des distros différentes (G'MIC étant bien entendu multi-plateforme).
La licence choisie est la CeCILL 2.0. Le site est encore un peu moche, car je me suis plus concentré sur les fonctionnalités de l'outil et sur la doc.
Merci de votre attention !
David.
Journal G'MIC : Un nouvel outil libre de manipulation d'images
17
août
2008
# bon ben c' est simple....
Posté par cortex62 . Évalué à 3.
Venant de l' équipe GREYCstoration je me doute que ça doit être bon.
Bon pis les gars qui font du mandelbrot en easter eggs (5 em image) moi je décroche. Désolé je suis limité et j' ai pas le temps ( j' ai compris le concept mais ça me fait presque peur).
Mais ça a l' air TRÉS intéressant tout ça, je ne comprend pas tout mais déja .....
Question chiante : comment on compile ? ( je sais il y a un binaire , I386 faut que je regarde).
Un dernier mot: MERCI et FÉLICITATIONS.
[^] # Re: bon ben c' est simple....
Posté par David Tschumperlé (site web personnel) . Évalué à 3.
L'idéal serait bien sûr d'avoir un "./configure" pour adapter au mieux la compilation au système, mais j'avoue que je ne sais pas faire. Attention, la compilation prend une dizaine de minute sur un PC avec 1Go de RAM. Avec 512Mo, il faut oublier, car ça swappe à mort (j'ai personnellement essayé et arrêté au bout d'une heure et demi...).
Par contre, une fois compilé, ca fonctionne bien même sur des petites machines (mon EEEPC peut en témoigner).
David.
[^] # Re: bon ben c' est simple....
Posté par nojhan (site web personnel, Mastodon) . Évalué à 2.
Sinon, ça fait plusieurs fois que je me dis en lisant ton code de CIMG que tu devrais absolument te mettre à boost [3], ça t'éviterais pas mal de corvées. Pour G'MIC, je ne dis rien, je n'ai pas réussi à trouver où était le code (je suis d'ailleurs étonné que les habituels raleurs n'ait pas relevé... ah merde, je viens de le faire, en fait).
Sinon, c'est chouette de voir que tu continues à faire du bon boulot, on en veut encore :-)
[1] http://www.scons.org/
[2] http://www.cmake.org
[3] http://www.boost.org/
[^] # Re: bon ben c' est simple....
Posté par Psychofox (Mastodon) . Évalué à 3.
moi pas comprendre. Les 2 posts précédents parlent de compiler G'MIC à partir de la makefile, tu crois qu'ils n'ont pas eu les sources ?
bon c'est simple c'est la (accessible bêtement depuis le bouton download du site) :
http://sourceforge.net/project/showfiles.php?group_id=234931
[^] # Re: bon ben c' est simple....
Posté par Octabrain . Évalué à 5.
Due to its high template structure, the compilation of G'MIC requires *a lot of memory and a lot of compilation time*. Don't try to compile it if you have less than 1Gb memory on your computer (you have been warned..) !
C'est un problème de conception, le code est si peu modulaire que tout le code est dans un seul fichier (je viens d'aller voir).
Je me demande même comment on peut penser qu'une personne étrangère au projet puisse se plonger dans un fichier source de 2Mo sans que cela ne cause chez elle tour à tour une migraine, une rupture d'anévrisme et un cancer spontané des neurones.
[^] # Re: bon ben c' est simple....
Posté par David Tschumperlé (site web personnel) . Évalué à 6.
Mais je te rassure, tu n'es pas le seul, et comme tu dois bien être le 300ème à me rabâcher cette affirmation (fausse), je me suis permis d'essayer d'expliquer tout ça dans une FAQ, il y a quelques temps :
http://cimg.sourceforge.net/reference/group__cimg__faq.html#(...)
(tu vois je fais des efforts).
En résumé, la modularité n'a rien à voir la dedans, G'MIC utilise un tas de fonctions différentes avec des types d'images différents (et de la généricité statique) et donc de toute façon, le compilo doit les compiler pour tous les types que l'on a prévu. C'est pour çà que ca prend du temps, diviser ton fichier .h en plusieurs ne va absolument rien changer à l'affaire (je prend le pari si tu veux.). Et si tu penses que CImg peut se précompiler en fichiers bibliothèque .a ou .so, c'est pas la peine non plus. Ca serait possible à la limite dans le cas de G'MIC, mais pas dans le cas général d'utilisation de CImg où tu as des fonctions membres dépendantes de 3 ou 4 paramètres template, que tu ne vas pas t'amuser à pré-compiler pour tous les types possibles. Tout ça est expliqué dans la FAQ.
Je m'énerve un peu, car tu es loin d'être le premier à juger sans avoir réfléchi un tout petit peu au problème. La blague vois-tu, c'est que jusque là, personne n'a pu me suggérer une *vraie* bonne idée pour améliorer les choses, et on peut pas dire que que je sois fermé sur ce point, bien au contraire.
David.
[^] # Re: bon ben c' est simple....
Posté par Achille Fouilleul (site web personnel) . Évalué à 3.
Mais c'est bien ce qu'il dit, il y a à mon avis aussi un gros problème de conception. Il ne s'agit pas de saucissonner le code en fichiers .h, bien sûr que ça ne règlerait pas le problème.
* Pourquoi tout mettre dans une seule classe (CImg)? À la fois du code dépendant de la plateforme, du code de traitement d'image, de tracé de formes. Tout cela pourrait avantageusement séparé.
* As-tu considéré les traits/policies? Tu conserves ainsi le polymorphisme statique (lorsqu'il est vraiment nécessaire). Il faudrait des benchmarks pour arbitrer avec le polymorphisme dynamique.
* Pourquoi toutes ces données codées en dur (polices, chemins, tableaux de constantes, etc.)?
* Des fonctions/macros qui prennent une dizaine de paramètres?!
Comme le post parent le suggère, jette un coup d'oeil à Boost, la STL, etc. Tu verras qu'il est possible de conserver de la généricité tout en gardant des tailles de fichier et des temps de compilation raisonnables.
Ne le prends pas mal, c'est du bon et gros boulot, les algos de traitement d'image sont certainement bons et ta bibliothèque utile, mais elle gagnerait à une conception utilisant mieux le langage C++.
Vois également la bibliothèque AGG (antigrain). Elle est très polymorphe (y compris statiquement), les headers et classes sont clairement décomposés.
[^] # Re: bon ben c' est simple....
Posté par David Tschumperlé (site web personnel) . Évalué à 2.
* Dans la classe CImg, il n'y a aucun code plateforme-dependent. C'est une grosse classe, car effectivement, les algos agissant sur les images sont des fonctions membres. Est-ce une erreur de conception ? Je ne crois pas. C'est différent de la STL ou de boost, mais ca permet un style de programmation assez naturel et lisible ('img.blur(3);' on comprend tout de suite ce que ca fait). Si on ne veut vraiment pas de fonctions membres dans les classes, alors on fait des structures C et c'etait pas la peine de faire du C++. Le fait que le compilo ait du mal n'est pas une raison valable pour décrier la conception, je pourrais te répondre que c'est la faute au compilo qui est mal fichu... (mais évidemment, c'est un raccourci que je ne me permettrais pas de faire).
* CImg utilise pas mal de traits, tu peux aller voir dans le code. En particulier pour determiner les types de retours des images quand c'est nécessaire. Mais le problème des traits c'est que quand ça devient systématique, ca devient souvent illisible au niveau du code les utilisant (oui, oui je trouve l'utilisation un peu poussée de boost rapidement illisible, et je crois pas être le seul..)
* Certaines données sont en dur, c'est vrai pour un souci pratique. C'est discutable, mais je ne crois pas que les 10 Ko de données qu'elle représentent au final sont la cause du temps de compilation. D'ailleurs, la plupart des exemples fournis avec CImg compilent relativement rapidement, et possèdent aussi ces données là. Donc, c'est définitivement pas la cause du problème.
* Les macros peuvent faire peur, mais elles sont très peu utilisées dans CImg, et je pense qu'elles le sont à bon escient. Ca fait peur parce que elles se trouvent en début de fichier, et que c'est vrai que ca prend de la place... Mais bon, c'est des macros, je vais pas les mettre à la fin du fichier...
G'MIC est un exemple assez extrême : Il nécéssite la compilation d'énormément de fonctions différentes, et évidemment cela se ressent avec une machine 'limite' (faut voir comment ca peut bouffer, un g++ en pleine action..). Mais l'utilisation de CImg dans un cadre plus 'normal' n'a pas ce genre de problème, fort heureusement.
[^] # Re: bon ben c' est simple....
Posté par Achille Fouilleul (site web personnel) . Évalué à 2.
Ce n'est pas ce que je veux dire. L'idée de la programmation objet (quel que soit le langague) est justement de séparer les concepts, d'avoir des classes minimalistes qui représentent un invariant. Il ne me semble pas judicieux, par exemple de mêler dans une même classe gestion des fichiers, des options de ligne de commande, l'interface utilisateur, etc.
J'ai bien vu que tu utilises des traits -- trop peu à mon goût, mais je découvre ta bibliothèque, alors je suis prudent dans mes commentaires :-).
En ce qui concerne les policies, tu pourrais bien, par exemple avoir une classe par algo (blur pour reprendre ton exemple) et t'en servir comme paramètre de template. Il s'agit là de métaprogrammation: la classe n'est jamais instanciée, elle sert de paramètre à une autre classe (cf. Policy-based design sur wikipédia, ou la bibliothèque Loki d'Andrei Alexandrescu). J'insiste, va voir Anti-Grain c'est aussi une bibliothèque graphique, indépendante du type de pixel, couleur, etc., statiquement polymorphe et (à mon avis) lisible.
En ce qui concerne de "faire du C++" je note que tu utilises pas mal de fonctions stdio/stdlib (fopen, sprintf, memcpy, etc.), alors que de meilleurs équivalents C++ sont disponibles (std::fstream, std::ostringstream, std::copy, etc.).
* Les macros peuvent faire peur, mais elles sont très peu utilisées dans CImg, et je pense qu'elles le sont à bon escient. Ca fait peur parce que elles se trouvent en début de fichier, et que c'est vrai que ca prend de la place... Mais bon, c'est des macros, je vais pas les mettre à la fin du fichier...
Pour les macros, c'est un peu pareil, c'est du C. Je suis sûr qu'il est possible de les réécrire sous forme de templates, elles seraient certainement plus courtes, "type-safe", et le compilateur devrait être capable de produire de meilleures optimisations.
[^] # Re: bon ben c' est simple....
Posté par Troy McClure (site web personnel) . Évalué à 3.
beurk beurk les iostream et dérivés pour moi c'est qu'il y a de plus moisi dans la lib stdc++ , tant qu'a faire autant reconstruire un truc clair et extensible à partir de la stdlib
[^] # Re: bon ben c' est simple....
Posté par benoar . Évalué à 7.
Le truc, c'est que le temps machine, ça ne coûte quasiment rien, mais le temps humain, beaucoup plus.
Ca fait pas mal de temps il me semble que cette remarque t'es faites, et tu n'as jamais voulu séparer quoi que ce soit. Regarde ce que ça donne aujourd'hui : 30000 lignes, et de la répétition de code à gogo !
C'est clair que ce serait un travail colossal de tout "réorganiser". Et c'est aussi le genre de truc bien chiant à faire ; en tous cas, je pense que tu t'amuses plus à coder tes algos.
Mais là, je ne sais pas si on peut encore faire quelque chose. J'ai voulu me dire "allez, je vais jeter un oeil voir si on peut pas faire quelque chose" : et bien non, impossible, et pourtant je m'attendais déjà à du lourd. Mais là c'est trop.
C'est clair que c'est un projet personnel, et jamais rien ni personne ne pourra rien y faire. C'est ton joujou, d'un côté ça doit être vachement sympa d'avoir un joujou comme ça. Mais sache que jamais personne ne pourra y contribuer, et que si un jour tu te désintéresses de ce joujou, je pense que personne n'osera y toucher. Ça restera un bout de code immutable dans un coin.
Tes justifications techniques sont parfois recevables, mais des fois ... franchement, copier/coller des fonctions pour les faire de 1 à n paramètres, c'est dégueu. Tu va me dire que c'est pour des raison de perf peut-être (plutôt que d'utiliser un tableau), mais je vais me répéter : le temps machine ce n'est rien par rapport au temps que devra passer quelqu'un ne serait-ce que pour en comprendre 1% (soit déjà 300 lignes, que tu compresses bien en plus !).
Forcément, tout ce boulot ne changera rien pour toi, qui connait déjà bien ton programme, et te fera personnellement perdre plus de temps qu'autre chose. Mais déjà, ça peut-être intéressant de faire de l'architecture, et ensuite ça pourra permettre à des gens de contribuer ! Mais oui, ça reste tâche à but purement altruiste.
Enfin, franchement, beaucoup des tes contraintes techniques sont résolvables avec un compilo moderne (c'est peut-être ça l'autre contrainte : que ça tourne avec VC++ 6 ...) : regarde boost, je te jure que c'est franchement du grand art. Et j'espère que tu pourras trouver cela intéressant.
Bon, tu pourras prendre ce commentaire comme une critique de plus, mais vraiment, je pense que beaucoup de ces critiques voudraient être constructives. Mais peu de personnes y peuvent sans volonté de ta part. Je veux bien essayer de t'aider, comme d'autres personnes je pense : je ne suis pas un pro du C++ mais j'ai déjà fréquenté les sources de pas mal de projets libres sur des plateformes différentes pour avoir quelques notions de modularité, portabilité et "propreté".
[^] # Re: bon ben c' est simple....
Posté par Troy McClure (site web personnel) . Évalué à 6.
c'est justement le probleme de boost, ils se regardent un peu trop le nombril à faire de l'art à grand coup de surcharge de l'operateur virgule et de meta-meta-programmation via le preprocesseur. Y'a des fois où il vaut mieux avoir 50 lignes un peu similaires, un peu "copié-collées" mais totalement explicites plutot que 10 lignes que seuls quelques élus peuvent comprendre, et qui vont declencher une artillerie monstrueuse qui va mettre ton quad-core et ton compilo à genous pour peniblement arriver au même resultat
[^] # Re: bon ben c' est simple....
Posté par Sebastien (site web personnel) . Évalué à 5.
En même temps, de ce qu'on en lit plus loin, le sus-dit code de 50 lignes copiées/collées fait aussi planter un PC moderne et décent, donc l'argument est un peu caduque pour le coups.
Et je pense qu'un copier/coller, c'est une erreur qui attends son heure. Parce que la moindre modification par la suite coûte autant que le nombre de copie. Si le code de 10 lignes est abscon mais unique, s'il est documenté, cela rendra la vie au final plus simple que 5 ou 10 répétitions d'une même chose.
[^] # Re: bon ben c' est simple....
Posté par David Tschumperlé (site web personnel) . Évalué à 2.
Les fonctions sont factorisées dans la plupart des cas.
Ton argument sur le plantage de PC est un peu pitoyable, je vois pas le rapport.
La compilation met du temps car il y a *énormement* de fonctions à compiler dans un même module, du fait de l'instanciation des fonctions templates pour beaucoup de types différents. Ca n'a rien à voir avec la conception de la bibliothèque en soi.
Trouve moi du code copier/coller que je peux factoriser dans CImg, je me ferais un plaisir de le faire.
[^] # Re: bon ben c' est simple....
Posté par Sebastien (site web personnel) . Évalué à 1.
Oh, je ne faisais que répondre "en général" par rapport au précédent contributeur.
Ton argument sur le plantage de PC est un peu pitoyable, je vois pas le rapport.
Le rapport, c'est qu'entre un code complexe (à la création, pas à l'utilisation sinon ça ne sert à rien) mais réduit, qui fait planter le PC de compilation et le code non maintenable car ne comportant que des répétitions triviales, qui fait planter le PC de compilation, je préfére le premier (dans la mesure où celui-ci n'est pas juste fait pour obscurcir la résolution problème). Mais pareil, c'est "en général" sur la maintenance de code.
D'ailleurs, J'avoue, jusqu'à présent, je n'avais pas regardé le code de CImg et au départ, au vu de la conversation, je croyais que ce n'était qu'une grosse collection de templates. Et depuis, j'ai vu les 436 macros, les quelques 2000 lignes qu'elles comptent et je préfére me marrer dans mon coin, s'il me l'est permis. D'ailleurs, il y a des petits trucs qui me font plus marrer que d'autres, mais ça fait longtemps que j'ai pas fait de C++ et j'avoue ne rien connaître au traitement d'images, donc pour l'instant je préfére me taire.
:)
[^] # Re: bon ben c' est simple....
Posté par David Tschumperlé (site web personnel) . Évalué à 3.
Peut-être qu'après tu prendras *vraiment* le temps de regarder comment c'est fait ou tu feras un effort pour comprendre.
[^] # Re: bon ben c' est simple....
Posté par Thomas Douillard . Évalué à 2.
À priori, histoire d'être cohérent, autant tout faire en template non ?
[^] # Re: bon ben c' est simple....
Posté par David Tschumperlé (site web personnel) . Évalué à 2.
Tu pourrais faire la même chose en définissant des itérateurs.
Les macros dans CImg ne servent à rien d'autre qu'à faire des boucles en évitant les itérateurs (elles commencent toutes par 'for(' si tu regardes bien).
Le truc, c'est que si tu utilises des itérateurs pas trop compliqués à programmer (je l'ai testé), le code généré n'est pas aussi optimal que celui généré avec les gros for.
Je pense que l'on peut faire en sorte d'avoir quelque chose d'équivalent en terme de performance avec des itérateurs, mais alors ca va demander de programmer des itérateurs relativement compliqués. Donc du coup, tu gagnes pas grand chose, ni en performance, ni en taille de code, avec des itérateurs.
Et comme en traitement d'images, les algos ont souvent besoin de boucler un grand nombre de fois sur les images, c'est assez critique d'avoir des boucles rapides. Donc j'ai laissé les macros pour ce faire.
Par exemple, tu peux regarder la macro 'cimg_for3x3()' qui parcourt une image en maintenant à chaque instant le voisinage 3x3 de la position courante. Hé bien, cette boucle est extrèmement rapide, comparée à tous les tests que j'ai pu faire avec des itérateurs. La raison, à mon avis, c'est que je ne relis pas mon voisinage 3x3 à chaque instant, mais je le décale vers la gauche, donc si par chance, les valeurs de ce voisinage sont mis dans des registres, ca fait juste des move de valeurs de registre à registre, et çà ca fonce, comparé à une lecture en mémoire.
Ces macros là, elles permettent d'écrire non seulement du code court, pour l'utilisateur, mais en plus, elles sont rapides à executer.
[^] # Re: bon ben c' est simple....
Posté par Cédric Chevalier (site web personnel) . Évalué à 0.
As-tu envisagé d'utiliser des accélérateurs matériels pour tes calculs ? du genre du Cell ou GPU ? (en simple précision on peut sortir jusqu'au Tflops maintenant avec une carte ...)
As-tu envisagé une parallélisation de ton application ?
Sinon, je ne suis pas spécialiste du domaine, mais la description de tes parcours et des listes de voisins me rappelle pas mal les algos de matrices, donc as-tu essayé d'utiliser des bibliothéques optimisées de calcul matriciel comme les BLAS ? (et là ça exploitera la superscalarité, et ça sera réellement optimisé pour ta machine).
[^] # Re: bon ben c' est simple....
Posté par olgk . Évalué à 2.
Evidemment, il y a tout une gamme de finasseries, entre un processeur où il faut activer tel ou tel comportement de prefetch dans le BIOS et un 970 qui gérait jusqu'à 8 flux de prefetch en détection hardware. On peut aussi évidemment hinter un peu ce qu'on va faire. Y'a de quoi faire du brutal.
[^] # Re: bon ben c' est simple....
Posté par David Tschumperlé (site web personnel) . Évalué à 2.
[^] # Re: bon ben c' est simple....
Posté par David Tschumperlé (site web personnel) . Évalué à 5.
Boost, je connais. C'est peut-être du grand art de conception C++, mais c'est pas super sympa à *utiliser* (je parle en particulier de GIL, la bibliothèque image de Adobe incluse dans Boost). Franchement *pour l'utilisateur* qui n'est pas un pro du C++, c'est du n'importe quoi. Est-ce que les gens d'Adobe responsables de GIL ont déjà pensé que les traiteurs d'images sont pas tous des programmeurs chevronnés en C++ ? Bah non jamais, je pense, car les mecs derrière GIL ce sont des bons gros programmeurs qui se font plaisir aussi de leur côté, mais franchement...
Quand on fait une bibliothèque, le minimum est de d'abord penser à *l'utilisateur* et de lui simplifier la tâche d'utilisation. Quand je vois çà (tiré de http://stlab.adobe.com/gil/html/giltutorial.html#ExampleSec ), je me dis que personne qui fait du traitement d'images n'a envie décrire çà pour calculer un gradient (et là ca le fait juste en 'x', c'est pour te dire :)
template <typename SrcView, typename DstView>
void x_gradient(const SrcView& src, const DstView& dst) {
gil_function_requires<ImageViewConcept >();
gil_function_requires<MutableImageViewConcept >();
gil_function_requires<ColorSpacesCompatibleConcept<
typename color_space_type::type,
typename color_space_type::type> >();
for (int y=0; y<src.height(); ++y) {
typename SrcView::x_iterator src_it = src.row_begin(y);
typename DstView::x_iterator dst_it = dst.row_begin(y);
for (int x=1; x<src.width()-1; ++x)
for (int c=0; c<num_channels::value; ++c)
dst_it[x][c] = (src_it[x-1][c]- src_it[x+1][c])/2;
}
}
Alors c'est peut-être du grand art, y a des beaux itérateurs, des beaux traits, tout ce que tu veux, mais pour l'utilisateur ça *suxx*. Je comprend qu'un traiteur d'images n'ait pas envie d'utiliser du C++ quand on voit çà. Avec CImg, tu peux écrire un gradient en 5 lignes, qui marche pour le cas général des images 3D multi-spectrales.
Alors moi je maintiens que le code même de CImg est peut-être ardu à aborder, mais que l'utilisation de CImg, c'est que du bonheur. Boost, ca fait peut-être bander les programmeurs, mais ca fait fuir les utilisateurs.
Je préfère la première solution pour ma part.
David.
[^] # Re: bon ben c' est simple....
Posté par benoar . Évalué à 6.
Là, je suis sur le cul. Je croyais que c'était un outil entièrement développé par toi, je ne savais pas que des gens avaient réussi à contribuer ... Bon bah bravo.
Que le code te plaise pas, soit, mais en aucun cas ton avis perso est un critère de qualité objectif de code, excuse moi de te le dire.
Heu, je sais que certains critères sont subjectifs, mais là des fois, tu cumules. Franchement, rien qui si tu pouvais juste le séparer en plusieurs .h, ça aèrerait quand même un peu ... (sans rien changer à la structure, hein)
Boost, je connais. C'est peut-être du grand art de conception C++, mais c'est pas super sympa à *utiliser* (je parle en particulier de GIL, la bibliothèque image de Adobe incluse dans Boost). Franchement *pour l'utilisateur* qui n'est pas un pro du C++, c'est du n'importe quoi. Est-ce que les gens d'Adobe responsables de GIL ont déjà pensé que les traiteurs d'images sont pas tous des programmeurs chevronnés en C++ ? Bah non jamais, je pense, car les mecs derrière GIL ce sont des bons gros programmeurs qui se font plaisir aussi de leur côté, mais franchement...
Je suis d'accord que la lisibilité du code est importante, et qu'il faut qu'il soit accessible au programmeur lambda. Mais déjà, assimiler ton code, je ne pense pas que n'importe quel utilisateur lambda pourrait le faire !
Quant à l'exemple que tu donnes .... bah moi je le trouve super lisible. D'un côté, templeet t'as bouffé la moitié du code donc c'est illisible dans ton commentaire, mais pour ceux qui veulent aller voir sur le lien que tu donnes ...
C'est limite si ça se lit pas comme de l'anglais : on prend une image source immutable, une destination mutable, qui doivent avoir un espace de couleur compatible. Ensuite, on itère sur chaque ligne, puise sur chaque pixel de la ligne, en faisant une simple interpolation ... Je ne vois pas ce qu'il y a de compliqué. Et en plus, comme le tiens, ça marche pour tous les cas et toutes les dimensions.
Bon OK, chacun aura un avis différent la dessus, et effectivement j'ai sûrement un avis biasé. Mais tant mieux si tu as des contributions. J'espère sincèrement que d'autres gens seront motivés pour bosser sur ton projet !
[^] # Re: bon ben c' est simple....
Posté par Tonton Benoit . Évalué à 5.
Ça a complètement bloqué mon PC (P4, 1go de ram) à la compil, j'ai du couper l'alim (même les sysRq ne marchais plus) et du coup j'ai planté ma partition principale avec le système dessus (heureusement j'ai un deuxième système avec KDE4 sur une autre partition qui n'a pas été corrompu).
Remarque j'aurai pu attendre aussi qu'il finisse de remplir la swap et que le noyau tue la compil mais avec 1go de swap ça aurait pu prendre des heures.
Donc :
- J'allais faire un ebuild mais j'ai peur que si je propose ça on m'accuse d'essayer de planter les PC des Gentooistes (en plus vu que ça plante chez moi impossible de tester)
- Je remettais toujours a plus tard mon passage a KDE4, mais du coup je suis obligé d'y passer donc merci :D
[^] # Re: bon ben c' est simple....
Posté par David Tschumperlé (site web personnel) . Évalué à 1.
et ca met environ 9-10 minutes, toutes options et optimisations activées, donc tu m'étonnes, je crois pas être tellement loin de ta config (à part le Gb de RAM supp :) )
J'ai rajouté dans la rubrique download des versions précompilées pour Linux, avec ou sans utilisation des bibliothèques externes. Pour ceux qui veulent tester...
David.
[^] # Re: bon ben c' est simple....
Posté par Tonton Benoit . Évalué à 2.
Justement 1 go de moins, c'est surtout ça la différence, et Firefox de lancé aussi.
[^] # Re: bon ben c' est simple....
Posté par LucioBrun . Évalué à -1.
En effet le ClassLoader chargerait LA classe... Ainsi toutes tes méthodes serait forcément très optimisées car toutes en mémoire et la JVM optimiserait ton code au fur et à mesure de son utilisation.
De plus, ça utiliserait à fond les registres de la machine virtuelle.
Il existe apparemment des programmes pour faire des Macro en Java.
En plus, ça se fonctionnerait sans soucis avec 4Go de RAM et un proc quadri-core.
Ainsi tu pourrais garder toute la modularité du code actuel
[^] # Re: bon ben c' est simple....
Posté par Victor . Évalué à 1.
# GREYC's Anatomy
Posté par Mouns (site web personnel) . Évalué à 6.
les bons points pour en faire une depeche sont :
- site interessant
- outils utile et fonctionnel
- besoin d'aide pour du port
- potentiellement besoin d'aide pour avoir des binding perl/python/ruby/php ...
[^] # Re: GREYC's Anatomy
Posté par David Tschumperlé (site web personnel) . Évalué à 3.
Le journal c'est surtout pour faire découvrir le truc et éventuellement voir si des gens sont potentiellement intéressés si ils ont des retours de compilation/utilisation/etc..
Si vous pensez que ca vaut une dépêche, pourquoi pas, mais faudrait pas que ça pollue plus que ça intéresse !
David.
[^] # Re: GREYC's Anatomy
Posté par Mouns (site web personnel) . Évalué à 3.
Faire une dépêche de temps en temps sur ce que tu fais, augmentera la visibilité et les retours sur ton soft.
[^] # Re: GREYC's Anatomy
Posté par David Tschumperlé (site web personnel) . Évalué à 1.
David.
[^] # Re: GREYC's Anatomy
Posté par Psychofox (Mastodon) . Évalué à 3.
G'MIC me semble très intéressant pour un user courant de imagemagick comme moi, y'a (y'avait ?) pas mieux pour traiter des lots d'images...
À ce propos , c'est prévu des bindings pour nos langages favoris(ruby, python, perl...) ou vous comptez sur la communauté pour les sortir ?
[^] # Re: GREYC's Anatomy
Posté par David Tschumperlé (site web personnel) . Évalué à 1.
Pour les bindings, je sais pas trop, à priori ca serait plus pour CImg que pour G'MIC qui est un outil en soi, et pas une bibliothèque. C'est à réfléchir en tout cas.
[^] # Re: GREYC's Anatomy
Posté par David Tschumperlé (site web personnel) . Évalué à 1.
# Question
Posté par LucioBrun . Évalué à -1.
[^] # Re: Question
Posté par Cédric Chevalier (site web personnel) . Évalué à -1.
[^] # Re: Question
Posté par LucioBrun . Évalué à -1.
[^] # Re: Question
Posté par Octabrain . Évalué à -1.
[^] # Pour en finir avec CImg..
Posté par David Tschumperlé (site web personnel) . Évalué à 5.
CImg est un projet open-source qui a le mérite d'exister et d'évoluer, quoi qu'on en dise. Cette bibliothèque a même permis de faire des choses concrètes, comme G'MIC ou GREYCstoration
(voir aussi la section 'liens' sur le site : http://cimg.sourceforge.net/links.shtml )
La conception, j'en conviens, n'est pas "traditionnelle" (c'est grave docteur ?), elle peut déplaire à certains : dans ce cas, ne l'utilisez pas, c'est aussi simple que ça. Pour le traitement d'images, tournez vous vers GIL, VIGRA, Freeimage, openCV (la liste est longue, rien que pour le C++). Faites même du Java si vous voulez (avec l'excellent ImageJ). On peut pas dire que dans ce domaine, il n'y ait pas le choix en biliothèques libres !
Et surtout ne croyez pas que vous détenez la vérité absolue parce que vous avez un certain style de programmation, on peut-être curieux et ouvert à autre chose, sans être hautain. Faut juste accepter que les gens ne fassent pas tout pareil que vous, c'est pas très compliqué.
Pour ma part, j'ai bien entendu les critiques (j'avoue que je commence à les connaitre par coeur, depuis 7 ans c'est toujours les mêmes), et je pense que j'en entendrais d'autres. Ca m'empêchera pas de continuer le boulot, avec les autres joyeux contributeurs, ne serait-ce que par respect pour ceux qui ont confiance dans CImg, qui l'utilisent et qui veulent un minimum de support. Je peux discuter avec plaisir des choix techniques de CImg en face à face, mais par mail ou par forum, c'est vite limité. Si vous avez des vraies interrogations, n'hésitez pas à me contacter directement.
Une remarque finale : le nombre de contributeurs à CImg n'a fait qu'augmenter et ca a permit que la bibliothèque "converge" vers quelque chose de stable et cohérent. Et ça, c'est un vrai plaisir pour moi. Pour ceux là, merci, et continuons comme ça ! Les autres peuvent aller voir ailleurs, ça ne vexera personne.
Sur ce, je vais me coucher. Demain, je release G'MIC 0.4, avec une nouvelle feature intéressante : la possibilité de faire des options personnalisée avec un fichier de macros
(oui oui, j'adore les macros :)
Bonne nuit.
David.
[^] # Re: Pour en finir avec CImg..
Posté par Frédéric COIFFIER . Évalué à 8.
Effectivement, depuis pas mal de temps que tu postes des news sur LinuxFR, les mêmes critiques ressortent à chaque fois.
D'un autre côté les gens râlent que ce qui est fait dans les labos de recherche français (ce qui semble être le cas de CImg) reste dans ces mêmes labos au lieu d'être mis à la disposition du public. On pourrait au moins te remercier de mettre ça à notre disposition et pas juste en nous envoyant le lien du site FTP contenant un code source que personne ne peut compiler (comme on peut le voir quelques fois).
J'avoue que je n'ai jamais développé avec CImg mais je l'ai utilisé au travers de Gimp ou de Digikam. CImg fait parti de cette boîte à outils dont j'aurai peut-être un jour besoin pour un prototypage (je n'y connais pas grand chose en traitement d'image mais en ingénierie, on ne sait pas à l'avance ce que l'on peut être amené à faire !).
Bonne continuation !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.