Bonjour à tous.
J'ai une info et un appel à contribution à proposer ici.
L'info, c'est que la dernière version 1.1.8 de CImg est sortie vendredi dernier. CImg [1] est une bibliothèque libre C++ pour le traitement d'images génériques, simple à utiliser et multi-plateforme, distribuée sous licence CeCILL.
Le package contient de nombreux exemples d'utilisation (voir [2] pour quelques screenshots et videos en ligne), et en particulier l'algorithme GREYCstoration [3] qui permet de débruiter, inpainter et redimensionner des images. Cet algorithme est basé sur des recherches assez récentes sur les EDP de diffusion [3.5] que j'ai menées au laboratoire GREYC, UMR 6072 du CNRS, implanté à Caen.
Cet algorithme a été porté il y a de cela quelque temps par Victor Stinner dans un plug-in GIMP [4] pour le débruitage d'images. Or depuis ce premier portage (il y a presque 2 ans maintenant), GREYCstoration (l'algorithme) a pas mal évolué, en particulier en terme de vitesse d'exécution (x3!) et de qualité de résultats. Victor m'a confirmé n'avoir plus le temps de s'occuper de ce plug-in, et son développement est donc gelé sur la toute première version de l'algo, ce que je trouve vraiment dommage !
J'ai bien essayé de me plonger un peu dans le code de Victor pour essayer de mettre à jour l'algo, mais j'avoue que la programmation de plug-in et autres GUI n'est absolument pas dans mon domaine de compétences, en plus d'avoir très peu de temps pour cela.
Par contre, j'ai créé une extension pour CImg, qui permet de faciliter l'intégration de GREYCstoration dans des applis tierces. Un exemple d'utilisation minimal [5] permet de se rendre compte de la simplicité d'utilisation.
La situation est donc la suivante :
- Il y a un plug-in GIMP déjà fonctionnel, mais pas très récent, contenant la GUI + le code de l'algorithme de débruitage (l'ancien, ré-organisé dans sa structure par Victor).
- Il y a une extension GREYCstoration de CImg pouvant être appelé simplement de n'importe quel programme C++ externe (un simple include et un appel à une méthode). Cette extension est à priori assurée d'être toujours à jour (c'est moi qui la maintient).
Ma question est donc :
Y-aurait-il quelqu'un(e) interessé(e) pour essayer de recoller ces deux bouts, afin de fournir un plug-in GREYCstoration pour GIMP qui pourrait se mettre facilement à jour en mettant simplement à jour CImg et en recompilant le plug-in ? En gros, il faudrait enlever le code de l'algo dans l'ancien plug-in, et interfacer avec l'extension GREYCstoration de CImg à la place. A noter que l'extension est prévue pour fonctionner de manière multi-threadé et renvoit notamment une indication sur l'état d'avancement du processus. Je ne pense pas que ca soit particulièrement compliqué mais faut mettre les doigts dans le cambouis de GIMP un peu quand même (si j'avais 10 ans de moins... :) ).
Voila, j'espère que ca interessera quelqu'un ! Je pense vraiment qu'avoir une méthode libre de débruitage d'images performante et customisable pour GIMP serait un super truc, avec une bonne visibilité. Si ca vous tente, contactez moi (e-mail boulot) je suis bien sûr prêt à donner un coup de main pour que ca avance au plus vite.
Merci de votre attention.
David.
--------- Références ------------
[1] CImg : http://cimg.sourceforge.net
[2] CImg Screenshots : http://cimg.sourceforge.net/screenshots.shtml
[3] GREYCstoration : http://www.greyc.ensicaen.fr/~dtschump/greycstoration/demons(...)
[3.5] GREYCstoration, le principe :
http://www.greyc.ensicaen.fr/~dtschump/data/ijcv2006.pdf
[4] Port de GREYCstoration pour GIMP : http://linuxfr.org/~haypo/17437.html
[5] Code source pour utiliser l'extension GREYCstoration de CImg : http://cimg.cvs.sourceforge.net/cimg/CImg/examples/greycstor(...)
# Hum..
Posté par liberforce (site web personnel) . Évalué à 10.
[^] # Re: Hum..
Posté par gaston1024 . Évalué à 7.
La comparaison d'ailleurs avec de bons logiciels propriétaires tenait largement la route.
Si l'algo a fait du chemin, il serait réellement dommage qu'il reste dans les cartons (ou dans les publications) de David. C'est un outil adapté et utilisable facilement pour de nombreuses tâches (et même en "production"...)
Jetez un oeil sur les videos et copies d'écran de l'ensemble de la bibliothèque CImg, c'est assez bluffant.
La recherche fondamentale publique en France est capable de choses magnifiques... qui resteront inconnues si personne ne s'en sert !
Merci à David et merci à ceux qui feront de son travail un outil utilisable pour tous.
# S'adresser aux devs de GIMP ?
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: S'adresser aux devs de GIMP ?
Posté par David Tschumperlé (site web personnel) . Évalué à 2.
Peut-être peut-il confirmer.. Mais effectivement, c'est dommage.
David.
[^] # Re: S'adresser aux devs de GIMP ?
Posté par GCN (site web personnel) . Évalué à 2.
J'imagine que la position des dév. de GIMP n'a pas évolué depuis.
[^] # Re: S'adresser aux devs de GIMP ?
Posté par halt . Évalué à 6.
GIMP non plus.
Pour moi, GIMP est LA déception des logiciels libres: en 2000, il pouvait concurrencer partiellement Photoshop 5.5 avec sa version 1.17. aujourd'hui, Gimp est quasiment le même.
Quelques bug corrigés, une gestion des images lourdes un peu meilleures mais aucune révolution. Pas de gestion du CMJK, des images 16bits, des méta-données IPTC.
David, as-tu contacté les développeurs de Krita qui peut-être sauront reconnaitre la qualité de ton algorithme.
[^] # Re: S'adresser aux devs de GIMP ?
Posté par Christophe Chailloleau-Leclerc . Évalué à 1.
[^] # Re: S'adresser aux devs de GIMP ?
Posté par soulflyb (Mastodon) . Évalué à 3.
GEGL (Generic Graphics Library) is a graph based image processing framework.
GEGLs original design was made to scratch GIMPs itches for a new compositing and processing core. This core is being designed to have minimal dependencies. and a simple well defined API.
Ce qui n'enlève rien aux propos du commentaire précédent le précédent (vous suivez ? ;) ;) ), Gimp a très peu évolué depuis, en gros, Gimp 2 ....
[^] # Re: S'adresser aux devs de GIMP ?
Posté par Edouard Gomez (site web personnel) . Évalué à 2.
Par contre, ce qui peut être fait, c'est de coder une glue C->C++ sur laquelle se baserait le plugin. Dans ce cas, le projet Gimp+plugin greycstoration serait 100% C, il aurait une chance d'etre revu et accepté. Par contre il faudrait, j'imagine, que cette glue C->C++ soit maintenue Upstream (David quoi :-)) sinon on se retrouve dans le cas où Gimp dépend de C++.
Un autre projet fait ce genre de chose. Il s'agit de libopenraw, Hugue Figuiere n'est pas pour un retour au C, il lui prefere le C++ pour ce projet. Par contre conscient que le C++ pose trop souvent des problemes d'ABI, il a codé une API C qui fait le pont entre le C++ et le C.
# Krita
Posté par Seazor . Évalué à 2.
http://dot.kde.org/1112424719/1112455063/1112456663/
http://docs.kde.org/stable/en/koffice/krita/commands-dialogs(...)
Est-ce que qqun sait si la situation est mieux suivie ?
Sinon, comme il y a une conférence sur krita au fosdem, j'en soufflerai 2 mots à cette occasion :-)
[^] # Re: Krita
Posté par David Tschumperlé (site web personnel) . Évalué à 3.
En faisant l'extension à GREYCstoration ,j'avais justement dans l'idée de centraliser l'utilisation de l'algo GREYCstoration pour pouvoir proposer des mises à jours simples aux développeurs sans qu'ils aient besoin de répercuter beaucoup de modifs sur leur propre code.
David.
# Krita et digikam
Posté par soulflyb (Mastodon) . Évalué à 2.
Concernant Krita, j'ai vu qu'il était toujours dans l'arborescence svn, mais pas moyen de trouver une info sur sa mise à jour (je ne risque pas d'y comprendre grand chose !), d'où ma question.
Merci.
# Une vraie bibliothèque.....
Posté par GuieA_7 (site web personnel) . Évalué à 0.
- personne au monde ne fait comme ça (parmi les personnes qui codent bien en tout cas...) ; c'est quand même un indice.
- si le packager pour le plug-in gimp l'a dit, que les dev krita préfèrent partir du code du plug-in Gimp, c'est peut-être un autre indice.
- les dev ne sont pas des imbéciles ; s'ils n'arrivent pas à gérer 3 .cpp qui se courent après, ils peuvent arrêter de coder....
Si ton code était bien séparé entre .h et .cpp, qu'on puisse obtenir une vraie bibliothèque, ça changerait surement des choses (et si comble du bonheur, il y avait en plus une interface en pur C, ça ouvrirait encore d'autres horizons -- même si SWIG gère aussi le C++) : un vrai paquet dans les distribs, des bindings vers d'autres langages (python etc...), un développement pour des plug-in facilité...
Enfin bon, je m'emporte, et je ne t'ai même pas félicité pour ton algo excellent ; mais je trouve dommage qu'il soit si mal mis en valeur.
[^] # Re: Une vraie bibliothèque.....
Posté par David Tschumperlé (site web personnel) . Évalué à 7.
Tu sais, j'ai pas mal discuté de çà avec Victor, et effectivement nous n'étions pas d'accord sur certains points. Je ne vais pas recommencer la discussion avec toi en profondeur, car ca risquerait d'être trop long.
Cela dit, tu t'emportes mais tu me parais bien prétentieux ! Pourquoi tu aurais toi la connaissance absolue de la façon de bien programmer ? Tu parles ici d'un sujet qu'apparemment tu ne maitrises pas : le C++ et ses spécificités, notamment la programmation générique à base de templates.
- Tu parles de séparation en .h et .cpp, c'est effectivement une technique assez classique mais dès lors que l'on parle de bibliothèque C++ générique utilisant à fond les templates, cette règle est généralement moins évidente, notamment quand le type des classes n'est connu qu'à la compilation (exactement comme quand on utilise la STL, qui est comme chacun sait, une bibliothèque faite avec les pieds par des débutants en programmation). Je peux te citer d'autres exemples. C'est un fait, la programmation générique utilisant des templates est un concept fort du C++ qui est assez particulier et qu'il faut prendre en compte.
- La plupart des classes du .h de CImg sont extrêmement bien séparées, et on peut tout à fait compiler la bibliothèque sans utiliser de display ou autres bibliothèques optionnelles. Ne t'arrête pas aux 50 premières lignes qui effectivement contiennent des tableaux de données dont j'ai besoin pour certaines fonctions. Si tu as le temps essayer de regarder un peu plus loin, tu verras que c'est bien structuré et très facile à lire (ce n'est pas le nombre importants de contributions et de corrections de bugs que je recois régulièrement qui va me dire le contraire, comme si bizarrement les gens avaient moins peur d'aller débugger un code de fonction plus court et bien localisé qu'un code étalé sur 50 fichiers différents...)
- Pour finir, je vais peut-être t'étonner, mais il y a un bon paquet de gens qui utilise CImg justement parce que c'est simplissime au niveau des dépendances et ca leur rappelle un peu la STL. Va voir dans les forums, je peux te trouver des messages absolument contraires au tiens qui encense cette structure. Alors bien sûr il y a des défauts je ne le cache pas (notamment le temps de compilation quand on active l'optimisation), mais beaucoup de qualités aussi, notamment le fait de pouvoir écrire des codes très courts (va voir la longueur des codes sources exemples fournis dans le package).
Bref je ne cache pas que CImg est un peu original, et a été clairement élaboré pour la programmation C++ générique. Alors oui ca s'interface pas très bien avec le python, et la structure ne ressemble pas à la façon typique qu'on enseigne en école d'ingénieur mais si c'est ton seul critère pour juger la valeur d'une bibliothèque, permets moi de te dire que c'est un peu léger.
Pour finir, CImg a maintenant 7 ans d'existence, et crois moi, si cette structure avait posé problème, je pense que ca aurait été modifié depuis bien longtemps.
Je pense qu'au contraire, elle a pu évoluer relativement rapidement grâce à cette simplicité d'écriture et d'utilisation.
Alors moi aussi je m'emporte, mais faudrais arrêter de vouloir donner des leçons comme tu le fais quand manifestement tu n'as pas plongé ton nez plus de 5 minutes dans cette bibliothèque. A l'inverse quand je vois que des gens "reconnus" (adobe) proposent aujourd'hui des bibliothèques de traitement d'images soit disant C++ qui s'utilisent avec des structures comme ca :
http://opensource.adobe.com/gil/html/giltutorial.html#Images(...)
Des fois je me dis que c'est pas la peine de faire du C++.
David.
[^] # Re: Une vraie bibliothèque.....
Posté par David Tschumperlé (site web personnel) . Évalué à 2.
[^] # Re: Une vraie bibliothèque.....
Posté par Snark_Boojum . Évalué à 0.
En résumé : C++ c'est de la daube.
[^] # Re: Une vraie bibliothèque.....
Posté par left . Évalué à 6.
- Je ne vois pas en quoi mettre du code dans le '.h' te gênes, c'est d'ailleurs ce que font beaucoup de langages, qui ne font pas de distinction entre déclaration et définition (au hasard sh,eiffel,perl,java,list,ocaml,python,C#,etc.)
- Enfin c'est sur qu'en C, on va pas déclarer des templates dans un '.h' puisque ce langage n'implémente pas les templates (et passer par le préprocesseur pour faire du template-like ou caster du void*, c'est au moins aussi pourri).
En résumé: ton résumé est naze.
[^] # Re: Une vraie bibliothèque.....
Posté par Snark_Boojum . Évalué à 3.
Et non, renommer un .h en .c (ou .cpp, .cxx, .cc, etc) ne change rien : c'est toujours un fichier qu'il faut #includer pour l'utiliser plutôt que linker avec.
Techniquement, le problème est que le C++ n'est pas un pur langage à part, il est construit sur le C. Or un fichier objet C ne peut contenir que des implémentations. Un foo n'est pas implémenté, donc ne peut trouver sa place dans un .o. Voir la faq C++ pour les détails.
En résumé, mon résumé est correct : une lib avec template doit venir en .h, c'est normal.
Que certains ne soient pas d'accord avec mon opinion ferme sur le C++ est une autre histoire.
[^] # Re: Une vraie bibliothèque.....
Posté par lolop (site web personnel) . Évalué à 3.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Une vraie bibliothèque.....
Posté par GuieA_7 (site web personnel) . Évalué à 0.
Alors non je n'ai pas ton expérience en C++ c'est bien certain. Mais l'argument 'ça existe depuis des années' désolé mais bof bof. Le VB aussi ça existe depuis des années....
Ensuite oui je connais la STL et le principe des templates ; et bien elle n'est pas constituée d'un seul fichier tu m'excuseras. Donc non je n'ai pas la prétention de connaître la meilleure façon de faire , sinon je ne me remettrais pas en question tous les 3 jours. Et si je suis peut-être prétentieux (on est mauvais juge de soi-même), permets moi de te retourner le compliment.
Alors tu fais ce que tu veux, je n'ai droit de regard sur ton travail (je précise que toutes les remarques que j'ai faites je les ai faites sur des souvenirs de précédents journaux ; c'est parce l'air de rien je me suis intéressé à ton travail). Mes critiques se voulaient constructives c'est tout, mais ta 1ère liberté, c'est de ne pas les écouter.
Je ne peux que souhaiter qu'une bonne âme face le plug-in gimp. Voilà.
[^] # Re: Une vraie bibliothèque.....
Posté par David Tschumperlé (site web personnel) . Évalué à 0.
Après, le style employé à chaud est peut-être un peu aggressif, mais étant donné le ton de ton premier message, tu m'excuseras je pense d'avoir répondu de la sorte.
David.
[^] # Re: Une vraie bibliothèque.....
Posté par GuieA_7 (site web personnel) . Évalué à 1.
[ argument technique oublié dans la précipitation : sinon découper en plusieurs fichiers, ça pourrait aussi apporter en temps de compilation (mais si tu codes en C++ comme un bourrin, tu dois le savoir) ]
Sans rancune.
[^] # Re: Une vraie bibliothèque.....
Posté par abramov_MS . Évalué à 3.
Je sais pas si c'est possible, je ne connais pas bien la licence mais bon si c'st libre fait un fork et decoupe en petit morceau le fichier.
Ce genre de reaction (surtout la precedente) a de quoi degouter la moindre personne de faire un logiciel libre.
Moi je lui dis merci et c'est vrai que j'aimerai que ce soit inclu dans krita, digikam et gimp.
[^] # Re: Une vraie bibliothèque.....
Posté par GuieA_7 (site web personnel) . Évalué à 1.
Je ne le referai plus, c'est promis ; je n'émettrai à l'avenir plus que des commentaires dithyrambiques. C'est comme ça que les logiciels s'améliorent, en émettant _que_ des encouragements.
<mode sincèrement gentil>
Continue David, c'est du bon boulot.
</mode sincèrement gentil>
[et si David s'est senti agressé, j'en suis vraiment désolé, c'était vraiment pas mon intention. Il faut croire qu'écrire des commentaires quand on a passé une journée de merde c'est pas mon fort]
[^] # Re: Une vraie bibliothèque.....
Posté par Anonyme . Évalué à 0.
Si son français était correct, de manière à ce que l'on puisse la déchiffrer convenablement, cela ferait certainement plus professionnel et t'ouvrirait d'autres horizons.
Enfin bon, je dis ça, je dis rien.
[^] # Re: Une vraie bibliothèque.....
Posté par GuieA_7 (site web personnel) . Évalué à 0.
Mais MERCI de ta critique.
[^] # Re: Une vraie bibliothèque.....
Posté par Monsieur Flynn . Évalué à 1.
Parce que c'est moi qui est en grande partie cette plaquette dont le français ne te semble pas correct.
Alors je dois dire il est vrai, que je ne comprend pas vraiment l'intêret de ton argument sur les fautes de français de cette plaquette dans une discussion sur le fait qu'une librairie en un seul fichier, c'est hautement perfectible et la pire des décisions possible.
Mais soit, après tout, je n'ai pas la science infuse et peut-être que ton argument a sa place dans la discussion. (bien entendu je ne considère pas que le fait de me ridiculiser par pure mesquinerie , comme quand on était môme dans la cour de récré fasse qu'il est sa place ici, nous sommes au dessus de ces basses pratiques n'est ce pas ?)
Mais donc, j'aimerais bien, que par message privé, tu me fasse la liste des mes erreurs de français, que je me couche moins couillon et que je puisse les corriger.
Comme ça la prochaine fois que moi ou quelqu'un d'autre ayant un lien avec cette plaquette discutera technique, il n'aura pas comme argument le fait que je fasses des fautes de français.
Merci d'avance pour ton message privé.
[^] # Re: Une vraie bibliothèque.....
Posté par Monsieur Flynn . Évalué à 1.
Quelques petites remarques. Et comme je suis fatigué, je vais parler franchement.
Tout mettre en un seul fichier, c'est clairement une erreur de développement de débutant.
Un fichier de 10 000 lignes c'est illisible. Il n'y a pas besoin de plonger son nez 5 minutes, 3h ou 30 secondes. Je serais malpoli , je dirais que un seul fichier c'est pourri ou autre chose.
Puisqu'on parle de template, qui a dit qu'on devait découper obligatoirement découper les fichier en .h et .cpp ?
C'est donc interdit de découper en plusieurs .h ? un par classe par exemple
ou de faire des .h et des .hxx ( ou hpp ou inc ) les h ne faisant que déclarer les autres définir ?
Les gens sont suffisant indigents dans leur compréhension d'une librairie pour ne vouloir qu'un seul enorme include. bah un fichier include_all.h qui fait tout les include des petits fichiers et que les gens qui le veulent pourront inclure.
Bon après pour le reste des arguments, du style la tentative de dénigrement par le machin sur l'école d'ingé .. c'est risible.
A et pour que tout soit clair, on sait jamais hein, je bosse dans le même bureau que le monsieur à qui tu réponds.
Et pour que ca soit clair aussi de la programmation template C++ on en mange depuis quelques années, on en mange professionnellement depuis plus d'un an et c'est bien la première que je vois ça ...
et pourtant des trucs bizarres, j'en ai vu...
[^] # Re: Une vraie bibliothèque.....
Posté par Victor STINNER (site web personnel) . Évalué à 1.
La STL c'est loin d'être *un* fichier ! Pour commencer, chaque "composant" a son fichier :
Ensuite, quand on ouvre ces fichiers, on ne trouve que d'autres includes vers des fichiers (a) "bits/(...).h" et "bits/stl_(...).h" (ex: bits/basic_string.h) et des (b) "bits/(...).tcc".
Les fichiers (a) ne contiennent que les prototypes, et bien documenté comme il faut. Fichiers courts, synthétiques, facile à lire.
Les fichiers (b) contiennent l'implémentation, le code gruiiik que seuls les gourous arrivent à lire :-)
Il y a donc 4 profondeurs de découpage :
- par composant
- include global pour simplifier la vie
- prototype
- implémentation
----
Pourquoi découper prototype et implémentation ? Ben le fichier prototype sert de documentation.
Pourquoi découper par composant ? Ben parce que les fichiers de 13.000 lignes ça pue de fesses (*plouf*, désolé).
Victor
[^] # Re: Une vraie bibliothèque.....
Posté par David Tschumperlé (site web personnel) . Évalué à 2.
J'ai juste dis que c'était des .h, la dessus tu as l'air d'accord non ?
Après, si vous voulez séparer la lib en plusieurs .h, pas de problèmes, mais
comme les classes s'utilisent les unes dans les autres (ce qui n'est pas le cas de la STL), j'imagine aisément que la conséquence va être la suivante : tout les codes utilisant CImg vont commencer par :
#include "CImg_namespace.h"
#include "CImg_display.h"
#include "CImg_toto.h"
...
#include "CImg_globals.h"
#include "CImg_tutu.h"
à la place de #include "CImg.h".
Alors dis moi, dans ce cas, où est le gain sur la vitesse de compilation ? sur la performance ? Bah oui tiens en fait, non ca sert à rien !
Un grand merci pour ces conseils avisés !
Quand je vois le toto du dessus qui parle d'erreur de débutant, j'imagine qu'il ne se classe donc pas dans cette catégorie.. quelle blague !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.