Colorisation intelligente dans GIMP

En tant que membre de l’équipe Image du laboratoire GREYC (CRNS, ENSICAEN, Université de Caen), j’ai implémenté un algorithme de “remplissage de dessin au trait” dans GIMP, aussi appelé “colorisation intelligente“. Vous avez peut-être entendu parler du même algorithme dans G’Mic (développé par la même équipe), donc quand on m’a proposé l’emploi, cet algorithme m’a rapidement intéressé. Ce devint ma première mission!

Le problème

Conceptuellement le remplissage de dessin au trait est simple: vous dessinez une forme au stylo noir, disons un cercle approximé, et vous souhaitez le remplir d’une couleur de votre choix. Vous pouviez déjà le faire, plus ou moins, avec l’outil de remplissage, en remplissant les couleurs similaires… à 2 problèmes près:

  1. Si le trait n’est pas bien fermé (il y a des “trous”), la couleur fuite. Les trous peuvent être le fait d’erreur de dessin, cependant on ne les trouve pas forcément aisément (cela peut être un trou d’un pixel au pire des cas), et perdre du temps à les trouver n’est pas très marrant. En outre, cela peut être un choix conscient voire artistique.
  2. Le remplissage laisse en général des pixels non coloriés proche des bordures du traits, à cause de l’interpolation, l’anti-aliasing ou pour d’autres raisons (à moins de ne dessiner qu’avec des pixels pleins, style “pixel art”), ce qui n’est pas un résultat acceptable.
2 principaux problèmes du remplissage des couleurs similaires

En conséquence, probablement aucun coloriste numérique n’utilise l’outil de remplissage directement. Diverses autres méthodes nécessitent par exemple l’outil de sélection contiguë (ou d’autres outils de sélection), l’agrandissement ou réduction de la sélection, puis seulement à la fin le remplissage. Parfois peindre directement avec une brosse est la méthode la plus adaptée. Assister à un atelier d’Aryeom sur le sujet de la colorisation est d’ailleurs absolument fascinant. Elle peut enseigner une dizaine de méthodes différentes utilisées par les coloristes. Elle-même n’utilise pas toujours la même procédure (cela dépend de la situation). Pour le project ZeMarmot, j’ai aussi écrit des scripts Python d’aide à la colorisation, qu’Aryeom utilise maintenant depuis des années, et qui fait un boulot très raisonnable d’accélération de cette tâche ingrate (mais la tâche reste ingrate malgré tout).

L’algorithme

Le papier de recherche s’intitule “Un algorithme semi-guidé performant de colorisation en aplats pour le dessin au trait” (on notera qu’il existe une version anglaise, mais le papier français est plus détaillé: “A Fast and Efficient Semi-guided Algorithm for Flat Coloring Line-arts“). J’ai travaillé sur la base d’un code C++ de Sébastien Fourey, avec les avis de ce dernier ainsi que de David Tschumperlé, tous deux co-auteurs du papier.

Pour nos besoins, je me suis intéressé à ces deux étapes de l’algorithme:

  1. La fermeture des traits, par la caractérisation de “points d’intérêt”, lesquels sont les bords de traits avec courbures extrêmes (on peut alors estimer que ce sont probablement des extrémités de lignes), puis en joignant ces points d’intérêts en définissant des facteurs de qualités à base des angles de normales, ou de distance maximum. Les lignes peuvent être fermées avec soit des splines (c’est à dire des courbes) soit des segments droits.
  2. La colorisation proprement dite, en “mangeant” un peu sous les pixels de traits, ainsi de s’assurer de l’absence de pixels non-coloriés près des bords.

Comme on peut le voir, l’algorithme prend donc en compte les 2 problématiques (que j’ai numérotées dans le même ordre, comme par hasard 😉)! Néanmoins je n’ai implémenté que la première étape de l’algorithme et ai adapté la seconde avec une solution propre (quoique basée sur des concepts similaires) à cause de problématiques d’utilisabilité.

Et voici donc le remplissage par détection de traits dans GIMP:

Remplissage par détection de trait

Je ne vais pas réexpliquer l’algorithme en détail. Si c’est ce qui vous intéresse, je suggère plutôt de lire le papier de recherche (10 pages), lequel est très clair, et a même des images très explicites. Si vous préférez lire du code, comme moi, plutôt que des équations, vous pouvez aussi regarder directement l’implémentation dans GIMP, principalement contenue dans le fichier gimplineart.c, en commençant en particulier avec la fonction gimp_line_art_close().

Ci-dessous, je vais plutôt me focaliser sur les améliorations que j’ai faites à l’algorithme, et que vous ne trouverez pas dans les papiers de recherche. Je rappelle aussi que nous avons travaillé avec l’animatrice/peintre Aryeom Han (réalisatrice de ZeMarmot) comme artiste-conseil, pour rendre l’implémentation utile pour de vrai, non juste théoriquement.

Note: cet article se concentre sur l’aspect technique de la fonctionnalité. Si vous souhaitez seulement savoir comment l’utiliser, je conseille d’attendre quelques jours ou semaines. Nous ferons une courte (néanmoins aussi exhaustive que possible) vidéo pour montrer comment l’utiliser ainsi que le sens de chaque option.

Étape 1: fermeture des traits

Pour donner un aperçu rapide de la logique algorithmique, voici un exemple simple à partir d’une ébauche de dessin par Aryeom (bon exemple puisqu’une telle esquisse est pleines de “trous”!). À gauche, vous pouvez voir l’esquisse, au milieu comment elle est traitée par l’algorithme (cette version de l’image n’est jamais visible par le peintre), et à droite mon essai de colorisation en aplats (avec l’outil de remplissage seulement, pas de brosse, rien!) en moins d’une minute (chronométrée)!

De lignes à colorisation, avec représentation interne au centre

Note: bien sûr, il ne faut pas voir cela comme un exemple de “travail final”. Le travail de colorisation est en général en plusieurs étapes, la première consistant en l’application d’aplats de couleur. Cet outil ne participe qu’à cette première étape et l’image peut nécessiter du travail supplémentaire (d’autant plus avec cet exemple qui se base sur une esquisse).

Estimer une épaisseur de trait globale locale (algo amélioré)

Un aspect de l’algorithme est rapidement apparu comme suboptimal. Comme dit plus haut, nous détectons les points clés grâce à la courbure des lignes. Cela pose problème avec les très grosses brosses (soit parce que vous peignez dans un style “lignes épaisses” ou bien juste parce que vous peignez en très haute résolution, donc avec des lignes “fines de dizaines de pixels”, etc.). L’extrémité de telles lignes peut alors présenter une courbure basse et donc ne pas être détectées. Dans le papier originel, la solution proposée au problème est:

Afin de rendre la méthode de fermeture indépendante de la résolution de l’image, une étape préliminaire permet de réduire si besoin l’épaisseur des tracés à quelques pixels, en utilisant une érosion morphologique. Le rayon utilisé pour cette érosion est déterminé automatiquement par estimation de la largeur des traits présents dans le dessin.

Section ‘2.1. Pré-traitement de l’image anti-aliasée’

Malheureusement calculer une estimation de largeur de traits unique pour un dessin entier présente des limites, puisque cela part du principe que le trait a une épaisseur constante. Demandez donc à un calligraphe ce qu’il en pense pour rigoler! 😉

En outre bien que cela fonctionnait globalement, des effets secondaires pouvaient apparaître. Par exemple des trous inexistants au préalable pouvaient apparaître (en érodant une ligne plus fine que la moyenne). Le papier était conscient de ce problème mais l’écartait en supposant que ce trou serait de toutes façons refermé dans l’étape de fermeture qui suivait nécessairement:

Il est à noter que d’éventuelles déconnexions provoquées par l’érosion appliquée, qui restent rares, seront de toute façon compensées par l’étape suivante de fermeture des traits.

Section ‘2.1. Pré-traitement de l’image anti-aliasée’

Pourtant dès les tests initiaux qu’Aryeom a effectuées avec la première version implémentée de l’outil, elle a rencontré des cas similaires. Une fois même, nous avions une zone parfaitement fermée à la base qui laissait fuiter la couleur, une fois l’algorithme appliqué ⇒ nous obtenions donc l’effet inverse du but de l’algoritme! Paradoxal! Pire, alors que trouver des micros trous dans des traits pour les combler est compliqué, trouver des micros trous invisibles (car existants seulement dans une représentation interne du dessin) tient de la gageure.

Pour couronner le tout, cette érosion ne semblait même pas vraiment bien accomplir son but, puisqu’on arrivait aisément à créer des dessins avec de grosses brosses où aucun point clé n’était détecté malgré l’étape d’érosion. Au final donc, cette étape d’estimation d’épaisseur de trait globale+érosion apportait plus de problèmes qu’elle n’en réglait.

Conclusion: pas glop!

Après de longues discussions avec David Tschumperlé et Sébastien Fourey, nous en sommes arrivés à une évolution de l’algorithme, en calculant des épaisseurs de ligne locales pour chaque pixel de trait (plutôt qu’une unique épaisseur de trait pour le dessin entier), simplement basé sur une fonction distance du dessin. Nous pouvons alors décider si une courbure est symptomatique d’un point clé relativement à l’épaisseur locale (plutôt qu’un test absolu sur un dessin érodé par une épaisseur moyenne).

Non seulement cela fonctionnait mieux, cela ne créait pas de nouveaux trous invisibles dans des zones fermées, détectait des points clés sur de très gros traits en supposant la variabilité des traits (que ce soit un choix stylistique ou parce que la perfection n’est pas de ce monde!), mais en plus c’était même plus rapide!

En exemple, la version originelle de l’algorithme n’aurait pas réussi à détecter les points d’intérêt pour fermer cette zone avec de si gros traits. Le nouvel algorithme n’a aucun problème:

» Pour ceux intéressés, voir le code du changement «

Parallélisation pour traitement rapide

La fermeture de traits est clairement l’étape la plus longue du traitement. Bien que cela reste raisonnable sur des images FullHD voire même 4K, sur mon ordinateur, cela pouvait tout de même prendre une demi-seconde de traitement. Pour un outil intéractif, une demi seconde, c’est un siècle! Sans compter si on se met à traiter des images énormes (pas impossible de nos jours), cela peut alors prendre plusieurs secondes.

J’effectue donc ce calcul en parallèle afin qu’il soit exécuté au plus tôt (dès que l’outil de remplissage est sélectionné). Puisque les gens ne sont pas des robots, cela rend l’intéraction bien plus rapide en apparence, voire dans de nombreux cas, on peut ne même pas se rendre compte qu’il y a eu temps de traitement.

Available line art “Source” in the tool options

Partiellement pour la même raison, vous pourrez remarquer une option “Source” qui propose plus qu’à l’habitude dans d’autres outils (“Échantilloner sur tous les calques” ou sur le calque actif uniquement). Pour cet outil, vous pouvez aussi choisir le calque au dessus ou dessous du calque actif. C’est le résultat à la fois d’une décision logique (la couleur appliquée n’est pas du trait par définition) et pour des raisons de performance (il n’est pas nécessaire de recalculer la fermeture à chaque ajout de couleur).

Étape 2: remplissage

Rendre l’algorithme interactif et résistant aux erreurs

Le papier propose de remplir toutes les zones d’un coup à l’aide d’un algorithme de watershed.

J’ai fait le choix de ne pas honorer cette étape de l’algorithme, principalement pour raison d’utilisabilité. Lorsque j’ai vu les images de démonstration de cet algorithme sur G’Mic pour la première fois, le résultat semblait très prometteur; puis j’ai vu l’interface graphique, et cela semblait peu utilisable. Mais comme je ne suis pas le peintre de l’équipe, je l’ai montré à Aryeom. Ses premiers mots après la démo furent en substance: “je n’utiliserai pas“. Notez bien qu’on ne parle pas du résultat final (qui n’est pas mal du tout), mais bien de l’intéraction humain-machine. La colorisation est fastidieuse, mais si la colorisation intelligente l’est encore plus, pourquoi utiliser?

Qu’est-ce qui est donc fastidieux? G’Mic propose plusieurs variantes pour colorier une image: vous pouvez par exemple laisser l’algorithme colorier aléatoirement les zones, ce qui permet ensuite de sélectionner chaque aplat indépendamment pour recolorisation; vous pouvez aussi guider l’algorithme avec des touches de couleurs, en espérant qu’il fonctionnera suffisamment bien pour inonder les bonnes zones avec les bonnes couleurs. Je propose aussi de regarder cet article sympa de David Revoy, qui avait contribué à la version de base de l’algorithme.

filtre « Colorize lineart [smart coloring] »
La colorisation intelligente dans G’Mic est un peu complexe…

Ce sont des méthodes intéressantes et très sûrement utilisables, voire efficaces, dans certains cas, mais ce n’est pas une méthode générique que vous voudrez utiliser dans tous les cas.

Déjà cela implique beaucoup d’étapes pour colorier un seul dessin. Pour l’animation (par exemple le projet ZeMarmot), c’est encore pire, car nous devons coloriser des dizaines ou centaines de calques.
En outre, cela implique que l’algorithme ne peut se tromper. Or nous savons bien qu’une telle hypothèse est absurde! Des résultats non voulus peuvent se produire, ce qui n’est pas obligatoirement un problème! Ce qu’on demande à un tel algorithme est de fonctionner la plupart du temps, du moment que l’on peut toujours revenir à des méthodes plus traditionnelles pour les rares cas où cela ne fonctionne pas. Si vous devez défaire la colorisation globale (car faite en étape unique), puis essayer de comprendre l’algorithme pour refaire vos touches de couleurs en espérant que la prochaine fois, cela marche mieux afin d’essayer encore, un peu à l’aveuglette, alors l’utilisation d’un algorithme “intelligent” ne peut être que perte de temps.

À la place, nous avions besoin d’un procédé de colorisation intéractif et progressif, de sorte que les erreurs de l’algorithme puissent être simplement contournées en revenant temporairement à des techniques traditionnelles (juste pour quelques zones). C’est pourquoi j’ai basé l’intéraction sur l’outil de remplissage qui existait déjà, de sorte que la colorisation (par détection de traits) fonctionne comme cela a toujours fonctionné: on clique et on voit la zone cliquée être remplie devant ses yeux… une zone à la fois!

C’est simple et surtout résistant aux erreur. En effet si l’algorithme ne détecte pas proprement la zone que vous espériez, vous pouvez simplement annuler pour corriger seulement cette zone.
En outre je voulais éviter de créer un nouvel outil si possible (il y en a déjà tellement!). Après tout, il s’agit du même cas d’usage dont s’est toujours occupé l’outil de remplissage, n’est-ce pas? Il s’agit simplement d’un algorithme différent pour décider comment se fait le remplissage. Il est donc tout à fait logique que ce ne soit qu’une option dans le même outil.

En conclusion, je remplace le watershedding sur l’image totale en utilisant encore une carte de distance. Nous avions déjà vu que cela sert comme estimation décente d’épaisseur (ou de demi-épaisseur pour être précis) locale des lignes. Donc quand on remplit avec une couleur, on utilise cette information pour inonder sous les pixels de lignes (jusqu’au centre de la ligne approximativement). Cela permet ainsi de s’assurer qu’aucun espace non colorié ne soit visible entre le remplissage et les traits. Simple, rapide et efficace.
C’est une sorte de watershedding local, en plus simple et rapide, et cela m’a aussi permis d’ajouter un paramètre “Max flooding” pour garder l’inondation de couleur sous contrôle.

Colorisation intelligente sans la partie “intelligente”!

Un usage possible, et bien cool, de ce nouvel algorithme est de se passer de la première étape, c’est-à-dire ne pas calculer la fermeture des traits! Cela peut être très utile si vous utilisez un style de trait sans rupture (design simple avec lignes solides par exemple) et n’avez donc pas besoin d’aide algorithmique de fermeture. Ainsi vous pouvez remplir des zones d’un seul clic, sans vous préoccuper des la sursegmentation ou de la durée du traitement.

Pour cela, mettez le paramère “Maximum gap length” à 0. Voici un exemple de design très simple (à gauche) rempli avec l’algorithme historique par couleurs similaires (au centre) et par détection de traits (à droite), en un clic:

Gauche: AstroGNU par Aryeom – Centre: remplissage par couleurs similaires – Droite: remplissage par détection de traits

Vous voyez le “halo blanc” entre la couleur rouge et les lignes noires sur l’image du milieu? La différence de qualité avec le résultat à droite est assez frappant et explique pourquoi l’algorithme de remplissage historique par “couleurs similaires” n’est pas utilisable (directement) pour du travail qualitatif de colorisation, alors que le nouvel algorithme par détection de traits l’est.

Outil de remplissage amélioré pour tous!

En bonus, j’ai dû améliorer l’intéraction de l’outil de remplissage de manière générique, pour tout algorithme. Cela reste similaire, mais avec ces détails qui font toute la différence:

Clic et glisse

J’ai mentionné plus haut un problème de “sursegmentation”. En effet on peut appeler un algorithme “intelligent” pour le rendre attrayant, cela ne le rend pas pour autant “humainement intelligent”. En particulier, nous créons des lignes de fermetures artificielles basées sur des règles géométriques, pas de reconnaissance réelle de forme ni en fonction du sens du dessin, et encore moins en lisant dans les pensées de l’artiste! Donc souvent, cela segmentera trop, en d’autres termes, l’algorithme créera plus de zones artificielles qu’idéalement souhaitées (si en plus, vous peignez avec une brosse un peu crénelée, cela peut être très mauvais). Regardons à nouveau l’image précédente:

L’image est “sur-segmentée”

Le problème est clair. on voudra sûrement coloriser le chien avec un aplat de couleur unique, par exemple. Pourtant il a été divisé en une vingtaine de zones! Avec l’ancienne intéraction de l’outil de Remplissage, vous devriez alors cliquer 20 fois (au lieu du clic idéal à 1), ce qui est contre-productif. J’ai donc mis-à-jour l’outil pour autoriser le clic glissé, tel un outil de peinture avec brosse: cliquez, ne relâchez pas et glissez sur les zones à colorier. Cela est désormais possible avec le remplissage par détection de traits ainsi que sur couleurs similaires (pour le remplissage sur sélection, c’est par contre non pertinent, bien sûr). Cela rend le remplissage de dessin sursegmenté bien moins problématique puisque cela peut être fait d’un seul tracé. Ce n’est pas aussi rapide que le clic unique idéal, néanmoins cela reste tolérable.

Prélèvement de couleurs

Une autre amélioration notable est le prélèvement aisé de couleurs avec ctrl-clic (sans avoir besoin de sélectionner la pipette à couleurs). Tous les outils de peinture avaient déjà cette fonctionnalité, mais pas encore l’outil de remplissage. Pourtant on travaille là aussi clairement avec la couleur. Par conséquent pouvoir très aisément changer de couleur par prélèvement sur les pixels alentour (ce qui est un usage très commun des peintres numériques) rend l’outil extrêmement productif.

Avec ces quelques changements, l’outil de remplissage est désormais un citoyen de première classe (même si vous n’avez pas besoin de la colorisation intelligente).

Limitations et travail futur possible

Un algorithme pour peintres numériques

La Colorisation intelligente est faite pour travailler sur des dessins au trait. Cela n’est pas fait pour fonctionner sur des images hors dessin, en particulier des photographies. Bien sûr, on découvre toujours des usages non prévus que des artistes aventureux inventent. Peut-être cela se produira ici aussi. Mais pour le moment, pour autant que je puisse voir, c’est vraiment réservé aux peintres numériques.

Traiter des cas autres que lignes noires sur fond blanc?

Les lignes sont détectés de la manière la plus basique possible, avec un seuil soit sur le canal Alpha (si vous travaillez sur des calques transparent) ou sur le niveau de gris (particulièrement utile si vous travaillez avec des scans de dessins).

Ainsi la version actuelle de l’algorithme peut avoir quelques difficultés pour détecter des traits, si par exemple vous scannez un dessin sur papier non blanc. Ou tout simplement, vous pourriez avoir envie de dessiner en blanc sur fond noir (chacun est libre!). Je ne suis cependant pas certain si ces cas d’usage sont suffisamment courants pour valoir d’ajouter toujours plus de paramètres à l’outil. On verra.

Plus d’optimisation

Je trouve que l’algorithme reste relativement rapide sur des images de taille raisonnable, mais je le trouve encore un peu lent sur de grosses images (ce qui n’est pas un cas rare non plus, notamment dans l’industrie de l’impression), malgré le code multi-thread. Je ne serais donc absolument pas surpris si dans certains cas, vous ne préfériez pas simplement revenir à vos anciennes techniques de colorisation.

J’espère pouvoir revenir tranquillement sur mon code bientôt pour l’optimiser davantage.

Des bordures de couleur peu esthétiques

Le bord du remplissage n’est clairement pas aussi “joli” qu’il pourrait l’être par exemple en coloriant avec une brosse (où le bord montrerait un peu de “texture”. Par exemple, jetons à nouveau un œil à notre exemple d’origine.

L’endroit où le bord du remplissage est visible aura probablement besoin d’une retouche. J’ai ajouté un paramère d'”antialiasing” mais clairement ce n’est pas une vraie solution dans la plupart des cas. Ça ne remplace pas une édition manuelle avec une brosse.

Le pire cas est lorsque vous planifiez de retirer les traits après colorisation. Aryeom fait parfois ce type de dessins où les lignes ne servent qu’en support de travail avant d’être retirées pour le rendu final (en fait une scène entière dans ZeMarmot, un peu “rêveuse”, est faite ainsi). Dans ce cas, vous avez besoin d’un contrôle parfait de la qualité des bords des zones de couleurs. Voici un exemple où le dessin final est fait uniquement de couleurs, sans traits externes:

Image de production du film ZeMarmot, par Aryeom

Pas encore d’interface (API) pour les plug-ins

Je n’ai pas encore ajouté de fonctions pour que les scripts et plug-ins puissent faire du remplissage par détection de trait. Cela est fait exprès car je préfère attendre un peu après la première sortie, notamment pour m’assurer que nous n’avons pas besoin de plus ou meilleurs paramètres, puisque une API se doit de rester stable et de ne plus changer une fois créée, au contraire d’une interface graphique qui peut se permettre plus facilement des changements.

En fait vous vous êtes peut-être rendus compte que toutes les options disponibles dans G’Mic ne sont pas disponibles dans les options d’outils de GIMP (même si elles sont toutes implémentées). C’est parce que j’essaie de rendre l’outil moins confus, étant donné que nombres de ces options nécessitent de comprendre la logique intime de l’algorithme. Plutôt que de passer son temps à trifouiller des curseurs au hasard, j’essaie de trouver une interface qui nécessite peu d’options.

Outil de sélection contiguë

La détection de traits n’est pour l’instant implémentée que pour l’outil de remplissage, mais cela serait aussi tout à fait adapté comme méthode de sélection alternative pour l’outil de sélection contiguë. À suivre…

Segmenter moins

Avec des lignes propres et nets, et des formes simples, l’algorithme marche vraiment bien. Dès que vous complexifiez votre dessin, et surtout utilisez des traits avec un peu de caractère (par exemple la série de brosses “Acrylic”, fournie dans GIMP par défaut), un peu trop de points clés faux-positifs sont détectés, et par conséquent le dessin sur-segmente. Nous sommes tombés sur de tels cas, donc j’ai essayé diverses choses, mais pour l’instant je ne trouve aucune solution miracle. Par exemple récemment j’ai essayé d’appliquer un flou médian sur le trait avant la détection de points clés. L’idée est de lisser les imperfections du trait crénelé. Sur mon exemple de base, cela a bien marché:

Centre: sur-segmentation avec l’algorithme actuel
Droite: toujours trop segmenté, mais bien moins, après avoir appliqué d’abord un flou médian

Malheureusement cela a rendu le résultat sur d’autres images très mauvais, notamment en créant des trous (un problème dont nous nous étions débarrassé en ne faisant plus d’étape d’érosion!).

Centre: résultat très acceptable avec l’algorithme actuel
Droite: mauvais résultat qui ferait fuiter la couleur et qui perd de nombreux détails

Donc je cherche toujours. Je ne sais pas si on trouvera une vraie solution. Ce n’est clairement pas un sujet facile. On verra!

En règle générale, la sursegmentation (faux positifs) est un problème, mais il reste moindre que ne pas réussir à fermer des trous (faux négatifs), notamment grâce à la nouvelle intéraction clic et glisse. J’ai déjà amélioré quelques problèmes à ce sujet, tels les micro-zones que le papier de recherche appelle des “régions non significatives” (or elles sont vraiment significatives pour les peintres numériques, car rien n’est plus embêtant à remplir que des petits trous de quelques pixels); et récemment j’ai aussi réglé des problèmes liés à l’approximation rapide de la surface des régions, laquelle peut être fausse dans le cas de régions ouvertes.

Conclusion

Ce projet fut vraiment intéressant car il a confronté des algorithmes de recherche à la réalité du travail de dessin au quotidien. C’était d’autant plus intéressant avec la rencontre de 3 mondes: la recherche (un algorithme vraiment cool pensé par des esprits brillants du CNRS/ENSICAEN), le développement (moi!) et l’artiste (Aryeom/ZeMarmot). Par ailleurs, pour bien donner le crédit à qui de droit, beaucoup des améliorations d’interface furent des idées et propositions d’Aryeom, laquelle a testé cet algorithme sur le terrain, c’est à dire sur de vrais projets. Cette coopération CNRS/ZeMarmot s’est même tellement bien passée qu’Aryeom a été invitée fin janvier pour présenter son travail et ses problématiques de dessin/animation lors d’un seminaire à l’université ENSICAEN.

Bien sûr, je considère encore ce projet comme un “travail en cours”. Comme noté plus haut, divers aspects doivent encore être améliorés. Ce n’est plus mon projet principal mais je reviendrai clairement régulièrement pour améliorer ce qui doit l’être. C’est néanmoins déjà dans un état tout à fait utilisable. J’espère donc que de nombreuses personnes l’utiliseront et apprécieront. Dites nous ce que vous en pensez!

Un dernier commentaire est que les idées derrière les meilleurs algorithmes ne semblent pas nécessairement les plus incroyables techniquement. Cet algorithme de colorisation intelligente est basé sur des transformations très simples. Cela ne l’empêche pas de fonctionner très bien et d’être relativement rapide (avec quelques limites bien sûr), de ne pas prendre toute votre mémoire vive en bloquant l’interface du logiciel pendant 10 minutes… Pour moi, cela est bien plus impressionnant que certains algorithmes certes brillant, et pourtant inutilisables sur les ordinateurs de bureau. C’est de ce type d’algorithme dont on a besoin pour les logiciels de graphisme pour le bureau. C’est donc très cool et je suis d’autant plus heureux de travailler avec cette équipe talentueuse de G’Mic/CNRS. 🙂

Amusez vous bien à colorier vos dessins! 🙂

Notre vision pour LILA et ZeMarmot

Imaginez un studio de film, avec des artistes et techniciens qualifiés, qui travaillent sur des films ou des séries intéressantes… et qui les partagent sous une Licence Libre, pour être visibles par tous, partout (télé, cinéma, web…), partageables et réutilisables.

Imaginez maintenant que ce studio utilise essentiellement du Logiciel Libre (et de l’Open Hardware si disponible), qu’ils le corrigent, voire modifient et l’améliorent au besoin, aussi bien pour des logiciels finaux (tels que GIMP, Blender, Inkscape…), de bureau (tel GNOME), voire jusqu’au système d’exploitation (GNU/Linux) et tout le reste!

Voici donc mon rêve pour l’association à but non lucratif LILA, et pour le projet ZeMarmot (notre premier film, d’animation). C’est ce que je vise depuis le début, mais je me dis que ce n’était peut-être pas suffisamment clair.

Si vous aimez ce rêve, je vous encourage à nous aider en donnant par Patreon, Tipeee, Liberapay, ou tout autre moyen (donation directe bancaire, Paypal, etc.). Car comme toute association à but non lucratif, LILA et ZeMarmot vit par et pour vous!

Si vous voulez lire plus, je rajoute des détails ci-dessous!

Mon emploi actuel

Au niveau personnel, j’ai récemment été engagé pour un an par le CNRS pour développer du code touchant à GIMP et G’Mic.

J’ai peu de salaire stable depuis quelques années, et je suis donc content que ce soit pour travailler sur GIMP (ce que j’ai fait bénévolement ou peu payé pendant 6 ans!)!
Pour ajouter un peu de contexte, l’équipe de G’Mic m’avait d’abord proposé de travailler sur un plug-in Photoshop, ce que j’ai poliment refusé. Je n’ai rien contre Photoshop, mais ce n’est sûrement pas le boulot de mes rêves. Le projet fut alors retravaillé pour que je puisse continuer à travailler avec GIMP. Deux projets principaux ont été identifiés:

  1. La gestion d’extension dans GIMP, ce dont j’avais déjà parlé (sans savoir à l’époque que je serais engagé pour cela), puisque cela aidera beaucoup G’Mic à être installé. J’en profiterai aussi pour améliorer les extensions de manière générale (ce que je prévoyais d’ailleurs depuis le début).
  2. L’implémentation de leur algorithme de colorisation intelligente dans GIMP. Ce projet vint de ma propre initiative quand ils m’ont proposé de travailler ensemble, car cela rentrait très bien dans mes propres plans, et rendrait enfin leur super algo “utile” (l’interaction dans G’Mic est des plus douloureuses!). J’en reparlerai dans un article dédié. Voici pour donner une idée:

Et ZeMarmot dans tout ça?

ZeMarmot est mon projet adoré (de même que celui d’Aryeom). Je le chéris et c’est là que je vois un futur (pas forcément ZeMarmot en soi, mais là où ça va mener). Ainsi même si j’ai une autre source de revenu temporaire, je voudrais réitérer que si vous aimez ce que j’ai fait jusque là, alors c’est à ZeMarmot qu’il faut donner. Financer ZeMarmot est le seul moyen de me permettre de continuer à améliorer GIMP sur le long terme.

Je vois cette année avec le CNRS comme une opportunité de permettre à ZeMarmot de s’épanouir. Car soyons clair, ce n’est pas encore le cas. Chaque année, nous répétons la routine de demander votre aide, et d’ailleurs on est très peu doué sur ce point (quand je vois notamment que les autres assos et fondations ont commencé leurs campagnes de dons depuis un mois!). On est des techniciens essentiellement (développeurs, animateurs…), et on est vraiment nul en marketing. Donc voici notre demande à la dernière seconde!

À ce jour, nous sommes financés à peine au dessus des 1000 € par mois, ce qui ne permet même pas de payer un salaire à temps plein au minimum légal en France. Ainsi en 2018, LILA a été capable d’engager Aryeom (réalisation/animation) et moi-même (développement) en moyenne 6 jours par mois. C’est peu! Pourtant c’est ce qui nous a fait vivre.
On a estimé qu’il faut au moins 2100€ par mois pour une personne, et qu’en vrai nous avons besoin de 5000€ par personne pour un salaire raisonnable et des conditions de travail acceptables (nous avons vu d’ailleurs que la fondation Blender fait aussi cette même estimation), même si cela reste sous les prix du marché d’ailleurs. Notre financement actuel est donc 4 fois trop petit pour un minimum déraisonnable et 10 fois sous le minimum raisonnable. Sans même parler de la lointaine possibilité d’engager plus de gens. Triste, hein?

LILA en 2 mot

LILA est enregistrée officiellement en France comme une association à but non lucratif, loi 1901. Son numéro d’activité est celui d’une production de film, lui donnant un statut vraiment unique lui autorisant d’engager des gens pour la production de films libres, ce qui est fait depuis 3 ans.

Le but de cette production n’est pas l’enrichissement d’actionnaires quelconques (il n’y en a pas). Nous voulons créer nos œuvres, les faire connaître et passer au projet suivant. Car nous aimons ce que nous faisons. C’est pour cela que ZeMarmot est sous licence Creative Commons by-sa, permettant à chacun de télécharger le film, le partager avec amis et famille, et même de le vendre ou de le modifier! Sans blague! Nous proposerons même chaque image source avec les calques!

En outre LILA paye de vrai salaire pour chaque participant. En effet, nous ne considérons pas que “Art Libre” signifie “œuvre au rabais” ou même “amateurisme”. C’est un projet sympa? Oui. Mais c’est aussi professionnel.

Ainsi si LILA était soudainement financé au dessus de toutes nos espérances, cela ne ferait pas de salaires indécents. Simplement LILA pourra embaucher plus de personnes pour faire des superbes films et logiciels plus rapidement et ainsi rendre le monde de l’Art plus agréable. C’est ça être une association à but non lucratif!

Et le logiciel Libre alors?

Là c’est l’autre aspect du studio: nous utilisons uniquement des logiciels libres! Non seulement cela, mais aussi pour en développons! Je ne parle pas de libérer un script interne, mal fait et utilisé par 3 personnes dans le monde tous les 36 du mois. En particulier, nous faisons partie de l’équipe de développement de GIMP! Ces dernières années, un quart des commits de GIMP sont les notres (ce qui peut être aisément vérifié, en particulier les commits à mon nom “Jehan”, de même que ceux d’Aryeom et Lionel N.) Je suis aussi à l’origine de la relaxe de notre politique de sortie pour que nous sortions davantage de versions de GIMP avec de nouvelles fonctionnalités (cela fait des années que je demandais cela et fut finalement acté depuis GIMP 2.10.0!). Il me semble évident que LILA a eu une contribution positive et importante pour GIMP.

Bien sûr GIMP est donc notre projet logiciel principal, ce qui n’a pas empêché divers patches ici ou là dans d’autres logiciels, parfois majeurs! Sans compter nos rapports de bugs très réguliers quand nous n’avons pas le temps de corriger nous-même… nous sommes aussi des utilisateurs importants de tablettes graphiques, avons des contacts avec des dévs de Wacom et Red Hat (on est d’ailleurs désolés, on sait qu’on peut être un peu chiant parfois avec nos bugs! 😛). Et ainsi de suite. Ainsi la seule chose nous empêchant d’en faire plus est le temps. On a besoin de plus de mains, ce qui ne peut être amélioré que si notre financement nous permet enfin d’engager de nouveaux développeurs!

Aussi soyons clairs: ce n’est pas un truc temporaire. Nous croyons tout simplement aux Logiciel Libre. Nous pensons que c’est la chose à faire, que chacun doit avoir accès aux meilleurs logiciels et aussi que c’est ainsi que peuvent être faits les meilleurs logiciels. Je le disais d’ailleurs: je fais environ 1/4 du code de GIMP. Cela signifie que 3/4 ne sont pas faits par moi! Et c’est sans parler de GEGL (le moteur graphique de GIMP). En d’autres termes, je ne pourrais pas en faire autant seul. J’adore travailler avec certains autres des développeurs les plus brillants que j’ai eu l’occasion de rencontrer. Non seulement cela, mais les autres développeurs de GIMP sont également sympas et agréables. Que demander de plus? C’est ça le logiciel libre.
C’est ainsi que l’utilisation et la contribution au Logiciel Libre est dans les statuts de notre studio, notre “contrat en tant que studio à but non lucratif” et cela ne disparaîtra donc pas.

2018 en revue

Une revue rapide des choses que j’ai faites en 2018:

  • 633 commits, soit près de 2 commits par jour en moyenne, dans la branche master de GIMP (sans compter ce qui est dans les branches de fonctionnalité, mon travail en cours) + mes patches dans divers projets que nous utilisons (GEGL, glib, GTK+, libwebp, Appstream…)
  • Aider le projet MyPaint pour préparer une nouvelle sortie de libmypaint v1 (espérons début 2019), et la création du paquet de données mypaint-brushes (maintenant un paquet officiel de MyPaint!).
  • La création et maintenance continue du flatpak de GIMP sur flathub (d’après ce qu’on nous a dit, le logiciel le plus téléchargé de flathub!)
  • La sauvegarde automatique des images en cas de plantage de GIMP
  • Outils de debug (traces d’exécution, infos de plateforme…)
  • Prise en charge basique de HiDPI sur GIMP 2.10 (et plus à venir pour le futur GIMP 3)
  • Travail en cours pour la gestion d’extension dans GIMP
  • Maintenance de données divers (icônes, brosses, appdata, etc.) de GIMP
  • Travail sur les tablettes et périphériques d’entrée
  • Mentor pour un stagiaire FSF (amélioration de la prise en charge de JPEG 2000)
  • Correction de la plupart des cas d’enfer du DLL des plug-ins sous Windows (problème majeur il y a encore peu!)
  • Revue et amélioration de nombreuses fonctionnalités (redressement d’image dans l’outil de Mesure, libheif, libwebp, plug-in de capture d’écran, texte vertical dans l’outil Texte, et bien plus!)
  • L’option de colorisation intelligence dans l’outil de remplissage

Et probablement plein de choses que j’oublie! J’aide aussi à la maintenance du site et à l’écriture d’article sur gimp.org (63 commits cette année). Et tout cela sans compter les patches sans rapport avec GIMP que je fais aussi (par exemple pour les méthodes d’entrée en Coréen) ou les nombreux rapports de bugs que nous écrivons ou aidons à corriger (notamment en étant les premiers à installer Linux sur une Wacom MobileStudio, ou du moins les premiers à en parler, des bugs furent corrigés jusque dans le noyau, et Wayland).

Quant à Aryeom, en 2018, elle a beaucoup travaillé sur ZeMarmot bien sûr (l’animation requiert énormément de boulot; un jour, on devra peut-être donner plus d’information sur le sujet), nous rapprochant davantage de la sortie du pilote (à ce sujet, nous avons récemment créé un compte Instagram où Aryeom poste régulièrement des images et vidéos courtes de son travail en cours, pour qui est intéressé!). Et aussi elle a participé à des projets tiers (nous rappelons que ZeMarmot ne peut financer que quelques jours par mois pour l’instant!), tel qu’un jeu de société interne pour l’association “Petits Frères des Pauvres“, une vidéo marketing pour le logiciel libre Peertube, des designs de pin’s pour la Free Software Foundation. Elle a aussi donné quelques cours de peinture numérique et retouche avec GIMP à l’université.

Bien sûr elle préférerait passer tout son temps sur ZeMarmot uniquement. Mais encore une fois… on a besoin de vous pour permettre cela!

Le Futur

Comment je vois notre futur: dans quelques années, on peut payer plusieurs artistes (réalisatrice, animateurs, artistes peintres, musiciens…). LILA sera enfin un studio certes petit mais productif.

Et bien sûr cela signifie aussi plusieurs développeurs, donc plus de contrôle sur nos outils de production libres. J’ai tellement de rêves! Enfin un éditeur vidéo stable et puissant sans être tordu (en contribuant au Blender VSE, à Kdenlive ou d’autres projets)? Et quand aurons nous des outils de compositing professionnels maintenus (2018 fut un peu triste)? Sans parler de communication entre outils pour éditer des XCF dans GIMP, voir les changements live dans Blender, etc.? Tant d’espoirs! Tant de rêves à réaliser si on avait le financement!

Les rêves peuvent se réaliser si vous aidez!

Que pouvez-vous y faire? Vous pouvez aider ce studio à devenir viable. Me faire engager par le CNRS est cool personnellement mais fut un peu triste pour ce que cela signifie pour le projet. Cela signifie un manque de dépendance notamment. Sans compter que c’est une situation encore très précaire et temporaire. Ce n’est pas une situation stable, de long terme.

Si nous atteignions 5000€ par mois en 2019, cela serait un premier pas énorme pour le projet et la preuve de viabilité du rêve de studio libre.

Nous aiderez-vous à créer un Studio d’Animation Libre? Le graphisme professionnel 2D Libre est à notre porte. Il lui faut juste un peu d’aide pour lui permettre de passer le pas de porte! 🙂

» Financez dans Patreon (USD $) «
» Financez dans Tipeee (EUR €) «
» Financez dans Liberapay «
» Autres méthodes de donation (notamment virement ou Paypal) «

Passez de bonnes fêtes de fin d’année! Et joyeuse nouvelle année!

Financement collaboratif de la gestion des extensions dans GIMP (et plus!)

Un de mes plus vieux projets pour GIMP est la création d’un système de gestion d’extensions. Le plus vieux message à ce sujet que j’ai pu trouver date de 2013, à peine un an après mes premières contributions.
J’ai commencé à travailler dessus, il y a quelques semaines.

J’ai en fait de nombreux projets concernant les façons d’étendre GIMP: une meilleure interface de plug-ins, la communication bidirectionnelle entre le cœur de GIMP et les plug-ins, et même la possibilité de hacker l’interface graphique de GIMP avec les plug-ins! Mais la priorité: à l’heure actuelle, installer un plug-in ou d’autres ressources est chiant et complexe.

Avant toute chose, un petit rappel:

Vous pouvez financer ZeMarmot/GIMP!

Tout ce que nous faisons pour GIMP, sous licence libre pour tous, est fait grâce au projet ZeMarmot. Ce projet paie notamment le développement de GIMP, puisque cela fait partie des améliorations nécessaires pour notre propre pipeline de production.

Cependant à ce jour, notre financement n’est même pas suffisant pour payer une seule personne à temps plein. Notre studio à but non lucratif a pourtant survécu avec 2 personnes jusque là pendant quelques années, avec des périodes de petites dépressions et de burnouts (un peu-beaucoup dernièrement).

Nous continuons à espérer financer collaborativement assez pour payer 2 salaires pleins et justes. Cela nécessite environ 4 fois le financement actuel. C’est pourquoi nous essayons cette nouvelle approche: parler de nos plans de développement en avance (plutôt qu’une fois faits, comme tout ce que nous avons déjà fait dans GIMP et d’autres logiciels libres), et donc pour une fois, je fais cet appel au financement avant de rentrer dans le détail, car on a vraiment besoin de vous!

Vous aimez les évolutions récentes de GIMP? Souhaitez-vous voir cela continuer dans cette lancée? Si tel est le cas, vous pouvez nous aider! Le projet est financé participativement actuellement sur ces 2 plateformes:

» Patreon crowdfunding (USD) «

» Tipeee crowdfunding (EUR) «

Qu’est-ce qu’une extension?

Ce que j’appelle une extension dans cet article est toute ressource pouvant être installée dans GIMP. Dans mon code actuel, une extension peut inclure:

  • des plug-ins
  • des brosses (brosses natives ou pour le nouvel outil MyPaint)
  • des dynamiques de peinture
  • des dégradés
  • des motifs
  • des palettes
  • des préréglages d’outil

Dans le futur, cela sera étendu pour inclure:

  • des scripts
  • des modèles d’image
  • des thèmes
  • des icônes
  • … et toute autre ressource à laquelle je ne pense pas encore.

Qu’est ce que la gestion d’extension?

Tout simplement, “gérer” des extensions signifier pouvoir:

  • chercher de nouvelles extensions (mises à disposition dans des dépôts distants);
  • installer de nouvelles extensions;
  • désinstaller des extensions;
  • désactiver des extensions (les rendre inactives sans les supprimer);
  • mettre à jour les extensions: quand un créateur d’extension en met une nouvelle version à disposition, GIMP devrait vous en avertir et vous donner la possibilité de mettre à jour en un clic.

Vous avez sûrement déjà une idée du type de fonctionnalité dont je parle. Par exemple, votre navigateur web (Firefox, Chrome, etc.) a probablement une telle fonctionnalité, et il est fort probable que vous ayiez déjà cherché/installé des extensions pour votre navigateurs dans votre vie. En gros, je souhaite que GIMP propose la même chose.
À ce jour “installer” une extension dans GIMP impliquait en général une recherche sur le web qui vous emmène sur une page quelconque (parfois dans des sites pas forcément fréquentables) avec des instructions bizarres vous demandant de télécharger une archive, et de la décompresser dans un répertoire caché au fin fond de votre disque. Parfois cela marchait, parfois non, et vous ne compreniez pas forcément ce que vous faisiez. En un mot: c’est la merde.

Pour le créateur d’extensions

Si vous créez des ressources pour GIMP, par exemple des brosses, des plug-ins, des images de démarrage ou autre, voici ce que ce projet vise pour vous: nous souhaitons mettre en place un site web où vous pourrez uploader vos extensions (nous recyclerons peut-être le vieux domaine registry.gimp.org ou en ferons un nouveau, tel que extensions.gimp.org).
Le code pour ce site sera sur gitlab.gnome.org, bien que le dépôt soit vide pour l’instant (je travaille sur le core code de GIMP en premier) comme je viens à peine d’en demander la création.

Techniquement une extension n’est rien de plus compliquée que l’ajout de métadonnées à votre travail: un nom d’extension, une description, des captures d’écran si votre extension s’y prête, etc. Votre adresse de site web est aussi bienvenue ainsi que celle de votre suivi de bugs, nous permettant de rediriger les gens dans la bonne direction au besoin (rendant votre travail plus efficace). Dans l’implémentation en cours, j’ai choisi le format AppStream de méta-données, bien connu des développeurs de Logiciels Libres, et simple à écrire (nous avons encore des détails à régler pour la prise en charge de Windows et peut-être même non-Linux en général, mais rien d’insurmontable). Les méta-données sont vraiment le composant principal permettant la recherche et la gestion correctes d’extensions!

Nous étendrons ce format avec quelques tags spécifiques vous permettant de décrire le contenu de votre extension. Par exemple, voici un squelette de méta-données pour une extension fournissant un set de brosses à installer (dans l’implémentation en cours, qui pourra changer):

<?xml version="1.0" encoding="UTF-8"?>
<component type="addon">
 <id>info.libreart.brushset</id>
 <extends>org.gimp.GIMP</extends>
 <name>My cool brush set</name>
 <summary>A collection of brushes for GIMP</summary>
 <url type="homepage">https://libreart.info</url>
 <metadata_license>CC0-1.0</metadata_license>
 <project_license>GPL-3.0+</project_license>
 <releases>
  <release version="0.1" date="2018-06-07" />
 </releases>
 <requires>
  <id version="2.10" compare="ge">org.gimp.GIMP</id>
 </requires>
 <metadata>
  <value key="GIMP::brush-path">brushes</value>
 </metadata>
</component>

C’est pas plus compliqué. Vous mettez vos brosses dans le répertoire brushes/ (tel que décrit par la clé “GIMP::brush-path“) et voilà!

Ce que ça change pour GIMP

Deux autres conséquences vraiment sympa si nous transformons certaines de nos données ou plug-ins fournis par défaut avec GIMP:

  1. Il vous sera possible de désactiver des fonctionnalités ou données dont vous n’avez que faire. J’ai entendu dire que certains supprimaient même des fichiers pour rendre les menus moins toufus, tellement GIMP a de plug-ins pr défaut. Maintenant cela ne sera peut-être plus nécessaire.
  2. Des mises-à-jour de fonctionnalités de base pourraient se faire hors-sorties: une sortie de GIMP est un travail lourd qui demande beaucoup de temps et de préparation. Avez-vous d’ailleurs remarqué que nous sommes maintenant plus rapide pour sortir GIMP (3 sorties en 2 mois!)? Nous allons bien sûr continuer dans cette lancée. Cependant avec des extensions qui peuvent être mises-à-jour par un canal moins contraignant, nous pourrions nous simplifier la tâche, faire moins de grosses sortie de logiciels, tout en ayant encore plus de mises-à-jour!

Et la sécurité, dans tout ça?

Soyons clair: côté sécurité, à l’heure actuelle, le système de plug-in de GIMP est une véritable passoire.

Toutefois on peut travailler sur certains aspects: le système devra comparer les fichiers listés dans les méta-données avec ceux présents dans l’extension. Une extension annonçant être un set de brosses uniquement ne devrait ainsi pas contenir d’exécutable par exemple.

Et bien sûr, tout fichier exécutable (c’est à dire plug-ins ou scripts) devrait passer par de la revue de sécurité. Cela signifie que nous devrons trouver ceux dans la communauté capable d’effectuer une telle revue. Je le prédis: cela prendra un peu de temps pour se mettre en place. Mais c’est ce par quoi on doit passer.

Enfin on ne pourra accepter les exécutables compilés dans un premier temps. Un exécutable compilé n’est de confiance que si nous l’avons compilé nous-même, sur nos serveurs. Cela rajoute de manière évidente tout un monde de complexité (encore plus sachant que GIMP tourne sous Linux, Windows, macOS, BSDs…). Au début, il paraît donc évident que nous ne pourrons autoriser les extensions C et C++ sur notre dépôt. Je sais qu’on va me rétorquer que cela signifie se passer des certaines des extensions les plus connues. G’Mic est le plug-in qui vient immédiatement à l’esprit! Je ne suis pas fou, et il me paraît évident que l’on devra mettre en place des exceptions dès le début pour des créateurs de plug-in de confiance (avec un parcours connu et des développeurs reconnus dans le Libre), pour les autoriser à uploader des plug-ins compilés dans ce nouveau système d’extensions. Notons que ceux-ci seront vraiment des exceptions.

Quoiqu’il en soit, rentrer dans le monde des extensions est un chemin difficile. On le sait tous, la sécurité est importante, surtout de nos jours, et GIMP n’est pas un si bon élève sur ce point. Un jour, ce serait bien d’ailleurs si les extensions pouvaient être lancées dans un environnement bac à sable par exemple. Comme disent certains: le chemin est long, mais la voie est libre!

Le code

Je l’ai dit, j’ai déjà commencé. Mon code actuel peut déjà charger et démarrer les extensions, lire et lister les métadonnées, et (dés)activer des extensions. Ce sont les bases. Mais cela ne fait que commencer.

Après les bases, il restera beaucoup à faire, tel qu’obtenir la liste des extensions depuis les dépôts, et travailler sur le site web (Patrick David devrait m’aider sur cet aspect; on rappelle qu’il a déjà fait notre nouveau site web et Pixls.us, la communauté à la mode pour les photographes utilisant du Logiciel Libre).

Je ne sais quand je finirai, notamment car je travaille sur plusieurs projets à la fois dans GIMP (comme une meilleure prise en charge des écrans haute densité, et bien sûr notre plug-in pour l’animation; mais aussi beaucoup beaucoup plus!). J’espère tout de même pouvoir avoir quelque chose à sortir pour le grand public d’ici la fin d’année. 🙂

Merci à tous!
Et n’oubliez pas: votre financement est plus que jamais nécessaire, sur Tipeee ou Patreon (ou regardez encore notre page générique de dons pour ZeMarmot ). Cela nous permet d’avancer nous-même et de faire avancer GIMP!

GIMP 2.10.0 est sorti!

Salut à tous!

Nous l’annonçons un peu en retard, puisque cela s’est passé le 27 avril, pendant la réunion du Graphisme Libre 2018 (à propos, pouvez-vous repérer l’équipe de ZeMarmot, Aryeom et Jehan, dans la photo d’adieu de la réunion?), mais voilà… après 6 ans de développement effréné, GIMP 2.10.0 est enfin sorti!

C’est une sortie absolument énorme. Jetez un œil aux notes de sorties. La taille de la page, qui défile encore et encore et encore… est à elle seule symptomatique. Et encore, on n’a pas tout mis dans ces notes de version. On a dû mettre certains changements de côté pendant l’écriture pour garder une page lisible.
Et en français, vous pouvez aussi lire cette dépêche sur la sortie de GIMP 2.10.0 (aussi écrite par Jehan, de ZeMarmot) sur LinuxFR!

Pour cette sortie, nous ne ferons pas de compte rendu détaillé sur nos contributions, comme pour les sorties intermédiaires, puisqu’il y a simplement trop, et notre compte-rendu serait aussi gros que les notes de sorties! On va vous épargner. 😛
En deux mots cependant, Jehan est le second plus gros contributeur de GIMP 2.10.0 avec 1126 commits et par conséquent, le projet ZeMarmot est le second plus gros contributeur de GIMP. Cool hein?!

Nous vous souhaitons d’apprécier cette version de GIMP (que vous pouvez télécharger ici) autant que nous avons apprécié la créer pendant 6 ans. Et ce n’est pas fini! À peine rentrés de la réunion du Graphisme Libre, et un peu épuisés (ce qui explique le retard de cette nouvelle d’ailleurs), nous commençons déjà à travailler sur GIMP 3, qui est un port vers GTK+3, en même temps que nous corrigeons un flot de nouveaux bugs (comme toujours après une sortie majeure).
Le futur de GIMP s’annonce ensoleillé!

Un grand merci à tous nos donateurs pour nous aider à créer un logiciel si extraordinaire! Chacune de vos donations a participé au développement du Logiciel Libre. Nous vous aimons!

Équipe ZeMarmot

Rappel: vous pouvez financer notre contribution au
Logiciel Libre sur Liberapay, Patreon ou Tipeee (et
autre) grâce au projet ZeMarmot.

ZeMarmot, principal contributeur de GIMP 2.10.0-RC1

Nous avons sorti GIMP 2.10.0-RC1 il y a déjà presque 3 semaines (et sommes même sur le point de sortir une RC2)! Mais c’est seulement maintenant que nous faisons notre petit compte-rendu habituel de contributeurs, en français (celui en anglais a été fait la semaine dernière, ce qui était déjà tard). Notre excuse étant bien entendu le fait que le développement de GIMP et la production de ZeMarmot nous prend le plus gros de notre temps; j’espère que vous considérerez cette excuse aussi valide que nous. 😉

Quoiqu’il en soit, ceci fut notre première Release Candidate de GIMP 2.10.0, c’est donc un énorme évènement (une Release Candidate, c’est une version presque finale, un peu entre une version de développement et une version stable)! Eh oui, 6 ans déjà que vous l’attendez, et l’attente touche à sa fin…

Quelle fut la partication de ZeMarmot?

C’est d’autant plus une sortie excitante pour nous que pour la première fois, je fus le contributeur majeur, avec 270 commits sur les 784 faits entre 2.9.8 et 2.10.0-RC1. C’est donc plus du tiers des modifications et corrections de bugs sur les 4 derniers mois! D’autres participants du projet ZeMarmot ont eux-même quelques commits, notamment Aryeom, notre réalisatrice, qui a contribué 2 icônes manquantes (pour se changer les idées entre ses séances d’animation de marmottes, image par image), ainsi que Lionel (un des membres du CA de l’association LILA qui gère le projet) qui a travaillé sur l’amélioration de la prise en charge de l’unité de mesure “pouce”.

On le voit, à chaque sortie, ZeMarmot est un acteur de plus en plus majeur du développement de GIMP. Il n’y a pas à dire, nous en sommes fier. Normalement après chaque sortie, je liste en détail mes contributions, mais il y en a tellement que j’ai décidé de désormais limiter aux quelques contributions plus marquantes:

  • Amélioration du debuggage avec une boîte de dialogue récupérant des données et traces d’exécution. J’en ai déjà parlé (en anglais seulement).
  • Sauvegarde automatiques d’images juste avant un crash! Oui vous ne rêvez pas! Alors je sais… GIMP est très stable. On a donc eu quelques remarques à ce sujet nous disant que de toutes façons, GIMP ne plante jamais (et on est fier de lire ce type de remarques car on a beaucoup travaillé pour en arriver à cette stabilité qui n’était absolument pas un acquis quand j’ai commencé à contribuer, il y a quelques années; c’est même l’une des raisons pour laquelle j’ai fait mes premiers patchs). Mais cela reste du logiciel, et dans le logiciel, tout est possible! Je développe celui-ci, et suis pourtant le premier à vous l’affirmer: non, GIMP n’est pas parfait! Il est très stable, mais les plantages peuvent arriver. Pire! C’est sûr, un jour, il vous plantera à la figure, si vous l’utilisez beaucoup! Et ce sera le jour où vous vous y attendrez le moins (loi de Murphy). La différence, c’est que maintenant GIMP sera prêt!
    Bon soyons précis, ce n’est pas non plus du “sauvetage” à 100%. Par nature, un crash est un état d’instabilité extrême d’un processus. On peut essayer de préserver des données, mais même cela peut échouer. Par contre souvent cela réussira. Et c’est seulement ce jour qui importera: celui où vos heures de travail auront été sauvées par ce petit bout de code. 😀
  • La pipette à couleur prend maintenant en compte la gestion des couleurs de votre moniteur sur macOS.
  • J’ai implémenté la capture d’écran avec l’API générique Freedesktop.  Sur les plateformes GNU/Linux, à terme, c’est censé remplacer les APIs spécifiques des environnements de bureaux. Néanmoins les implémentations GNOME/KDE gardent tout de même la priorité à ce jour jusqu’à ce que les implémentations Freedesktop soient plus complètes (et ainsi éviter des pertes de fonctionnalités).
  • J’ai ajouté de nouvelles configuration des préférences pour l’export de métadonnées, et fait en sorte que tous nos plug-ins d’export respectent ces préférences (notamment en rajoutant de nouvelles APIs pour les développeurs de plug-ins: gimp_export_exif()gimp_export_xmp() et gimp_export_iptc()). C’est un sujet sensible car les métadonnées de fichiers peuvent contenir des données sensibles (votre nom souvent déjà, souvent le nom de votre entreprise voire votre adresse email, parfois même des coordonnées GPS que les appareils modernes ajoutent automatiquement, etc.) et clairement certaines personnes peuvent préférer ne pas avoir à gérer et filtrer manuellement ces données et simplement demander à ne pas les exporter par défaut.
  • Diverses nouvelles APIs pour les développeurs de plug-in:
    • gimp_get_pdb_status() retourne le statut du dernier appel PDB. Cela permet à un plug-in qui dépend d’autres plug-ins d’en savoir plus sur les raisons de retour. Par exemple si une procédure est stoppée intéractivement, cela ne doit pas être considéré comme une erreur, mais plutôt comme une interruption manuelle.
    • gimp_stack_trace_available(), gimp_stack_trace_print() et gimp_stack_trace_query() pour aider au débuggage de plug-ins.
    • gimp_context_get_distance_metric() et gimp_context_set_distance_metric() pour le choix de métrique de distance utilisé par gimp_edit_blend() (et à usage futur).
  • Amélioration de l’API gimp_edit_blend() qui se base maintenant sur l’opération “gegl:distance-transform“, ce qui rend la procédure bien plus rapide.
  • Amélioration du traitement d’image splash avec du redimensionnement pour apparaître avec une taille raisonnable sur toute dimension d’écran.
  • Des vulnérabilités furent reportés fin 2017, donc j’ai corrigé CVE-2017-17784, CVE-2017-17786, CVE-2017-17787 et CVE-2017-17789.

Au milieu de tout cela, j’ai aussi déjà annoncé le nouveau paquet mypaint-brushes.
Enfin il y a toutes ces autres mini-fonctionnalités mais surtout les nombreux bugs corrigés. En fait je ne crois pas que j’aurais pu corriger aussi facilement autant de bugs sans notre nouveau système de débug. Donc j’en suis particulièrement content. Je sais que certains ne considèrent pas cela si important (ce n’est pas une vraie fonctionnalité, pour du dessin ou de l’édition d’image ou autre). Je le sais, puisque j’ai lu sur un forum une remarque se plaignant que la news sur gimp.org mette surtout en avance des fonctionnalités de debug, comme si cela ne les valait pas. Pourtant c’est une des contributions dont je suis le plus fier. Je l’ai expérimentée ces derniers mois, et très clairement, cela nous a aidé énormément à débugguer plein de problème sans même avoir eu à demander aux gens de faire des actions ésotériques (telles que “pourriez-vous lancer GIMP dans un débuggueur?” – “Un quoi?”).
En outre je ne le rappellerai jamais assez, mais pour moi la stabilité et fiabilité d’un logiciel est l’une des bases qualitatives. Cette fonctionnalité va clairement dans ce sens.

Quoiqu’il en soit, je l’avais déjà dit: la correction de bug et stabilité sont mes buts personnels pour la 2.10. Comme vous le voyez, ce n’étaient pas des paroles en l’air. 🙂

Tutorer un étudiant pour coder dans GIMP

Parmi les autres nouvelles sympas, un étudiant, Darshan Kadu, nous a approché comme stagiaire FSF. Je lui ai proposé de continuer le portage de notre prise en charge du format JPEG2000  (passant d’une implémentation basée sur Jasper vers OpenJPEG, puisque la première bibliothèque est déprécié). J’agis donc comme tuteur. Ce n’est pas ma première fois à travailler avec des étudiants universitaires. J’ai déjà donné quelques cours dans une université parisienne l’an dernier, et franchement j’aime beaucoup ces échanges (que ce soit avec un seul stagiaire ou une classe entière).

Cela a relancé les discussions sur GSoC et si on souhaitait à nouveau tenter d’y participer (pour mémoire, le projet GIMP y a participé plusieurs années mais a ensuite arrêté; en fait il me semble que le dernier GSoC du projet fut l’année où j’ai commencé à faire mes premiers patchs sur GIMP, je n’ai donc jamais eu l’opportunité d’y participer en tant que tuteur). Quelques personnes proposaient d’avoir des stagiaires pour travailler sur toute sorte de fonctionnalités majeures dans le cœur de GIMP. Je voudrais commenter ce souhait.
Personnellement cela m’intéresse de participer car j’aime accompagner des étudiants dans le monde du développement professionnel. Si au passage, on peut avoir quelques patchs cools, c’est génial. Mais je pense qu’un tel évènement ne doit pas être utilisé juste pour avoir du “bon code pas cher”. Déjà car j’ai toujours détesté l’exploitation de stagiaires mal payés (bon en l’occurrence, avec GSoC, ils ont clairement une paie raisonnable). Ensuite simplement pour une raison qualitative: je pense que tout projet qui se repose principalement sur ce type de contribution ne peut obtenir que du code peu maintenable et de piètre qualité.

C’est simple: quelque soit votre métier, imaginez vous quand vous étiez étudiant. Maintenant demandez vous ce qu’il se passerait si on lâchait le “vous étudiant” à votre poste actuel (auquel vous êtes arrivé après des années à apprendre le métier, à faire des projets, avec des succès et des erreurs…). Pensez-vous vraiment que vous auriez révolutionné votre métier? J’espère que vous répondrez non, sinon c’est un peu triste que vous considériez ne pas avoir évolué posivitement depuis votre vie étudiante! ;p

Donc oui, GSoC comme tout stage, est une opportunité sympa pour travailler avec des jeunes esprits vifs et avec des idées neuves. Mais cela ne doit pas être pris comme une sorte de solution magique pour obtenir du code pas cher, rapide et bon. J’ai l’impression que beaucoup de gens voient cela ainsi malheureusement.
Bon on verra l’an prochain si on décide finalement d’y revenir (cette année encore, on ne s’est pas inscrit), mais je souhaitais donner un peu mon avis à ce sujet puisqu’il est dans l’air.

Release Candidate? Sortie de 2.10 bientôt?

Clairement nous travaillons dur ces derniers temps. Nous sommes même passé sous les 10 bugs bloquants il y a quelques jours (mais cela oscille beaucoup, et à l’heure d’écriture, on est de retour à 10 bugs)!

Nous avons tout de même dû discuter un peu s’il fallait vraiment nommer cette sortie une RC. En effet de manière stricte, ce ne devrait pas être un “candidat pour une sortie (stable)”. Cependant nous sommes un peu fatigué de trainer des pieds (depuis 6 ans!). GIMP 2.10 ne sera pas parfaite. Aucune sortie de logiciel ne sera jamais parfaite. C’est un fait! Mais GIMP 2.10 sera déjà vraiment méga cool, même s’il devait sortir dans l’état actuel. C’est pourquoi on s’est dit qu’on devait un peu pousser dans le bon sens. Faire une “Release Candidate” est donc une sortie psychologiquement forte pour se dire “maintenant faut qu’on pousse vers la sortie”. Et c’est donc exactement ce que l’on fait. 🙂
Attendez vous donc à voir la 2.10 très bientôt, sauf si vraiment on découvre un problème très grave que nous n’aurions pas repéré jusque là (on touche du bois!).

Amusez vous bien avec GIMP 2.10 RC1, tout le monde! Et surtout, testez, testez, testez! Et envoyez des rapports de bugs si vous trouvez quelque chose qui ne va pas! 😀

 

Rappel: vous pouvez financer mon travail sur du
Logiciel Libre sur Liberapay, Patreon ou Tipeee
à travers le projet ZeMarmot.

Nouvelle image pour nouvelle année

New year 2018

Bonne année à tous!

Aryeom a commencé le premier jour de l’année par un dessin en live de bienvenue à la nouvelle année, qui est dorénavant l’image d’en-tête du présent site.  Il était temps d’ailleurs, notre précédent en-tête était un peu à tendances estivales. 🙂

New year 2018Cette image est aussi au format 16:9 donc vous pouvez l’utiliser en fond d’écran si vous le souhaitez et si le format correspond. Cliquez simplement la miniature à droite pour la télécharger pleine taille.
Elle est sous licence Creative Commons BY 4.0 par Aryeom Han, réalisatrice de ZeMarmot.

En outre la session de dessin numérique fut diffusée live (comme beaucoup de sessions de GIMPage d’Aryeom dorénavant, tel qu’expliqué dans la section “Live Streaming du travail sur ZeMarmot” de notre compte-rendu 2017). Si vous avez manqué le live, vous pouvez vous rattrapper en regardant l’enregistrement. Comme d’habitude, nous rappelons que ce ne fut pas édité après coup, ni accéléré, ni rien; nous n’avons pas non plus rajouté de musique pour rendre la vidéo “cool” ou quoi que ce soit du genre. 😛
Il s’agissait d’un vrai live, avec Aryeom concentrée sur son dessin, ce qui explique qu’il s’agisse d’une vidéo de presque une heure avec des endroits où il ne se passe d’ailleurs rien. Faites avance rapide si vous voulez juste voir la progression en quelques minutes. 😉
Bon visionnage!

Ce live et ce dessin sont rendus possibles grâce à nos nombreux donateurs!

Rappel: les créations (Art Libre) d'Aryeom peuvent
être soutenues financièrement sur Liberapay, Tipeee
ou Patreon (projet ZeMarmot).

ZeMarmot, GIMP 2.9.8 et compte-rendu de fin 2017…

Et voilà, GIMP 2.9.8 est sorti il y a quelques jours, dernière version de développement de GIMP! Comme il est de  coutume, nous détaillons ci-dessous notre implication dans cette version, notamment pour que nos donateurs sur les plateformes de financement participatif savent ce qu’ils financent.

Comme en plus, l’année 2017 vient de terminer, je complèterai aussi ce post avec notre rapport de fin d’année, comme nous avions déjà fait fin 2016.

Qu’avons-nous fait dans GIMP 2.9.8?

Pendant ces derniers mois, j’ai décidé de me concentrer surtout sur de la correction de bug. J’ai terminé quelques fonctionnalités ici ou là, mais me suis en fait beaucoup retenu de coder trop de nouvelles choses. Pourquoi donc? Parce que je pense que nous avons assez de nouveautés et qu’on est à un point où on doit simplement sortir GIMP 2.10 au plus vite. Bien sûr, GIMP 2.10 pourrait être 2 fois mieux en repoussant de quelques mois, et 10 fois mieux en repoussant encore plus. Mais au final, quel intérêt si personne ne le voit?! Je prévois donc de me focaliser essentiellement sur les bugs et finalisations de fonctionnalités commencées jusqu’à la sortie de 2.10.

J’ai aussi passé beaucoup de temps à la gestion des rapports de bugs (plus d’une  centaine de participation à des rapports de bug entre 2.9.6 et 2.9.8, i.e. en 3 mois et demi).  J’ai notamment entamé la réorganisation de notre cible 2.10 en sélectionnant les bugs “bloquant” pour GIMP 2.10. À ce jour, il nous reste donc 29 bloqueurs à considérer en priorité pour GIMP 2.10.

De même, j’ai redoublé d’effort pour que nous puissons enfin avoir une sortie flatpak officielle de GIMP sur flathub, ce qui est le cas depuis le 16 octobre! Ce paquet est bien sûr disponible dans la section GNU/Linux de la page de téléchargement de GIMP, avec un gros bouton orange “Install GIMP flatpak” (au passage, vous remarquez le dessin en haut de page? C’est un dessin d’Aryeom!).

À ce jour, on ne peut installer que la version stable par ce biais, c’est à dire GIMP 2.8.x (flathub n’accepte que les versions stables) mais en l’installant par ce biais, quand GIMP 2.10 sortira, vous serez en mesure de le mettre à jour aisément et rapidement (probablement le jour de la sortie) avec une build officielle!
Dans tous les cas, la maintenance de ce flatpak me prend un temps certain (en particulier pour garder le manifest flatpak à jour dans notre dépôt de source et tester les builds)!

En tout, je suis l’auteur de 122 commits entre GIMP 2.9.6 et 2.9.8, sur 474 commits totaux (soit ~25%), et j’ai poussé quelques autres commits de développeurs tiers après revue de code…
Notons aussi encore 2 commits “invités” par Lionel N., membre du Conseil d’Administration de LILA, l’association loi 1901 gérant le projet ZeMarmot.

Bien entendu, même si je dis m’être concentré sur les bugs, j’ai participé à quelques fonctionnalités sympas qui sont arrivées avec cette sortie:

  • Prise en charge d’import de fichiers PDF protégés par mot de passe (les 2 commits de Lionel de LILA!) et une nouvelle procédure `file-pdf-load2()` pour que les plug-ins et scripts puissent aussi ouvrir des PDFs avec mot de passe, mais aussi des PDFs multi-pages (il était déjà possible d’importer des PDFs multi-pages graphiquement, mais la fonctionnalité n’était pas disponible pour les scripts et plug-ins).
  • Amélioration du système d’aide: en cas de détection d’installations multiples de manuels dans plusieurs languages, GIMP permettra dorénavant la sélection du langage de manuel préféré dans les Préférences (Interface > Help System). Il me semble que cette fonctionnalité est importante car nous avons régulièrement des gens ne comprenant pas pourquoi GIMP ne voyait pas le manuel qu’ils avaient installés.  En outre, nous n’avons pas autant de traductions du manuel que de l’interface graphique. Ainsi nous avons 3 traductions chinoises de l’interface (zh_CN|TW|HK) mais uniquement une traduction du manuel (zh_CN). Je pourrais tout à fait imaginer quelqu’un avec une interface zh_HK (chinois de Hong Kong) utilisant alors le manuel zh_CN (chinois simplifié). De même que quelqu’un pourrait vouloir son interface en breton (oui, on a une traduction bretonne!) et un manuel en français.
  • La version verbeuse (ligne de commande: gimp -v) affiche maintenant aussi des informations sur le compilateur C utilisé (utile pour le debugging).
  • Les information de rotation et de retournement du canevas sont maintenant visibles dans la barre de statut et cette information est interactive (en cliquant les icones de retournement, vous remettez le canevas à l’endroit; cliquer l’angle de rotation ouvre la boîte de dialogue “Sélectionner l’angle de rotation“). Certaines personnes remarquaient en effet qu’à force de retourner ou tourner le canevas, on pouvait “s’y perdre” et ne plus savoir s’il était retourné ou non. En outre la barre de statut a déjà les informations de zoom, très similaires. 🙂
  • Implémentation de la capture d’écran pour KDE/Wayland.
  • Implémentation de la pipette à couleur pour KDE/Wayland.
  • Amélioration de la gestion du délai pour les captures d’écran.
  • Revue des patches de prise en charge du format HGT et amélioration de ceux-ci avec de l’auto-détection des variantes (SRTM-1 et SRTM-3), et aussi une procédure `file-hgt-load()` pour les scripts et plug-ins.

Quoiqu’il en soit, je considère que les corrections de bug et la maintenance de code que j’ai faites furent plus importantes que cette liste de fonctionnalités, mais c’est malheureusement toujours compliqué de rendre une liste de bugs aussi attrayante qu’une liste de fonctionnalités! Cela ne m’empêchera pas de continuer à me focaliser sur les bugs jusqu’à la sortie de 2.10.

ZeMarmot en 2017: notre compte-rendu!

Vous le savez bien: ZeMarmot, ce n’est pas seulement du code sur GIMP, même si ce logiciel est une grosse partie du projet. ZeMarmot est avant tout la réalisation d’un film d’animation, en 2D dessinée, animation traditionnelle mais néanmoins numérique (dessin sur ordinateur et non papier). Bien sûr, nous dessinons dans GIMP. Pour être plus précis, Aryeom Han, animatrice et réalisatrice, dessine (pas moi). Et nous finançons le projet participativement.

Finances

Cette année fut un peu dure psychologiquement et nous nous sommes demandés à plusieurs reprises si le projet était bon pour nos vies.  En effet, le financement participatif augmentait, mais très lentement pendant tout 2017 (autour des 400 € par mois).

C’est ainsi qu’en octobre, j’ai lancé un appel à l’aide après que mon ordinateur ait cassé, et nous fûmes très heureux que beaucoup de gens y répondent. Le financement a doublé en quelques jours.

Ensuite, soyons clair: notre financement actuel est plus ou moins de 1000€ mensuels (depuis octobre), ce qui est mieux et nous a donné beaucoup d’espoir; cependant cela ne nous paie pas 2 salaires (en fait, pas même un seul temps plein). Nous espérons donc que si vous appréciez notre projet, que ce soit pour le développement de GIMP et/ou pour le film ZeMarmot, vous ne nous oublierez pas et soutiendrez le projet en donnant. Nous vous en serons très reconnaissant!

Les donations à ZeMarmot peuvent se faire là:

» Liberapay «
(donations hebdomadaires, USD et EUR possibles, frais les plus bas)

» Patreon «
(donations mensuelles, USD ($) seulement)

» Tipeee «
(donations mensuelles, EUR (€) seulement)

Live Streaming du travail sur ZeMarmot

Nous sommes conscients que le peu de nouvelles du côté animation n’était pas idéal. L’animation est un travail qui prend beaucoup de temps; donc le travail sur le film avance, mais c’est simplement très dur de donner des nouvelles concrètes.

À titre d’exemple, en fonction de la complexité et du détail d’animation, une minute d’animation peut prendre un mois de travail à temps plein, voire plus (vous trouverez pleins de liens sur le web, qui donnent tous des infos similaires).
Cela dépend bien sûr de vos choix artistiques. De l’animation vectorielle ou de  l’animation limitée (Les Simpson par exemple) seront animées bien plus rapidement. En gros vous n’animerez pas South Park ou un film Disney à la même vitesse (ce qui n’est pas un problème, mais un choix; j’apprécie aussi Les Simpson ou South Park). Dans le cas de ZeMarmot, comme vous le savez, nous avons choisi un style détaillé et une animation traditionnelle classique. C’est un choix (que nous avons parfois regretté à cause du temps pris, mais ce qui est fait est fait!).

C’est ainsi qu’ Aryeom a décidé de diffuser des lives de ses sessions de travail! Après quelques jours de recherche de logiciel, elle a choisi OBS comme logiciel libre de streaming (on a au passage réussi à casser Fedora en réinstallant les pilotes NVidia en suivant des tutoriels! :p), et après plusieurs tests en décembre, elle a commencé officiellement ses lives publics le 25 décembre 2017!

Voici le lien où les lives sont régulièrement visibles:

» https://www.youtube.com/c/LibreArtInfo/live «

Nous n’avons pas encore trouvé l’organisation idéale pour planifier les lives à venir. Par conséquent, le mieux pour le moment est soit de nous suivre sur Twitter, soit de s’inscrire à la chaîne Youtube, ou simplement de jeter un œil de temps en temps sur le lien ci-dessus.

Les lives précédents sont automatiquement enregistrés et visibles en différé sur la chaîne à la fin du streaming. Soyez prévenus cependant: il s’agit de vrais lives de quelqu’un travaillant réellement. Cela signifie déjà que c’est du temps réel (et pas accéléré 20 fois comme on peut le voir dans divers “speed painting”), des erreurs peuvent se produire et cela n’est pas édité ensuite. Il n’y a pas de son (ni musique, ni parole) et Aryeom n’intéragit pas avec les gens en direct. Elle est concentrée sur son travail et ne regarde pas le streaming. De temps en temps, nous regardons le chat et on peut répondre à des questions, mais ne considérez pas cela comme une évidence. Il s’agit d’un aperçu du travail d’animateur professionnel et non d’un service de chat ou de questions-réponses. De même, il arrive que l’animateur fasse une pause au milieu d’un live et nous ne vous promettons pas que vous ne vous ennuierez jamais. 😉
D’ailleurs le plus long streaming qu’elle ait enregistré à ce jour est de plus de 7 heures d’affilées! Vous êtes prévenus! 😛

Dans tous les cas, c’est une expérience vraiment très enrichissante et nous avons déjà reçu des commentaires très positifs de la communauté.

 

Symbiose Art+Code

Nous avons eu régulièrement la question: “pourquoi ne pas faire de financements participatifs séparés pour le développement et l’animation?

Réponse: parce que ce projet est un tout. C’est une symbiose. Je code du Logiciel Libre car je l’utilise; si ZeMarmot n’existait pas (ou un autre projet où on utiliserait GIMP), alors je ne contribuerais probablement pas à GIMP. C’est aussi simple que cela. Aryeom de son côté n’utiliserait probablement pas GIMP si elle n’avait pas un développeur à ses côtés.

Nous rappellons que c’est ainsi que nous avons commencé nos premiers patchs à GIMP: nous avions des bugs et des crashs et considérions alors que GIMP n’était pas suffisant pour un usage professionnel à l’époque. Nous sommes heureux de pouvoir dire que c’est beaucoup beaucoup mieux de nos jours (avec la version de développement). Soyons clairs que nous ne sommes pas les seuls responsables, loin de là! Nous sommes chanceux de pouvoir hacker GIMP aux côtés de plusieurs développeurs vraiment talentueux (notamment Mitch, le mainteneur de GIMP, qui est toujours là après 20 ans!). Par contre le fait qu’on nous ait permis d’y mettre du notre est clairement la raison pour laquelle nous nous accrochons à ce projet.

Pour illustrer à quel point notre projet est un tout, lors d’un streaming d’Aryeom, il y a quelques jours, nous avons été capable de démontrer en live comment nous travaillons ensemble. Pendant le live, un crash de GIMP s’est produit! Ouch! En quelques minutes, elle fut capable de trouver des étapes de reproduction du crash, et moins de 2 heures plus tard (cela ne m’a pas pris 2H, mais je pouvais pas non plus abandonner mon activité du moment d’un coup!), j’ai poussé un correctif dans le dépôt de source de GIMP.

Et c’est ainsi que le projet ZeMarmot est un projet très efficace de 2 personnes, une collaboration d’un développeur et d’une animatrice (qui travaille quotidiennement et professionnellement avec ce logiciel), et absolument pas 2 projets séparés. 🙂

Ainsi si jamais vous vous êtes retenu de donner jusque là car vous souhaitez seulement donner pour un film, ou au contraire seulement donner pour du développement GIMP, nous espérons que vous pourrez revoir votre jugement et voir qu’en donnant à ZeMarmot, vous aidez tous les aspects du projet en même temps!

GIMP Motion

GIMP Motion est notre our plug-in pour l’animation dans GIMP (nous en avions déjà parlé en démontrant la création d’animations simple puis complexes). Vous pouvez d’ailleurs aussi le voir en action presque quotidiennement dans les lives d’Aryeom maintenant.

Malheureusement j’en ai un peu négligé le développement dernièrement pour la raison donnée précédemment: je me concentre surtout sur la sortie de GIMP 2.10 pour le moment. J’espère donc bien que cette sortie sera très bientôt (pour en finir enfin avec GIMP 2 et commencer l’aventure GIMP 3!).
Cela signifie que GIMP Motion ne sera vraisemblablement pas inclus dans GIMP 2.10, mais il sera sûrement dans une sortie GIMP 2.10.x puisque nous avons décidé début 2017 que nous relâchions notre politique d’absence de nouvelles fonctionnalités dans les versions mineures. J’ai donc décidé que GIMP Motion n’était pas prêt pour être considéré “stable”. C’est d’ailleurs exactement pour cela que je pousse cette relâche de notre politique de sortie depuis 2014 (cf. la section “Les Réunions GIMP” dans notre compte-rendu LGM 2014!): pour ne pas se presser à sortir des fonctionnalités à moitié faites ni pousser les sorties indéfiniment.

Nous utilisons ce plugin en interne bien sûr, mais il reste instable et avec de nombreux bugs. Vous êtes prévenus!

Documenter le processus d’animation

Cette année, nous avons beaucoup moins documenté notre travail. On a bien eu un article sur l’animatique, le key-framing, etc. et un sur le background design. Nous avons aussi fait quelques conférences pendant le festival NUMOK des bibliothèques parisiennes ainsi qu’aux JM2L avec quelques explications du processus d’animation que nous n’avons pas encore mises noir sur blanc (mais bientôt!).

Mais ce n’est pas assez puisque nous souhaitons vraiment documenter le plus possible pour que les techniques de films animées n’aient pas de secret pour tous. Comme je disais, cette année ne fut pas rose et nous n’étions tout simplement pas dans dans l’esprit. Espérons que nous ferons mieux l’an prochain!

ZeMarmot à la télé!

Grâce aux JM2LZeMarmot est passé 2 fois à la télé en fin d’année. Dans toutes les vidéos, GIMP est clairement mentionné et visible à l’écran, de même qu’Aryeom hackant des animations dans GIMP, sous bureau GNOME. 🙂

Nous sommes ainsi passé sur France 3 côte-d’Azur (à l’écrit aussi):

Puis sur PleinSud TV (à 2:32):

Et une mention dans le journal papier Nice Matin:

Matériel mis à jour

Grâce au financement accru de fin d’année, nous avons pu renouveler notre matériel. En particulier nous avons acheté une Wacom MobileStudio Pro (en gros un portable-tablette de Wacom) sur laquelle notre première action fut de remplacer Windows par une distribution GNU/Linux (Fedora 27) et d’installer GIMP. Cela fontionne bien! Bon soyons clair: on a tout de même ouvert plus d’une dizaine de rapports de bug pour divers projets libres, donc ne vous attendez pas à une prise en charge parfaite. Mais on y travaille!

Nous avons d’ailleurs documenté  un peu l’évolution sur un moment Twitter avant de devoir faire une pause à cause de problèmes matériels (nous avons dû renvoyer la tablette au service après-vente qui a mis plus de 3 semaines à nous la retourner!).

Nous publierons plus tard un guide complet pour ce matériel de peintre numérique avec GNU/Linux et GIMP. 🙂

Conclusion

L’année fut dure mais intéressante et la fin d’année en particulier nous a redonné de l’espoir que l’on croyait perdu, avec un financement un peu plus raisonnable et une mise-à-jour du matériel.

Les streamings d’Aryeom GIMPant ZeMarmot furent aussi une idée super cool et nous sommes heureux de voir que les gens semblent apprécier. À ce jour, nous n’avons eu que des retours positifs. Nous aurions dû en faire plus tôt!

Nous avons donc espoir que les choses continueront à s’améliorer. Nous aimons ce que nous faisons et notre projet, et rêvons de ce jour où nous pourrons dire fièrement que nous sommes capable de vivre de Logiciel Libre et d’Art Libre.
Lorsque ce jour arrivera, ce sera clairement un jour heureux où nous pourrons sabrer le champagne. 🙂

En attendant, nous vous souhaitons à tous une année 2018 heureuse, amusante et libre!

Le projet ZeMarmot maintenant aussi sur Liberapay!

On nous parle régulièrement de Liberapay. Cette plateforme de financement récurrent est différente des plus connues (telles que Patreon or Tipeee) surtout du fait qu’elle est gérée par une association (française) à but non-lucratif avec des frais bien moindres (de ce que je comprends, il n’y a que les frais de paiement, mais pas de frais de plateforme!) puisqu’ils s’auto-financent sur leur propre plateforme (en outre, le code même du site est du Logiciel Libre).

Bien sûr, on ne peut qu’apprécier le concept. Par le passé, nous avons toutefois été réticent d’y faire un compte pour une raison principale: ZeMarmot est déjà présent sur 2 plateformes (quand nous avons commencé, nous ne connaissions pas Liberapay) et plus de plateformes signifie plus de temps utilisé pour la gestion, un temps que nous préférons utiliser plus intelligemment en codant du Logiciel Libre et dessinant/animant de l’Animation Libre.

Cependant, vous avez peut-être entendu parler des changements récents de frais de plateforme sur Patreon qui ont mis en colère le web (une simple recherche sur votre moteur de recherche favori vous trouvera des dizaines d’articles sur le sujet). Bon finalement ils sont revenus sur leur décision après quelques jours, en s’excusant, et tout et tout. Mais c’est un peu trop tard. Comme la plupart des projets sur Patreon, nous avons perdu plus de 20 patrons pour plus de 80$ de donation par mois (c’était les chiffres tels que je les avais comptés y a une semaine; probablement pire au final), soit plus de 10% des donations sur Patreon en à peine 4 jours. Et malgré les excuses de la plateforme, aucun des patrons partis n’est revenu. La confiance avec la plateforme est de manière évidente rompue aux yeux de certains.

C’est la raison pour laquelle nous avons finalement décidé d’ouvrir un compte sur Liberapay. Donc si vous aimez le projet ZeMarmot, ainsi que nos contributions à GIMP,  vous pouvez dorénavant aussi nous financer ici:

» ZeMarmot Liberapay page «
https://liberapay.com/ZeMarmot/

Différences principales avec les autres platformes:

  • donations possibles en EUR (€) ou en USD ($), c’est plutôt cool;
  • il n’y a pas de système de “nouvelles”, c’est donc à chacun de se tenir informé par ses propres moyens (par exemple en lisant le présent blog, ou encore en suivant le compte twitter du projet);
  • tous les donateurs sont anonymes (ce qui signifie notamment qu’ils n’apparaîtront pas dans le générique du film);
  • la page de projet est localisée (pour l’instant en français et anglais).

Notez qu’il ne s’agit que d’une option de donation additionnelle. Nous n’abandonnons pas ni Patreon ni Tipeee. Ne vous sentez donc pas obligés de vous inscrire sur cette autre plateforme si vous ne le souhaitez pas et appréciez Patreon/Tipeee.

Enfin nous rappelons que le projet ZeMarmot est géré par l’association française, à but non lucratif (loi 1901), LILA. En particulier, cela signifie qu’il y a aussi d’autres moyens de soutenir notre projet financièrement, notamment par des donations directes à l’association LILA (beaucoup de banques européennes permettent des virements sans frais à l’intérieur de l’UE, à vérifier avec votre banque; cela peut donc s’avérer la solution la plus efficace) ou Paypal (pour les très petits montants, les frais sont très chers, mais pour la plupart des donations, ils sont très acceptables), etc. Si vous souhaitez voir la liste complète des moyens de donner à LILA, et donc à ZeMarmot et pour du développement sur GIMP: https://libreart.info/fr/donate

P.S.: comme la plateforme Liberapay est plutôt cool et se finance par son propre système, nous avons décidé de donner un peu en retour (pour l’instant environ 2% des donations reçues, ce qui reste moins cher que les frais de toutes les autres plateformes).

Appel à l’aide: financement du développement de GIMP et d’animation Libre

En deux mots: notre travail de développement sur GIMP ainsi que la production du film ZeMarmot est actuellement financé à un peu plus de 400€ par mois. Cela ne paie pas nos factures. Et là — paf! — mon ordinateur vient de casser et la tablette graphique d’Aryeom montre des signes de faiblesse depuis un certain temps maintenant. L’avenir du projet ne s’annonce pas radieux.

C’est pourquoi nous vous appelons à l’aide!
Vous pouvez financer le développement de GIMP et la production de ZeMarmot sur Patreon ou Tipeee!

Lire dessous pour les détails…


Si vous nous lisez régulièrement, vous savez que je contribue énormément au développement de GIMP. Nous sommes à peine une poignée de développeurs réguliers sur GIMP. Je suis l’un d’eux. Mes contributions vont des corrections de bug régulières aux fonctionnalités majeures, ainsi que de la maintenance de plusieurs parties du code et de la revue de code contribué. Je fais tout cela dans le contexte du projet ZeMarmot, aux côtés d’Aryeom Han, réalisatrice et animatrice. Nous dessinons avec et hackons GIMP car nous croyons dans le Logiciel Libre.
Bien entendu, je contribue aussi à de nombreux autres Logiciels Libres.

Notre but, absolument-pas-secret, est de pouvoir un jour vivre du développement de Logiciel Libre et de création d’Art Libre. Clairement pour l’instant, c’est un échec. Avec environ 400€ par mois, pour 2 personnes, l’association LILA a à peine de quoi rémunérer quelques jours par mois (ce qui est fait selon les règles, donc avec une partie non négligeable de cotisations sociales). Soyons clair, ces 400€ ne sont même pas assez pour payer le loyer du studio de 31m² où nous vivons, que nous louons dans la banlieue éloignée de Paris; donc dire que nous n’en vivons pas serait un euphémisme. Nous vivons principalement de nos économies et de ce que nous pouvons avoir d’autre pour vivre. Cet “autre” bien sûr nous prend du temps que nous préférerions passer sur ZeMarmot.

Car oui clairement, travailler à plein temps pour créer du Logiciel Libre ainsi que de l’Art Libre ne nous déplairait vraiment pas. Pour l’instant, on en est loin.

La raison principale pour laquelle nous continuons est que nous avons promis au moins la sortie du pilote. Les contributeurs comptent sur nous. Bien sûr, l’autre raison est que nous espérons toujours que les choses vont s’améliorer pour nous permettre finalement de vivre de nos passions. Quoiqu’il en soit, le projet avance lentement car on ne peut pas vraiment se permettre de mourir de faim. Souvent nous en sommes assez démoralisés.

C’est donc la raison de cet appel. Si vous en avez les moyens et pensez que GIMP est un logiciel important, alors je vous propose de financer ZeMarmot qui paye du développement.
De même si vous voulez voir plus d’Art Libre, et notamment de sympathiques films d’animation, voire plus tard d’autres films toujours sous licences LIbres, de qualité professionnelle, alors là aussi je vous propose de financer ZeMarmot.

» Financement Patreon «
» Financement Tipeee «

Notre matériel se meurt…

L’autre raison de cet article soudain? La situation que je dépeinds n’est pas nouvelle. Ce qui est nouveau est que mon ordinateur portable vient de casser. Il ne s’allume plus, tout simplement. Je ne sais pas encore si c’est réparable, mais dans tous les cas, cela ne sent pas bon. Mes données vont bien, puisque je fais des sauvegardes régulières (et je ne crois pas que le disque soit cassé bien que je n’aie pas encore vérifié). Par contre je n’ai plus d’ordinateur pour travailler (j’écris cela depuis un netbook 32-bit de 8 ans d’âge, machine de secours qui malheureusement peine rien qu’à ouvrir le navigateur web!).

De son côté, la tablette graphique d’Aryeom a des problèmes depuis longtemps. Vous vous en rappelez peut-être, nous avons  réglé le problème en partie. Malgré cette réparation de fortune, la tablette s’éteint régulièrement sans raison, nous forçant à retirer et remettre la batterie pour la redémarrer, ou autre “contournement” similaire. Nous craignons donc que nous soyons forcé d’en acheter une autre un jour prochain s’il lui prend aussi de ne plus s’allumer du tout.

Cette panne d’ordinateur fut donc le déclic pour cet appel, comme je me rends bien compte de la précarité de notre situation. Peu de financement, des économies qui se font la belle, et maintenant des problèmes de matériel (coûteux). Nous faisons donc appel à vous tous, ceux qui aiment le Logiciel Libre et/ou l’Art Libre. Pensez-vous que ZeMarmot soit un projet positif? A-t-il un sens, et donc devrait-il continuer à prospérer? C’est en tous cas ce que nous croyons depuis le début, et ce pourquoi nous continuons. Si c’est aussi votre cas, un peu d’aide ne serait pas de refus, proportionnellement à vos moyens. Et si vraiment vous n’avez pas les moyens du tout, alors faites passer le mot, c’est toujours ça. 🙂

ZeMarmot est une aventure dure mais merveilleuse pour nous, et tant que possible nous aimerions éviter une fin triste (bien que nous ne regretterions pas une seconde de l’aventure!).

Merci d’avoir lu!

GIMP 2.9.6 et ZeMarmot

Note: copie d’une nouvelle initialement postée sur Patreon et Tipeee.

Image de démarrage de GIMP 2.9.6, par Aryeom
Image de démarrage de GIMP 2.9.6, par Aryeom

Le mois dernier, nous avons sorti la 3ème version de développement de GIMP, version 2.9.6, pour préparer l’arrivée de la prochaine version stable, GIMP 2.10.

Comme pour les versions  précédentes, le projet ZeMarmot fut un des contributeurs majeurs avec  274 commits (sur 1885 en tout) par Jehan, 4 par Aryeom (quelques icônes  manquantes, une nouvelle dynamique “Pressure Size” très utile pour appliquer des aplats de couleur,  et l’image de démarrage pour cette version de développement), et même pour la première fois 3 commits de Lionel, un des membres du conseil d’administration de l’association LILA. Donc environ 15% de GIMP 2.9.6 vous est offert par ZeMarmot! 🙂

Nous suggérons de jeter un œil à l’annonce officielle. Et si vous souhaitez la liste précise et complète des contributions de Jehan en particulier, elle est publique et visible sur le dépôt de source.

Les nouveautés dans la 2.9.6 par ZeMarmot

  • avoir rendu thread-safe la libgimp, ce qui en langage  moins abscons signifie de simplifier le travail pour les extensions de  tourner sur plusieurs processeurs (tous les ordis de nos jours étant  multi-processeurs);
  • ajouter l’affichage des angles lors du dessin de lignes;
  • faire de la revue de code pour la prise en charge du format d’image  WebP ainsi que diverses améliorations et corrections (avec notamment un patch de notre part sur la libwebp même);
  • la capacité de  changer aisément la visibilité exclusive des calques dans des groupes de calques avec shift-click (une fonctionnalité qu’Aryeom a demandé et  testé/utilisé pendant plusieurs mois avant que nous la reportions dans  GIMP);
  • contribution à l’effort des développeurs de Darktable et RawTherapee pour notre nouveau plugin “raw” permettant d’ouvrir des images dans GIMP à travers ces logiciels tiers (le projet GIMP préconise et privilégie l’entraide et le lien entre les Logiciels Libres);
  • une contribution pour que GIMP suive la limite multi-thread de GEGL (encore une fois pour une meilleure utilisation des processeurs, mais cette fois dans le cœur de GIMP);
  • diverses améliorations de la prise en charge de PDF, en particulier l’export de PDF multi-pages à partir de plusieurs calques (c’est justement sur ce sujet que Lionel a fait ses premières dents de programmeur avec l’aide de Jehan!);
  • la revue de code et des corrections pour une amélioration de l’import et l’export d’images PCX;
  • la capacité pour les plug-ins de s’installer dans un sous-répertoire propre, ce qui va notamment enfin permettre de faire disparaître “l’enfer des DLLs”, un problème récurrent sous Windows de plug-ins qui embarquaient des librairies qui faisaient planter les autres plug-ins;
  • changer diverses valeurs par défaut pour s’ajuster aux standards  actuels (tailles de polices plus grandes, dimension d’image par défaut  en fullHD, résolution de 300 PPI par défaut au lieu de 72…);
  • une  adaptation intelligente de la précision des affichages de dimension  physique en fonction de la résolution d’impression, pour permettre plus  de précision dans divers endroits (outil de mesure, barre de statut, etc.);
  • possibilités de choisir sa taille d’icônes, ce qui permettra  d’adapter GIMP aux petits écrans, aux écrans haute densité, ou autre;
  • auto-détection de la résolution native de l’écran pour adapter la taille des icônes par défaut (ce choix par défaut peut toujours être  changé, cf. point précédent);
  • icônes vectorielles par défaut pour faciliter les changements de taille;
  • accueillir les nouveaux contributeurs en écrivant un fichier de style  de code pour vim, et en intégrant des fichiers contribués pour emacs et  kate;
  • écriture d’un paquet Flatpak pour GIMP;
  • et bien plus! Des corrections de bugs et des fonctionnalités mineures par dizaines!

Flatpak pour les créateurs sous Linux?

Les créateurs qui utilisent GIMP sous un système d’exploitation GNU/Linux ont probablement entendu parler de Flatpak,  le système générique d’applications pour Linux. Puisque nous utilisons aussi Linux ici, il nous semblait important que GIMP soit aisément et rapidement accessible dans une version récente (avec les systèmes de paquets actuels, obtenir une version récente demande souvent d’attendre plusieurs mois après la sortie!). Nous profitons de la sortie de 2.9.6 pour tester un premier paquet public. Puisque nous n’avons pas de serveur très stable à notre disposition, nous le mettons seulement à disposition des contributeurs Patreon et Tipeee pour l’instant, mais essaierons de faire en sorte que ce paquet soit disponible pour tous très bientôt!

Pour info, les utilisateurs Windows ont déjà un paquet téléchargeables; et un paquet MacOS devrait aussi normalement sortir (cela dépend du mainteneur du paquet qui a eu quelques priorités familiales). Mais ils ne sont pas gérés par nous. » Voir la page de téléchargement! « 🙂

Merci… et en route vers 2.10!

J’espère que vous aimez nos contributions à GIMP! Sachez que c’est rendu possible grâce à tous nos contributeurs, que ce soit sur Patreon ou Tipeee, lors de crowdfunding précédents, ou de ceux qui nous font des donations directes.

Ce  n’est pas facile tous les jours et nous avons eu plus d’une fois un  coup de blues du fait du manque de moyen, mais le fait que vous êtes  nombreux à nous aider nous donne du courage.
Merci à vous!

Nous continuons et vous apporterons une superbe version stable GIMP 2.10. 🙂

Amusez-vous bien!