Articles précédents : Articles
- [9] Nouvelle version de Lemonldap le SSO sous GPL
- [51] Brevets logiciels : nouvelle attaque des promoteurs.
- [6] CELF Technical Conference
- [119] Google contre la pollution des sites web
- [54] Les versions de développement de Prelude maintenant indisponibles
- [7] Libre en Fête IV - édition 2005
- [51] Un consortium pourrait ré-écrire une partie du noyau pour éviter les risques liés aux brevets
- [42] Gnome 2.10 approche
- [79] [Débat] Implémentations libres de java : sont elles utilisées dans la pratique ?
- [16] MathEnPoche (MEP) a donné naissance à MEP version papier
Liens connexes
Dépêche modérée par
Dépêche éditée par
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.
![[en]](../../../images/en.png)
> Lire les commentaires (9 commentaires, moyenne: 3,9).
img_img contre ImageMagick
La page d'img_img ne cache pas qu'img_img promet d'être similaire à ImageMagick, mais n'explique pas pourquoi les auteurs du projet veulent réécrire la roue. Si le support de quelques formats ou opérations leur manque, pourquoi ne pas l'ajouter à ImageMagick ?
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 () le 23/01/2005 à 01:31. (lien). Évalué à 1.ça me rappelle Gnome et KDE, tiens
--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008-
[^]Re: img_img contre ImageMagick
Posté par Bruce Le Nain (Jabber id, page perso, ) le 24/01/2005 à 09:33. (lien). Évalué à 2.Oui, mais j'ai plutôt compris que c'est le comportement (application en ligne de commande) qui se rapprochera de celle d' ImageMagick (et de son fork dont j'ai oublié le nom) et non l'application en elle même. Un peu comme l'excellent Cimg, panel d'outils graphiques très puissant en ligne de commande (qui utilise d'ailleurs ImageMagick pour travailler les images jpg et png).
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 () le 25/01/2005 à 08:42. (lien). Évalué à 4.>ImageMagick (et de son fork dont j'ai oublié le nom)
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 () le 23/01/2005 à 11:02. (lien). Évalué à 2.Img_img se focalise juste sur l'ouverture d'un fichier, aucun redimensionnement et autre "feature" d'image magic. Ce qui pourrait permettre une moindre dépendance et un fonctionnement plus simple.
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 (page perso, ) le 23/01/2005 à 11:59. (lien). Évalué à 3.vu que la librairie est focalisé sur le chargement des images (simplicité)
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 () le 23/01/2005 à 17:21. (lien). Évalué à 2.
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. »
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 (Jabber id, ) le 23/01/2005 à 20:02. (lien). Évalué à 7.ImageMagick peut étre utilisé comme greffon ou programme externe poar un soft GPL mais ne peut pas étre lié/link a un soft GPL, c'est celon moi la principal raison et motivation.
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.--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.
-
[^]Re: img_img contre ImageMagick
Posté par ArBaDaCarBa () le 24/01/2005 à 15:10. (lien). Évalué à 4.> On ne retrouve les sources que pour Linux et Windows. Quid de MacOS (X) ou autre plateforme?
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.
-
Cette page a été générée par Templeet en 0.1058s (dont 0.0398 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.