Journal Sortie de G'MIC 1.3.4.0

Posté par  (site web personnel) .
Étiquettes :
14
8
mar.
2010
La version 1.3.4.0 de G'MIC (GREYC's Magic Image Converter), outil libre et générique pour le traitement d'image, est sortie.

http://gmic.sourceforge.net

G'MIC est développé dans l'équipe IMAGE du laboratoire GREYC (CNRS, Caen). Il propose un framework complet pour le traitement d'image, puisqu'il définit à la fois un langage de script dédié à la création de pipelines de traitements, fournit un interpréteur libre de ce langage sous forme d'une bibliothèque unique (en C++, d'environ 2.5 Mo) utilisable par n'importe quel logiciel libre tiers, ainsi que deux binaires intégrant cet interpréteur : gmic d'une part, et gmic_gimp d'autre part, permettant respectivement d'utiliser les possibilités de traitements de G'MIC à partir de la ligne de commande ou sous forme d'un greffon additionnel pour GIMP.

Les paquets .deb pour i386 et amd64, ainsi que la version compilée pour Windows, sont dores et déjà disponibles dans la section Download du site.

Les nouveautés de cette version 1.3.4.0 se focalisent sur l'interpréteur du langage, et peu sur le greffon GIMP (qui est probablement la partie de G'MIC la plus utilisée à ce jour). Parmi les nouveautés principales, on notera :
  • Une stabilisation du langage : Quelques nouvelles commandes natives sont apparues (produit matriciel en natif, calcul des tenseurs de structures...), un meilleur mode debug de l'interpréteur, et pas mal de petites corrections de bugs de ci, de là. En guise de démonstration du langage, un Jeu de la vie interactif a été programmé en G'MIC. Vous pouvez le tester par la commande toute simple gmic -x_life (copie d'écran1) (copie d'écran2).

  • Une réécriture de la documentation de référence : Je pense avoir réalisé maintenant une documentation plus claire, bien qu'encore un peu rébarbative (mais en même temps, c'est un manuel de référence, pas un tutoriel). Il est intéressant d'y jeter un coup d'oeil pour avoir une idée du nombre et du type de commandes comprises par l'intérpréteur G'MIC à ce jour. Peut-être y verrez vous une fonctionnalité qui vous intéresse.

  • L'amélioration de la gestion des objets 3d maillés : G'MIC est maintenant capable de lire/générer/écrire/afficher des données d'objets 3d maillés contenant des textures, des sprites ou des 'sphères parfaites (non maillées)'. Peu de commandes utilisent encore cet aspect texture, mais on peut imaginer que cette possibilité ouvre pas mal de perspectives pour la réalisation de filtres ou d'effets originaux sur des images. Pour exemple, voici quelques objets tests créés et affichés par G'MIC (copie d'écran1) (copie d'écran2).
Pour finir, je donnerais quelques indications sur les différences qui existent entre G'MIC et ImageMagick (IM), qui est un outil souvent cité comme référence dans le domaine du traitement d'images en ligne de commande :
  • IM est très très fort en ce qui concerne les entrées-sorties, la variété des types de fichiers lus et écrits. G'MIC se concentre plus sur le traitement proprement dit que sur les entrées-sorties (même si il n'est pas si mauvais dans ce domaine, notamment en ce qui concerne les images TIFF 16 ou 32 bits/composantes). La définition de pipelines complexes de traitement est en général plus simple dans G'MIC que dans IM, notamment quand on commence à vouloir traiter et fusionner des données provenant de listes d'images.
  • G'MIC travaille en interne avec des images pouvant être définis sur des domaines 3d (images volumétriques), chaque pixel pouvant être lui-même un vecteur de dimension quelconque (images multi-spectrales), codé en valeurs flottantes. Il gère ainsi mieux les formats d'images à valeurs flottantes ou volumétriques que son homologue IM qui se focalise plus sur les images couleurs classiques, que ce soit pour le traitement ou les entrées-sorties.
  • G'MIC définit un langage extensible et complet : On peut nourrir l'interpréteur avec ses propres commandes, écrites en langage G'MIC, et les stocker dans un fichier de commande unique, alors que IM favorise plutôt l'écriture de scripts séparés.
  • G'MIC possède des modules de visualisation plus avancés que IM, notamment pour visualiser des images à valeur flottantes, des tracés de courbes, des objets 3d. G'MIC a la possibilité de gérer des fenêtres interactives ou les évênements utilisateurs peuvent être captés. Les différentes commandes x_life, x_spline, x_mandelbrot, x_fish_eye ou encore x_fourier illustrent bien cet aspect interactif qu'il n'est pas possible d'avoir avec IM.
Bref, G'MIC n'a pas été conçue comme une alternative à ImageMagick, ni comme une surcouche (comme j'ai pu déjà l'entendre dire). C'est un framework tout à fait différent, à mon avis intéressant pour les traiteurs d'images de tout poil, et que je vous invite donc à essayer quand vous aurez un peu de temps. Il apporte également une solution clé-en-mains pour l'ajout de filtres divers et variés dans n'importe quel logiciel de traitement d'images, et ce, pour un encombrement assez restreint (2.5 Mo au total) par rapport à ses capacités.

N'hésitez pas à y jeter un oeil !

  • # LWN

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

    Je te conseille de faire un article sur G'MIC et de l'envoyer au site Linux Weekly News (pour leur section Development).
    Si il est publié cela améliorera beaucoup la visibilité de ton logiciel je pense.

    • [^] # Re: LWN

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

      Merci pour la suggestion, ça me semble adapté effectivement. J'essaierai de faire ça un de ces quatres.

      • [^] # Re: LWN

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

        J'ai l'impression qu'il suffit d'envoyer un courriel à lwn-AT-lwn.net à chaque nouvelle version du logiciel (bien sur en anglais).

        Je pense que pas mal de gros logiciel mettent cette adresse dans leur liste "announce".

        • [^] # Re: LWN

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

          Oui mais là ce qu'il faudrait viser c'est plus que l'annonce basique de la sortie d'une nouvelle version.
          Ce serait mieux de faire un petit article sur ce qu'est G'MIC et ce qu'il apporte de cool par rapport à ce qui existe déjà (avec screenshots et tout).

  • # format d'image avec perte mais profondeur de couleur supérieur à 8 bit

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

    Salut,
    Je profite de ce journal pour poser une question sur un sujet qui me semble connexe. Existe-t-il à votre connaissance des formats d'image compressé avec perte mais disposant d'une « dynamique » de couleur supérieure à celle offerte par le jpeg ?
    Je pose la question car il ne me semble pas pertinent de stocker des images sous forme de matrice (raster) juste parce que l'on souhaite préserver les informations colorimétriques potentiellement exploitables. Le problème se pose par exemple pour la conservation de photographies au format RAW : pour une photographie dont un jpeg de bonne qualité prend ~1Mo, il faut ~10Mo pour stocker la version raw parce que la compression est faite de manière non destructive. Ne pourrait-on pas imaginer un format de compression retenant les informations pertinentes spatialement comme le jpeg tout en offrant les possibilité de retouche ultérieure que permet une image stockant 10 à 16 bits d'information par canal de couleur ? Est-ce que cela existe déjà ? Est-ce standardisé ? Peut-on imaginer faire simplement ce genre de chose avec un outil comme G'MIC ?

    PS : après consultation de « atilf » il me semble que les mots colorimétrique et spatialement peuvent être ajoutés dans le dictionnaire de linuxfr.

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: format d'image avec perte mais profondeur de couleur supérieur à 8

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

      Question secondaire pour les experts, existe-t-il des formats de rendu d'image non matriciels, c'est-à-dire utilisant des réseaux de pixel autre que rectangle (par exemple un réseau triangulaire pourrait donner des pixels aux formes hexagonales, donc plus proche d'un cercle) ? Si oui, G'MIC gère-t-il ce genre d'images ?

      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

      • [^] # Re: format d'image avec perte mais profondeur de couleur supérieur à 8

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

        Il me semble qu'il existe une version du jpeg 16 bits que personne n'utilise. Il me semble aussi que jpeg2000 permet cela mais personne ne l'utilise à cause de la quantité de brevet. Il me semble que Microsoft a sorti un format raw compressé sans perte à spec ouverte. Mais je n'ai pas de nouvelle.

        L'idéal serait un format de fichier qui comprime en yuv, avec 24 bits pour le y, et 7 ou 8 pour le u et v, cela correspond à la vision humaine. Cela serait aussi super top si le format embarquait une colorimétrie "absolue" pour éviter de se taper des conversions rgb<-> adobe<-> CMYK, etc...

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

      • [^] # Re: format d'image avec perte mais profondeur de couleur supérieur à 8

        Posté par  . Évalué à 2.

        J’ai du mal à voir l’application de ce genre d’images… quoiqu’il en soit un pixel reste un point, libre à vous de choisir votre pavage : carré, hexagonal, circulaire, canard à trois pattes, pas besoin d’avoir un format d’image spécifique.

    • [^] # Re: format d'image avec perte mais profondeur de couleur supérieur à 8

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

      J'ai déjà croisé (une seule fois) des fichier JPEG monochrome codé en 12 bits, et c'est vrai que peu de logiciels arrivaient à en faire quelque chose. Je crois que le fait qu'il y ait peu de formats supportant le 16bits/canal en compression avec perte s'explique par le fait que le 16bits/canal est plus ou moins considéré comme une précision 'de luxe' pour coder les images (couleurs en tout cas), et que donc on a rarement envie de pourrir ces données 16 bits avec de la compression avec perte.

      • [^] # Re: format d'image avec perte mais profondeur de couleur supérieur à 8

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

        Certes. Si je ne m'abuse les images monochromes en 12 bits sont utilisés en médecine pour les radiographies. Les médecins voulant absolument éviter même l'éventualité d'une erreur médical pour cause de manque de précaution : on imagine l'effet d'un « votre parent est décédé des suites de l'opération, en fait la masse morbide qui apparaissait sur le scanner était un artefact de numérisation ; nous n'aurions pas dû opérer.» Ceci dit, je serais donc surpris que l'algorithme de compression utilisé soit le jpeg.

        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # Excellent G'MIC

    Posté par  . Évalué à 4.

    Je viens de tester avec G'MIC une fonction que j'utilise souvent, nommée avec Gimp, échelle et taille du calque', 'smart upscale' avec G'MIC.
    J'ai agrandi une image à 200%. Il n'y a pas photo, si j'ose dire. Le filtre de Gimp produit un effet 'peau d'orange' sur certaines zones (idem pour le zoom) tandis que celui de G'MIC respecte l'image.
    Gimp version 2.6.7

    "L'art est fait pour troubler. La science rassure" (Braque)

Suivre le flux des commentaires

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