David Tschumperlé a écrit 337 commentaires

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 !

David.

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).

David.

Ou alors peut-être Aurélie Charon (l'enquêtrice..), ha oui bon faut vraiment que j'écoute alors je suis plus bien sûr..

D'après la fiche que j'ai vue ici : http://www.radiofrance.fr/franceinter/chro/espritcritique/in(...)

C'etait juste pour préciser à qui on a affaire...

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..

David.

Bah je suppose que c'est dépendant de la définition de la conversion RGB->XYZ.
Moi j'utilise celle décrite dans la FAQ Poynton :

http://www.poynton.com/ColorFAQ.html

Est-ce que c'est celle là que tu utilises aussi ?
C'est juste une fonction linéaire de RGB, et ca a tendance effectivement à booster la composante Y, donc quand on visualise sous forme RGB, ca donne une image verdatre
(la visu dans inrcast se fait toujours en utilisant RGB, même si la signification des canaux n'est pas du tout RGB).

Quand je fais :

inrcast image.jpg -rgb2xyz -xyz2rgb

je retrouve bien l'image initiale. Est-ce que tes valeurs sont bien sur 8 bits ? (mon RGB suppose des valeurs entre [0,255]).

David.

Bon alors comme j'ai eu quelques retours et demandes de fonctionnalités, j'ai sorti une version 0.2, qui contient quelques fonctionnalités en plus :

- Conversion entre espaces couleurs RGB,XYZ,Lab,HSL,HSI,HSV,YUV,YCbCr.
- Segmentation par croissance de région.
- Extraction d'isocourbe ou d'isosurface à partir d'une image 2D ou 3D et sauvegarde possible en objet 3D (format .off de Geomview).

C'est assez simple, CImg c'est une bibliothèque C++ pour le traitement d'images, et inrcast ou GREYCstoration sont deux logiciels utilisant cette bibliothèque !

Ha non il gère pas le 12 bits en output, il fait du 8 ou du 16.

J'imagine que tu pourrais utiliser plutôt çà qui te permettrait une grande variété de choix de fontes pour tes titres.

http://freetype.sourceforge.net/index2.html

CImg n'est pas vraiment spécialisé dans l'écriture de texte !
Par contre, si tu as des filtres divers et variés à appliquer sur une vidéo ca pourrait être plus dans ses cordes.

David.

Tiens du coup tu me fais découvrir aussi Kdenlive qui m'a l'air très sympa. Par contre je ne comprend pas bien ta question, de quelle génération temps réel parles-tu ?

Cela dit, tu peux très bien l'utiliser pour pré-générer disons 30000 captchas différents dans un sous répértoire du serveur, avec les fichiers textes 'solutions' correspondants, et ca te permet d'avoir une petite base suffisante de captchas pour une taille faible (les images sont assez petites).
J'imagine qu'avec un petit script qui va bien, tu peux faire qu'un captcha soit choisi aléatoirement à l'affichage de ta page.

Tu n'as pas tort sur certains points.
Je viens donc de faire une petite modif pour avoir des cercles d'épaisseurs quelconques et des dégradés de couleur dans les lettres.
Ca me semble un peu plus dur à analyser comme images.

Haaa.... Polytech'nice, ex-alias l'ESSI, ha que voila une bonne école, et agréable à vivre avec çà !
Je me rappelle que RMS était venu faire sa conférence à l'ESSI, en commencant par jouer du pipeau, ce qui avait eu un effet qui n'était peut-être pas celui escompté pour introduire un argumentaire sérieux...

Néanmoins, un rendez vous à ne pas manquer !

Bon ca y'est j'ai essayé de bidouiller un peu pour qu'on puisse lancer le nouveau mode dans le plug-in GIMP. Je n'ai pas réussi à faire d'onglets, mais j'ai pu ajouter de nouveaux sliders/boutons pour sélectionner le mode de débruitage . Ce n'est pas très beau mais ca a l'air de fonctionner. GTK est encore très obscur pour moi...
En attendant que le côté 'cosmétique' s'améliore, au moins il y a déjà la fonctionnalité ! J'ai mis l'archive à jour pour ceux que ca intéresse..

David.

Ha oui, justement tu devrais peut-être essayer d'utiliser la nouvelle méthode utilisant les patches, je pense que ca devrait mieux préserver
les détails et enlever la trame qu'avec l'ancienne.
L'exemple [4] avec le desert me donne des meilleurs résultats je trouve qu'avec les anciennes versions de GREYCstoration.
Je n'ai pas fait des millions de tests, mais ca pourrait être intéressant d'essayer (tu peux m'envoyer une image test pas mail si tu veux).

David.

Le problème c'est que ca prend quand même un temps non négligeable pour le calcul, et déjà pour une preview c'est quelquefois un peu long avec certains paramètres, donc avec deux previews en même temps, ca risque de ramer sévère...
Mais c'est une bonne idée dans l'absolu.

David.

Une petite vidéo pour bien se rendre compte de l'inutilité du truc :

http://fr.youtube.com/watch?v=BZmmbyNwStw&NR=1

D'un point de vue de mon employeur, je pense que CImg est une assez bonne chose : je passe pas mal de temps dessus en dehors de mon temps de travail, le CNRS et l'INRIA sont référencés sur les pages du projet. Tout le monde est content (pour le moment).

En ce qui concerne les mails d'insultes, je n'en ai pas recu des tonnes heureusement, mais ça provenait principalement de gens qui n'arrivaient pas à faire tourner le truc comme il voulait alors ça devait les enerver je suppose. Comme je répond pas, j'ai pas trop l'explication en fait ("bizarrement", je crois me rappeller que c'était principalement des Windowsiens, c'est çà de faire des libs multi-plateformes.. :) )

David.

Oui c'est une bonne remarque, en fait je suppose que c'est parce que les auteurs des differentes intégrations ont des visions différentes des paramètres..
Ce qui m'amène à me dire qu'il faudrait vraiment que j'écrive une doc complète sur le rôle et l'importance des paramètres.

David.

Tout à fait, d'ailleurs je vais essayer d'aider à le débugger dans Digikam cet après midi, pour bien finir la semaine !

David.

Pour le paramétrage, je pense qu'il faudrait effectuer une première analyse statistique (grossière) de l'image (genre estimation du niveau de bruit, type de bruit, etc...), qui tenterait de régler des paramètres 'optimaux'.
C'est un gros problème en soi, mais c'est une idée que j'aimerais creuser.. Mais pas pour tout de suite à mon avis !

L'ancienne version est utilisée dans Digikam.
GREYCstoration est codée en utilisant la bibliothèque CImg.

J'ai envoyé un mail à Gilles Caulier, j'espère pouvoir l'aider à intégrer la nouvelle version dans DigiKam.

David.

Mais qui a dit que la STL c'était un seul fichier ? C'est du grand n'importe quoi !
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 !

Je n'ai fait que répondre point par point à ton argumentaire, si tu trouves ca prétentieux, c'est bien dommage, j'essayais d'être constructif.
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.