GREYCstoration a tout un tas de paramètres qui permettent une grande flexibilité dans le type de restauration. En gros si tu pousses trop, ca bave et c'est complètement normal.
La force des logiciels commerciaux dans ce domaine, c'est simplement qu'ils ont des jeux de paramètres pour leurs algos qui sont super adaptés à tous les types d'appareil photos existant ou presque sur le marché. Ils se sont cassé les fesses pour faire çà mais c'est sur qu'une fois que c'est fait c'est super.
Ca fait maintenant un moment que je lance un appel pour ajouter des possiilités de "profils" dans GREYCstoration (vois la page principale, c'est écrit tout au début en vert pétant : http://cimg.sourceforge.net/greycstoration ). Perso je n'ai pas trop de temps pour faire çà, et surtout pas trop de compétences en GTK (ce qu'il faut pour faire une belle interface utilisable par tous pour selectionner ses profils, etc...).
Si tu sais faire, ou si tu connais quelqu'un qui sait faire et qui est motivé, ca m'intéresse plus que fortement. J'ai même proposé de faire ça dans le cadre de projets encadrés en école d'ingénieur, mais aucun élève n'a été intéressé et n'a choisi le sujet.
Le plug-in GREYCstoration, je l'admets, est loin d'être user-friendly, et l'interface est carrément à revoir. Mais je crois que les algos qui tourne derrière sont bons et sont pas du tout ridicules façe à la concurrence propriétaire. Ce qu'il manque à mon avis, c'est juste un peu de polish pour rendre ça plus facile à utiliser.
Je profite donc de ta critique pour relancer un appel aux volontaires éventuellement intéressés dans l'amélioration du plug-in. Le fichier source est très court, car l'algorithme lui-même fait partie de la lib CImg, et le code du plug-in ne s'occupe donc que de l'interface utilisateur (voir le source ici : http://cimg.cvs.sourceforge.net/cimg/CImg/examples/greycstor(...) )
Pour répondre plus précisement (je n'ai pas recu ton mail, excuse moi).
Je ne suis pas sûr que ta méthode marche forcément mieux, d'abord qu'est-ce qui se passe si la video contient des mouvements non rigides (genre vagues, etc..) ?
De même pour le problème ultra-classique des occlusions, tu vas certainement avoir des effects de ghost. Si tu as quelque chose qui tourne, ca m'intéresse pour comparer, mais clairement le problème du retiming n'est pas *simple*, ni même complètement résolu à l'heure actuel. J'avoue que j'ai un peu tiqué quand j'ai lu :
"Je pense que l'on peut faire assez simplement ce genre de chose :".
Si Stéphane Mallat (qui n'est pas connu pour être le dernier des imbéciles) a monté une boite Let It Wave qui s'occupe de ce genre de problèmes, c'est que ce ne sont pas des problèmes faciles. Enfin à ma connaissance, mais je me trompe peut-être.
Très intéressant ! Cependant il me semble quand même que le problème du retiming peut aussi se poser dans le cas de videos progressives (non-entrelacées), et dans ce cas, tu ne peux plus utiliser l'info temporelle que te donne l'entrelacement.
Alors c'est pas très souvent qu'on en rencontre de telles vidéos, mais est-ce que ce n'est pas censé devenir le futur standard pour la HD ?
Je n'ai pas une connaissance très claire des optimisations possibles, mais j'ai juste remarqué que mes boucles sur mes images allaient plus vite avec les macros que j'avais faites qu'avec les itérateurs équivalents (et pas qu'un peu) sur mon PC qui est tout ce qu'il y a de plus classique. Il y a surement moyen d'optimiser encore plus le code en s'adaptant au hardware, mais ce n'est pas mon but en soi. Le fait est que les itérateurs étaient moins rapide (et pas tellement plus jolis à *utiliser*), donc je ne les ai pas spécialement gardés. Rien n'empêche d'en faire pour ceux que ca amuse d'ailleurs.
Bon je voudrais faire une requête aux gens qui critiquent à tour de bras, et qui trouve que CImg c'est tellement comique que ça mérite des attentions particulières :
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 :)
Les macros dans CImg, c'est juste une facon un peu spéciale de faire des *boucles*.
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.
Je vois pas tellement de copier/coller dans CImg je tiens à le dire.
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.
Je dirais juste que c'est quand même bizarre, car je recois de plus en plus de contributions pour CImg qui ne sont pas triviales du tout, donc c'est que ça doit pas être si illisible que çà. 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.
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 :)
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.
* ImageMagick ne gère pas (à ma connaissance) complètement les formats d'images volumiques, G'MIC peut les lire, et les décomposer en série de coupes, par exemple. Pareil pour 'display' qui se limite aux images 2D. G'MIC peut visualiser des images volumiques 3D, on peut se balader dans les coupes, etc..
* ImageMagick ne gère pas (à ma connaissance) les formats d'images multi-spectrales avec un grand nombre de composantes (genre image ou chaque pixel est un vecteur de 256 composantes). G'MIC, si.
* En fait, chaque image G'MIC est en interne considérée comme une image volumique multi-spectrale à nombre de composante arbitraire, et de type arbitraire. Les images 2D couleurs en sont justes un cas particulier. Ca veut dire par exemple, que tu peux charger une images volumique 3D à 256 canaux, et faire un blur 3D ou une convolution 3D dessus, ca va marcher. La plupart des fonctions de G'MIC (toutes en fait..) marchent correctement sur les images volumiques multi-spectrales (et ont été programmée pour ce cas général là).
* ImageMagick ne gère pas de listes d'images de manière aussi flexible que G'MIC. Ici, tu peux charger deux images, décider de convoluer l'une avec l'autre, de les additionner, etc... Dans ImageMagick, tu as beaucoup d'opérations de manipulation, mais ça travaille plutôt image par image, sans tellement d'interaction possible entre les images.
* G'MIC semble avoir moins d'opérateurs, mais je dirais qu'il faut se méfier, car ce sont des opérateurs "de base'" qui peuvent s'enchainer pour donner des filtres complexes (voir la page web). Par exemple le '-solaris' de convert peut très bien être réalisé en enchainant plusieurs commandes G'MIC.
* G'MIC est 'typé', tu peux facilement convertir par exemple une image codée en 8 bits, en image 16 bits de même format, par exemple pour le ppm : gmic -t uchar input8.ppm -t ushort -o output16.ppm
* G'MIC sait extraire des caractéristiques 3D à partir des images, comme les isosurfaces ou les cartes d'élévations, et est capable de les visualiser. Je pense pas que ImageMagick sache faire çà.
Je dirais que ImageMagick c'est top pour les images 2D couleurs, mais dès que tu as plus de dimensions, c'est pas toujours possible de récupérer les infos que tu veux. G'MIC utilise en interne un format d'images très générique, qui permet plus de flexibilité de manip pour ce type d'images.
C'est lequel ton logiciel ? En ce qui me concerne, pour convertir une image quelconque dans un format que je sais relire facilement dans mes programmes, je préfère ne pas lancer une grosse interface graphique et avoir à trifouiller dans 3 ou 4 menus, alors qu'en une ligne de commande c'est fini. Alors en plus si je dois faire çà pour N images...
Pareil si j'ai envie de visualiser vite fait une image volumique par exemple, je vais avoir tendance à utiliser G'MIC justement plutôt que de lancer une grosse usine à gaz avec une interface.
Mais je pense que c'est juste une question d'habitude. Cela dit, ma modeste expérience me fait donc dire que quand même les outils de manip d'images en ligne de commande, c'est bien pratique !
G'MIC possède une interface simple de visualisation d'images. Il n'y a pas pleins de boutons partout, ca se pilote principalement au clavier et à la souris, mais c'est relativement efficace.
Travaillant également dans le domaine du traitement d'images, je me permets de ne pas être d'accord avec toi : les outils en ligne de commandes sont très utiles dans ce domaine.
Je ne compte pas le nombre de fois que j'ai utilisé 'convert' de ImageMagick dans des scripts divers et variés.
Pour ma part, je le compile sur un P4 3Ghz, 2Go de Ram avec g++ 4.2.3,
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...
* 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.
Bon là, je me permets de te répondre que tu racontes des âneries...
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.
Voila j'ai envoyé une dépêche..
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.
Bon à priori, je pensais que l'intérêt que pouvait porter le lecteur linuxfrisien (ça se dit?) à cet outil était assez limité puisque c'est quand même assez spécialisé dans le traitement d'images, et en plus c'est pas super user-friendly au premier abord (de la grosse ligne de commande). En plus le site est vraiment tout moche pour le moment.
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 !
Pour compiler, il y a un Makefile de fourni dans le repertoire 'gmic-0.2/src/'. En trifouillant dedans, on peut activer/désactiver des fonctionnalités qui nécéssitent des bibliothèques externes (libjpeg, libpng, etc...). Du coup, si on veut compiler avec le maximum de fonctionnalités (ce qui est fait par defaut), il faut pas mal de paquets *-dev pré-installés.
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).
Tu pourrais m'envoyer juste un exemple d'image en .j2c, pour voir ?
Si c'est du 12 bits je comprend que la conversion en RGB foire à priori, car cela ne va pas donner du 8 bits en sortie, il va falloir renormaliser quelque part (c'est possible à priori, il y a l'option '-val' qui fait çà).
Si tu peux m'envoyer une image ca m'interesse, car je ne connais pas trop ce format, c'est toujours bon d'avoir un exemple dans un coin pour voir ses particularités..
[^] # Re: Ca dépend...
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche Point sur deux logiciels de graphisme GIMP et Blender. Évalué à 10.
La force des logiciels commerciaux dans ce domaine, c'est simplement qu'ils ont des jeux de paramètres pour leurs algos qui sont super adaptés à tous les types d'appareil photos existant ou presque sur le marché. Ils se sont cassé les fesses pour faire çà mais c'est sur qu'une fois que c'est fait c'est super.
Ca fait maintenant un moment que je lance un appel pour ajouter des possiilités de "profils" dans GREYCstoration (vois la page principale, c'est écrit tout au début en vert pétant : http://cimg.sourceforge.net/greycstoration ). Perso je n'ai pas trop de temps pour faire çà, et surtout pas trop de compétences en GTK (ce qu'il faut pour faire une belle interface utilisable par tous pour selectionner ses profils, etc...).
Si tu sais faire, ou si tu connais quelqu'un qui sait faire et qui est motivé, ca m'intéresse plus que fortement. J'ai même proposé de faire ça dans le cadre de projets encadrés en école d'ingénieur, mais aucun élève n'a été intéressé et n'a choisi le sujet.
Le plug-in GREYCstoration, je l'admets, est loin d'être user-friendly, et l'interface est carrément à revoir. Mais je crois que les algos qui tourne derrière sont bons et sont pas du tout ridicules façe à la concurrence propriétaire. Ce qu'il manque à mon avis, c'est juste un peu de polish pour rendre ça plus facile à utiliser.
Je profite donc de ta critique pour relancer un appel aux volontaires éventuellement intéressés dans l'amélioration du plug-in. Le fichier source est très court, car l'algorithme lui-même fait partie de la lib CImg, et le code du plug-in ne s'occupe donc que de l'interface utilisateur (voir le source ici : http://cimg.cvs.sourceforge.net/cimg/CImg/examples/greycstor(...) )
Merci de votre aide potentielle :)
David.
[^] # Re: Conférence vidéo du collège de France
Posté par David Tschumperlé (site web personnel) . En réponse au journal 'Retiming' vidéo et logiciels libres. Évalué à 4.
Je ne suis pas sûr que ta méthode marche forcément mieux, d'abord qu'est-ce qui se passe si la video contient des mouvements non rigides (genre vagues, etc..) ?
De même pour le problème ultra-classique des occlusions, tu vas certainement avoir des effects de ghost. Si tu as quelque chose qui tourne, ca m'intéresse pour comparer, mais clairement le problème du retiming n'est pas *simple*, ni même complètement résolu à l'heure actuel. J'avoue que j'ai un peu tiqué quand j'ai lu :
"Je pense que l'on peut faire assez simplement ce genre de chose :".
Si Stéphane Mallat (qui n'est pas connu pour être le dernier des imbéciles) a monté une boite Let It Wave qui s'occupe de ce genre de problèmes, c'est que ce ne sont pas des problèmes faciles. Enfin à ma connaissance, mais je me trompe peut-être.
David.
[^] # Re: Conférence vidéo du collège de France
Posté par David Tschumperlé (site web personnel) . En réponse au journal 'Retiming' vidéo et logiciels libres. Évalué à 1.
(ha si en fait).
David.
[^] # Re: Conférence vidéo du collège de France
Posté par David Tschumperlé (site web personnel) . En réponse au journal 'Retiming' vidéo et logiciels libres. Évalué à 2.
David.
[^] # Re: Quelques idées...
Posté par David Tschumperlé (site web personnel) . En réponse au journal 'Retiming' vidéo et logiciels libres. Évalué à 2.
Alors c'est pas très souvent qu'on en rencontre de telles vidéos, mais est-ce que ce n'est pas censé devenir le futur standard pour la HD ?
David.
[^] # Re: bon ben c' est simple....
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. Évalué à 2.
[^] # Pour en finir avec CImg..
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. É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: bon ben c' est simple....
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. É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 David Tschumperlé (site web personnel) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. É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 David Tschumperlé (site web personnel) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. É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 David Tschumperlé (site web personnel) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. É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: vs imagemagick
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G'MIC : Un nouvel outil libre de manipulation d'images.. Évalué à 10.
* ImageMagick ne gère pas (à ma connaissance) complètement les formats d'images volumiques, G'MIC peut les lire, et les décomposer en série de coupes, par exemple. Pareil pour 'display' qui se limite aux images 2D. G'MIC peut visualiser des images volumiques 3D, on peut se balader dans les coupes, etc..
* ImageMagick ne gère pas (à ma connaissance) les formats d'images multi-spectrales avec un grand nombre de composantes (genre image ou chaque pixel est un vecteur de 256 composantes). G'MIC, si.
* En fait, chaque image G'MIC est en interne considérée comme une image volumique multi-spectrale à nombre de composante arbitraire, et de type arbitraire. Les images 2D couleurs en sont justes un cas particulier. Ca veut dire par exemple, que tu peux charger une images volumique 3D à 256 canaux, et faire un blur 3D ou une convolution 3D dessus, ca va marcher. La plupart des fonctions de G'MIC (toutes en fait..) marchent correctement sur les images volumiques multi-spectrales (et ont été programmée pour ce cas général là).
* ImageMagick ne gère pas de listes d'images de manière aussi flexible que G'MIC. Ici, tu peux charger deux images, décider de convoluer l'une avec l'autre, de les additionner, etc... Dans ImageMagick, tu as beaucoup d'opérations de manipulation, mais ça travaille plutôt image par image, sans tellement d'interaction possible entre les images.
* G'MIC semble avoir moins d'opérateurs, mais je dirais qu'il faut se méfier, car ce sont des opérateurs "de base'" qui peuvent s'enchainer pour donner des filtres complexes (voir la page web). Par exemple le '-solaris' de convert peut très bien être réalisé en enchainant plusieurs commandes G'MIC.
* G'MIC est 'typé', tu peux facilement convertir par exemple une image codée en 8 bits, en image 16 bits de même format, par exemple pour le ppm : gmic -t uchar input8.ppm -t ushort -o output16.ppm
* G'MIC sait extraire des caractéristiques 3D à partir des images, comme les isosurfaces ou les cartes d'élévations, et est capable de les visualiser. Je pense pas que ImageMagick sache faire çà.
Je dirais que ImageMagick c'est top pour les images 2D couleurs, mais dès que tu as plus de dimensions, c'est pas toujours possible de récupérer les infos que tu veux. G'MIC utilise en interne un format d'images très générique, qui permet plus de flexibilité de manip pour ce type d'images.
[^] # Re: Pas d'IG ?
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G'MIC : Un nouvel outil libre de manipulation d'images.. Évalué à 5.
Pareil si j'ai envie de visualiser vite fait une image volumique par exemple, je vais avoir tendance à utiliser G'MIC justement plutôt que de lancer une grosse usine à gaz avec une interface.
Mais je pense que c'est juste une question d'habitude. Cela dit, ma modeste expérience me fait donc dire que quand même les outils de manip d'images en ligne de commande, c'est bien pratique !
David.
[^] # Re: Pas d'IG ?
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G'MIC : Un nouvel outil libre de manipulation d'images.. Évalué à 6.
Travaillant également dans le domaine du traitement d'images, je me permets de ne pas être d'accord avec toi : les outils en ligne de commandes sont très utiles dans ce domaine.
Je ne compte pas le nombre de fois que j'ai utilisé 'convert' de ImageMagick dans des scripts divers et variés.
David.
[^] # Re: GREYC's Anatomy
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. Évalué à 1.
[^] # Re: bon ben c' est simple....
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. É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 David Tschumperlé (site web personnel) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. É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 David Tschumperlé (site web personnel) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. É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: GREYC's Anatomy
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. É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) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. Évalué à 1.
David.
[^] # Re: GREYC's Anatomy
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. É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: bon ben c' est simple....
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. É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: AC : Aurélie Charon
Posté par David Tschumperlé (site web personnel) . En réponse au journal Logiciel libre sur France Inter ?. Évalué à 4.
# AC : Albanel Christine
Posté par David Tschumperlé (site web personnel) . En réponse au journal Logiciel libre sur France Inter ?. Évalué à 6.
C'etait juste pour préciser à qui on a affaire...
[^] # Re: Version 0.2 disponible
Posté par David Tschumperlé (site web personnel) . En réponse au journal Inrcast : Un autre outil de manipulation d'images.. Évalué à 2.
Si c'est du 12 bits je comprend que la conversion en RGB foire à priori, car cela ne va pas donner du 8 bits en sortie, il va falloir renormaliser quelque part (c'est possible à priori, il y a l'option '-val' qui fait çà).
Si tu peux m'envoyer une image ca m'interesse, car je ne connais pas trop ce format, c'est toujours bon d'avoir un exemple dans un coin pour voir ses particularités..
David.