Pour ceux qui ne connaissent pas Cinepaint (ex filmgimp), c'est une application développée à partir de Gimp pour faire de la retouche d'image dans les films. Les utilisateurs et "codeurs" de ce logiciel sont des grands studios - on retrouve par exemple Rhythm & Hues pour le film Harry Potter.
L'un des principaux inconvénients était l'impossibilité de l'utiliser sur plate-forme Mac à cause de sa dépendance à GTK1.
La nouvelle initiative est de réécrire Cinepaint et utiliser FLTK - nom de code Glasgow.
En plus de cette réécriture, une bibliothèque de conversion/lecture/écriture d'image est développée : 'img_img'. Cette bibliothèque a pour but d'être utilisée en ligne de commande et d'être intégrée à d'autres projets tel que Blender/Verse.
On en arrive au projet Blender/Verse : celui-ci aspire à être une base de donnée d'image/objet 3D partagés entre différents utilisateurs et modifiés en direct.
En effet le projet a défini un protocole réseau pour le partage d'objet graphique et la mise à jour. On retrouve ainsi un greffon pour Gimp. C'est assez impressionnant.
On peut supposer que l'idée finale est d'intégrer Verse dans Blender et ainsi pouvoir partager les différents objets 3D créés.
# img_img contre ImageMagick
Posté par Boa Treize (site web personnel) . Évalué à 10.
Je ne connais pas bien ImageMagick, mais il semble bien documenté, avoir une API C++, être distribué sous une licence plutôt sympathique (proche dans l'esprit d'une licence BSD) et être installé sur la plupart des machines Linux. Alors pourquoi lancer un nouveau projet ?
[^] # Re: img_img contre ImageMagick
Posté par Gniarf . Évalué à 1.
[^] # Re: img_img contre ImageMagick
Posté par Bruce Le Nain (site web personnel) . Évalué à 2.
Il me semblait d'ailleurs avoir lu que Gimp aussi devait passer en tout ligne de commande avec une interface indépendante.
[^] # Re: img_img contre ImageMagick
Posté par oliv . Évalué à 4.
GraphicsMagick (mais où vont ils chercher tout ça ! ;) )
http://www.graphicsmagick.org/(...)
>Il me semblait d'ailleurs avoir lu que Gimp aussi devait passer en tout ligne de commande avec une interface indépendante.
Tu as un peu mal interprété: Le gimp peut-être utilisé sans interface graphique depuis la version 2.2 (ou est-ce depuis la 2.0? je ne sais plus). Avant, c'était impossible, l'interface était obligatoire.
[^] # Re: img_img contre ImageMagick
Posté par Geo Vah . Évalué à 2.
Le code :
// initialization:
ImgImg img_img;
ImgPluginData plugin_data;
memset(&plugin_data,0,sizeof(plugin_data));// Important to zero first!
// specify file to read and plug-in to use:
plugin_data.filename = "test8.ppm";
plugin_data.libname = "img_ppm";
// read the file into an RGB buffer:
bool ok = img_img.Read(plugin_data);
// expose the raw RGB buffer:
ImgData& img_data=img_img.GetImgData();
... do whatever you want to the flat RGB raster in memory ...
// write this 8-bit raster as a 16-bit ppm:
plugin_data.filename = "test16.ppm";
plugin_data.write_options = "bits=16";
ok = img_img.Write(plugin_data);
Ne devrait pas radicalement changer, vu que la librairie est focalisé sur le chargement des images (simplicité)
De plus si on regarde bien :
http://www.imagemagick.org/www/download.html?(...)
On ne retrouve les sources que pour Linux et Windows. Quid de MacOS (X) ou autre plateforme?
La licence quand à elle est une Apache-Style. Je ne sais pas bien quelles sont les limitations et les plus par rapportà la GPL.
Enfin, un des premiers ajouts à cinepaint par rapport à gimp a été le support des "image formats up to 32-bit per channel deep", ce que imagemagic ne supporte pas il me semble.
[^] # Re: img_img contre ImageMagick
Posté par Boa Treize (site web personnel) . Évalué à 3.
Rien n'oblige d'utiliser tout ImageMagick. Je remarque au passage que j'ai des JPEG un peu corrompus qu'imlib refuse de charger alors qu'ImageMagick les affiche sans problème (mais en m'avertissant de la légère corruption). La simplicité d'imlib n'est donc pas toujours la bienvenue.
On ne retrouve les sources que pour Linux et Windows.
La seule différence, c'est le format de l'archive (tar.gz contre zip). Quasiment tous les projets font ça, je suis surpris que tu ne connaisses pas. Ta remarque fait limite troll, surtout vu que la page précise bien : « ImageMagick is quite portable, and compiles under almost every general purpose operating system that runs on 32-bit or 64-bit CPUs. »
"image formats up to 32-bit per channel deep", ce que imagemagic ne supporte pas il me semble
C'est possible, je ne connais pas bien. Mais pourquoi ne pas améliorer ImageMagick dans ce cas ? C'est vrai que ce n'est pas forcément simple, voilà en tout cas le premier argument valable pour la création d'img_img.
[^] # Re: img_img contre ImageMagick
Posté par Geo Vah . Évalué à 2.
Honte sur moi, je n'ai regarder que très rapidement la page de download d'image magcick.
Enfin, sachant que ce sont des studios assez important qui vont l'utiliser, on peut supposer qu'il y a une bonne raison de leur part.
Ps : je ne fais pas partit des dev de cinepaint/img_img ni un utilisateur avertit, je vais juste faire un tour sur le site de temps en temps et vu qu'il n'y avait pas de news la dessus, j'en ai fait une ...
[^] # Re: img_img contre ImageMagick
Posté par Beretta_Vexee . Évalué à 7.
La licence d'ImageMagick bien que compatible avec la GPL, n'est pas la GPL ce qui peut compliquer pas mal de chose pour ces projets.
[^] # Re: img_img contre ImageMagick
Posté par ArBaDaCarBa . Évalué à 4.
En lisant le reste de la page:
It also runs under Windows '98 and later ('98, ME, NT 4.0, 2000, and XP), Macintosh (MacOS 9 and 10), VMS, and OS/2.
Puis si on lit la partie "macintosh":
An extended source code package for MacOS 9 (including configured delegates and MetroWerks CodeWarrior build files) may be found here. Note: Use the Unix source package from the top directory for MacOS 10.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.