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).
- 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.
N'hésitez pas à y jeter un oeil !
# LWN
Posté par patrick_g (site web personnel) . Évalué à 10.
Si il est publié cela améliorera beaucoup la visibilité de ton logiciel je pense.
[^] # Re: LWN
Posté par David Tschumperlé (site web personnel) . Évalué à 3.
[^] # Re: LWN
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je pense que pas mal de gros logiciel mettent cette adresse dans leur liste "announce".
[^] # Re: LWN
Posté par patrick_g (site web personnel) . Évalué à 5.
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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: format d'image avec perte mais profondeur de couleur supérieur à 8
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
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 nicoastro . Évalué à 2.
[^] # Re: format d'image avec perte mais profondeur de couleur supérieur à 8
Posté par David Tschumperlé (site web personnel) . Évalué à 2.
[^] # Re: format d'image avec perte mais profondeur de couleur supérieur à 8
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Excellent G'MIC
Posté par maderios . Évalué à 4.
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.