Journal Inrcast : Un autre outil de manipulation d'images.

Posté par  (site web personnel) .
Étiquettes :
0
4
juin
2008

Hello les gens !

Pour manipuler les images 2D en ligne de commande, on connait tous le magnifique programme convert proposé dans la boite à outils ImageMagick [1]. Dans un genre très (très) proche, il y a aussi gm de la boite à outils GraphicsMagick [2].



Je vous propose aujourd'hui de découvrir inrcast [3], un outil open-source pour manipuler les données images 2D, 3D, et les vidéos. Quel intérêt me demanderez-vous ? Il y a quelques différences importantes avec les outils cités précédemment :

  • inrcast permet de gérer naturellement des listes d'images volumiques multispectrales, donc in-fine de manipuler des images à grande dimensionnalité (par exemple, des séquences d'images médicales volumiques qu'on peut trouver en IRM de perfusion, ou encore des séquences d'images avec plus de 3 canaux qu'on peut trouver en imagerie satellitaire méteo par exemple), ce que ne permet pas ImageMagick. Bon bien sûr, les images couleurs 2D rentrent aussi dans ce cadre.

    Du coup, inrcast est très pratique pour décomposer/isoler les frames d'une vidéo ou les slices d'un volume en plusieurs fichiers images 2D, ou au contraire de les rassembler dans des fichiers volumiques.



  • inrcast est typé, c'est à dire qu'il sait gérer les différents types de stockage des valeurs de pixels (unsigned char, short, float, etc...). On peut par exemple l'utiliser pour convertir une image 3D volumique en format Analyze à valeurs flottantes en un format Tiff multipage 16 bits. L'utilisateur a le choix de spécifier le type de pixel d'entrée à considérer et le type de sortie. Assez pratique aussi quand on reçoit des images dans un format un peu bizarre et qu'on veut vite les remettre dans un format avec lequel on a l'habitude de travailler.



  • incast comprend un module de visualisation/exploration d'images simple et pratique à utiliser. On peut zoomer et se balader dans une image 2D/3D ou une suite d'image assez facilement, en utilisant la souris et/ou le clavier. C'est un peu comme display de ImageMagick, mais pour des images de dimensions plus grandes.



  • inrcast sait lire les fichiers d'objets 3D .off (format GeomView). Oui ça sert pas à grand chose, mais il fallait le dire, c'est bonus !


  • Il faut souligner que inrcast peut s'appuyer en partie sur ImageMagick ou GraphicsMagick si ceux-ci sont installés, mais aussi sur XMedcon [4] (pour lire les images au format dicom) ou encore FFMPEG [5] (pour lire/écrire les séquences vidéos).


    Bref, c'est un programme potentiellement assez pratique pour les traiteurs d'images de tout poils. C'est une version 0.1, donc encore assez expérimentale mais tout à fait fonctionnelle. A noter que la compilation des sources sont dispo met *beaucoup* de temps et demande *beaucoup* de mémoire si les optimisations sont activées.
    N'hésitez pas à donner des retours d'utilisation ou des suggestions.
    (Je cherche quelqu'un qui saurait faire un paquet pour inrcast en passant :) )

    ** Références :



    1. ImageMagick : http://www.imagemagick.org/

    2. GraphicsMagick : http://www.graphicsmagick.org/

    3. Inrcast : http://cimg.sourceforge.net/inrcast/

    4. Medcon : http://xmedcon.sourceforge.net/

    5. FFMPEG : http://ffmpeg.mplayerhq.hu/

  • # *WorkBench*

    Posté par  . Évalué à 4.

    Hmmm ... Je vais essayer ton soft dans notre labo post-prod (ciné), voire s'il va plus vite que imagemagick et autres softs :-)

    ps: il sait gérer le JPEG2000 en input et output ?
    • [^] # Re: *WorkBench*

      Posté par  . Évalué à 4.

      J'ai oublié un "ps": Il sait gérer en output les images 12 bits ?
      Imagemagick fait semblant de les gérer (en fait, il génère des images 16 bits)
    • [^] # Re: *WorkBench*

      Posté par  (site web personnel) . Évalué à 3.

      JPEG2000 est toujours blinde de brevet ? Il y a quelques temps, il avait ete conclu qu'il était inutilisable a cause de cela. JPEG et png etait bien suffisant pour la plus part des cas.

      Il me semble que seul le cinéma numérique utilise le jpeg2000.

      Quel serait le statu d'un logiciel libre gérant un tel format ?

      "La première sécurité est la liberté"

      • [^] # Re: *WorkBench*

        Posté par  (site web personnel) . Évalué à 3.

        Quel serait le statu d'un logiciel libre gérant un tel format ?

        Les brevets logiciels étant encore illégaux à ce jour en Europe, cela serait un logiciel libre. En revanche, pour les US, cela posant un petit souci, cela aboutirait sans doute dans une section non-free (non-us auparavant dans Debian en fait) des distributions lorsque le paquet est compilé avec l'option supportant ce format breveté (un peu comme ffmpeg, VLC, mplayer et consors lorsqu'ils ont certaines options disponibles).
        Le code source est lui libre bien sûr (bienvenue dans le casse-tête des droits des marques et des brevets lorsqu'ils s'ajoutent au droit d'auteur qui n'est dans certain cas pas simple non plus).
      • [^] # Re: *WorkBench*

        Posté par  . Évalué à 2.

        Raaahh, c'est pas possible, j'entend toujours cela à tout bout de champs;
        Le JPEG2000, certes, à des brevets, mais les personnes en possédant ont refusé toutes royalties ou demandes diverses dessus:

        « Part 1, Core coding system (intended as royalty and license-fee free - NB NOT patent-free) »

        LIBJPEG possède un codec J2C input/output pour cela.
        Dans pas mal de produit dans le secteur (digital cinema), cette librairie est utilisée et - si mes souvenirs sont exactes - elle est même recommandée dans les spécifications techniques.
        • [^] # Re: *WorkBench*

          Posté par  (site web personnel) . Évalué à 4.

          Tu n'es pas bien clair. Peuvent-il changer les conditions du jour au lendemain si cela leur chante ?

          "La première sécurité est la liberté"

          • [^] # Re: *WorkBench*

            Posté par  . Évalué à 2.

            La FAQ sur ce point :
            http://www.jpeg.org/faq.phtml?action=show_answer&questio(...)

            Normalement, il y a eu un deal (contrat je crois, j'ai un doute) pour que les gens qui font partie du JPEG(2000) Consortium ne casse pas les bonbons avec cela;

            D'un autre côté, je vois mal une boite de software changer sa politique à ce niveau là au vue des intêrets que le Digital Cinema en fait.
            (en gros, je doute que l'un des boys du consortium est envie de se mettre à dos le consortium + les plus grosses majors US Cinema ... c'est pas dans leurs intêret)
            • [^] # Re: *WorkBench*

              Posté par  (site web personnel) . Évalué à 3.

              En gros, si j'ai bien compris la FAQ, le "part 1" de la spec JPEG2000 est utilisable sans problème. Par contre, la "part2" est parfaitement inutilisable à cause de technologie en licence RAND.

              Sachant évidement, que même le groupe JPEG ne garantit pas qu'il n'y ai pas de brevets qui trainent quelques part.

              "La première sécurité est la liberté"

      • [^] # Re: *WorkBench*

        Posté par  . Évalué à 2.

        Oui enfin bon, les brevets n'ont pas empêché toutes normes MPEG de prospérer ... moi je verrai plutôt une sorte de décrédibilisation de la part des acteurs de formats concurrents.
        • [^] # Re: *WorkBench*

          Posté par  (site web personnel) . Évalué à 2.

          Oui et non, ces histoires de brevets ont provoqué pas mal de problème comme la guerre mp3/ogg voir pire dans la vidéo avec le mpeg4 vs flash vs Xvid vs ffmpeg.

          Cela explique aussi une partie des ennuis sur le navigateur web et l'utilisation de flash qui est quand même pas terrible.

          Les DRM ne sont pas la seul composante des problèmes, les brevets en posent aussi beaucoup.

          "La première sécurité est la liberté"

  • # Rapport avec les travaux précédents ?

    Posté par  (site web personnel) . Évalué à 3.

    Je commence à m'y perdre un peu...

    Quel le rapport de inrcast avec CImg, GreyCstoration, etc... ?
    Bref, une petite overview ?

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # Version 0.2 disponible

    Posté par  (site web personnel) . Évalué à 6.

    Bon alors comme j'ai eu quelques retours et demandes de fonctionnalités, j'ai sorti une version 0.2, qui contient quelques fonctionnalités en plus :

    - Conversion entre espaces couleurs RGB,XYZ,Lab,HSL,HSI,HSV,YUV,YCbCr.
    - Segmentation par croissance de région.
    - Extraction d'isocourbe ou d'isosurface à partir d'une image 2D ou 3D et sauvegarde possible en objet 3D (format .off de Geomview).
    • [^] # Re: Version 0.2 disponible

      Posté par  . Évalué à 3.

      > - Conversion entre espaces couleurs RGB,XYZ,Lab,HSL,HSI,HSV,YUV,YCbCr.

      T'es un rapide dit donc, j'avais proposé cette feature ce matin, le temps de prendre un café et y'avait déjà la version les colorspace-conversion dispo sur CVS :-)

      Bon, par contre, ce qui est bizarre c'est la conv semble ne pas marcher chez moi .... (mais j'ai un doute sur l'input aussi)
      En gros, quand je prend Jasper (JPEG2000 encoder/decoder) pour passer de XYZ à sRGB, la conversion se passe bien (enfin je crois, j'ai aucune couleurs flashies); Par contre, j'ai toujours une image très verte.

      En utilisant inrcast, je me retrouve toujours avec les couleurs flashies + verdate.
      ( sample: ./inrcast /tmp/dcp/0000150.j2c -zyz2rgb -o test.jpg )

      Assez bizarre ... je dois merder quelque part ...
      • [^] # Re: Version 0.2 disponible

        Posté par  (site web personnel) . Évalué à 4.

        Bah je suppose que c'est dépendant de la définition de la conversion RGB->XYZ.
        Moi j'utilise celle décrite dans la FAQ Poynton :

        http://www.poynton.com/ColorFAQ.html

        Est-ce que c'est celle là que tu utilises aussi ?
        C'est juste une fonction linéaire de RGB, et ca a tendance effectivement à booster la composante Y, donc quand on visualise sous forme RGB, ca donne une image verdatre
        (la visu dans inrcast se fait toujours en utilisant RGB, même si la signification des canaux n'est pas du tout RGB).

        Quand je fais :

        inrcast image.jpg -rgb2xyz -xyz2rgb

        je retrouve bien l'image initiale. Est-ce que tes valeurs sont bien sur 8 bits ? (mon RGB suppose des valeurs entre [0,255]).

        David.
        • [^] # Re: Version 0.2 disponible

          Posté par  . Évalué à 3.

          Alors, là, tu me la coupe.
          Heuuuu, je suis pas spécialiste colorimétrie donc je vais essayer de répondre au plus correct possible.

          Alors, mes images à l'origine sont en 12 bits:

          $ jasper/bin/imginfo -f /tmp/dcp/0000150.j2c
          jpc 3 1920 1080 12 9331200

          Conversion en JPEG classique avec inrcast XYZ2RGB :
          $ inrcast /tmp/dcp/0000150.j2c -xyz2rgb -o /tmp/test.jpg
          Ca me donne une bouillie de pixels

          Conversion en JPEG classique avec inrcast RGB2XYZ :
          $ inrcast /tmp/dcp/0000150.j2c -rgb2xyz -o /tmp/test.jpg
          Noir total.
          Pour info :
          $ jasper/bin/imginfo -f /tmp/test.jpg jpg
          3 1920 1080 8 6220800

          Donc output en 8 bits

          Avec Jasper (conversion en sRGB avant) :

          $ jasper --input /tmp/dcp/0000150.j2c --output /tmp/test.jpg --force-srgb
          forcing conversion to sRGB
          $ imginfo -f /tmp/test.jpg
          jpg 3 1920 1080 8 6220800

          Plus aucune couleur flashie, par contre un bon teint vert.

          J'essaye de retravailler après avec inrcast :
          $inrcast /tmp/test.jpg -xyz2rgb -o /tmp/test2.jpg
          Le ton verdatre disparait, mais les couleurs flashies réapparaissent.

          Bon, déjà j'arrive à un autre point de niveau ... je continue mes investigations

          A vous les studios !

          PS: Si j'ai pas répondu à tes questions ou mal compris, t'as le droit de m'insulter (mais seulement en XYZ)
          • [^] # Re: Version 0.2 disponible

            Posté par  (site web personnel) . Évalué à 2.

            Tu pourrais m'envoyer juste un exemple d'image en .j2c, pour voir ?
            Si c'est du 12 bits je comprend que la conversion en RGB foire à priori, car cela ne va pas donner du 8 bits en sortie, il va falloir renormaliser quelque part (c'est possible à priori, il y a l'option '-val' qui fait çà).

            Si tu peux m'envoyer une image ca m'interesse, car je ne connais pas trop ce format, c'est toujours bon d'avoir un exemple dans un coin pour voir ses particularités..

            David.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.