- 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.
- 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....
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 !
# En dépêche ?
Posté par Florent Fourcot . Évalué à 7.
[^] # Re: En dépêche ?
Posté par David Tschumperlé (site web personnel) . Évalué à 5.
Pour tester les exemples, le mieux c'est encore d'installer les paquets debian avec les exemples pré-compilés, qui s'installent dans /usr/bin avec le préfixe 'cimg_'.
En particulier, 'cimg_CImg_demo' donne une bonne idée de ce qu'on peut faire.
David.
# style C++
Posté par rewind (Mastodon) . Évalué à 4.
En revanche, je trouve qu'il faudrait quand même noter le nombre de fonctions dans la classe principale. Car c'est bien là le style de la lib, mettre un maximum de fonctions dans une seule classe. Ça ne veut pas dire que c'est mal fait, c'est d'ailleurs assez bien documenté je trouve [0], mais je trouve que c'est pas très scientifique de comparer avec une lib qui a beaucoup de classes mais peut-être moins de fonctions au total.
Sinon, ma petite proposition : y aurait-il moyen de créer un langage de script qui permette de faire du dessin, une sorte d'adaptation du langage POV-RAY en 2D ? Ça serait sympa pour spécifier des schémas par exemple et les générer automatiquement.
[0] http://cimg.sourceforge.net/reference/structcimg__library_1_(...)
[^] # Re: style C++
Posté par SKBo . Évalué à 2.
[^] # Re: style C++
Posté par rewind (Mastodon) . Évalué à 2.
[^] # Re: style C++
Posté par Ontologia (site web personnel) . Évalué à 2.
Des équivalent lisibles ? YAML, format ini classique, le format de google ( http://code.google.com/p/protobuf/ )
etc...
XML est très bien pour des échanges entre applications, mais pour l'humain.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: style C++
Posté par rewind (Mastodon) . Évalué à 4.
Parmi les équivalents que tu cites, je dirais qu'ils n'ont pas tous la portée de XML. YAML par exemple est très bien mais pas d'équivalent d'une DTD, de là il est beaucoup plus difficile de comprendre un document YAML standalone. Avec ses balises nommés, le XML permet une meilleure compréhension. Le format ini classique est vraiment trop basique pour faire des choses évolués, à moins de recoder une couche par dessus. Quant au format de Google, je ne le connais pas, mais il semble orienté RPC, je vais y jeter un oeil, ça a l'air intéressant.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.