Journal [Traitement d'image] Sortie de CImg 1.3.0

Posté par (page perso) .
Tags :
16
17
fév.
2009
Après quasiment 8 mois de développement, la mouture 1.3.0 de la bibliothèque CImg est disponible. Voici en quelques mots, les caractéristiques principales de cette bibliothèque :
  • 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.
Pas mal de nouveautés sont présentes dans cette dernière version 1.3.0, grâce à de nombreuses contributions venant d'un peu partout dans le monde. On pourra en particulier citer :
  • 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 :

Merci pour votre attention !
  • # En dépêche ?

    Posté par . Évalué à 7.

    Je pense que ce journal aurait très facilement eu sa place dans les dépêches. Il donne envie de tester ce logiciel :)
    • [^] # Re: En dépêche ?

      Posté par (page perso) . Évalué à 5.

      Bon je n'ai pas proposé une dépêche, car CImg ce n'est pas vraiment nouveau, j'en parle depuis un petit moment maintenant.

      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 . Évalué à 4.

    Je ne vais pas commenter le style C++, c'est vrai que ce n'est pas très conventionnel, de là à dire que ce n'est pas la bonne manière de faire, non. C'est une autre manière de faire.

    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 . Évalué à 2.

      SVG ?
      • [^] # Re: style C++

        Posté par . Évalué à 2.

        Oui et non. Pour des objets simple, SVG est déjà très verbeux, et quand il faut composer des objets, ça devient vite l'enfer. SVG est un bon format de base mais pas vraiment un truc utilisable directement. Si tu ne connais pas, jette un œil au format POV-RAY, tu verras ce que je veux dire, le langage est très orienté utilisateur.
        • [^] # Re: style C++

          Posté par (page perso) . Évalué à 2.

          L'XML est par nature verbeux et illisible...

          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 . Évalué à 4.

            XHTML est le parfait contre-exemple de cette affirmation. Il ne faut pas être sectaire contre le XML, certains format XML sont tout simplement inadapté à l'humain (ODF par exemple, SVG dans une moindre mesure), d'autres en revanche, quand ils ont été pensé pour ça dès le départ, peuvent s'y prêter (XHTML par exemple).

            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 à ceux qui les ont postés. Nous n'en sommes pas responsables.