La prochaine version majeure de GIMP se rapproche à grands pas. Le projet a déjà connu quatre sorties de développement : 2.9.2 fin 2015, 2.9.4 mi‐2016, 2.9.6 en août 2017 et 2.9.8 cette semaine.
Puisque nous prévoyons de sortir la version stable 2.10 très prochainement, les versions de développement s’accélèrent et nous devrions sortir bientôt des release candidates. C’est donc un moment où les remontées de rapports de bogues et les tests sont primordiaux.
Dans cet article, nous évoquerons certaines des évolutions majeures de la prochaine version de GIMP sans nécessairement rentrer dans le détail.
Enfin, nous listerons les moyens d’aider le projet GIMP, aussi bien en listant les moyens de donations (périodes de fin d’année propices à cela !) que les moyens de contribuer du temps : code, design, connaissances…
NdM : le projet ZeMarmot permet de faire beaucoup évoluer GIMP. Il est important de le soutenir !
Sommaire
- Nouveautés de la 2.9.2
- Nouveautés de la 2.9.4
- Nouveautés de la 2.9.6
- Nouveautés de la 2.9.8
- Ce qu’il reste à faire avant 2.10
- Financement du développement
Note : les descriptions ci‐dessous sont un résumé très rapide de chaque sortie de développement qui ne reflète qu’une infime partie des nouveautés de chaque version. Pour en savoir un peu plus, il est conseillé de lire les articles de sorties officiels (liens plus haut ; en outre, les articles officiels ont des vidéos que l’on ne peut intégrer ici), qui eux‐même ne sont que partiels. Pour une meilleure idée des nombreux changements, je ne peux que vous conseiller de vous référer au fichier NEWS, qui — bien que cette liste ne soit pas exhaustive non plus (vous voudrez lire le git log pour cela) — est la source la plus complète tout en restant simple à lire.
Nouveautés de la 2.9.2
Cette première version de développement fut très importante puisqu’il s’agit de la première version depuis le portage du moteur graphique. GEGL est en effet le changement majeur entre GIMP 2.8 et 2.10. Nous en avions d’ailleurs déjà parlé sur LinuxFr.org.
En deux mots, cela apporte les images à haute précision des couleurs, la prévisualisation des filtres sur le canevas, l’accélération matérielle et à multiples fils d’exécution (multi‐thread), etc. Et, bien entendu, toute la logique interne de GIMP a été revue, ce qui fut un gros travail, sans pour autant être si visible. En particulier avec GEGL, tout traitement d’image est un graphe, ce qui annonce le futur de GIMP pour l’édition non destructrice.
En outre, de nouveaux outils ont fait leur apparition, notamment en résultats de plusieurs Google Summer of Code, tels que :
- outil de transformation unifiée (toutes les transformations en un outil : rotation, mise à l’échelle, perspective, déplacement et inclinaison) ;
- outil warp, qui remplace le filtre iWarp et permet des effets similaires de manière bien plus intuitive :
La gestion des couleurs est devenue un citoyen de première classe en étant intégrée dans le cœur de GIMP, la gestion avancée des métadonnées fait son entrée et la peinture numérique n’est pas en reste avec la rotation et l’inversion du canevas.
De nouvelles prises en charge de formats ont aussi été implémentées : OpenEXR et WebP. Et plusieurs autres prises en charge de formats sont corrigées ou améliorées.
On peut aussi noter le portage de la gestion des fichiers vers GIO dans tout le code de GIMP, ce qui permet notamment l’accès aux fichiers distants de manière générique et fiable.
Nouveautés de la 2.9.4
Neuf mois plus tard, l’interface graphique de GIMP fait son petit défilé de mode avec l’arrivée de nouveaux thèmes et d’icônes symboliques, et surtout vectorielles, projet que je mène en gérant des contributeurs pour donner un renouveau à l’interface.
Outre l’aspect esthétique, le travail continue fort avec une gestion des couleurs de plus en plus poussée (dont notamment l’ajout de l’épreuvage numérique, ou soft‐proofing), ainsi qu’une amélioration constante de GEGL. Les filtres sont aussi progressivement portés comme opérations GEGL, et la prévisualisation de filtres peut désormais même se faire en comparaison avec l’image actuelle en manipulant un « rideau » de prévisualisation.
En outre, nous travaillons étroitement avec des développeurs de darktable et commençons ainsi une collaboration pour que les images brutes RAW s’ouvrent automatiquement dans ce développeur d’images RAW avant d’être automatiquement renvoyées dans GIMP ; en d’autres termes, si darktable est installé, il devient notre nouveau « greffon » pour la prise en charge des RAW, avec communication bilatérale. Vous pouvez, par exemple, voir cela fonctionner sur cette vidéo en lien (notons que certains en commentaires ne comprennent pas et croient que celui qui présente va trop vite ; mais non, c’est juste qu’il n’y a rien à voir : l’association entre GIMP et darktable marche simplement sans rien faire).
Nous travaillons aussi avec les développeurs de MyPaint et avons ainsi intégré leurs brosses dans GIMP (en plus des formats de brosses existants) grâce à la bibliothèque libmypaint sur laquelle je me suis mis à contribuer (au point d’obtenir les droits d’écriture sur le dépôt).
Ce n’est d’ailleurs pas le seul ajout intéressant pour les peintres numériques dans cette version, puisque j’y ai codé notamment la peinture en miroir, mandala et tuile après un financement participatif.
» Compte‐rendu de la contribution du projet ZeMarmot pour GIMP 2.9.4 «
Nouveautés de la 2.9.6
Cette version, sortie il y a quelques mois, accélère les optimisations pour les performances de GIMP, en particulier via l’optimisation de GEGL même et notamment en travaillant beaucoup sur l’exécution en parallèle (multi‐threading) des opérations.
Parallèlement je travaille sur la prise en charge des écrans à haute densité de pixels (HiDPI), ce qui était une des grosses raisons pour laquelle j’avais poussé à l’utilisation d’icônes vectorielles. De plus en plus de personnes se plaignaient que les icônes étaient vraiment trop petites sur leur super écran QHD ou 4K, nous avons donc pris les devants. Cela tombe bien, car nous avons nous‐mêmes acquis une tablette‐PC QHD le mois dernier ! À partir de la 2.9.6, la taille des icônes est désormais configurable depuis les préférences (avec auto‐détection de la densité de pixels par défaut), totalement indépendamment du thème choisi.
En parallèle, d’autres contributeurs travaillent sur la manipulation des filtres avec des poignées directement sur le canevas (pour une édition intuitive).
Plus important, GIMP se met à différencier davantage les espaces de couleurs linéaires et perceptuels (notamment dans les modes de calques), tout en séparant également les concepts de composition (compositing) et de mixage (blending) pour les utilisateurs avancés.
Le mode traversant (pass‐through) applicable à des groupes de calques (pour que ceux‐ci puissent ne servir que pour l’organisation) fait son apparition, ainsi que les étiquettes en couleurs pour organiser ses calques.
Continuant dans notre collaboration avec les autres projets, RawTherapee rejoint notre concept de greffon RAW. Dorénavant si RawTherapee est installé, il sera aussi utilisable comme intermédiaire. Et si darktable et RawTherapee sont tous deux présents sur votre machine, il sera possible de sélectionner le développeur RAW de votre choix dans les préférences de GIMP.
On notera que nous aimons collaborer avec d’autres projets. C’est, je pense, une des marques de fabrique de GIMP, qui a toujours collaboré avec les logiciels tiers et les a incité à s’améliorer. Et, surtout, nous poussons pour un écosystème logiciel amical. Pourquoi faire mal (avec un petit greffon et quelques curseurs mal pensés) ce que des logiciels libres spécialisés font déjà très bien, en l’occurrence ici du développement de RAW ? Certains peuvent y voir une logique de « suite créative du Libre » tout en gardant l’indépendance de chaque acteur.
Côté formats, il est désormais possible d’exporter des fichiers PDF multi‐pages, de nouvelles variantes du format PCX sont prises en charges, le format PSD (et d’autres) bénéficient aussi de nombreuses corrections de bogues. Les fonctionnalités avancées du format WebP, implémenté basiquement dans la 2.9.2, sont dorénavant prises en charge, en particulier l’animation, ce qui en fait un super remplaçant à GIF, si toutefois Firefox en ajoutait la prise en charge (plus performant, plus petits fichiers et meilleure qualité d’image, avec notamment une vraie gestion de la transparence et des couleurs 24 bits).
Ce n’est pas tout ! le projet ZeMarmot fut un des contributeurs majeurs et je vous recommande la lecture du compte‐rendu de la contribution du projet ZeMarmot pour GIMP 2.9.6
Nouveautés de la 2.9.8
Les nouveautés ralentissent car nous commençons à nous concentrer sur les corrections de bogues et quatre mois seulement se sont écoulés depuis la version précédente.
Notons que nous désactivons dorénavant OpenCL par défaut. En effet, les versions parallélisées (multi‐threaded) des algorithmes sont souvent plus rapides que les versions accélérées par le processeur graphique (notamment avec le pilote beignet pour les cartes Intel), et certains pilotes graphiques provoquent des bogues de rendu (en particulier les pilotes NVIDIA).
Une nouveauté en particulier fait cependant sa petite sensation : l’édition des dégradés directement sur le canevas avec l’outil de dégradé. Cela fait suite au travail d’interaction dynamique avec les filtres sur le canevas entamé dans la version 2.9.4 (mais utilisé jusque‐là uniquement sur deux filtres mineurs comme base de test, à savoir Spirale et Supernova).
L’article officiel contient aussi une vidéo plus explicite qu’une description textuelle !
En dehors de cela :
- un nouveau filtre d’affichage pour mettre en valeur les zones sous‐exposées et surexposées d’une image fait son apparition ;
- la gestion des couleurs migre progressivement vers l’utilisation de babl seulement (en remplacement de LittleCMS) quand cela est possible, permettant un gain de performance assez important ;
- le portage pour Wayland continue son chemin, notamment avec l’implémentation des captures d’écran (KDE et GNOME) ainsi que de pixels uniques (KDE seulement pour l’instant, GNOME n’ayant pas encore l’API) ;
- la fonctionnalité de « coller sur place » apparaît, permettant de coller d’une image à l’autre en gardant les mêmes coordonnées ;
- les boutons curseurs (spin buttons) de GIMP ont été améliorés, car beaucoup de gens ne réalisaient pas que les zones haute et basse permettaient un glissement respectivement instantané et relatif. Les deux zones sont désormais illuminées au survol de la souris pour marquer la différence :
- les informations de rotation et d’inversion de canevas sont désormais affichées dans la barre d’état et permettent de revenir à l’état initial d’un clic :
- il est désormais possible de choisir le langage de l’aide contextuelle, indépendamment de la langue de l’interface :
- la prise en charge des fichiers PSD est encore améliorée ;
- les fichiers PDF avec mot de passe sont désormais importables ;
- le format HGT de la Shuttle Radar Topography Mission (NASA et autres organismes spatiaux) est désormais pris en charge et permet de créer des cartes de relief à partir de données d’élévation de cette mission (voir mon article expliquant ce format et son utilisation) :
- et bien plus !
Note : Le projet ZeMarmot n’a pas encore préparé son compte‐rendu sur son implication (importante encore) dans la sortie de cette version toute fraîche.
Ce qu’il reste à faire avant 2.10
Il reste au jour de l’écriture du présent article 49 bogues marqués pour 2.10, bien que ce nombre ne cesse d’osciller depuis des mois (fin mars, nous annoncions passer sous la barre des 50 bogues !).
Néanmoins, j’ai récemment repriorisé les bogues en marquant en bloqueurs les bogues que nous devons corriger en priorité (soit parce qu’ils concernent des fonctionnalités importantes et beaucoup usitées, soit parce qu’ils sont critiques, de type « plantage » ou gel du logiciel, soit pour des rapports avec correctif proche de la complétion qu’il serait dommage de reporter, etc.). Ce sont les bogues en rouge dans la liste donnée en lien plus haut. Ainsi, on peut considérer qu’il ne reste en fait que 18 bogues bloquant la prochaine version majeure de GIMP !
Bien sûr, cette liste elle‐même doit être pondérée, car nous nous attendons à de nouveaux bogues rapportés après les sorties de développement et nous avons aussi quelques tâches que nous savons avoir à faire sans pour autant avoir créé de rapports de bogue.
Nous sommes ainsi en train de considérer le gel des fonctionnalités et des chaînes de caractères (en particulier, les textes visibles de l’interface), pour ainsi rentrer dans une phase de sortie des versions release candidates qui préparent la sortie finale de GIMP 2.10.
Quoi qu’il en soit, nous sommes très proches d’une sortie. C’est donc une période très excitante !
Comment aider GIMP à passer les dernières étapes avant stabilisation ?
La première chose à faire, la plus évidente, est de tester cette nouvelle version de développement et de rapporter les bogues. Malheureusement, nous ne fournissons pas de construction (build) de développement pour GNU/Linux à ce jour (nous proposons désormais un build Flatpak officiel sur Flathub, mais il ne concerne que la version stable).
Vous devrez donc vous procurer un des constructions tierces (il existe un PPA non officiel et certaines distributions proposent des paquetages de la version de développement, semble‐t‐il) ou le compiler vous‐même.
Bien entendu, pour ceux qui codent et ont envie de se faire les dents, il est possible de jeter un œil à notre liste de bogues pour la version 2.10. Cependant les bogues bloqueurs restants sont pour la plupart peu recommandables à de nouveaux contributeurs, mais nous acceptons bien sûr des corrections sur d’autres bogues aussi.
La liste des bogues « newcomers » peut aussi être d’intérêt.
On peut aussi noter que nous avons quelques hésitations au sujet des nouveaux thèmes apparus dans la version 2.9.4. En particulier parce que le contributeur qui les a commencés semble s’en être désintéressé alors qu’ils ont divers problèmes, notamment des contrastes faibles ici et là, mais aussi parce qu’ils sont livrés avec beaucoup trop d’images pour l’interface alors qu’un thème devrait être le plus léger possible (juste des règles de style, pas d’images). Certains parlent même d’abandonner ces thèmes.
Nous accueillons donc à bras ouvert les gens qui veulent soit corriger et maintenir les thèmes existants, voire carrément en proposer de nouveaux plus maintenables.
Financement du développement
GIMP, c’est quoi ? C’est qui ?
GIMP a été entièrement développé en bénévolat jusqu’à très récemment. Et, notamment, il n’existe même pas d’entité légale GIMP, ce qui explique qu’il ne peut y avoir de développement payé par le projet. L’argent du projet (par donation) est géré par la fondation GNOME qui sert d’organisme « chapeau » à GIMP (notons bien que GIMP n’est pas un projet GNOME, il s’agit d’un accord mutuellement bénéfique) et ne sert que pour les activités bénévoles. Par exemple, tous les ans, il permet de faire venir les développeurs et autres personnes importantes de la communauté du graphisme libre au Libre Graphics Meeting (LGM) et cette année même à la Wilber Week. Nous nous en servons aussi régulièrement pour financer certains évènements (dont notamment plusieurs LGM justement, qui a commencé historiquement comme une extension de la réunion GIMP si j’ai bien compris).
Le projet a gardé cet esprit très social et bénévole que j’apprécie énormément.
Et pour financer du développement ?
Dernièrement, certains développeurs tentent de vivre de leurs contributions de code par financements participatifs. Il s’agit de pippin et moi‐même. Ces financements sont faits en nos noms propres (dans mon cas, plutôt au nom du projet ZeMarmot, dont il est régulièrement question sur LinuxFr.org), mais le projet GIMP nous soutient (nos campagnes respectives sont ainsi citées sur la page de donation de GIMP).
Øyvind Kolås, alias pippin (il tient à la minuscule sur son pseudo), est le mainteneur actuel de GEGL, le moteur graphique de GIMP. Il a commencé le financement participatif mensuel de son travail en début 2017 sur la plate‐forme Patreon et a ainsi récemment fait le bilan de sa première année assez positive.
De notre côté, le bilan est moins positif (même si les perspectives se sont un peu améliorées en fin d’année après avoir partagé un peu de nos problèmes financiers), notamment car nous sommes deux personnes sur le projet ZeMarmot.
Il semblerait que le problème principal soit le côté symbiotique art+code de notre projet. Certaines personnes nous ont ainsi dit explicitement qu’elles ne veulent pas nous financer car elles s’intéressent à GIMP mais pas à un film d’animation (apparemment, si je faisais un financement pour le développement seulement, j’aurais plus, ce qui m’attriste !). Pourtant, c’est l’un des cœurs de notre projet et nous ne souhaitons pas changer cela. Sans ce projet artistique, je ne coderais pas GIMP ; et sans mes corrections, Aryeom ne travaillerait pas sur ce film non plus. Comme je le disais, c’est symbiotique, mais c’est aussi symbolique !
Surtout que je ne pense pas affirmer vainement que GIMP profite énormément de l’usage que nous en faisons car nous l’utilisons de nombreuses heures au quotidien. Nous sommes ainsi les premiers à tomber sur beaucoup de bogues, ce qui permet des corrections très rapides.
Quoi qu’il en soit, tant qu’on arrive à tenir, je reste l’un des développeurs principaux du logiciel GIMP avec 306 commits en 2017 (sur 1 710 en tout, soit plus de 17 % des commits de l’année) et je rêve de pouvoir, un jour, financer suffisamment nos projets libres pour pouvoir affirmer en vivre.
En conclusion, comme la page officielle de donation de GIMP l’indique, il y a trois cibles de donation pour aider GIMP :
- donner au projet GIMP : cet argent sera utilisé pour les activités communautaires uniquement ;
- donner à pippin pour le développement de GEGL, sur Patreon ou Liberapay ;
- donner à ZeMarmot, ce qui se transformera en salaire pour moi pour le développement de GIMP, sur Liberapay, Tipeee, ou Patreon (Liberapay est a priori la plate‐forme avec le moins de frais, et l’on peut donner en euros et dollars états‐uniens).
Vous pouvez aussi donner directement à l’association LILA, association de loi 1901 française qui gère le projet ZeMarmot, par exemple en virement permanent (souvent sans frais en zone euro avec IBAN, bien que cela reste fonction des banques).
En cette fin d’année 2017, période de dons aux associations, j’espère donc que vous considérerez un petit don à LILA/ZeMarmot/GIMP !
Et j’espère aussi que vous appréciez les évolutions de GIMP.
Aller plus loin
- Liste des fonctionnalités majeures entre 2.8.x et 2.10. (1273 clics)
- Notes de sortie de 2.9.2 (106 clics)
- Notes de sortie de 2.9.4 (78 clics)
- Notes de sortie de 2.9.6 (89 clics)
- Notes de sortie de 2.9.8 (240 clics)
- Donation pour développement de GIMP/ZeMarmot par Liberapay (203 clics)
# Excellent travail.
Posté par gusterhack . Évalué à 10.
Très bon travail j'ai donnée pour Zemarmot pour (le film d'animation et pour le développement de gimp). Je regarde souvent les log git de Gimp et effectivement tu contribue énormément. En tout cas entre la 2.8 et la futur 2.10 sa va être le jour et la nuit. Hâte d'avoir la 2.10 qui seras sans doute doute dans la futur Debian 10. Même si maintenant je compile les dernière build pour suivre les nouveautés.
[^] # Re: Excellent travail.
Posté par Jehan (site web personnel, Mastodon) . Évalué à 8. Dernière modification le 14 décembre 2017 à 21:26.
Merci!
Clairement. On n'utilise plus la 2.8 depuis presque 2 ans. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Excellent travail.
Posté par tao popus . Évalué à 5.
Merci pour ce super article aussi (en plus du travail effectué sur Gimp). Effectivement, je n'avais pas vu pour la partie haute/basse des glissoirs, c'est une bonne idée d'illuminer les 2 parties.
Le lien de notes de version pour gimp-2.8.9 retourne un 404, avec une animation sympa.
Sur ArchLinux, il y a un paquet AUR gimp-devel qui permet de suivre les mies à jour.
Je ne sais pas pourquoi, peut être parce que babl et gegl sont des paquets -git, mais il faut les mettre à jour manuellement. donc il faut d'abord les (ré)installer à chaque nouvelle version devel).
Donc, je conseillerais de faire ça (l'ordre est important, tout en une seule ligne marche peut être mais pas testé), il faut préalablement installer pacaur bien entendu) :
[^] # Re: Excellent travail.
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
Oui, c'est une bonne évolution design cette illumination. Ça a été codé par un nouveau développeur super actif depuis un an (Ell), qui est apparu et soudain s'est mis à contribuer plein de code de super niveau. Ça fait plaisir.
Oups! En effet, c'est l'adresse sur le site testing quand la news était encore en brouillon. Le bon lien:
https://www.gimp.org/news/2017/12/12/gimp-2-9-8-released/
Si un gentil modo pouvait mettre à jour!
Eheheh. Oui ça c'est un petit cadeau de ZeMarmot aussi. ;-)
On a contribué cette animation pour la page 404 y a quelques temps en profitant de l'occasion pour découvrir les animations SVG (il me semblait avoir fait un journal à ce sujet, mais je le retrouve pas).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Excellent travail.
Posté par ZeroHeure . Évalué à 2.
C'est fait.
Pour les curieux de l'animation voici l'ancien lien
https://testing.gimp.org/news/gimp-2-9-8-released.html
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Excellent travail.
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
En fait, c'est juste une page 404, donc n'importe quel page inexistante de gimp.org affichera l'animation. ;-)
Genre: https://www.gimp.org/bonjour
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Excellent travail.
Posté par Stéphane Ascoët (site web personnel) . Évalué à -8.
Ce qui m’embête c'est qu'une page 404 est censée être légère et que là, ça participe à l'embonpoint du Web entraînant un sur-armement matériel.
[^] # Re: Excellent travail.
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
C'est juste une petite blague inoffensive et on parle là d'une petite image vectorielle de 130KB sur le site d'un éditeur d'image et de peinture moderne. Presque n'importe quelle image sur la page d'accueil (celles en bandeau) est plus lourde (alors qu'y en a plusieurs).
Parler de sur-armement matériel pour cette petite blagounette animée de 130kb sur le site d'un logiciel d'imagerie me paraît être un sur-armement lexical. :P
P.S.: en plus sur un site entièrement statique, qui ne pratique donc pas de surarment côté serveur!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Excellent travail.
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Surtout pour une page qui est sensée ne pas être vue. :-)
Avec beaucoup de perversité on peut imaginer une page 404 qui boucle des requêtes vers le serveur pour déclencher une alerte température !
cf. le xkcd kivabien ( ͡° ͜ʖ ͡°)
ce commentaire est sous licence cc by 4 et précédentes
# roadmap trop importante ?
Posté par ff9097 . Évalué à 7.
Bonsoir,
Merci pour votre travail sur GIMP qui reste un élément très important et emblématique de l'écosystème libre.
Ne pensez-vous pas que la roadmap 2.10 n'est été trop importante étant donné le nombre limités de contributeurs actifs sur le projet ? Par exemple j'ai du mal à comprendre pourquoi ne pas s'être contenté de la migration GEGL pour cette version. Je ne vais pas expliquer les avantages d'avoir des releases plus fréquentes je pense ne rien vous apprendre mais j'ai du mal à comprendre
Merci
[^] # Re: roadmap trop importante ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 15 décembre 2017 à 02:24.
Je crois que cette phrase de mon article répond à ta question:
En gros, une entreprise (ou autre entité unique qui gère un logiciel avec des employés) va avoir sa roadmap interne et elle priorise plus facilement certains trucs. Ce n'est pas forcément mieux pour tout. Cela peut d'ailleurs provoquer des conflits avec la communauté quand certains aspects sont trop strictement contrôlés par cette entité, voire quand des refus (ou non-intégration sans refus clair) de fonctionnalités se produisent sans raison claire (par exemple, le rapport de bug de la fonctionnalité WebP dont je donne un lien plus haut vers le bugzilla de Mozilla est à un moment complètement parti en vrille car il y a des patchs depuis plus d'un an et beaucoup de gens attendent que Mozilla finissent la revue et l'intègre; au final le bug est passé lecture seule pour stopper la montée en troll).
Ils ont des employés, ils ont une roadmap probablement assez directive, ils s'y tiennent, et parfois s'ils ont le temps, ils se permettent de regarder un peu ce que fait la communauté.
Dans le cas de GIMP, c'est complètement différent. Pourquoi? Parce qu'y a aucun manager pour dire "c'est la roadmap, c'est comme ça, vous obéissez", et aucun employé pour suivre cette roadmap (qu'il peut discuter, mais au final s'il veut garder son job et que ses arguments sont refusés, il suivra). La "roadmap" de GIMP est donc totalement fluide et cible mouvante. Si tu préfères, on peut presque dire qu'il n'y a pas vraiment de roadmap (dit-il en donnant un lien). Elle est "presque" faite après coup. Ou plutôt puisqu'on se base quasi-essentiellement sur le volontariat, elle dépend des contributeurs du moment. Si y a un contributeur très impliqué qui un jour décide que telle fonctionnalité est sa priorité, alors cela rentre plus ou moins naturellement dans notre roadmap. Bon sauf si la dite-fonctionnalité est totalement tordue et que les autres dévs la refusent… en particulier le mainteneur qui aura le dernier mot (il y a quand même une "vision" du logiciel, disons qu'elle est plus fluide que dans un logiciel commercial).
Pour 2.10, le seul vrai item de la roadmap initiale selon moi, le fil directeur, c'était — je pense — le port de GEGL. Quasiment tout le reste, c'était des choses qui sont simplement arrivées naturellement pendant ce port car des gens (les dévs core ou des contributeurs externes) ont proposés ces améliorations. Quasi rien de ce que vous lisez dans cette news n'était initialement prévu (du moins, pas noir sur blanc comme un plan clair et net).
Le port GEGL en particulier a pris beaucoup de temps car c'est un sujet compliqué, et comme tu le dis, y a peu de développeurs. Lors de mes premiers builds (fin 2012, quand j'ai commencé à contribuer avec quelques patchs mineurs), le gros du port vers GEGL avait déjà été fait, mais GIMP 2.9 était tout simplement inutilisable au quotidien. Les opérations et surtout la peinture sur canevas était incroyablement lentes (tu faisais un trait puis tu allais faire un café le temps que ça apparaisse, ou presque ;p). Les choses se sont progressivement améliorées mais cela a pris du temps. Pendant ce temps là, quand les gens proposaient des patchs pour des nouvelles fonctionnalités super cools, ben le projet allait pas les refuser (sinon les gens proposent plus de patchs et y a pas de nouveaux dévs!).
En gros, tu ne peux pas refuser des fonctionnalités en demandant aux gens de bosser sur autre chose. Si un gars nous propose un patch géniale sur une fonctionnalité révolutionnaire, tu ne vas pas lui dire "ah c'est pas dans notre roadmap, désolé. Par contre, on remarque que tu es un développeur doué. Tu voudrais pas plutôt coder sur GEGL ou le port de GEGL dans GIMP?". Tu fais ça, le gars se barre (en gueulant ou silencieusement suivant les tempéraments), tu entends plus parler de lui et tu viens de tirer un trait sur ta fonctionnalité révolutionnaire.
Par contre, si tu te dis "c'est vraiment trop cool, faut qu'on intègre ça", ben tu te prends un peu de temps pour faire de la revue, commenter le code, demander des corrections, puis l'intégrer, probablement rajouter du code autour pour rendre le truc encore plus génial, etc. Au final, oui tu as utilisé du temps (qui peut-être aurait pu être utilisé pour le port de GEGL… ou pas! On rappelle: volontariat, les gens bossent sur ce qu'ils veulent), ça n'a pas fait avancer GEGL, mais tu as une méga fonctionnalité à la fin. Et le nouveau contributeur, peut-être même qu'il va rester dans le coin et proposer d'autres fonctionnalités géniales. Ou pas. Peut-être qu'il va vouloir aider au port GEGL. Ou pas. Peut-être qu'il va se barrer et on va jamais le revoir. C'est 90% des cas mais ça reste mieux que refuser la fonctionnalité et le gars se barre dans 100% des cas, et en plus on perd une fonctionnalité.
Et surtout, les nouvelles fonctionnalités n'impactent en rien (ou rarement) le port vers GEGL. Donc les refuser sous prétexte que ce n'est pas dans la roadmap n'a aucun intérêt. Refuser une fonctionnalité super cool car GEGL est lent, ou que d'autres parties de GIMP ne sont pas encore portées n'améliore pas ces aspects problématiques (ça n'empire pas non plus. En gros, rien à voir, fils unique, quoi…). Par contre bien sûr, on demande à ce que les nouvelles fonctionnalités soient bien basées sur GEGL (si pertinent). On veut pas intégrer une fonctionnalité basée sur 2.8 et devoir la porter après coup. Là oui, ce serait aller à reculons.
Je suppose que tu parles de sorties avec de nouvelles fonctionnalités. Non parce que sinon, GIMP a des sorties tous les 3 à 6 mois (on est à la version 2.8.22, ça fait 12 sorties depuis 2012, c'est plutôt fréquent!). ;-)
Donc oui, je suis d'accord avec toi; notre problème est qu'on fait partie de ces logiciels de la vieille époque qui ont des majeures, mineurs, avec une sémantique des versions, et en particulier: pas de nouvelles fonctionnalités dans une mineure. Depuis les logiques de sortie ont changés dans beaucoup de logiciels jusqu'au point de même faire sauter les logiques de majeures/mineures tout court (beaucoup de logiciels incrémentent simplement à chaque sortie).
On était bloqué par le port de GEGL. Comme je l'ai dit, pendant plusieurs années, c'était trop lent, ou trop imparfait, etc. Mais on est bien conscient du problème et on a décider de faire évoluer notre mode de sortie après la 2.10 car nous entamerons alors un nouveau port qui peut être à nouveau long: le port vers GTK+3.
Nous avons donc décidé et annoncé officiellement en début d'années que nous assouplirons la règle "pas de nouvelle fonctionnalité dans des sorties mineures" après GIMP 2.10.
C'est une évolution que je pousse depuis 2014 (voir par exemple ce compte-rendu de LGM, section "Les réunions GIMP"), et j'ai finalement réussi à faire progresser cela jusqu'à une officialisation.
Donc oui, GIMP aura des sorties de fonctionnalités plus régulières à partir de 2.10. Il y a de fortes chances que nous assouplissons encore plus la logique des versions après GIMP 3. En tous cas, c'est personnellement dans ce sens là que je pousse.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: roadmap trop importante ?
Posté par ʭ ☯ . Évalué à 4.
Merci pour cette excellente communication!
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: roadmap trop importante ?
Posté par tao popus . Évalué à 1.
Et d'un autre côté les version devel (pas git mais numérotées) sont suffisamment stable pour être utilisées sur des tâches quotidiennes (peut être pas sur de la grosse production ou en sauvegardant régulièrement ?). Personnellement, j'utilise depuis au moins un an, pas intensivement, mais assez souvent, je n'ai eu aucun plantage. J'ai toujours eu tendance à faire ça avec Gimp d'ailleurs.
[^] # Re: roadmap trop importante ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 8.
On l'utilise sur de la petite prod (utilisation quotidienne mais par une personne) depuis environ 2 ans.
C'est en effet très stable (mon object n°1).
Ensuite il faut garder en mémoire que ça reste une version de développement quand même et nous on peut se le permettre plus facilement car je suis là. Il m'est arrivé (une unique fois) d'avoir à "sauver" des fichiers XCF corrompus par un bug. Un artiste non-codeur seul n'aurait vraisemblablement pas pu le faire. Mais de manière général, c'est vrai pour toute production de film (récente, donc avec utilisation de technos numériques). Si tu regardes les génériques de tout film, y a toujours des équipes de développeurs (principalement pour développer les logiciels internes, je pense, mais on peut imaginer qu'ils seront aussi présent pour sauver des fichiers en cas de bourdes et qu'ils peuvent aider les artistes ponctuellement au besoin).
Nous on est juste la version réduite avec équipe de 1 artiste + 1 dév. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: roadmap trop importante ?
Posté par gnumdk (site web personnel) . Évalué à 9.
Je pense que ce n'est absolument pas pertinent de continuer ce port, il faut à mon avis viser directement GTK+4 car sinon, on aura un Gimp GTK+3 qui sortira 1 ans après que tout l'environnement GNOME soit porté sous GTK+4…
[^] # Re: roadmap trop importante ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
Ce n'est pas exclus, on en parlait lors de notre réunion Wilber Week (cherche "GTK+4" dans le lien).
À ce jour, GTK+4 n'est pas sorti et il ne faut donc pas mettre la charrue avant les bœufs, surtout que c'est encore vachement instable (par nature de pas être sorti!).
À suivre…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: roadmap trop importante ?
Posté par alex666 . Évalué à 0.
Assez de débats sur l'interface; des fonctionnalités !!!
Utilisateur depuis une dizaine d'années de Gimp (en retouche photo), parfaitement content de l'interface multifenêtres qui fait régulièrement l'objet de Gimp-bashing…
Parfaitement satisfait, y compris des 2.9.x qui sont pour moi parfaitement utilisables.
Je vais faire un don à Gimp (mais pas à Marmot qui n'est pas dans mon champ d'intérêt, désolé Jehan…)
[^] # Re: roadmap trop importante ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Je pense que cette news (et les liens officiels pour compléter) sont suffisants pour te rendre heureux alors, non? ;-)
Je crois pas qu'on ait oublié les nouvelles fonctionnalités. :P
Sinon je voulais noter que la mise-à-jour de GTK+, c'est énormément plus que de l'interface pure. Déjà c'est des fonctionnalités en pagaille. J'ai commencé une meilleure prise en charge de HiDPI dans GIMP 2.10, mais GTK+ >= 3 va énormément simplifier les choses pour une bien meilleure prise en charge des densités d'écran diverses. De même pour une bien meilleure prise en charge des tablettes graphiques qui est vachement problématique dans GIMP 2.x à ce jour. Notamment on aura enfin du hotplug (à l'heure actuelle, la tablette doit être branchée avant de démarrer GIMP pour être détectée/active), de bien meilleures détections de périphériques, et on pourra travailler sur la proposition de meilleurs configurations par défaut, etc. Y a aussi la prise en charge native de Wayland (pour l'instant, ça passe par XWayland). Et bien sûr l'accès à plein de nouveaux widgets (ce qui n'est pas juste esthétique mais utile). Une prise en charge des variantes de thèmes natives (comme les thèmes clairs et sombres) qui ne sont plus des thèmes différents, mais un même thème avec une variante (ce n'est pas juste esthétique; énormément de personnes considèrent les thèmes sombres comme une fonctionnalité essentielle, en particulier pour un logiciel de graphisme). Des thèmes bien plus maintenables en CSS.
Et j'en oublie.
De plus l'interface, c'est aussi la simplicité d'usage ("l'utilisabilité" chère aux designers, "usability" en anglais). Et franchement, c'est pas rien.
Très bien. Y a pas de problèmes. Déjà si tu fais un don au projet GIMP, c'est super cool et je t'en remercie.
Je rappelle cependant que les contributions de ZeMarmot, c'est pas juste "faire de l'animation" avec GIMP, ni même "faire du dessin", loin de là. 99% des changements qu'on a apportés sont super utiles à tous. Et je parle même pas du débugging quotidien (donc de la stabilité notamment) et de la revue de code importante qu'on fait. Voir aussi nos comptes-rendus de la 2.9.4 et 2.9.6 notamment (on en avait pas fait pour la 2.9.2 bien qu'on contribuait déjà, et pas encore fait celui de la 2.9.8).
Le logiciel est un tout (y a pas une partie "photo" dissociée d'une partie "dessin"), et pour pouvoir dessiner convenablement, on a besoin d'un logiciel bon globalement et donc nous l'améliorons globalement.
Bon c'était ma minute marketing, parce qu'il faut bien. Mais si tu n'es toujours pas convaincu de notre utilité, je vais pas faire mon lourd. :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Une build !
Posté par ted (site web personnel) . Évalué à 4. Dernière modification le 15 décembre 2017 à 12:05.
J'aimerai beaucoup aider à remonter des bugs, mais sans build c'est compliqué. Cela signifie installer plein de dépendances, dans des versions particulières, pour réussir peut être à avoir un GIMP qui marche: on passe plus de temps à faire ça qu'à utiliser le logiciel.
Je comprend que fournir des builds c'est compliqué pour les dev, mais il suffirait de faire une fois un flatpack pour que tout le monde puisse en bénéficier. Ça doit être automatisé, comme le font Blender et Firefox…
Remplir un rapport de bug, ce n'est déja pas donné à tout le monde, alors compiler son logiciel…
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Une build !
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
J'avais noté une fois la liste de dépendances (obligatoires et optionnelles) pour quasi l'ensemble des options de GIMP sous Linux (il manque que webkitgtk mais c'est parce que nous nous basons sur une trop vieille version à cause de GTK+2, qui commence à disparaître des distributions depuis cette année), avec une Fedora 27:
À mettre en correspondance aux bons paquets sur une autre distrib.
Puis tu dois compiler toi-même libmypaint, babl, GEGL et enfin GIMP (dans cet ordre, sauf libmypaint qui peut être compilé n'importe quand tant que c'est avant GIMP).
L'ensemble du processus, compilation comprise se fait en moins de 30 minutes sur ma machine de ~5 ans (bonne machine néanmoins: i7, 8GB de RAM et SSD) et j'ai vu des compilations de GIMP vachement plus rapides sur de meilleures machines.
Voilà avec ça, je crois que ça devrait pas prendre trop de temps. :-)
Bien sûr, sur d'autres distributions moins à jour que Fedora, il n'y a pas à douter que tu devras probablement compiler d'autres dépendances (peut-être lcms2 voire libpng; il m'est déjà arrivé d'avoir à compiler Exiv2/GExiv2 mais ça date un peu et j'espère que toutes les distribs se sont mises à jour depuis) mais ça reste rapide (je pense que sur une distrib moderne, tu peux largement compiler GIMP et les dépendances absentes du système de paquet en moins d'une heure).
C'est pas compliqué. Je maintiens le flatpak officiel de GIMP sur flathub (mais c'est la version stable, pas de build dév; politique flathub). J'ai déjà les fichiers "manifest" pour un flatpak dev et un nightly et je mets à jour un dépôt privé pour ceux-ci que je fournis pour l'instant juste aux donateurs (et aux gens qui m'en font la demande en privé). La raison est que mon "serveur" est en fait un vieux desktop dans la cave de l'association LILA, qui peine à tourner (le paquet entier compile en 24h dessus, alors qu'il compile en moins de 2h sur flathub — c'est plus que ce que je disais plus haut, mais y a plus de dépendances à compiler dans ce cas là et c'est surtout à cause de webkit qui prend à lui seul 99% du temps de compilation!), tellement vieux qu'il a aidé à trouver et tester un bug de flatpak pour des vieux x86 sans SSE (de mémoire)! Donc je peux pas m'en servir pour soutenir la charge de millions d'utilisateurs de GIMP qui veulent la dernière version.
Je recherche donc une solution. On va peut-être pouvoir fournir ce dépôt sur les serveurs de GIMP mais c'est pas encore clair/sûr (je n'ai pas l'accès perso aux serveurs de download de GIMP; et volontariat, tout ça, j'ai du mal à chopper l'info auprès de ceux qui ont l'accès).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Une build !
Posté par ted (site web personnel) . Évalué à 2.
Je suis sous Linux Mint 18.3, je tenterai la compilation avec tes indications. J'arriverai peut être à le faire, mais je connais pas mal d'utilisateurs de Gimp plutôt technophiles qui n'en sont pas capable, et c'est dommage de se priver du retour de ces utilisateurs.
J'ai vu que Flatpak est installé sur mon ordinateur, mais je ne l'ai jamais utilisé, et je ne sais pas comment ça fonctionne (je n'arrive pas à le lancer depuis le gestionnaire de logiciels, et ne le trouve pas dans les menus). À moins qu'il n'y ait pas d'interface?? Je trouve le système AppImage plus simple: un gros binaire à exécuter, ça juste marche.
Pour partager les builds, tu ne penses pas que Bittorrent puisse faire l'affaire? On a le projet dans notre association de nous auto-héberger, il y a peut être moyen de seeder un peu, et moi de même depuis la maison. Au moins pour les RC!
Notre asso a fait un don à LiLa le mois dernier, du coup si on peut avoir une build… ;)
(Je n'avais pas eu de réponse en vous envoyant un message depuis votre formulaire de contact)
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Une build !
Posté par ff9097 . Évalué à 2. Dernière modification le 15 décembre 2017 à 19:02.
flatpak n'a pas d'interface officielle, mais GNOME Logiciels le gère très bien. Tu peux aller voir https://flathub.org/ pour mieux comprendre.
AppImage n'est pas pareil, c'est juste un gros bundle sans aucune intégration système, sans sandbox, sans installation ni mise à jour propre
[^] # Re: Une build !
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
Cool merci.
Je retrouve pas cet email. Normalement je fais la revue de tous les emails reçus par l'asso et essaie d'y répondre personnellement (bien que je croule aussi sous les emails, donc des fois, il m'arrive de les remettre à plus tard, puis d'oublier de répondre).
Tu peux m'envoyer un email, par exemple à jehan chez GIMP (nom de domaine du logiciel), qui est un alias vers mon adresse principale. Et oui bien sûr, y aura pas de problème pour te donner un accès à mon build flatpak. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Une build !
Posté par AR7 (site web personnel) . Évalué à 6. Dernière modification le 16 décembre 2017 à 00:52.
Ça me fait penser que j'avais construit une AppImage d'une version de développement de GIMP pour voir à quoi ressemblait le plugin GIMP Motion. C'était le haut de la branche wip/animation du coup, pas de la branche master.
Le dépôt est là. L'AppImage réussissait à se lancer sur openSUSE Tumbleweed, Leap 42.3 et sur Debian 9 quand j'avais testé. Mais je n'étais pas allé très loin après…
J'avais fait ça avec l'Open Build Service. Cela permet d'automatiser la récupération des sources depuis un dépôt git, la construction du paquet RPM et, du coup, la création d'une AppImage à partir du paquet RPM et de ses dépendances. Il crée aussi visiblement un fichier zsync, ça doit être utile pour mettre à jour l'AppImage.
Les sources sont là.
[^] # Re: Une build !
Posté par claudex . Évalué à 7.
Si c'est juste un serveur pour distribuer des fichiers en https que tu cherche, je peux t'en fournir avec accès via sftp. Si c'est pour du build, il y a moyen aussi (mais il faut que m'organise un peu).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Une build !
Posté par alex666 . Évalué à 1. Dernière modification le 15 décembre 2017 à 17:07.
Pour moi, il suffit de cliquer sur "mettre à jour Gimp-git" dans pamac (Manjaro) et d'aller prendre un café…
C'est atrocement compliqué! et ça prend tout compris 20 mn chez moi (un café, plus c'est rapide et moins c'est bon)
Et pour selfcompiler, c'est un script de 2 lignes qu'on trouve facilement
# Énorme!
Posté par Stéphane Ascoët (site web personnel) . Évalué à 2.
Peut-on donc conclure de tout cela que le CMJN sera géré, enlevant ainsi un gros reproche fait par beaucoup à The Gimp ?
Tu parles de Darktable et d'un autre outil Raw, mais Ufraw est-il toujours connectable ?
[^] # Re: Énorme!
Posté par alex666 . Évalué à 2.
Je conseillerais photoflow, plugin que j'utilise toujours, dans ses fonctions basiques, et qui ne se limite pas à 8 bits (sauf manip)
Pourquoi faire de la retouche locale, des masques et tout le toutim dans un convertisseur de raw, alors que Gimp règle ça très bien?
Pourquoi un convertisseur de raw se mêlerait-il de catalogage?
[^] # Re: Énorme!
Posté par Stéphane Ascoët (site web personnel) . Évalué à 1.
À qui poses-tu ces questions? Je ne me sens pas concerné…
[^] # Re: Énorme!
Posté par alex666 . Évalué à 0.
Tu as raison!
Il s'agit de questions générales…
Des logiciels "à tout faire" pour ne pas (trop) dépayser ceux qui ne conçoivent le monde de l'image qu'à travers un certain logiciel? et qui de toute façon seront le bec dans l'eau si leur logiciel disparaît ou devient trop payant.
Pour ufraw, sauf erreur de ma part, il ne gère que le 8 bits et est peu maintenu. Dommage.
[^] # Re: Énorme!
Posté par Lahminewski . Évalué à 1.
Je suis d'accord avec toi j'ai pas mal de problème avec les logiques couteaux suisse où les logicielles sont bon mais il faut prendre le pack en entiers.
J'aimerais bien trouver un Rawterapee ou un darktable sans le catalogage. Je regarderais si photoflow ça marche pour moi. ;)
[^] # Re: Énorme!
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
Pour info, je viens de jeter un œil rapide et il semble que le dév de Photoflow ait fait un plug-in avec la nouvelle API de GIMP: http://photoflowblog.blogspot.fr/2017/02/the-new-photoflow-gimp-plug-in-interface.html#more
En installant ce plug-in, il sera donc possible d'utiliser Photoflow comme plug-in raw au même titre que les autres. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Énorme!
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
Y a du soft-proofing qui permet de voir l'image convertie dans un profil colorimétrique de sortie (qui peut typiquement être un profil CMYK d'imprimante). Mais l'image de travail (cad les pixels) reste RGB.
Il s'agit d'un plug-in tiers, n'est-ce pas? Dans ce cas, je pense que ça devrait marcher, oui. L'API reste compatible entre 2.8 et 2.10 (ce sera une autre histoire à partir de GIMP 3 où on fera un peu de ménage de vieilles API dépréciées, mais vous avez le temps en années!), donc les plug-ins doivent toujours fonctionner. Quoique, je suis pas sûr ce que GIMP fait si plusieurs plug-ins essaient de s'enregistrer pour le même format avec les APIs standards. Donc à vérifier.
Dans tous les cas, je conseille à ce logiciel de se mettre à jour et donc plutôt passer par la nouvelle API pour se déclarer comme gérant les fichiers de type RAW: gimp_register_file_handler_raw().
Cela permettra d'être traité par GIMP au même titre que les autres, d'être disponible dans les préférences (utile en cas d'installation de plusieurs logiciels de ce type pour sélectionner son préféré), etc.
Ce que nous avons fait avec darktable et RawTherapee n'est absolument pas un "contrat d'exclusivité". Tout logiciel de développement de RAW est invité à se joindre à la fête et à pouvoir communiquer avec GIMP pour le traitement des RAW.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Énorme!
Posté par Stéphane Ascoët (site web personnel) . Évalué à 1.
J'ai créé un ticket, sans grand espoir, le projet semblant fort peu actif.
# Financement du développement seul
Posté par gasche . Évalué à 6.
C'est très étonnant comme réticence, je trouve, mais ça suggère une solution simple : pourquoi ne pas aussi ouvrir une source de financement en ton nom propre, au titre du développement de Gimp seulement ? Tu pourrais soit parler uniquement de la partie "film d'animation" dans l'espace ZeMarmot, soit parler des améliorations de Gimp dans tes retours d'information sur les deux financements. Je pense que personne ne verrait de problème à ça : les gens qui veulent financer seulement le code donneraient sur ton "compte de développeur Gimp", ceux qui veulent financer les deux (et Artyom aussi) donneraient sur ZeMarmot.
[^] # Re: Financement du développement seul
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Et pourtant… j'ai eu plusieurs commentaires de la sorte. Y a aussi le cas de ceux qui croient que ce qu'on fait ne touche que l'animation ou le dessin et donc ne changera rien à leur utilisation (photo par exemple). Y a justement le cas un peu plus haut en commentaire de cette news.
J'y ai pensé, mais déjà, ce serait une sorte de mensonge. Mon travail est essentiellement collaboratif et si jamais en faisant cela, le financement du film reste bas et on décide de l'arrêter, même si on me donnait beaucoup de sous pour du dév GIMP général seulement, ben je voudrais arrêter aussi probablement. Les gens ne comprendraient pas parce que je leur aurais promis du dév général de GIMP en mon nom (et ils auraient donc raison de ne pas comprendre). Je veux pas leur mentir et donc je suis clair dès le début: on fait ZeMarmot, en conséquence de quoi on améliore GIMP énormément et continuellement. C'est ça le vrai projet.
Je fais ça parce qu'on utilise GIMP, et on a nos priorités effectives. Cela ne nous empêche pas de faire du dév général au passage, bien au contraire. C'est une conséquence évidente car le logiciel doit marcher bien globalement pour marcher bien dans notre cas d'usage. Mais ça n'empêche que je veux garder notre priorité en tête.
Pour moi, ma motivation principale de contribution à un logiciel, c'est parce que je l'utilise et rencontre un problème ou un manque. J'ai plusieurs patchs dans Blender car on avait des crashs avec certains exports de format (de mémoire); un patch dans Firefox (pour un truc que finalement je n'utilise pas; mais à l'époque c'était pour ça); des patchs dans mplayer puis mpv pour des fonctionnalités dont j'avais besoin car ce sont mes lecteurs vidéos de choix (enfin mplayer l'était, maintenant je suis passé à mpv); etc. Je patche, car j'utilise, pas juste pour me faire plaisir (même si ça me fait aussi plaisir accessoirement). C'est comme ça. GIMP et ZeMarmot, c'est donc pareil. :-)
Autre point: on a déjà 3 plateformes de financement (on en avait 2 jusqu'à y a quelques jours, mais après les problèmes de Patreon ce mois-ci, et comme plusieurs personnes nous parlaient de Liberapay, on vient d'y ouvrir un compte)!. Et franchement c'est lourd en gestion. On n'est pas une entreprise, on n'a pas de service de gestion et compta dédié. C'est nous qui faisons un peu tout (avec des bénévoles de LILA qui aident). Je préfère aussi éviter de diviser encore plus avec un financement séparé.
Finalement, dernier point: j'aime le travail d'équipe. J'aime que les gens savent qu'on bosse à plusieurs et c'est pour ça que ce qu'on fait est d'autant plus cool au final. Dans GIMP, non c'est pas moi qui code tout. On a quelques autres dévs très prolifiques (et très très bons), et j'adore aussi faire de la revue de code pour des contributions uniques de qualité. C'est aussi gratifiant d'intégrer un patch de quelqu'un d'autre que de coder moi-même quelque chose (même si mon nom n'apparaît que dans le second cas, le travail est parfois aussi important en revue de code).
Pour ZeMarmot, c'est pareil. C'est du travail d'équipe. Aryeom peut dessiner car elle a un logiciel à la hauteur car des gens comme moi le corrigent et implémentent des fonctionnalités utiles. Réciproquement je fais de bonnes corrections car Aryeom me dit que non, ça, ça va pas, etc. Il m'est arrivé plusieurs fois de jeter des heures de code d'un truc que je croyais trop cool car, quand je le montre à Aryeom, elle me démontre qu'en fait ça lui compliquera la vie (et donc à d'autres aussi); ou de changer complètement certaines implémentations après qu'elle me fait la bonne remarque que ça pourrait être beaucoup mieux comme ci ou ça (et c'était vrai!).
C'est un travail d'équipe, c'est la réalité et il ne faut pas la nier. Je veux donc faire un financement d'équipe, et pas en mon nom propre. C'est comme les groupes de musique au nom d'un unique musicien/chanteur star, j'ai toujours trouvé ça triste et pas cool (même si le musicien est peut-être exceptionnel, là n'est pas la question). Y a une équipe, faut un nom de groupe. Ben là, pareil. ZeMarmot, c'est pas juste moi. On est un groupe, et j'aime ça.
Mon rêve, ce serait qu'on passe le stade de 2 personnes. Un jour, si on a suffisamment de financement, on pourrait avoir un studio avec beaucoup d'artistes et aussi beaucoup de développeurs, et on corrigerait plein de bugs et implémenterait des fonctionnalités cools dans plein de logiciels (pas juste GIMP; on utilise Linux, et que des logiciels libres; tout ce qu'on utilise et qui ne marche pas suffisamment bien pourrait devenir une cible de contribution si on avait suffisamment de développeurs).
C'est mon petit rêve perso. Mais ça ne peut se faire que si on passe le stade d'arriver déjà à financer au moins 2 salaires (on en est encore loin!). Et donc ça ferait une équipe encore plus grande. Faire un financement pour moi seul serait donc contre-productif et dans la mauvaise direction. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Financement du développement seul
Posté par Renault (site web personnel) . Évalué à 10.
Au moins tu es clair et tu sais ce que tu veux c'est bien, chouette projet.
Mais j'ai une question à propos du financement. Tu veux que les gens financent le film pour aider à contribuer au logiciel. Je comprends la logique et c'est une bonne idée.
Mais je ne crois pas que tu aies répondu à la question suivante : en fait ta démarche c'est celle de la Blender Fondation. Ils ont pas mal de films à leur actif et Blender a évolué avec ces films. As-tu tenté (et veux-tu tenter) de collaborer avec eux dans cette démarche ? Ne pourraient-ils pas vous aider d'une façon ou d'une autre à défaut de faire un film ensemble ?
Cela pourrait être un moyen de mutualiser la logistique, le marketing et d'améliorer peut être votre financement.
[^] # Re: Financement du développement seul
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 16 décembre 2017 à 17:51.
J'ai eu à plusieurs reprises des échanges avec Ton Roosendaal, mais pas sur le sujet de la collaboration, me semble-t-il. Il est au courant de notre projet (notamment il a tweeté une fois au moins dessus). En gros, non, on n'en a jamais vraiment parlé.
Ceci dit, eux sont intéressés par Blender (c'est normal, leur fondation a été créée dans le but d'améliorer Blender, pas d'autres Logiciels Libres, ni pour l'Art Libre, à l'inverse de LILA) et je ne suis pas sûr qu'ils voient un grand intérêt (au sens de l'intérêt de la fondation) à notre film. Personnellement, probablement (le tweet de Ton disait justement que notre projet avait le bon esprit), mais pas pour la fondation. Ensuite c'est pas forcément vrai. Les films d'animation 2D modernes ont souvent un peu de soutien 3D dernièrement (par ex pour les scènes avec beaucoup de rotation, genre caméra qui tourne autour d'un perso qui court, une des grandes faiblesses de la 2D dessinée à cause de la difficulté des changements de perspective; ou pour les backgrounds de scènes, notamment de type bâtiments; etc.) et si on avait des fonds, on prévoyait de faire de même (on a des contacts Blender, cf. notre page de film par exemple qui donne un nom d'une telle personne dans "l'équipe", même si dans les faits, ça n'a jamais pu se faire à ce jour car on n'a pas de quoi payer). Peut-être qu'on pourrait tenter une collaboration, mais je pense que ce ne sera intéressant de leur proposer qu'après la sortie du pilote.
Quant aux aides de type marketing, oui ils peuvent nous aider s'ils parlent de nous, bien sûr. Mais si on est pas un projet de la fondation, ils voudront probablement pas! Et en fait, je viens soudainement de me rappeler que si, je leur avais déjà demandé (je laisse quand même mon erreur précédente pour une trace du cheminement de pensée!). Il me semble que c'était pour un autre petit projet avec du Blender. Je leur avais demandé s'ils pouvaient nous faire un peu de pub. Laisser un petit post sur le site par exemple, pour aider le financement d'un "projet ami". Et on m'avait aimablement refusé car ils ne font que de la promotion des projets de la fondation même.
Note que je ne leur en veux pas, c'est compréhensible. Y a beaucoup de projets tiers, et si on se met à parler de tous les projets, déjà ça n'en finit plus, ensuite ceux dont on ne parle pas se sentiront laissés pour compte. Je pense qu'en fait, la vraie réponse, c'est qu'ils ne feraient que de la pub de projets qui sortent vraiment du lot en utilisant Blender (ce qui leur permet donc en même temps de faire de la pub pour Blender même), donc de projets déjà avec un bon succès. C'est un peu comme ça que le monde marche: on n'aide pas les petits, seuls ceux qui sont déjà grands (c'est à la fois triste et à la fois compréhensible, comme je le disais. Un peu la version réaliste du "aide toi, le ciel t'aidera").
Quoiqu'il en soit, je pense réessayer de rentrer en contact avec eux après la sortie du pilote. Il reste des possibilités, et notre pilote aiderait pour la partie "sortir du lot". Mais dans tous les cas, je ne souhaite pas "miser" sur ce type d'aide seulement. J'ai appris avec le temps que la seule aide réellement fiable, c'est soi-même qui la crée (même l'aide financière, c'est en général car on a d'abord réussi à prouver qu'on la vaut que les gens acceptent de nous financer). Il ne faut pas trop dépendre des autres et espérer des "miracles". Cela marche rarement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Financement du développement seul
Posté par Renault (site web personnel) . Évalué à 6.
Je comprends ton point de vue, je n'ai jamais dit qu'ils seraient d'accord ou que cela se ferait automatiquement.
Je vais quand même expliciter mon avis, cela pourra peut être t'aider sur la manière d'aborder la question. Notamment quand tu voudras en rediscuter avec eux.
Déjà tu parles d'émerger de la masse des petits projets. Je comprends que Blender Foundation ne souhaite investir au mieux quand dans des projets avec un gage de sérieux et de crédibilité. Peut être que ZeMarmot n'est pas un projet assez mature artistiquement parlant pour eux. Je peux le comprendre. Mais quand même, tu es parmi les plus gros contributeurs à GIMP de ces dernières années, ce n'est pas rien. Je pense que cet aspect peut aider à crédibiliser ton projet. Je doute qu'ils ne soient pas sensibles à cet aspect.
De plus, oui la Blender Foundation va aider essentiellement des projets concernant Blender directement. Mais c'est une vision un peu court termiste et non globale de l'écosystème.
Par exemple, Red Hat, Canonical ou SUSE investissent des ressources financières et humaines sur des projets comme GNOME alors que ce qu'ils vendent c'est surtout du support pour des serveurs. Mais améliorer GNOME fait de la publicité, permet aussi d'avoir un environnement plus complet et cohérent car le poste de travail de l'administrateur système ou de la secrétaire auront aussi le même système d'exploitation.
Là où je veux en venir c'est que Blender est un outil non autosuffisant pour les graphistes. GIMP, Inkscape et d'autres outils sont indispensables pour une entreprise orientée dans le secteur. Améliorer GIMP peut aider à améliorer l’implantation de Blender. D'autant que je crois que les deux logiciels peuvent être scripté par Python, cela pourrait permettre à un développeur d'aider des graphistes des deux métiers par exemple pour ajouter ce dont ils ont besoin. Je ne connais pas les possibilités des concurrents proprio, mais je doute qu'une telle possibilité existe.
Bref, Blender pourrait tirer un bénéfice si GIMP et d'autres logiciels pour graphistes parvenaient à s'améliorer.
[^] # Re: Financement du développement seul
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Je suis d'accord avec tout ce que tu dis. Ce n'est pas moi qu'il faut convaincre. ;-)
Ceci dit, j'ai fait une recherche dans mes emails et ai aussi retrouvé une discussion avec Ton en 2015, que j'avais oubliée. Elle confirme les positions de la fondation Blender qui veut se limiter aux projets Blender, bien que Ton laissait ouvert un futur possible où aider un projet GIMP (de manière exceptionnelle) n'était pas totalement hors de question. Peut-être un jour, donc. Il disait qu'en tous cas ce n'était pas possible à l'époque avec l'état des finances. Peut-être maintenant, qui sait.
Donc comme je dis, je réessaierai sûrement dans quelques mois.
Mais dans tous les cas, comme je disais, j'ai appris à ne pas mettre trop d'espoir dans une direction particulière. Tout ce que tu me dis, je le sais, et suis d'accord, et ai tenté maintes fois. Si ça marche, tant mieux, mais faut bien savoir que les chances sont faibles car les projets ont tous leurs priorités. Tu parles de "Red Hat, Canonical ou SUSE" qui investissent dans des projets tiers sans rapport directs avec eux, mais pour un tel petit projet qui rentre dans le système (et qui d'ailleurs est souvent un projet maintenu par un employé dans son temps libre, donc ce n'est pas forcément totalement sans rapport), et qui fera pas mal parler de lui (donc effectivement fait de la pub pour le projet sponsor), combien sont refusés?
Que ce soit Blender, RedHat ou Canonical, et plein d'autres gros acteurs du Libre, j'avais tenté de les contacter, sans succès. En fait, je crois que j'ai contacté (souvent à plusieurs reprises) tous les gros et moyens projets (entreprises ou fondations) de l'écosystème Libre. J'ai même mis en page de bons dossiers complets en PDF, avec images, et liens vidéos, pour expliquer notre projet, ce qu'il en ressort pour le libre, l'intérêt pour le sponsor (en personnalisant pour chaque sponsor souvent), etc. Ça n'a à ce jour rien donné, par contre cela m'a pris un temps fou. Je ne dis pas que ça ne donnera jamais rien. Peut-être qu'un jour, à force de la contacter, une entreprise/fondation qui a refusé (ou pas répondu) plus tôt décidera de nous aider. Par exemple quand on sortira davantage du lot. Simplement j'ai appris à ne pas mettre trop d'espoir, à perdre trop de temps et à donner trop de valeur à ce type de contacts car au final, les quasi-seuls financements et aides d'autres types qu'on ait jamais réussi à obtenir, ce sont ceux qu'on n'a jamais demandés et les financements participatifs, et principalement de la part de particuliers (même si y a aussi quelques entreprises dans les sponsors du premier financement, et même quelques associations, surtout dernièrement).
Dans les faits, chaque entreprise/fondation a tout de même des objectifs et essaie de ne pas diverger trop. Ils font quelques gestes vers la communauté, mais cela reste limité. C'est d'ailleurs aussi compréhensible (surtout pour une fondation de la taille de Blender qui commence à être connue mais n'est pas non plus un acteur si gros encore qu'elle peut se permettre de trop diverger sans quelques risques, je pense).
Voilà. Ce sera ma dernière réponse sur ce sujet car y répondre aussi me prend trop de temps.
Je ne dis pas que tu as tort. Au contraire, je suis d'accord. Mais faut garder la tête sur ses épaules sur ce genre de sujet, surtout quand on est une très petite équipe (et que donc se disperser a un coût non négligeable). On a tout essayé maints et maints fois. On continuera, mais avec modération.
La vision que tu présentes du libre est un peu utopique à mon avis (et moi aussi je l'avais).
Cela étant dit, je t'invite à leur parler de nous (sur les réseaux sociaux par exemple). :-)
Je pense que si plein de gens parlaient régulièrement de ZeMarmot à Ton/Blender, un jour si je le recontacte, il se dira que oui, ZeMarmot a l'air d'être un projet avec de l'avenir (car il en aura entendu parler à maints reprises par des inconnus) et que la fondation Blender a tout à y gagner à nous aider. Sa position pourrait être beaucoup plus enthousiaste pour un projet dont il entend beaucoup parler.
Cela vaut pour RedHat, Canonical, et d'autres entreprises ou Fondations. Je pense que si 100 inconnus parlent de ZeMarmot à Ton, ce sera 100 fois plus impactant que si moi, en tant que représentant du projet, je lui en reparle 10 fois.
En fait, cela commence doucement. Plus de personnes parlent de nous maintenant sans qu'on soit de la discussion. C'est bien. Et c'est comme ça qu'on va peut-être rentrer dans le radar de ces autres gros acteurs.
Je conclurai par un conseil que je donne aux gens qui sont intéressés par le financement de projet: je crois que la meilleure qualité à avoir, c'est l'endurance (et toutes les variantes: l'obstination, la constance, persévérance…). Si tu fais quelque chose publiquement pendant des années et des années, au fur et à mesure, de plus en plus de gens te voient. De plus en plus de gens te suivent. Il n'y a pas de recette miracle. Il n'y a pas d'aide miracle non plus (que ce soit la fondation Blender ou autre). La plupart des gros projets sont nés ainsi d'ailleurs.
L'une des rares choses qui peut accélérer cela est si on a déjà beaucoup d'argent (c'est pas notre cas). Une autre chose est la chance. Mais je suis de ceux qui pensent que la chance, on se la crée soi-même (justement en étant persévérant). Donc ça boucle.
Si un jour la Fondation Blender nous aide, je saurai juste que c'est parce qu'on a su persévérer suffisamment longtemps, plus que par une rhétorique quelconque (aussi vraie soit-elle).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Financement du développement seul
Posté par Renault (site web personnel) . Évalué à 5.
Tant mieux tes propos avant n'étaient pas clairs dessus. :)
J'en ai conscience et je te remercie d'avoir éclairci cela. Je pense que ce serait bien pour toi et le projet que quelqu'un t'assiste sur la communication, pour le faire pour Fedora notamment, c'est très chronophage mais essentiel. Et quand je vois tes messages sur Zemarmot, GIMP, tes confs et tout, tu abats un gros boulot (et de qualité) même en dehors du graphisme et du code.
Je ne suis pas naïf ne t'en fais pas je suis d'accord avec toi. C'est juste que je voyais un lien évident entre la Fondation Blender et GIMP par rapport à ce projet (avec leur activité passée) et que de souvenir tu n'avais jamais évoqué le sujet. Après bien entendu, il n'y avait et il n'y aura aucune garantie que cela se concrétise un jour. Et qui ne tente rien, n'a rien.
Je ne suis pas un adepte de ces services mais sur mon blog cela pourrait arriver oui. Je suis d'accord que cela peut avoir un terme un impact positif. C'est un beau projet en tout cas. ;)
Bon courage pour la suite.
[^] # Re: Financement du développement seul
Posté par claudex . Évalué à 6.
Il faut aussi noter que si tu fais un truc depuis longtemps, tu inspire beaucoup plus confiance. Parce que tu donne des preuves que tu es fiable (ça ne veut pas dire que tu ne vas pas arrêter demain). Contrairement à beaucoup de projets qui durent trois mois et puis s'arrêtent faute de motivation.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Financement du développement seul
Posté par claudex . Évalué à 4.
D'après Misc, chez Red Hat, c'est autosuffisant https://linuxfr.org/users/fsx999/journaux/retour-d-experience-d-une-petite-administration-sous-linux-depuis-8-ans-qui-fait-marche-arriere#comment-1722079
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.