Bref de quoi faire tout ce que tu dis beaucoup plus simplement, et surtout de manière plus éfficace étant donné qu'il n'y a pas à transférer les données d'un programme à l'autre.
Pour ma part, je ne suis pas sûr que je serais plus efficace en python qu'en macros G'MIC, comme tu le dis au début, chacun son point de vue et ses connaissances :)
Je peux te dire par contre qu'écrire un filtre en G'MIC peut se faire *très rapidement* si on connait un peu la syntaxe (j'ai du en écrire une dizaine rien que ce matin, en m'inspirant des filtres existants pour GIMP).
Par ailleurs, avec un collègue (que je salue) nous avons déjà travaillé sur l'intégration des fonctionnalités de G'MIC dans son logiciel de visu / traitement de volumes 3D : http://qvox.sourceforge.net (QVOX) et le transfert des données n'est clairement pas un problème pour les performances, étant donné que tout peux se faire en passant par des pipes (G'MIC peut lire et écrire des images en entrée et sortie standard). Et pourtant, dans notre cas, nous transférons des images voiumiques à valeurs flottantes, donc à priori des données beaucoup imposantes que les images 2D couleurs qu'on peut avoir dans GIMP.
Alors par rapport à G'MIC, j'ai peur que ca ne puisse pas t'être très utile, car G'MIC est conçu avant tout comme un logiciel de traitement plutôt que d'analyse d'images.
Dans ton problème particulier, tout dépend du type d'images et du type d'informations qui va caractériser tes disques : est-ce qu'ils ont une couleur particulière, et ce qu'ils peuvent être en perspective, est-ce qu'ils sont sur un fond fixe connu ? un fond uniforme ? une taille connue ? etc..
Suivant les critères que tu va définir pour caractériser tes objets, tu vas avoir besoin de méthodes plus ou moins compliquées pour récupérer leur position : du simple seuillage couleur, de la transformée de Hough circulaire (peut marcher pour les cercles collés en particulier), de la segmentation par contours actifs (ou régions actives), ou un mix de tout ça, avec la prise en compte de tous les a-priori que tu connais..
Je crois pas qu'on puisse dire qu'une méthode va mieux marcher qu'une autre tant que tu n'auras pas défini précisement ces a-priori là.
Je trouve le nouveau système très pratique, mais je me permets une petite remarque cependant : Dans les préférences, on peut maintenant choisir de ne pas afficher certains items en page d'accueil, avec certains items cochés et d'autres décochés.
C'est juste un petit peu piégeux, parce que un item coché ne va pas s'afficher alors qu'on a plutôt l'habitude d'avoir quelque chose en plus quand on coche une option de ce style. Pourquoi n'avoir pas mis juste une option afficher avec des items cochés ou décochés.
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.
[^] # 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é à 4.
Bref de quoi faire tout ce que tu dis beaucoup plus simplement, et surtout de manière plus éfficace étant donné qu'il n'y a pas à transférer les données d'un programme à l'autre.
Pour ma part, je ne suis pas sûr que je serais plus efficace en python qu'en macros G'MIC, comme tu le dis au début, chacun son point de vue et ses connaissances :)
Je peux te dire par contre qu'écrire un filtre en G'MIC peut se faire *très rapidement* si on connait un peu la syntaxe (j'ai du en écrire une dizaine rien que ce matin, en m'inspirant des filtres existants pour GIMP).
Par ailleurs, avec un collègue (que je salue) nous avons déjà travaillé sur l'intégration des fonctionnalités de G'MIC dans son logiciel de visu / traitement de volumes 3D : http://qvox.sourceforge.net (QVOX) et le transfert des données n'est clairement pas un problème pour les performances, étant donné que tout peux se faire en passant par des pipes (G'MIC peut lire et écrire des images en entrée et sortie standard). Et pourtant, dans notre cas, nous transférons des images voiumiques à valeurs flottantes, donc à priori des données beaucoup imposantes que les images 2D couleurs qu'on peut avoir dans GIMP.
David.
[^] # Re: Détecter des formes
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é à 4.
Dans ton problème particulier, tout dépend du type d'images et du type d'informations qui va caractériser tes disques : est-ce qu'ils ont une couleur particulière, et ce qu'ils peuvent être en perspective, est-ce qu'ils sont sur un fond fixe connu ? un fond uniforme ? une taille connue ? etc..
Suivant les critères que tu va définir pour caractériser tes objets, tu vas avoir besoin de méthodes plus ou moins compliquées pour récupérer leur position : du simple seuillage couleur, de la transformée de Hough circulaire (peut marcher pour les cercles collés en particulier), de la segmentation par contours actifs (ou régions actives), ou un mix de tout ça, avec la prise en compte de tous les a-priori que tu connais..
Je crois pas qu'on puisse dire qu'une méthode va mieux marcher qu'une autre tant que tu n'auras pas défini précisement ces a-priori là.
David.
[^] # Re: Rhaaa
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.
David.
[^] # Re: Une petite remarque
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche Évolutions sur LinuxFr. Évalué à 3.
# Une petite remarque
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche Évolutions sur LinuxFr. Évalué à 10.
C'est juste un petit peu piégeux, parce que un item coché ne va pas s'afficher alors qu'on a plutôt l'habitude d'avoir quelque chose en plus quand on coche une option de ce style. Pourquoi n'avoir pas mis juste une option afficher avec des items cochés ou décochés.
Voila, c'est tout, sinon c'est parfait pour moi.
David.
[^] # 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.