- CImg est une bibliothèque C++, basée sur l'utilisation (basique) de templates. Elle définit un nombre minimal de classes (4 au total) et de fonctions permettant une manipulation aisée d'images dans un programme C++, en gérant par exemple les entrée-sorties, l'affichage/l'interaction, le filtrage, la manipulation géométrique, le dessin de primitives, etc.... C'est une bibliothèque libre et multi-plateforme, développée (et utilisée quotidiennement) dans l'équipe Image du laboratoire de recherche (CNRS) GREYC, à Caen/France. Son développement a commencé fin 1999, à l'INRIA de Sophia-Antipolis.
- CImg a été conçue avant tout dans un but de simplicité d'utilisation. Elle est adaptée lorsque l'on cherche, par exemple, à faire du prototypage d'algorithmes de traitement d'image. Elle est relativement légère, contenue principalement dans un fichier d'en-tête C++ CImg.h à inclure en début de source. Elle est adaptable dans le sens où elle peut utiliser des bibliothèques externes pour améliorer ses performances ou ses capacités, sans que cela ne soit obligatoire. Sa conception (quelquefois décriée) en fait une bibliothèque très facile à inclure dans vos propres réalisations.
- CImg est générique. Ses classes permettent de manipuler aussi bien des signaux 1D que des images 2D ou 3D multi-valuées (couleurs par exemple, ou avec un nombre quelconque de composantes), ainsi que des séquences d'images (séquences temporelles typiquement). Les valeurs des pixels des images sont des types templates, et il est donc possible de gérer de manière transparente des images à 8 bits ou 16 bits par composante, mais aussi à valeurs flottantes. Elle est d'ailleurs l'une des rares bibliothèque capable de gérer correctement les fichiers TIFF à valeurs float.
Il est également intéressant de souligner ce que CImg n'est pas :
- Une bibliothèque ultra-générique permettant de représenter des images à grilles non régulières, définies sur des espaces à 42 dimensions, contenant des pixels de type tenseurs d'ordre N. La généricité de CImg est limitée : on ne peut pas tellement aller au delà des séquences d'image volumiques à N composantes et à valeurs flottantes. Néanmoins, cela englobe déjà la plupart des types de données images que l'on rencontre habituellement.
- Une bibliothèque à conception conteneur - algorithmes, comme la bibliothèque standard. Pour le traitement d'image, il y a déjà GIL et VIGRA enlarge your image qui utilisent ce type de conception ayant de nombreux adeptes (souvent assimilée à la seule bonne manière de faire du beau C++, ce qui est évidemment faux). En particulier, CImg évite de définir 256 classes différentes, chacune possédant 10 paramètres templates.
- L'apparition de G'MIC et du plug-in pour GIMP, qui est basé sur CImg et qui permet de créer des filtres ou des effets personnalisés à l'aide d'un interpréteur de macros de traitement d'images. G'MIC est déjà sorti il y a quelques semaines, en utilisant une version béta de CImg 1.3.0.
- La prise en charge de la bibliothèque FFMPEG pour la lecture/écriture native de fichiers vidéos dans CImg.
- L'amélioration du plug-in GREYCstoration pour GIMP, permettant entre-autre de traiter seulement certaines caractéristiques des images (luminance / chrominance). C'est probablement la dernière version de GREYCstoration à sortir, puisque G'MIC contient lui-même ces fonctionnalités, et qu'il est beaucoup plus évolutif, de par sa conception même.
- Une fonction de visualisation pratique pour l'affichage et l'exploration de signaux 1D.
- Et bien sûr, de nombreuses corrections de bugs....
Voilà ! Donc, si vous êtes intéressés par le C++ et le traitement d'image, vous pouvez récupérer cette dernière version 1.3.0 de CImg, disponible en .zip, .tar.gz, ou en paquet debian, avec éventuellement les exemples pré-compilés pour les version 32 ou 64 bits de votre OS favori. Les exemples permettent de voir rapidement ce que CImg est capable de faire en quelques lignes seulement.
Pour finir, voici quelques liens utiles illustrant quelques CImg-itudes :
- Copies d'écrans des exemples fournis dans l'archive de CImg.
- Une vidéo du programme de démonstration principal d'utilisation de CImg. Elle montre de nombreux effets (le plupart, écrits en quelques lignes), qui illustrent les différentes capacités de la bibliothèque.
- Un tutorial montrant comment faire un premier code avec CImg.
- Des slides complets de présentation de la bibliothèque, pour se familiariser avec CImg sans se fatiguer.
- Quelques effets réalisés avec G'MIC, via les fonctionnalités de CImg.
- Quelques résultats obtenus par GREYCstoration, via les fonctionnalités de CImg.
Merci pour votre attention !
Aller plus loin
- Journal à l'origine de la dépêche (4 clics)
- Site officiel de CImg (12 clics)
# placement par rapport à ITK
Posté par Bubu . Évalué à 4.
En un mot: je suis sûr que CImg a ses particularités j'aurais aimé savoir lesquels.
Bon courage,
Bubu
[^] # Re: placement par rapport à ITK
Posté par Fussty . Évalué à 3.
Ceci étant, pour avoir utilisé les deux. Je dirais que CImg a l'avantage d'être simple à utiliser, prendre en main et surtout pratique à utiliser dans ses projets. De plus CImg inclus un bon nombre d'algos intéressants et outils de visus rapides à mettre en oeuvre. En revanche, je trouve le code illisible et difficile à adapter pour un cas particulier, une visualisation particulière, une adaptation d'un filtre, dans le sens ou c'est difficile de contribuer au développement. De mon avis perso c'est une lib a utiliser en tant qu'utilisateur.
Avec les explicit instantation, la compilation avec ITK s'est nettement améliorée et je ne sais pas ce que ca donne avec la nouvelle version de CImg de ce coté là. Car le fait d'avoir un unique CImg.h peut sembler pratique mais ca rend la compilation lente (un fichier de 36840 lignes c'est assez long à parcourir ...).
Comme dit dans l'article, CImg a été concu pour sa simplicité. ITK est très bien, et sans doute bien plus complète que CImg mais très lourd pour certains utilisateurs / certaines utilisations. La visualization est nettement meilleure en utilisant VTK, mais encore une fois CImg a l'avantage (ou non) de tout intégrer dans une même lib ( dans un même fichier).
En tout cas c'est cool pour le plugin GIMP :).
Amael
[^] # Re: placement par rapport à ITK
Posté par jm trivial (site web personnel) . Évalué à 2.
Je ne pense pas que la lenteur de la compilation des applications utilisant CImg soient dû à la taille du fichier, mais plutôt aux propriétés massivement template de la librairie.
[^] # Re: placement par rapport à ITK
Posté par Fussty . Évalué à 1.
[^] # Re: placement par rapport à ITK
Posté par Anonyme . Évalué à 1.
Peut être l'as tu laissé…
# Commentaire personel
Posté par Mathieu Malaterre (site web personnel) . Évalué à 1.
...
multi-plateforme, développée (et utilisée quotidiennement) dans
...
...
il y a déjà GIL et VIGRA enlarge your image qui utilisent ce type de conception ayant de nombreux adeptes (souvent assimilée à la seule bonne manière de faire du beau C++, ce qui est évidemment faux).
...
J'imagine que Adobe a payé des gens pour GIL et qu'il l'utilise en interne, parce que ca repond a un besoin.
Et effectivement ITK n'est meme pas cité dans l'article... sans doute parce que templaté: ce qui implique que c'est du "mauvais C++" CQFD.
[^] # Re: Commentaire personel
Posté par Seazor . Évalué à 1.
Par exemple, le "enlarge..." était barré dans le journal, il est en clair ici et c'est sur que ca fait désordre dans une news !
Pour le reste genre la comparaison avec la concurrence, j'y connais rien, j'en dirai pas plus.
[^] # Re: Commentaire personel
Posté par rewind (Mastodon) . Évalué à 5.
La remarque que le fait que ce soit "templaté donc du mauvais C++" est totalement débile vu que la classe principale de CImg est templaté, mais si tu avais pris la peine au moins de cliquer sur un des lien (il y en a pourtant beaucoup), tu t'en serais aperçu très vite.
La seule chose qu'on peut reprocher à cet article (et que j'ai déjà signalé en commentaire [0] dans le journal à l'origine de la dépêche), c'est qu'il n'indique pas le nombre de fonctions dans la classe principale et il y en a énormément. Ce n'est pas vraiment une mauvaise conception, plutôt un choix, qui peut se défendre tout à fait (même si personnellement, je ne fais jamais ce choix là).
[0] http://linuxfr.org/comments/1008412.html
[^] # Re: Commentaire personel
Posté par loufoque . Évalué à 1.
Donc cette dépêche, qui est pro-CImg, essaie de descendre GIL comme elle peut, en citant tous les concepts et modèles de ceux-ci implémentés, ainsi que différents utilitaires comme le support pour la méta-programmation, les concepts statiques et dynamiques, la programmation fonctionnelle, les variants etc., pouvant ainsi prétendre que c'est trop compliqué.
Alors que si on regarde la doc (onglet modules), c'est tout de suite clair et simple. Il y a une douzaine de concepts, qui sont les éléments fondamentaux pour le traitement d'image. Chacun a un certain nombre de modèles (on peut en faire autant qu'on veut).
Voilà, c'est tout. Il faut juste comprendre comment la programmation à base de concepts fonctionne, qui est d'ailleurs la manière recommandée de programmer en C++... (mais bon, peu de personnes la connaissent vraiment, en fait, et tout le temps rejette ce qu'on ne comprend pas)
(*) Une approche à base de concepts permet la rétro-ingénierie et l'intégration non-intrusive avec n'importe quelles autres types et bibliothèques, définissant ainsi une solution *réellement* générique.
[^] # Re: Commentaire personel
Posté par David Tschumperlé (site web personnel) . Évalué à 2.
- Premièrement, j'ai effectivement écrit cet article dans le cadre d'un journal, pas d'une dépêche, d'où le ton un peu plus libre qui est utilisé. Je tiens à préciser que je n'ai pas été sollicité pour faire une version 'dépêche' de ce journal, ni même était prévenu du passage en dépêche. Ca s'est fait en tout cas, je découvre ça aujourd'hui. Je ne critique pas : si je ne voulais pas qu'on réutilise ma prose pour alimenter le site LinuxFR, je n'aurais pas posté un journal sur ce site à la base.
- Secundo, je n'ai jamais dit que GIL c'était nul, bien au contraire. J'ai juste souligné que ce n'était pas facile d'accès. Et ça, je crois pas que tu puisses prétendre le contraire. Comme tu le dis toi-même, il y a des tas de concepts à connaitre pour comprendre et utiliser correctement GIL. Je vais peut-être t'étonner, mais la plupart des spécialistes en TI (que je connais du moins) non seulement se foutent royalement de connaitre ces concepts, mais même s'ils le voulaient, ils n'ont même pas forcément l'expérience nécessaire de 15 ans qu'il faut pour les maitriser en C++.
Alors GIL, c'est bien joli, mais quand je vois le code qu'il faut pondre pour calculer un simple gradient (http://stlab.adobe.com/gil/html/giltutorial.html#ExampleSec)(...) je doute qu'à part les programmeurs de chez Adobe, il y ait beaucoup de monde intéressé pour élaborer des algos génériques non triviaux pouvant se mettre dans GIL.
- Troisièmement, tu m'as l'air d'être le type même de gens dont je dénonce les pensées uniques, quand tu dis :
Voilà, c'est tout. Il faut juste comprendre comment la programmation à base de concepts fonctionne, qui est d'ailleurs la manière recommandée de programmer en C++... (mais bon, peu de personnes la connaissent vraiment, en fait, et tout le temps rejette ce qu'on ne comprend pas)
Typiquement, vous oubliez que la force du C++ c'est justement qu'il est multi-carte, et que c'est un langage qui n'enferme pas le programmeur dans un style de programmation. C'est bien pour ça que ça a un tel succès d'ailleurs. Oui, tu peux faire de la programmation basée concept, ou pas, utiliser des templates, ou pas, etc... Il serait dangeureux de croire qu'il n'y a qu'un style unique permettant de faire du "bon" C++. Regarde juste la diversité des concepts derrière les bibliothèques de traitement d'images en C++ : Entre ITK, VIGRA, GIL, CImg, OLENA, et j'en passe, que de différences !! Et heureusement ! Tout le monde peut s'y retrouver, et choisir la bibliothèque qui convient le mieux à son profil de programmation. Ce qui est important, c'est d'avoir des ponts possibles entre les bibliothèques, c'est tout.
Clairement, CImg a opté pour une certaine facilité d'utilisation. Ce n'est pas ce qui motive les gens derrière GIL. CImg est pratique pour faire du prototypage rapide d'algorithme. Ce n'est pas le cas de GIL. GIL a pleins de qualités mais dans d'autres domaines (grande généricité "potentielle", intégration dans du code existant, etc..)
C'est à l'utilisateur de faire son choix, et CImg participe à élargir le panels d'outils disponibles.
David.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.