David Tschumperlé a écrit 337 commentaires

  • [^] # Re: Double

    Posté par  (site web personnel) . En réponse au journal CImg Library 1.0.7 et licence CeCILL. Évalué à 1.

    Quel en serait l'interet, sachant que l'on peut
    redistribuer du code CeCiLL en GPL assez facilement ?
  • [^] # Re: perf ?

    Posté par  (site web personnel) . En réponse au journal CImg Library 1.0.7 et licence CeCILL. Évalué à 1.

    Oui, pareil pour sun/solaris, il risquerait de pas aimer :)
    Cela dit, rien n'empeche de faire des bouts de code
    optimisés pour le bas niveau (je pense à l'affichage surtout)
    qui soit spécifiques à une certaine plateforme.
    C'est d'ailleurs ce qui est déjà fait dans la librairie CImg, pour l'affichage et la gestion des evenements (utilise X11 pour unix/max, et windows GDI pour win). A priori ca doit être transparent
    pour l'utilisateur final.

    Pour répondre à nicO, moi le C++ ca me permet surtout de
    faire des classes templates, après les bouts d'algo ils
    travaillent sur un buffer de données exactement comme je le
    faisais en C avant (d'ailleur la premiere version de CImg etait
    ecrite en C, et generait des fonctions génériques avec des macros
    à gogo). Je suppose que le passage en C++ ne m'a pas
    pénalisé de ce coté la (pas d'hiérarchie compliquée à gérer,
    pas des trucs de conceptions qui cacherait des bouts de code lents)
  • [^] # Re: perf ?

    Posté par  (site web personnel) . En réponse au journal CImg Library 1.0.7 et licence CeCILL. Évalué à 1.

    Je ne connais pas blast.
    Les performances de CImg ne sont surement pas "optimales",
    dans le sens ou aucune aide 'hardware' n'est utilisée (ni
    pour l'affichage, ni pour les calculs).
    Par contre, les algos sont relativements optimisés, ca permet
    quand même de faire des traitements rapides.
    C'est surtout au niveau de l'affichage je crois que il y aurait
    des progrès à faire en terme de rapidité.
  • [^] # Re: Excellent

    Posté par  (site web personnel) . En réponse au journal Restauration d'image au CNRS. Évalué à 2.

    Option '-o' pour sauvegarder le resultat :

    greycstoration -restore noisy.png -o restored.png
  • [^] # Re: R0X0R

    Posté par  (site web personnel) . En réponse au journal Restauration d'image au CNRS. Évalué à 6.

    C'est tout à fait ca, effectivement. On attend que la publication sorte,
    et à terme, je pense libérer les sources.
  • [^] # Re: Comparaison algo...

    Posté par  (site web personnel) . En réponse au journal Restauration d'image au CNRS. Évalué à 4.

    Le gros avantage de la méthode que tu décris est de prendre en compte la texture de l'image par recopie de blocs déjà existant.
    Notre méthode fait juste du lissage, et ne peut donc pas créer de textures à l'intérieur de zones à inpainter.
    En fait, on est pas très adapté pour l'inpainting, par rapport à ce qui
    existe maintenant (l'algo de Perez, mais aussi
    http://visgraph.cs.ust.hk/cktang/paper/cvpr2003/imgrep.html(...)
    par exemple), c'est pourquoi je n'insiste pas trop sur cet aspect.
    Je me concentre plutôt sur le débruitage et l'interpolation, qui à
    mon avis dont des problèmes mieux adaptés aux équations que
    l'on a proposé et implémenté.
  • [^] # Re: Dommage

    Posté par  (site web personnel) . En réponse au journal Restauration d'image au CNRS. Évalué à 7.

    Cela dit, c'est pas "algorythme" non plus....

    ALGORITHME. s.m. Terme didactique. L'art de calculer. L'Algorithme des entiers. L'Algorithme des fractions.
  • [^] # Re: Ca a l'air sympa mais...

    Posté par  (site web personnel) . En réponse au journal Restauration d'image au CNRS. Évalué à 7.

    Normalement, on peut desactiver la visualisation en mettant
    l'option '-visu 0' en argument de la ligne de commande.
    Par contre, je ne sais pas si ca ne va pas aller chercher la lib X quand meme, meme si aucune fonction X n'est appellée pendant le processus (je ne connais pas bien le mécanismes des libs dynamiques).
  • [^] # Re: Heu le C ?

    Posté par  (site web personnel) . En réponse au message Bien s'entourer en c, et plus si affinités. Évalué à -1.

    Heureusement qu'il y a des gens comme toi qui maitrisent parfaitement ce langage,
    et qui permettent a la communaute du libre d'avancer dans le bon sens avec du vrai
    beau code qui marche.
    C'est fantastique de t'avoir parmi nous, merci encore de ta presence.

    David.
  • [^] # Re: bibliothèque de traitement d'images plus simple ?

    Posté par  (site web personnel) . En réponse à la dépêche Quelques précisions sur la bibliothèque de traitement d'images 'INRIA'. Évalué à 2.

    Oui, CImg ne se veut pas un projet de la taille de ITK (je suis tout seul à travailler dessus !).
    Je pense néanmoins que c'est assez utile pour faire rapidement de petits prototypes fonctionnels, dans le milieu de la recherche ou de l'éducation.

    David.
  • [^] # Re: Heu ... qu'est ce que j'ai rate ?

    Posté par  (site web personnel) . En réponse à la dépêche Quelques précisions sur la bibliothèque de traitement d'images 'INRIA'. Évalué à 2.

    Il reste quelques bugs que je suis en train de corriger,
    mais normalement ton bug ne devrais pas se produire, car la fonction incriminée n'était pas appellée dans les programmes de test.
    Peut-être que ton compilo essaie de compiler les fonctions inline qui ne sont pas utilisées.
    Je suis en train de travailler sur la version 1.0.6, qui est sur CVS.
    Tu peux essayer de prendre la derniere version CVS pour voir si le probleme se corrige.

    Et les bugs, c'est bien de les signaler directement sur le forum du projet sourceforge (lien a partir de la page principale de CImg),
    ca permet d'avancer encore plus vite.

    Merci d'avance.
    David.
  • [^] # Re: Merci David !

    Posté par  (site web personnel) . En réponse à la dépêche Quelques précisions sur la bibliothèque de traitement d'images 'INRIA'. Évalué à 1.

    Pas pour le moment, mais si quelqu'un a une suggestion simple, sans passer par de libs supplémentaires que X11, je suis preneur du bout de code...

    David.