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 ]
# xcf-utils
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Outils autour de Gimp : Pack My Sprites et Xcftools. É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 ]