David Tschumperlé a écrit 337 commentaires

G'MIC également, particulièrement dans sa version "ligne de commande", permet de visualiser des données 1d (courbes), 2d (images) et 3d (volumes et/ou objets vectoriels). Il ne fait pas "que" de l'image, puisqu'il est également capable de faire de l'évaluation d'expressions et du calcul matriciel (inversion, résolution de systèmes linéaires, SVD, ..), tout ça à partir du shell. En ce qui me concerne, il a remplacé Matlab, au moins pour les calculs simples, et la visualisation de données.

En fait, je crois que ça lit aussi le .PPM. Je pense que Zonder voulait plutôt parler du 'PNM' qui inclut le PGM, le PPM et d'autres variantes (mais pas toutes supportées par PINK) : http://netpbm.sourceforge.net/doc/pnm.html

Après PINK a créé ses propres variantes (extensions) de formats PNM pour gérer le stockage des images volumiques par exemple. A ma connaissance, ce n'est relu que par PINK et G'MIC pour le moment.

Du coup, vous pouvez allez sur la référence de G'MIC pour voir des résultats d'opérateurs PINK :

http://gmic.sourceforge.net/reference.shtml#section41

Dommage en effet qu'ils ne donnent pas quelques screenshots de leurs opérateurs. C'est peut-être une suggestion intéressante à leur faire.

Pour le moment, seuls les fichiers multi-pages en formats TIFF sont gérés (en entrée seulement).
Le multi-page TIFF en sortie sera géré dans la prochaine version 1.4.9.0
(une première version 'testing' devrait apparaitre ce soir sur le site).

• Ce langage de script (pourquoi "pseudo" ?) a été pensé dès le départ pour optimiser l'écriture de pipelines d'opérateurs de traitements d'images, donc oui, il a une utilité dans le cadre de G'MIC : tu peux écrire des pipelines impliquant plusieurs images d'entrées et ou de sortie, et ce, de manière très concise, beaucoup plus qu'avec n'importe quel autres langage (lua inclus). Le but premier, c'est bien de permettre d'écrire des traitements relativement compliqués, à partir de la ligne de commande.

• Après, si on sort de ce cadre, le langage n'est pas forcément intéressant à utiliser en tant que tel, et je ne le conseillerais pas personnellement pour faire autre chose que de la conception de pipelines de traitement d'images (de même que je n'utiliserais probablement pas du Bash pour développer des gros algorithmes de calcul par exemple, même si c'est surement possible). Le but n'est surement pas de faire du "gros code" avec !

• De mon côté, j'ai essayé évidemment de "pousser" un peu le bouchon dans certaines commandes (par exemple -x_jawbreaker, -x_life, et la plupart des commandes interactives), pour voir jusqu'où on pouvait aller avec ce langage, aussi bien dans un but de curiosité, que de débuggage de l'interpréteur. Au final, on peut faire des choses assez amusantes avec. Et surtout, contrairement à la première impression, les bases du langages sont très simples et très logiques.

• Pour aborder le langage G'MIC, je conseillerais de jeter un oeil aux fantastiques tutoriaux de Jérome : http://zonderr.wordpress.com/ , qui apportent un regard extérieur tout à fait intéressant et intuitif sur la façon dont le langage fonctionne.

'theoretical' devrait plutôt ici être remplacé par 'analytical expression' : le filtre possède plusieurs pré-réglages de cartes de profondeurs plus ou moins adaptés au type d'image à traiter (portrait, paysage, intérieur, ..). On peut également donner au filtre une carte de profondeur personnalisée si l'on en possède une. Le filtre utilise ensuite l'image et la carte de profondeur pour générer une seconde vue 'décalée' pour arriver au 'rendu 3d' (anaglyphe ou stéréo).

Ca peut paraitre assez basique, mais si la photo est bien adapté à l'une des cartes de profondeurs pré-rentrée, alors ça donne un effet 3d très sympa.

Même avec du web/mail/zic sur un netbook double coeur (qui arrivent en masse), ca devrait pouvoir être visible, surtout si la musique passe par Deezer avec du Flash qui clignote.

Oui :

CImg possède une classe CImgDisplay permettant d'afficher rapidement des images et d'interagir avec (gestion des évènements possibles).

G'MIC intègre également un visualiseur d'image.

Les deux permettent de gérer les séquences d'images volumiques flottantes multi-canaux.

..tu peux utiliser CImg, c'est simple et pratique à utiliser :

http://cimg.sourceforge.net

(plus simple à installer/utiliser qu'OpenCV je pense).
Je l'utilise pour l'encadrement de TD en Master depuis quelques années maintenant, ca permet d'écrire du code concis et efficace.

Pour continuer la pub : en outils ligne de commande, il y a aussi G'MIC :

http://gmic.sourceforge.net

Attention, ce ne sont pas des outils ultra-optimisés mais ca a l'avantage d'être portable, facile à installer, et très adapté pour le prototypage d'algorithmes.

Fin de la pub, votre programme habituel reprend dans quelques instants.

Mais si justement il y a a discuter.
Je trouve pas la version du commentaire ci dessous plus lisible pour ma part. G'MIC est effectivement basé sur une syntaxe type 'ligne de commande', et je vois pas trop le problème (si pour toi c'est un problème, passe sous Windows).

Tes préjugés c'est bien gentil, mais comme le post précédent, tu n'as pas d'argumentation ("y a pas à discuter" c'en est pas une), ça vaut rien, et tu ferais mieux de te taire sinon ça fait du bruit pour rien. C'est du niveau de "Le PSG ça pue" ou "Aux chiottes l'OM".

Quand on a rien à dire de plus intéressant que ce que tu viens de dire, on s'abstient.

Ha oui c'est vrai, j'ai pas remarqué que j'avais été odieux avec lui, excuse moi platement !

Avoir une opinion c'est bien, l'argumenter un peu c'est encore mieux.

Merci de ton commentaire parfaitement impartial et tout à fait utile !

En plus c'est fun d'écrire des dépêches !

Bien essayé ! :)

caennais, caennais... les cannois c'est plus au sud..

Ici, je pense que ce n'est pas forcément facile du fait de l'utilisation des templates. Je ne connais pas trop Python, mais les classes principales de CImg sont paramétrées elles-mêmes par un paramètre template.
Est-ce que c'est quelque chose que Python sait gérer ?

La réponse est oui. CImg ne s'intéresse pas au type des pixels quand il fait des transformations géométriques, donc que ce soit du 8, 16 ou 32 bits entier ou flottants, la sortie de la fonction de rotation sera la même que celle d'entrée.

Comme c'était une contrainte en bonus...

Et puis rien n'empêche éventuellement de sauver l'animation frame par frame pour en faire un .mpeg qui sera lisible sur un téléphone portable.

Moi je conseille l'utilisation du C++ avec la bibliothèque CImg, qui permet d'ouvrir facilement des fenêtres et de faire des animations dedans (et gérer des interactions utilisateurs éventuellement). C'est libre, multi-plateforme et c'est compilé, et on peut des choses intéressantes en peu de ligne de code.

http://cimg.sourceforge.net

Quelques exemples d'animations avec codes sources à l'appui :

http://cimg.sourceforge.net/screenshots.shtml

Non, il n'y a jamais eu de telles demandes. G'MIC est basé sur des algos de traitement d'images "classiques", vues comme des tableaux de pixels, pas comme des descriptions d'objets vectoriels, et à priori, si on veut traiter de telles images avec G'MIC, il faudra forcément les convertir un moment ou à un autre en tableaux de pixels.

Cela dit, on peut aussi prendre ça comme un compliment, d'écrire des dépêches comme patrick_g :)

On peut voir les dépendances par exemples ici :

pour l'outil en ligne de commande :

http://packages.debian.org/fr/sid/gmic

et pour le plug-in :

http://packages.debian.org/fr/sid/gimp-gmic

G'MIC est en fait très modulable et il est possible de le compile avec seulement un sous-ensemble des dépendances. Il conserve la plupart de ses possibilités de traitements, les dépendances étant là principalement pour la gestion des formats de fichiers images en entrée/sortie.

Une inclusion dans Krita serait envisageable, à mon avis c'est une très bonne idée, vu que Krita sait gérer le 16bits.
Après, personnellement je n'ai pas le temps, mais si quelqu'un est motivé, je pourrais donner un coup de main avec plaisir.

Oui mais alors si ça n'est pas promu en dépêche, on ne verra jamais ton commentaire ? :)

J'ai déjà croisé (une seule fois) des fichier JPEG monochrome codé en 12 bits, et c'est vrai que peu de logiciels arrivaient à en faire quelque chose. Je crois que le fait qu'il y ait peu de formats supportant le 16bits/canal en compression avec perte s'explique par le fait que le 16bits/canal est plus ou moins considéré comme une précision 'de luxe' pour coder les images (couleurs en tout cas), et que donc on a rarement envie de pourrir ces données 16 bits avec de la compression avec perte.

Merci pour la suggestion, ça me semble adapté effectivement. J'essaierai de faire ça un de ces quatres.