Sortie de CImg 1.3.0

Posté par (page perso) . Modéré par Florent Zara.
Tags : aucun
14
18
fév.
2009
Audiovisuel
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 !
  • # placement par rapport à ITK

    Posté par . Évalué à 4.

    Cette bibliothèque me semble très intéressante. J'aurais cependant aimé un petit comparatif de CImg et ITK (http://itk.org ). En effet ce dernier est une (sinon la) référence dans le domaine du traitement de l'image (pour rappel cmake, qui s'occupe maintenant de kde, a été développé pour/par itk/vtk -kitware- ).

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

      Je crois que tu oublies de préciser que ITK est une référence dans le domaine du traitement d'image, mais principalement dans le domaine de la recherche et du médical. ITK est peu connu dans un tas d'autres domaines (Vision, Industrie ...).

      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 (page perso) . Évalué à 2.

        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

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

          Oui certainement, mais j'utilise d'autres lib masssivement templatées (notamment CGAL) et j'ai souvent l'impression que la compilation avec CImg est plus lente ... ceci dit je n'ai jamais regardé plus en détails.
          • [^] # Re: placement par rapport à ITK

            Posté par . Évalué à 1.

            Dans la doc de CImg ils donnent un exemple de compilation avec -O2 qui ralentit considérablement la chose.
            Peut être l'as tu laissé…
  • # Commentaire personel

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

    Pourquoi la depeche est rempli de commentaires personnels ?

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

      Parce que c'est repiqué directement du journal de l'auteur du soft.

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

      Les commentaires viennent d'un des auteurs donc il défend son pré carré, à raison d'ailleurs.

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

      C'est parce qu'avec GIL, on a une solution tellement bien conçue(*) qu'on est bien en mal de dire que CImg c'est mieux.
      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 (page perso) . Évalué à 2.

        Je reviens de quelques jours de vacances, donc je suis un peu en retard sur le sujet, néanmoins je voudrais faire quelques commentaires :

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