Journal Outils autour de Gimp : Pack My Sprites et Xcftools

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
31
15
fév.
2013

Sommaire

Gimp est un logiciel libre de traitement d'images matricielles. La dernière version est sortie en mai 2012 et avait bien sûr été présentée sur LinuxFR. C'est aussi un logiciel phare du monde du libre, pour lequel de nombreux greffons sont développés et autour duquel plusieurs outils gravitent. Je vais vous parler de deux outils qui m'intéressent particulièrement : Pack My Sprites et Xcftools.

Pack My Sprites

Pack My Sprites est un outil qui génère des feuilles de sprites à partir d'une ou plusieurs images au format XCF. Il s'agit d'un outil que j'ai développé durant la production d'Andy's Super Great Park. Il est écrit en C++ et diffusé sous les termes de la GPL 3.

L'idée de départ était de réduire autant que possible le temps qui séparait la réalisation d'une image dans Gimp et sa visualisation dans le jeu. En effet, avec un outil classique de création de feuilles de sprites, je dois répéter les étapes suivantes à chaque fois que je veux voir l'image dans le jeu :

  • Dimensionner l'image à sa taille finale ;
  • Sélectionner les calques du sprite et masquer les autres ;
  • Exporter l'image dans un fichier png ;
  • Répéter les deux étapes précédentes pour chaque image ;
  • Lancer le logiciel de création de feuille de sprite ;
  • Sélectionner les images ;
  • Générer la feuille.

Chacune de ces étapes est répétitive et inutile, et devrait donc être automatisée. J'avais donc besoin d'un logiciel de création de feuille de sprites qui fonctionne directement avec mes images sources : les fichiers XCF que je crée avec Gimp.

Pack My Sprites se distingue d'autres outils de créations de feuilles de sprites tels que Sprite Sheet Packer, Texture Packer, glue ou encore Nanimstudio, sur différents points :

  • il travaille directement avec les fichiers XCF plutôt qu'avec des images intermédiaires ;
  • il fonctionne sans interface graphique afin de faciliter l'automatisation de la génération des feuilles de sprites (glue est aussi un outil en ligne de commandes) ;
  • il sait générer des fichiers Makefile qui recréent les feuilles de sprites quand les fichiers XCF sont modifiés.

Exemple d'utilisation

Voici une capture de la fenêtre de Gimp dans laquelle j'ai dessiné une animation d'un oiseau qui vole:
Oiseau dans Gimp

Pour produire la feuille de sprites depuis cette image et une autre, j'écris le fichier suivant décrivant chaque sprite de l'animation :

/* file bird.spritedesc */
sprite_sheet "bird" 256 x 256 order "height"

/* The source images. */
fly "bird-fly.xcf.bz2"
afraid "bird-afraid.xcf.bz2"

/* The sprites. */
"afraid" autosize * 0.33 with afraid
  "eyes"
  "beak"
  "body"
  "tail"
;

"fly 1" autosize * 0.33 with fly
  "body"
  "eyes"
  "back wing 1"
  "wing 1"
;

"fly 2" autosize * 0.33 with fly
  "body"
  "eyes"
  "back wing 2"
  "wing 2"
;

"fly 3" autosize * 0.33 with fly
  "body"
  "eyes"
  "back wing 3"
  "wing 3"
;

/* etc. */

Puis j'exécute la commande suivante pour générer la feuille de sprites :

pack-my-sprites bird.spritedesc

La commande produit deux fichiers. La feuille de sprites :

Les sprites de l'oiseau

et un fichier contenant la position et la taille des sprites dans la feuille :

fly 1: 0 0 75 84
fly 2: 76 0 75 84
fly 3: 152 0 75 84
fly 4: 0 85 75 84
fly 5: 76 85 75 84
fly 6: 152 85 75 84
fly 7: 0 170 75 84
fly 8: 76 170 75 84
afraid: 152 170 94 69

Obtenir l'outil

L'outil est disponible depuis son site Web ainsi que sur GitHub. Il n'y a pas de paquets pour les distributions pour l'instant. Son utilisation nécessite l'installation de xcfinfo et de gimp.

Améliorer l'outil

La version mise en ligne a été suffisante durant le développement de notre jeu mais elle peut encore être améliorée. Par exemple, au niveau de la syntaxe du fichier de description des sprites, on peut supprimer la liste des fichiers XCF et les nommer directement lors de la déclaration d'un sprite.

L'algorithme de placement des sprites dans la feuille est assez rudimentaire. Plusieurs méthodes de calculs existent et mériteraient d'être explorées.

L'utilisation de xcfinfo et gimp se fait par un appel à popen(). Pour le premier on lit le résultat de la commande pour récupérer les informations sur les calques, pour le second on passe un script Scheme qui génère l'image finale. Ce serait plus classe si on passait directement par une bibliothèque de manipulation des XCF.

Enfin, comme l'outil s'appuie sur xcfinfo, il ne pourra pas être disponible sous Windows tant que Xcftools ne l'est pas non plus.

Xcftools

Xcftools est une suite d'outils en ligne de commandes pour extraire des informations de fichiers au format XCF. Ces commandes sont :

  • xcf2pnm, pour convertir un fichier XCF en un fichier Portable_anymap ;
  • xcf2png, pour convertir un fichier XCF en un fichier Portable_Network_Graphics ;
  • xcfview, pour afficher un fichier XCF à l'écran ;
  • xcfinfo, pour extraire des informations sur les calques d'un fichier XCF.

Les outils de conversion permettent de choisir les calques à utiliser et même de changer leur mode de composition.

Ces outils ont soudainement prit un coup de vieux avec la sortie de Gimp 2.8 et ses groupes de calques. En effet, Xcftools a été écrite pour gérer les images de la version 2.6 de Gimp et même si elle arrive à extraire des informations des images au nouveau format, le résultat n'est pas toujours celui espéré.

Reprise du développement

Cette suite d'outils a initialement été développée par Henning Makholm. La dernière version est sortie en juillet 2009, sous licence GPL 2 d'après le site de l'auteur, ou dans le domaine public d'après les sources.

Je suis particulièrement intéressé par l'outil xcfinfo, notamment pour Pack My Sprites ; c'est pourquoi j'ai envoyé un patch à l'auteur pour y ajouter la gestion des groupes de calques. Comme je n'ai pas reçu de réponse, j'ai décidé de forker le projet sur GitHub pour y ajouter ce patch et reprendre un peu le développement.

T'es le bienvenu

Les premières modifications que j'ai faites ont été d'ajouter l'affichage de la hiérarchie des calques dans xcfinfo, puis d'entamer une migration du système de construction vers CMake afin de pouvoir compiler pour Windows (c'est la branche cmake sur GitHub). En effet, la suite utilisait un mélange d'autotools et de scripts divers qui, combinés avec quelques macros bien placées dans le code, permettaient d'obtenir un logiciel qui compile. Vous l'aurez compris, ces outils sont développés en C.

Les outils me conviennent très bien dans leur état actuel. Cependant il est clair qu'ils sont incomplets tant qu'ils ne gèrent pas correctement les groupes de calques ; c'est pourquoi j'hésite à packager tout de suite une nouvelle version. De plus, aucune des améliorations que j'entrevois ne me motive ; c'est pourquoi je cherche des gens intéressés pour les prendre en main.

Idéalement il faudrait adapter le code d'aplatissement de l'image afin de prendre en compte le mode de composition des groupes de calques. Il faudrait aussi gérer les groupes quand les calques sont passés en paramètres au programme. Dans l'absolu on pourrait utiliser libgimp pour composer les images au lieu de refaire les algos en interne. Ça me semblerait bien plus simple mais on s'éloignerait de la philosophie initiale de l'outil.

  • # OpenRaster

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

    Juste une remarque : il serait peut-être cool de prendre en charge le format OpenRaster.

    • [^] # Re: OpenRaster

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

      En effet sa serait super cool. Comme Gimp sait lire ce format et que Pack My Sprites lui délègue complètement la composition de l'image finale, il suffirait d'un outil équivalent à xcfinfo pour OpenRaster (orainfo ?) afin de pouvoir extraire l'information des calques du fichier et l'utiliser dans Pack My Sprites.

  • # Un autre concurrent

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

    http://darkfunction.com/editor/

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Je devrais pas mais tant pis

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

    La dernière version est sortie en mai 2013

    J'ai beaucoup ri à cette phrase :D

    kentoc'h mervel eget bezan saotred

  • # xcf-utils

    Posté par  (site web personnel, Mastodon) . Évalué à 8.

    Salut,

    au sujet de xcftools, j'avais également envoyé un patch pour un problème de compilation, il y a quelques mois (novembre). Je vois que t'en as corrigé d'autres mais pas celui que j'ai eu d'ailleurs, donc je viens de t'envoyer mon patch par email, pendant qu'on y est. Et tout comme toi, je n'avais aucune réponse de l'auteur originel. Enfin pareil, la reprise de ce code ne me motive pas. Non pas qu'il est mauvais ou quoi (je m'en souviens même plus depuis le temps), mais que d'après moi ces outils ont un problème de base: ils réimplémentent le format XCF séparément de la libgimp. Ce serait OK si XCF était un format standard (comme OpenRaster dont parle quelqu'un plus haut) avec une spéc donnée. Mais voilà, XCF est considéré par l'équipe de GIMP comme un "dump" de l'organisation interne d'une image GIMP. Bien sūr, l'équipe fait en sorte qu'on puisse toujours lire des vieux fichiers XCF dans GIMP même, mais ça ne va pas plus loin (pas de volonté de format stable en dehors de l'utilisation dans GIMP même). D'ailleurs la seule doc qui existe du format XCF est justement celle qui fut écrite par Henning Makholm, celui à l'origine des xcftools (et cette doc est intouchée depuis 2009, il manque donc plein de trucs dedans). En d'autre termes je trouvais que réimplémenter un outil qui faisait pareil que la libgimp, c'était un mauvais plan de base (aussi bien cela soit-il techniquement, juste difficilement maintenable).

    Alors la libgimp a un problème tout de même: elle nécessite GIMP. Ce n'est pas une librairie indépendante et tout outil qui charge la libgimp doit nécessairement être lancé par GIMP même.
    J'ai essayé d'en discuter un peu avec l'équipe GIMP, mais même si je pense que personne ne serait contre si quelqu'un se chargeait de patcher GIMP dans ce sens, si personne ne le fait, les dévs actuels n'en ont pas l'utilité, donc c'est loin d'être une priorité (ce que je comprends). Et bien que je sois un dév GIMP moi-même depuis quelques mois, ce n'est pas non plus ma priorité comparée à d'autres corrections et fonctionnalités que je veux intégrer (surtout qu'une libgimp indépendante serait un énorme boulot, c'est loin d'être anodin).
    La proposition d'un autre dév était qu'il était probablement plus simple de pousser le support de XCF vers GEGL, ce qui est intéressant mais pas la solution selon moi. Car ce qui est intéressant dans la libgimp, c'est pas uniquement charger, convertir ou faire des opérations sur le format, c'est aussi toutes les autres fonctions pour travailler sur un fichier XCF et qui ne se retrouveraient pas dans GEGL (des opérations sur les calques, les masques, les chemins, parasites, etc.).

    Ma solution a donc été de réimplémenter ce que je souhaitais des xcftools dans un script shell qui encapsule l'appel à GIMP, lancé sans UI. On ne voit donc absolument pas que ça lance GIMP console, bien que ce soit tout de même une dépendance du script. Cependant je me suis dit que la dépendance GIMP ne devait pas être un problème pour quiconque veut travailler sur des XCF a priori.
    En outre, cela n'empêche nullement de l'utiliser sur un serveur sans serveur graphique non plus, par exemple pour des crons, des hooks, ou autre script automatique, puisqu'il est possible de compiler GIMP sans UI avec l'option --enable-gimp-console (note que je n'ai pas personnellement testé).
    Au final cela fait donc un script python de quelques lignes qui peut faire tout ce que fait xcftools, mais en mieux, et de manière certifiée conforme, puisque ça utilise la libgimp. Aussi y a le support des groupes (qui était effectivement un point manquant pour moi), mais aussi je fais un hash du bitmap dans chaque calque.
    Mon but d'utilisation des xcftools était en effet principalement pour faire un diff entre deux images afin de l'intégrer à mon flot de travail git.
    Cela fait qu'en cas de conflit, ou simplement pour voir un historique, je sais si entre deux commits, il y a simplement eu un changement du nom du layer, ou de son contenu, si un layer a été juste déplacé. Je peux même repérer un layer dont le contenu a été changé, le nom aussi, puis déplacé! Ou bien si c'est juste l'offset qui change, etc.
    En gros en cas de conflit, on fait comme avec du code, on voit ce qui a changé, et si ce sont des layers différents, ou juste des renommages de calque, pof! On peut merger (à la main) sans risque!
    Bon note que ce hash et le fait que ça charge GIMP rend mon xcf-info vachement plus lent que le xcfinfo des xcftools. Mais je trouve personnellement xcfinfo quasi inutile pour un diff (aucun moyen de savoir si un dessin a changé, juste les noms/dimensions/alpha!). Donc ça reste une meilleure option pour mes besoins.

    Enfin bon, je viens de créer un projet xcf-utils sur mon compte TuxFamily pour y déposer mon code. Comme ça quiconque souhaite peut y jeter un coup d'œil et/ou l'utiliser. Je pense que c'est un code bien plus pérenne, et en mēme temps 100 fois plus simple. Tu peux faire un checkout du code là:
    git clone git://git.tuxfamily.org/gitroot/xcfutils/xcfutils.git
    (ou web: http://git.tuxfamily.org/xcfutils/xcfutils?p=xcfutils/xcfutils.git;a=tree)

    Par contre, je pense que toi, tu es surtout intéressé par xcf2png/pnm. Je n'ai pas réimplémenté cela pour le moment, bien que je compte faire quelque chose dans le genre, et pour quelque chose d'assez similaire à toi, puisque c'est pour faire des animations. En fait je travaille sur tout un workflow d'animation qui utilise GIMP pour le dessin. Mais ce code sera pour une prochaine release quand tout sera bien en place. :-)
    C'est en gros basé sur le code du plugin animation-playback, mais en bien meilleur (pas juste 1 calque = 1 frame) et avec plein de features plus avancées, mais en restant simple (GAP par exemple est une usine à gaz qui essaye presque d'implémenter un NLE dans GIMP, selon moi!).
    Mais tu peux toujours t'inspirer de mon code, et surtout de comment j'utilise un bête script shell pour en gros lancer un plugin GIMP indépendant. Ça veut dire que si tu peux faire un plugin GIMP (et comme on peut presque tout faire en plugin…), alors tu peux aussi le lancer comme un simple script shell! C'est toute l'idée.
    En tous cas, perso je veux pas m'embêter avec ce code C qui duplique toute une logique de libgimp, mais avec qques années de retard. Fais ça en quelques lignes de code (soit script-foo, soit python) en quelques minutes. :-)

    Bon ensuite on peut considérer que c'est un gros hack. Mais il sert à remplacer xcftools qui est — selon moi — un hack encore plus gros.
    L'idéal serait définitivement d'avoir une libgimp indépendante, mais cet idéal n'existe pas encore. :-)

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: xcf-utils

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

      Merci pour ses explications!

      Ca rends pour moi la décision de "forcer" l'utilisation du format XCF vraiment bizarre.

      En effet depuis les dernières versions de gimp, le format de sauvegarde est toujours xcf. Pour utiliser un autre format, il faut passer par un menu (ou un raccourci clavier) "Exporter", moins pratique que l'ancien système (on pouvait choisir le format lors de l’enregistrement).

      Pour pousser un format instable?

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: xcf-utils

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

        Salut,

        je pense qu'il y a incompréhension. Le but n'est nullement de "forcer" l'utilisation de XCF. C'est simplement que XCF est le format de GIMP. De même que si tu sauves dans Blender, ça sauve un .blend (tu peux pas sauver autre chose), qui est le format de Blender et pas plus fait à servir de format d'échange avec un autre programme non plus. Si tu veux un autre format qui n'est pas le format natif du logiciel, eh bien tu "exportes". Par exemple tu peux essayer d'exporter ton XCF en png, ou en PSD, etc. Et tu peux exporter ton blend en 3ds, etc. Pareil pour Audacity ou Ardour. Tu ne "sauves" que dans leur format respectif, mais si tu veux un fichier son (vorbis, flac, etc.), tu "exportes".
        Ce sont des logiciels qui ont fait le choix de faire une différenciation entre une sauvegarde et un export. Plein de logiciels font ce choix, alors que d'autres ont un design où ils mélangent les deux fonctionnalités (par exemple LibreOffice permet de "sauver" dans son format OpenDocument natif, et d'exporter en .doc avec la même fonction).

        Alors pourquoi différencier? Parce que le format natif est adapté au logiciel, toutes les fonctionnalités y sont, donc il n'y a pas de perte de données. Quand tu sauvegardes ton travail en XCF dans GIMP, tu ne perds aucune donnée (c'est un peu faux, il y a un type de données qu'aucun format de dessin ne sauve: l'historique. Donc à l'heure actuelle, aucun format graphique n'est parfaitement sans perte). Si tu "exportes" en png, tu obtiens un image plate, tu perds tes calques, tes masques, tes chemins, ta sélection. Pire si tu exportes en jpg, tu perds même en image (puisqu'il y a perte de qualité). Donc l'idée est que tu travailles toujours en XCF, qui est le format qui a tout ce que fait GIMP. Puis au dernier moment, quand tu es content de ton travail, tu "exportes" dans un format fait pour être visionné, ou échangé, etc.
        Il est bien moins grave que quelqu'un ait à exporter (ce qui ne prend pas plus de temps, juste un raccourci différent) plutôt que le risque que quelqu'un qui aille un peu vite perde des données (perde ses calques, etc.).

        Hormis cela, GIMP n'a absolument aucune intention de "pousser" le format pour une utilisation générique, bien au contraire. Il a toujours été clair que XCF, c'était pour GIMP, pas plus. Y a d'ailleurs d'autres logiciels qui ont apparemment forké le format XCF, mais ça a divergé depuis et ce sont donc maintenant des formats différents.

        Pour servir de format d'échange qui conserve certaines fonctionnalités, il y a OpenRaster qui est développé en collaboration par les équipes de divers logiciels Libres, et dit s'inspirer d'OpenDocument, pour les images raster (= bitmap, ce n'est donc pas un format vectoriel). Mais ça reste encore super basique. J'ai lu la spec (qui ressemble plus à un brouillon sur un bout de table d'ailleurs pour l'instant) en 5 minute top-chrono, elle est extrêmement incomplète, imprécise et a peut-être un vingtième des fonctionnalités de XCF (en gros, ça supporte les calques et groupe de calque, et basta! C'est tout).
        La mailing list, sur laquelle je suis inscrit depuis des mois, est aussi quasiment silencieuse.
        Alors attention ce n'est pas une critique. Comme tout projet Libre/Standardisation, c'est animé par ceux qui sont intéressé. Les coupables, c'est nous, donc moi aussi. Pour ma part, j'ai juste fait 2/3 messages sur la liste, et un patch sur la librairie libora, c'est tout. J'ai justement pas mal de propositions, mais faut que je me fasse le temps.
        Le jour où OpenRaster a l'ensemble des fonctionnalités de GIMP, alors peut-être qu'on réfléchira à en faire notre format natif, tout comme LibreOffice utilise maintenant le standard OpenDocument. Si un logiciel comme MyPaint a pu déjà en faire son propre format natif, c'est seulement parce que le logiciel n'a aucune fonctionnalité avancée (pour le dessin même, il paraîtrait qu'il est mieux que GIMP, mais hors cela, il est très basique). En attendant ce n'est pas une solution viable.

        Notez que pour la 3D, ils ont le format d'échange COLLADA qui ressemble bien plus à quelque chose. Bon j'ai jamais lu, et je n'ai aucune idée de la qualité. Mais y a un vrai organisme de standardisation, des sociétés qui soutiennent, c'est vraiment beaucoup utilisé, et la spéc fait des centaines de pages. Ensuite aucune idée si un jour Blender va échanger son format blend avec Collada. Blend fait beaucoup de choses aussi, dont certaines sont peut-être unique. Le format COLLADA contient-il tout blend? Aucune idée.

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: xcf-utils

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

          Je travailles avec plusieurs logiciels: krita pour un dessin global, gimp pour les retouches au pixel près, nanimstudio pour l'animation ou tiled pour créer des niveaux.

          Le seul format commun, c'est le png donc je travaille toujours sans calque et autres effets spécifiques.

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: xcf-utils

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

            Salut,

            ça je comprends bien. Il s'agit du format d'échange, non du format de travail. De même de des développeurs ne donnent pas seulement un code source aux utilisateurs, mais ils leur donnent une version binaire prête à l'emploi d'un double clic.

            Maintenant laisse moi te donner un exemple:

            Tu fais ton sprite. C'est un bonhomme tout petit, et il bouge pas beaucoup. Mais il bouge quand même les pieds au moins quand il marche, probablement les mains aussi, peut-être même qu'il tourne la tête.
            Qu'est-ce que tu fais quand tu veux faire les diverses versions de sa démarche? Bien sûr, tu peux faire le petit bonhomme complet, puis tu dupliques le calque (ou tu fais une autre image, ou que sais-je), et tu changes juste un peu les pieds, puis les mains, puis tu re-dupliques le calque, etc. Tu fais autant de calques/images que de frames.
            Mais voilà, un jour, tu veux changer son corps. Un truc tout con: tu trouves que la veste rouge lui va pas. Tu veux la faire bleue. Bah! Facile. Tu dois changer la couleur de la veste sur chaque frame finie de l'animation! Donc tu recharges chaque png un à un, et tu modifies la veste.
            Pourtant le corps est exactement le même sur chaque! Mais tu multiplies ton travail par le nombre de frame/png.

            Maintenant plutôt que faire cela, voilà ce que tu pourrais faire: tu fais le corps qui bouge jamais sur un calque, deux versions de la tête (une à gauche, une à droite, ou que sais-je), trois versions des bras (balancés d'un côté ou de l'autre, ou au "repos"), pareil pour les jambes. Et tu as maintenant 1 * 2 * 3 * 3 = 18 frames différentes en seulement 1 + 2 + 3 + 3 = 9 calques (avec juste quelques pixels par calque. Dans ton cas, un calque, c'est juste les bras par exemple). Et le jour où tu veux changer la couleur du corps, tu changes seulement deux calques, puis tu lances un script (que tu as écrit à côté) qui regénère tes 18 frames de png en 1 centième de secondes.
            Puis le jour où tu veux changer plus, facile aussi, et fait en quelques secondes.
            En travaillant que sur des png par contre, ce jour là où tu veux faire un gros changement sur ton bonhomme, t'es vraiment dans la merde, et tu peux tout aussi bien tout reprendre du début.

            Julien Jorge dans ce journal a montré un très bon exemple de ce workflow dont je parle, et que tu as tout intérêt à prendre dans ton cas aussi. Regarde bien sa copie d'écran. Il a un layer pour le corps, des layers pour diverses positions pour chaque aile, etc.
            Moi c'est encore pire. On fait des dessins animés. Genre 10, 24 ou plus images par seconde, taille HD. Tu te rends bien compte que si je recopiais des éléments fixes à chaque frame, le jour où je veux changer cet élément (qui bougeait pas pendant genre 10 secondes par exemple, donc quelques centaines de frames!), c'est mort, on se tire une balle.

            C'est pour cela que tu devrais vraiment travailler avec des XCF, sauver tes XCF et même les versionner (les png par contre, sauf cas particulier, ne les versionne pas si tu peux éviter. C'est du généré! Pas du source). Ton application finale, elle utilisera toujours des png, qui seront générés automatiquement à partir des tes XCF par une commande dans le Makefile (ou autre système de compilation), ce qui fait que tu as jamais à t'en préoccuper, mais tu bosses uniquement sur les XCF. Tu ne devrais même pas à avoir à exporter à la main dans GIMP en png en fait. Tu te rends compte si tout le monde faisait cela? On n'utiliserait jamais GIMP! Ou alors tu veux te limiter à une dizaine de persos dans ton jeu, ou alors tu aimes le boulot chiant de fourmi (afficher le layer, masquer avant, exporter, afficher, masquer, exporter, etc. 1 fois par frame), ou alors tu prévois de sous-traiter en Inde. :-D
            Non on ouvre GIMP, on fait la partie "intéressante" (on dessine), on sauve, on ferme GIMP, et on veut taper Make, et basta. C'est fini. On a un jeu (dans ton cas) compilé avec de nouvelles images juste finie. :-)

            Ce que tu es en train de faire là, c'est l'équivalent pour un programmeur de bosser directement sur la source compilée, ou plutôt sur du code généré: tu as un code, tu le compiles, puis tu jettes ton code original. Et lorsque tu veux modifier ton code, tu bosses à partir de la version générée que tu recompiles, puis tu rejettes, etc. Bien sûr c'est encore faisable car dans ton cas ton code "compilé" (png) est moins barbare qu'un binaire, mais ça reste de la donnée générée, avec tout ce que cela implique (perte de donnée, complexification, etc.).

            D'ailleurs je viens de revoir à nouveau ton post sur nanim, tu écris

            Enfin, il faut recommencer pour toutes les positions clefs de l'animation, n'ayant pas la possibilité d'engager une armée d'intervallistes, je me suis contenté de 5 frames

            Forcément, tu redessines tout à chaque fois! Alors que si tu avais séparé avec des calques, et généré avec un script tes pngs, t'as juste à dessiner une nouvelle position des bras, et paf t'as une nouvelle frame.

            Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

            • [^] # Re: xcf-utils

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

              En fait je travaille déjà un peu comme ça, mais avec les différents éléments dans des png séparés et je combine mes images soit à la main quand il y en a peu, soit avec des scripts quand il y a beaucoup.

              j'utilise imagemagick, par exemple pour les changements de couleur, : http://www.imagemagick.org/Usage/color_mods/#modulate_hue

              Pareil pour les rotations, je passe par une implémentation de rotsprite en python: http://www.pineight.com/pc/

              Je suis d'abord un développeur, donc j'ai plutôt tendance à combiner de petits outils en ligne de commande :-)

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: xcf-utils

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

      Je te rejoins complètement sur le fait que Xcftools prend une direction peu fiable en implémentant le format XCF hors de Gimp. Je comptais plutôt sur la libgimp dans l'avenir, sans m'être penché dessus encore. As tu des détails sur ce qui empêche la libgimp d'être utilisé hors de Gimp ? Qu'attend-elle de l'application qui la charge ?

      Au sujet des fonctionnalités, le seul outil qui m'intéresse dans Xcftools est xcfinfo. Pour tout ce qui concerne les opérations sur l'image j'utilise des scripts Scheme que je passe à gimp-console. Du coup ton outil me conviendrait bien à ceci près que j'aimerais que cela fonctionne sous Windows. J'ai commencé à migrer Xcftools pour pouvoir livrer une version Windows mais ça me semble plus difficile avec ton outil qui utilise des scripts shell.

      Je migre le journal dans l'espace de rédaction. Es-tu intéressé pour y présenter xcf-utils ?

      • [^] # Re: xcf-utils

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

        Salut,

        As tu des détails sur ce qui empêche la libgimp d'être utilisé hors de Gimp ? Qu'attend-elle de l'application qui la charge ?

        Techniquement aucune idée. J'imagine qu'à l'origine pas grand chose, mais à l'heure actuelle, changer cela doit être vraiment compliqué.
        Théoriquement, je vois personnellement aucune raison. Je vois pas pourquoi on pourrait pas avoir une libgimp totalement indépendante, et GIMP utiliserait cette libgimp (et d'autres applications pourraient aussi). C'est à vrai dire ce que je ferais si je développais GIMP de zéro aujourd'hui (à vrai dire, pour tout "gros" projet que je fais, c'est le type de design que je fais: baser le programme sur une librarie indépendante qui implémente le cœur des fonctionnalités).
        Historiquement j'imagine qu'à l'origine les développeurs n'ont fait la libgimp que dans l'idée d'avoir des plugins. Ils n'ont pas dû s'imaginer à l'époque que des gens pourraient vouloir ouvrir des fichiers XCF hors de GIMP.
        Factuellement une application indépendante ne peut faire un include de la libgimp. Tu peux essayer, tu peux compiler, et au moment de lancer, ça dit ça:
        bash
        ./test is a GIMP plug-in and must be run by GIMP to be used

        Même erreur si ton plugin est python, C, script-fu, etc. Tu dois donc lancer d'abord la console gimp et de là lancer ton script.

        Au sujet des fonctionnalités, le seul outil qui m'intéresse dans Xcftools est xcfinfo. Pour tout ce qui concerne les opérations sur l'image j'utilise des scripts Scheme que je passe à gimp-console. Du coup ton outil me conviendrait bien à ceci près que j'aimerais que cela fonctionne sous Windows. J'ai commencé à migrer Xcftools pour pouvoir livrer une version Windows mais ça me semble plus difficile avec ton outil qui utilise des scripts shell.

        Ok donc tu pourrais utiliser mon outil en effet (xcf-info, note le tiret, pour pas empêcher les gens qui veulent tester les deux).
        En plus je me suis réveillé ce matin en me disant "pourquoi je l'ai pas écrit en C?". En effet le plus problématique de mon script est sa lenteur. Or la lenteur est dûe à 3 facteurs:
        - on charge GIMP (sans UI, mais quand même): ça, je peux rien y faire;
        - je fais un hash de chaque image de layer: ça c'est pour moi une fonctionnalité indispensable pour rendre xcf-info utile lors d'un git diff;
        - c'est du python.
        Sur des petits XCF, c'est raisonnable, mais je travaille avec des XCF en HD (1920x1080) avec des dizaines de calques, si ce n'est une centaine, de calques.
        Donc comme je disais, ce matin, je me suis dit que le fait que ce soit en python est le seul truc que je peux changer. J'ai donc passé plusieurs heures à réimplémenter mon xcf-info en C (j'ai au passage découvert et corrigé un bug dans gimptool, c'est une bonne journée). Il est maintenant 2 à 3 fois plus rapide que la version en Python. J'ai quasi fini. Je pense que je pousserai ça sur le dépôt un peu plus tard aujourd'hui.

        Pour le petit script shell, il fait genre une dizaine de lignes, tu l'as regardé? En gros il se contente d'encapsuler l'appel à gimp-console (parce que c'est une ligne de commande à se taper la tête au mur si on voulait retenir cela), rien d'autre (j'ai quelques lignes pour simuler un --help, mais c'est pour faire joli, y a en gros qu'une seule ligne qui sert à quelque chose en fait). Je sais bien que le shell Windows est nul comparé même aux shell Unix les plus basiques, mais ça je pense que ça peut forcément le faire quand même.
        Si tu fais ce petit script Windows, n'hésite pas à m'envoyer le patch, je l'intégrerai pour les plateformes Windows. :-)

        Je migre le journal dans l'espace de rédaction. Es-tu intéressé pour y présenter xcf-utils ?

        Bien sûr.

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Suivre le flux des commentaires

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