Jehan a écrit 1632 commentaires

Ce que ton lien indique, c'est qu'on peut diviser une image en blocs et avoir plusieurs tables de couleur (une par bloc), ce qui permet de ne pas être limité à 256 couleurs. Mais ça reste quand même super limité, ou alors faut faire de très petits blocs (possiblement 16×16 pixels si chaque pixel a une couleur différent, ce qui serait courant dans une photo; et c'est probablement ce que cette image que tu donnes fait même si j'ai pas vérifié l'image).

Ensuite le problème n'est pas qu'il y a une ou plusieurs palette de couleur. On pourrait imaginer par exemple qu'il pourrait être autorisé d'enregistrer certaines couleurs en RGB et d'autres en gris dans la palette. En fait, le vrai problème est que GIF ne semble même pas prendre en charge les couleurs en niveau de gris du tout. Ça fait un bout de temps que j'avais pas relu la spéc, alors je viens de jeter un rapide coup d'œil (GIF 89a est la dernière version): https://www.w3.org/Graphics/GIF/spec-gif89a.txt
Regarde les sections 19 et 21 en particulier. Les tables de couleur n'attendent que du RGB.

Donc la réponse est: non, ce n'est pas possible en GIF.

De toutes façons, GIF n'est absolument pas adapté pour les photos avec les attentes de qualité modernes et la taille du fichier exploserait avec le genre d'astuce que tu pointes. Donc on serait loin d'une solution au problème évoqué même si GIF permettait d'indexer des couleurs en nuances de gris.

Ensuite, soyons francs, GIF est un format tellement basique que tu trouveras très peu de cas d'usage moderne où la réponse à une question sera: "oui, GIF le permet contrairement aux autres formats" 😛

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

tisaac:

(un super logicielle avec une équipe de développement où la compétence semble concurrence la sympathie)

😜

Et avec GIMP, je n'ai pas l'impression que l'on puisse générer la grille et la sauvegarder indépendamment du reste de l'image.
[…]
Malheureusement, je ne suis absolument pas programmeur. Donc, je ne pourrai pas vérifier si cela vaut le coup.

Ah ça, j'ai pas dit que c'était du click'n play à la portée de tous. Il faut clairement mettre les mains dans le code. J'étais juste dans l'exercice de pensée: il est faisable de modifier le code pour générer une grille séparée en vectorielle et d'exporter l'image en nuances de gris avec une grille vectorielle en couleur par dessus. Et ça pourrait être une façon d'avoir une image plus petite, puisque c'est le but évoqué (à tester pour voir à quel point ça vaudrait le coup ou non, bien sûr).

Ysabeau:

Tu as une notion de calques dans GIMP qui permet ce genre de choses. C'est fait pour.

Oui. Ensuite pour implémenter au mieux l'idée que j'évoque, il faudrait qu'on ait des calques vecteurs. Cela devrait être possible dans une version peu après la sortie de GIMP 3, puisqu'on a déjà un patch en instance de revue pour cela. Mais j'attends l'après-GIMP 3 pour faire cette revue de code (voir les calques de type non-destructive dans notre feuille de route).

Une fois qu'on aura ça, il devrait être possible d'implémenter l'export avec des parties en raster et d'autres en vectoriel (dans les formats qui permettent cela).

En attendant, ça reste possible, mais faut faire un peu plus de bidouillage.

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

A condition que tu ais la source en vectoriel.

Mais de quoi tu parles? Tu as lu le post d'origine? 😜

Le cas d'usage évoqué est celui de quelqu'un qui crée cette grille de couleur à partir d'une image en couleur. La source en vectoriel, il n'y a pas besoin de "l'avoir", c'est toi qui la crées à la base.

Il n'a jamais été question de travailler sur des images avec grilles de couleur pré-existantes. Tu te fais des nœuds au cerveau pour rien. 😝

Ensuite, c'est un peu de travail (mais pas énorme non plus; l'algorithme est tellement simple que n'importe quel développeur pourrait le réimplémenter super rapidement pour générer du vectoriel) et je ne suis pas sûr que ça vaille le coup, comme je disais dans mon commentaire. Ensuite à chacun de voir.

En tous cas, c'était pour répondre à l'exercice de pensée proposé:

Et puis, je me demande s'il y a quand même moyen d'utiliser la grille d'assimilation des couleurs pour réduire le poids de mes images.

Et sinon pour ton commentaire:

Mais admettons que tu ais la source en vectoriel, du coup du peux utiliser SVG : stockage de l'image en gris dans une balise "image" et ajout des info vectorielles par dessus, SVG sait faire.

C'est vrai. C'était ma solution 1 avec un format qui embarque les 2 données dans des calques/objets séparés. CQFD.

Je pensais à PDF au début mais ce n'était pas adapté pour de l'affichage d'image au milieu de contenu web. J'avais pas pensé au plus simple, SVG, qui serait pour le coup un très bon choix, effectivement.

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

Ici (image du journal), la grosse différence entre couleur et gris est que les couleurs sont du artificiel par facile à coder.
Tes "bidouilles" imaginées ne touchant pas à cette problématique, tu ne gagneras rien.

Ben si c'est justement exactement ce que propose mon commentaire, relis. Je propose de coder ces couleurs en vectoriel car on voit bien que ce ne sont que des lignes droites colorées qui sont au contraire extrêmement simples à coder en vecteur, et cela fera un fichier de faible taille.

Et là il n'y a plus aucun des problèmes que tu mentionnes dans d'autres commentaires, à savoir de trouver un algo qui trouve une "cohérence" pour compresser ces couleurs.

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

C'est ce que j'allais dire. La plupart des formats (tous?) ne permettent pas d'avoir certains pixels en niveaux de gris, et certains pixels en couleur. Donc avoir une telle image principalement en niveaux de gris avec juste quelques pixels (la grille) en couleur en revient juste à avoir une image entièrement en couleur. Simplement beaucoup de ces couleurs seront "grises", ce qui dans la pratique va le plus souvent signifier que 2 composants sur 3 seront "inutiles". Par exemple si les pixels sont en RGB, chaque composant (rouge, vert et bleu) seront simplement identiques (donc 2/3 de l'info est redondante). En Y'UV, seule la luma sera utile (et beaucoup d'autres modèles de couleurs séparant la luminance, ce sera similaire avec le seul composant luminance utile).

Alors comme dit plus haut, ça doit pouvoir se compresser très bien, mais bon… c'est sûr qu'avec presque 2/3 de données inutiles, idéalement plutôt que compresser cette partie, on aimerait pouvoir s'en débarrasser tout simplement.

Je vois 2 solutions:

1. Soit un format d'image avec un concept de calques ou d'objets, et dont chaque calque/objet peut avoir un modèle de couleur différent. On aurait donc l'image principale dans un calque/objet en niveaux de gris et la grille par dessus dans un calque/objet en couleur. Ce serait idéal. Malheureusement il n'y a pas tant de formats qui permettent cela, et surtout utilisables pour simplement afficher des images dans un navigateur.
2. Soit séparer l'image en 2 fichiers d'image: une image en niveaux de gris et une image en couleur (avec la grille seulement) puis les réassembler sur la page web (avec HTML5 canvas et quelques lignes de javascript à peine par exemple; en faisant un fallback sur l'image en niveau de gris seulement en l'absence de JS).

Notons pour cette seconde solution que séparer la grille en format vectoriel, par ex. SVG, (plutôt qu'un quelconque format raster) même serait encore mieux (des lignes droites avec des aplats de couleur, c'est du vectoriel idéal donc taille probablement encore plus faible), laquelle pourrait tout aussi bien être composité sur l'image en niveaux de gris (comme dit plus haut, soit dans un format d'image unique qui est capable de contenir plusieurs types d'images différentes, soit à l'affichage en HTML/JS).

Ensuite clairement la solution 2 images + HTML/JS rajoute de la complexité au système (même si cela pourrait être scripté pour n'avoir qu'à donner une image en couleur, puis des scripts généreraient la version en niveaux de gris, la grille de couleur en vectoriel et le code HTML/CSS automatiquement). Disons que je joue le jeu d'essayer de trouver la solution qui permettrait la plus faible taille de fichiers, mais ce n'est pas forcément la solution la plus simple malheureusement. Et puis faudrait tester pour vérifier l'intuition. Sait-on jamais si vraiment la compression ne fait pas des merveilles, comparée à 2 images avec tout l'overhead que cela implique.
Donc j'imagine très bien que ce ne sera pas la solution choisie. 😉

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

ça reste au bon vouloir des optimisation, et si on sait que l'on peu exploser ça stack avec un récursion, je l'utiliserais pas.

C'est vrai. C'est une bonne remarque. J'espère donc que cet attribut va se répandre, et notamment arriver chez GCC. Je vois que ça a été discuté et notamment il est expliqué qu'ils ont déjà toute l'infra mais n'ont pas d'attribut exposé (dans la discussion, certains se demandaient comment gérer cela pour les architectures où c'est plus compliqué à assurer, bien que j'ai l'impression qu'au final, il n'y ait pas vraiment de cas absolument impossible à gérer). Quelqu'un dans la discussion l'a même implémenté en plug-in GCC mais j'ai pas l'impression que c'est arrivé dans l'implémentation standard (en tous cas, mes recherches ne donnent rien).

Ensuite pour modérer un peu, on ne fait pas forcément des récursions pour des choses qui sont suffisamment énormes pour exploser la stack (même si on peut ne pas connaître la fin d'une récursion avant de la commencer). Souvent, on peut faire des récursions pour des choses qui sont habituellement de taille raisonnable (bien que si cela dépend de données utilisateurs par exemple, cela peut aussi être un vecteur d'attaque; enfin bon, c'est du cas par cas).
Mais oui, c'est sûr que dans certains cas, je comprends que cela puisse être une limitation si on a besoin de compiler sans optimisation et si on n'a pas accès à l'attribut explicite musttail.

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

Mon propos, c’est que dans mon souvenir les précédentes releases étaient de bonne qualité, en tous cas assez pour ne pas nécessiter de nouvelle version avant la prochaine release. Ce qui pour moi est un signe fort de qualité et de stabilité du logiciel

Bof ce genre de choses arrivent, c'est tout. On a déjà dû faire ça quelques fois chez GIMP (une sortie immédiate après une autre pour cause de bug impactant découvert juste après; dernière en date en 2021 si je ne m'abuse). Au contraire, ça veut dire que l'équipe est au taquet, suit bien les retours de sortie (plutôt qu'une méthode "je sors du code et je me barre") et est réactive.
Ça arrive à tout le monde de découvrir de gros problèmes qu'on a loupé.

je rappelle ce que j’ai déjà dit : je n’ai pas encore eu le temps de tester le logiciel !

Peut-être est-ce alors la meilleure raison pour ne pas faire de commentaire sur la stabilité du logiciel alors, non? Qu'en penses-tu? 😉

Mon intention n’était ni de déprécier le travail des contributeurs de darktable ni de vexer quiconque, et je m’excuse si mon message a été perçu comme tel.

Pas de prob. C'est juste que je vois de plus en plus de remarques sur darktable, surtout ces dernières années depuis que ce contributeur a cherché à envenimer les choses à son profit (comme quoi, cela montre bien qu'il suffit d'une personne pour tout gâcher). Et ça me rappelle un peu trop ce qu'on vit chez GIMP aussi. Mais bon, on va dire que pour GIMP, maintenant je suis vacciné. J'ai l'habitude et ai déjà lu un peu tout et n'importe quoi comme théorie à notre sujet (qui deviennent rapidement des "vérités" aux yeux des gens à force de passer d'un forum à l'autre).

C'est triste de voir que dès que certains projets commencent à avoir un peu de notoriété, on se met à faire et propager des rumeurs dessus.

Enfin bon, je ne suis personnellement ni vexé ni rien. Je ne suis même pas un contributeur darktable et ne crois pas avoir souvent regardé leur code (je me retiendrais donc de faire la moindre remarque dessus, justement!). C'était juste une note de manière générale car je connais bien ce genre de commentaires qu'on vit aussi beaucoup chez GIMP et puis j'ai remarqué une forme d'acharnement à ses débuts sur darktable ces derniers temps.

J'en appellerais seulement à un peu moins de rumeurs et un plus de bienveillance. Ce genre de journaux serait alors plus agréable à lire. C'est tout. 🙏

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

Mais oui, si on parle de C/java/Rust/python ou autre je suis d’accord.

Je peux pas dire pour ta liste complète, mais en C (et C++) au moins, les compilateurs sont capables de reconnaître et optimiser des fonctions récursives terminales depuis très longtemps (tu trouves des références à cela sur des liens vieux de plus de 10 ans). 🙂

Cela inclut au moins les principaux compilateurs (GCC, clang, etc.).

En plus, je découvre même un nouvel attribut musttail dans Clang (et discuté pour GCC) super intéressant car il permet de forcer les optimisations en récursion terminale même si on désactive les autres optimisations de manière globale à la compilation.

Je transmets la nouvelle de cet attribut pour info et parce que je le découvre moi-même, mais l'optimisation de récursion terminale existait déjà en C, et ce depuis longtemps. Je le répète (allez pas dire que c'est apparu en 2021! La seule différence, c'est que maintenant on peut informer le compilateur pour s'assurer que le code est optimisé, alors qu'avant on devait se fier à la capacité du navigateur à détecter les récursions terminales, ce qui marchait bien déjà). Perso j'en utilise régulièrement.

Enfin bon, la récursion terminale, c'est bon. Mangez en! C'est une bonne pratique de développement.

De toute façon, toute personne qui écrit une méthode récursive a intérêt à l’accompagner d’un commentaire qui justifie pourquoi c’est une bonne idée de faire ça, tellement ça pose de problèmes (taille de pile à l’exécution, lisibilité, maintenance…).

Pour la "taille de pile", comme dit juste au dessus, ce n'est pas un problème pour quiconque utilise un langage ou compilateur moderne (cela inclut le C). Au contraire, c'est justement en écrivant du code récursif terminal qu'on règle ce genre de problèmes quand ils adviennent.

Pour la lisibilité et maintenance… je sais pas ce que tu développes, mais je ne suis absolument pas d'accord avec ce commentaire. Au contraire, du code récursif est souvent très compréhensible et justement a un pouvoir d'auto-documentation du code grâce au nom de fonction qui rend l'algorithme souvent encore plus lisible et évident.

Comme dit plus haut, j'utilise régulièrement des fonctions récursives, et j'essaie d'ailleurs en général de les rendre terminales.

Il y a des cas qui se prêtent plus à de simples boucles itératives, mais aussi beaucoup de cas où les fonctions récursives aident énormément (à la simplicité du code, sa logique, en rendant le code vraiment clair et lisible, et enfin bien sûr par sa capacité à être très efficace grâce aux optimisations dont les compilateurs sont capables de nos jours).

Enfin bon, c'est assez étonnant parce que pour moi, c'est l'inverse de ce que tu dis! 😜

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

Emphase rajoutée dans ce commentaire:

Par contre, deux points m’inquiètent : la sortie de deux versions correctives, et la vidéo de présentation du blog de darktable contient beaucoup trop de variantes à base de « Ça ne fonctionne pas » et de bugs d’affichage.

C'est quand même triste ce genre de réflexion. C'est là que tu vois qu'en tant que développeur, quoi qu'on fasse, on est "perdant":

• Si on ne sort pas de correctif, le projet est mal maintenu, voire "moribond" car peu d'activité (aux yeux du grand public). 😵
• Si on en sort (rapidement en plus! Ce qui devrait montrer la réactivité de l'équipe, cf. point précédent!), le projet est mal maintenu, sûrement par des pieds Nickelés qui savent pas développer. C'est une preuve que le logiciel a plein de bugs! 🤦

Breaking News! Tout logiciel imposant a des bugs (et pas qu'un peu)!

Sincèrement si le logiciel plaît et est utile à quelqu'un, alors c'est un bon projet (pour toi au moins). Il a des bugs? Certes, comme tout projet (ouioui même les plus gros projets propriétaires financés par millions ou milliards)! Si t'as de la chance, ce sont des bugs dont tu peux faire abstraction en attendant la correction. Voire si t'es développeur, tu peux corriger toi-même si ça t'impacte trop; ou en tant que non développeur, tu peux donner au projet ou payer quelqu'un (même des indés ou petites entreprises, si un problème impacte suffisamment ton business, c'est tout à fait raisonnable d'y allouer quelques fonds). Et ces derniers points sont le gros avantage du logiciel libre!

Pas besoin d'aller y mettre des rumeurs à base de "y paraît que", surtout avec des suppositions sur la maintenance du projet. Surtout que je sais qu'une bonne partie des rumeurs, ces dernières années, sur le code de darktable soit-disant trop complexe à maintenir vient d'un développeur à la personnalité difficile (pour ne pas dire autre chose), qui est parti faire son fork en crachant du venin sur darktable. La première (et seule) fois que je l'ai rencontré, il savait pas qui j'étais et s'est mis aussi à cracher sur GIMP sans raison (sauf qu'on était dans une conf inter-projets de graphisme libre; il a dû se dire que c'est une bonne idée d'écraser les autres projets rapidement) dans les premières minutes de discussions en disant un truc du genre que c'était un tas de merde à mettre à la poubelle (enfin je sais plus les termes exactes, je me rappelle juste que c'était une remarque lapidaire et imagée qu'il avait utilisée).

Ce que j'en avais retenu personnellement, c'est juste que j'avais plus trop envie de parler avec cette personne antipathique.

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

Au contraire, je pense que c'est une très bonne comparaison. Il s'agit de réécrire de zéro un logiciel pour faire la même chose que l'ancien. Le fait qu'il le fasse différemment, avec des techniques modernes et des choix adaptés au monde actuel va de soi (de même que je suis sûr que c'était le cas dans l'exemple cité par fearan). On ne parle donc pas d'être "compatible" mais bien de refaire un logiciel de zéro pour les mêmes usages.

Wayland est effectivement un bon cas de "tout réécrire a foutu la merde pendant 10 ans au moins". Certes pour beaucoup de gens, Wayland est devenu utilisable, il y a quelques années déjà. Néanmoins, même pour ces personnes, cela a provoqué de nombreuses années charnières où il ne s'est rien passé dans le monde de la gestion des périphériques graphiques de sortie. Tout simplement parce qu'il n'y avait plus (ou presque) de dévs X pour développer quoi que ce soit (de nouveau, ou en correction) parce que "Wayland, c'est l'avenir".

Pendant des années, ça a donc été la merde pour la gestion des écrans haute densité (c'est pourtant loin d'être nouveau, même dans le ± grand public), dans la gestion du multi-écran, surtout avec des résolutions différentes et dans plein d'autres trucs.
Et même si maintenant Wayland est utilisable par le grand public, ça reste inutilisable pour le graphisme pro (qui est pourtant — je le rappelle — l'une des industries majeures dans les gros utilisateurs du numérique métier). On nous fait miroiter le futur avec le HDR, etc. mais la simple correction des couleurs (calibration, etc.) en SDR n'existe pas encore dans Wayland stable. Dans toutes ces années, le HDR aurait aussi pu arriver sur X11 s'il y avait encore du développement.

Et ainsi de suite.
Alors me faites pas dire ce que je n'ai pas dit. J'attends avec impatience que tout cela arrive dans Wayland, et je ne me fais aucune illusion que Wayland est le futur… parce qu'y a pas le choix et qu'on est déjà allé si loin, c'est pas comme si on allait faire un retour en arrière. Maintenant faut juste pousser pour que ces choses qui manquent (puis les nouvelles "fonctionnalités de la mort qui tue") soient rapidement implémentées. Je ne fais pas partie de ceux qui disent qu'il faut arrêter et retourner à X11. Cela ne m'empêche pas de regarder le passé et le présent avec un regard critique pour en tirer des leçons.

En fait, il fut un moment où il me semble bien que Linux commençait à avoir le vent en poupe et à être considéré de plus en plus sérieusement dans le monde du graphisme et surtout du son. Ces 2 moments critiques ont été perdus (j'ai l'impression) avec une succession de mauvaises directions techniques, même si ça revient pour le graphisme (mais pas grâce à Wayland — du moins pas pour l'instant —, surtout avec des logiciels qui commencent à prendre plus d'importance).

En fait dans mon expérience, aucune tentative de "réécriture de zéro" n'a eu un bilan totalement positif. J'ai aussi travaillé pour une startup qui a un jour décidé — il y a plus de 10 ans — de refaire tout son site en Python (parce que c'était la mode, et plus PHP qu'on utilisait jusque là! 🤦), micro-services (tout doit être en micro-services! 🖧) avec des APIs, etc. etc. On a passé 6 mois à temps plein dessus avant qu'un manager décide de tout mettre à la corbeille (on avait bien avancé, mais on était tout simplement pas au niveau de l'ancien site qui avait été construit depuis des années) et qu'on doit continuer à améliorer le vieux site à la place. J'étais l'un des seuls (voire le seul?) d'ailleurs à être contre ce projet de réécriture au début, mais ça m'a pas fait plaisir pour autant d'avoir raison. Parce que gâcher 6 mois de travail, c'est pas glop.

Pour parler de mon expérience plus au présent, tout ceux qui ont gueulé contre GIMP et ont dit qu'on peut réécrire un logiciel de graphisme en quelques années, qui serait au même niveau, se sont gaufrés. Attention, je dis pas non plus qu'il ne faut pas faire de tels logiciels. C'est d'ailleurs bien d'avoir plus de logiciels, plus de choix avec des directions et décisions différentes. Mais il faut simplement être conscient que pour en arriver au niveau de GIMP, il leur faudra 15 ans au moins si ce sont de bons développeurs (GIMP a presque 28 ans, mais disons qu'ils éviteront peut-être certains écueils, ne feront pas nos erreurs, etc. Je leur laisse le bénéfice du doute…). Et à ce moment là, 15 ans plus tard, ils auront accumulé leur propre dette technique inévitable. Et GIMP aussi aura évolué dans ce laps de temps. S'ils sont conscients de cela et font cela en connaissance de cause, tout ira bien. En un an ou deux, ils auront peut-être de super fonctionnalités et sûrement même des trucs qu'ils feront mieux que GIMP (ce qui est bien suffisant pour avoir des gens intéressés!). Mais ils ne seront pas aussi complet, car cela prend du temps et ne peut être qu'incrémental. Tant que les gens ne comprendront pas cela, ils continueront à se vautrer en repartant à chaque fois de zéro, dès qu'y a un petit nouveau qu'il croit qu'il fera mieux que tout le monde.

Et encore une fois, ce n'est pas impossible de refaire tout de zéro, il faut juste savoir qu'il y a un prix à payer (et ce prix peut être tout simplement 15 ans de stagnation, coincé entre le vieux logiciel qui n'avance plus techniquement et le nouveau qui fait certains trucs aussi bien, parfois mieux si on a de la chance, mais ne fait pas plein de trucs importants que faisait l'ancien).

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

Depuis plusieurs mois (années ?), je lis vos comptes rendu des nouvelles fonctionnalités, et elles me semblent très intéressantes (bien que je ne fasse plus de photo). Pourquoi attendre pour sortir une version 3.0 finale ?

Déjà parce qu'on était dans le modèle ancien de "release when it's ready", qui explique que la sortie de GIMP 2.8 a aussi mis 4 ans (2008 à 2012), 2.10 a mis 6 ans (2012 à 2018) et 3.0 aura vraisemblablement mis entre 5 et 6 ans (on a démarré en 2018).

Comme les gens le savent, on est en train de changer ce modèle (bon on sort encore les choses "quand elles sont prêtes" mais tout la subtilité est d'arriver à définir différemment "ce qui doit être prêt"), d'ailleurs sur une impulsion de notre part, puisque c'est un changement que j'ai proposé lors du Libre Graphics Meeting de 2014. C'est ainsi que depuis GIMP 2.10.0, on applique cette nouvelle politique de sortie: on sort désormais de nouvelles fonctionnalités même lors des sorties micro maintenant! Tout ce qui est suffisamment aisément backportables sort dans les versions 2.10.x. Je suggère donc de jeter un œil sur le tag "GIMP" sur Linuxfr et de lire les articles de sortie des versions stables pour se rendre compte qu'il y a des nouveautés à chaque fois (et pas juste des corrections de bug).

Pour moi le risque d'attendre trop longtemps est de démotiver les développeurs de n'avoir rien de montrable "officiellement", et de démotiver les utilisateurs attendant trop longtemps les nouvelles fonctionnalités

Donc si ce que tu dis était vrai avant 2018, ce n'est plus le cas depuis (puisque maintenant les développeurs attendent juste quelques mois pour voir leur code utilisé et les utilisateurs pour l'utiliser).

Ensuite comme tout, on peut faire mieux. Mais cela demande rigueur et organisation. Et surtout, cela prend du temps, des années même. On ne change pas une organisation de 28 ans en quelques mois (c'est le meilleur moyen de tout pêter, certains l'apprennent à leurs dépends, par exemple des milliardaires qui s'amusent à acheter des boîtes et les font quasi couler en quelques mois en pensant être des révolutionnaires! 🙄).

Et donc maintenant après la première étape de 2018 avec GIMP 2.10, on passera à une seconde étape avec GIMP 3.0. Je l'explique d'ailleurs dans mon rapport 2022 de janvier 2023 (qui n'a pas été traduit sur Linuxfr):

While this second target is still definitely a big plan in our roadmap, I don’t think that making it again a huge development cycle with dozens of features and taking several years is the wisest thing. This old development model made sense back in the day, but less nowadays in my opinion.

En gros, on arrête de faire de grosses cibles gigantesques. J'ai aussi entièrement réorganisé notre roadmap post-3.0 non plus par versions mais en sous-roadmaps par catégorie de fonctionnalités dont les éléments peuvent être implémentées dans n'importe quelle version. C'est important puisque ça signifie que nous ne sommes plus contraints à de grosses listes de fonctionnalités. Nous avons maintenant un ensemble de directions globales vers lesquelles nous nous dirigeons (notre "vision" pour le futur de GIMP, en gros), c'est tout.

Donc c'est bien ce qu'on fait, on a même déjà commencé depuis plusieurs années; ça prend juste du temps pour faire encore mieux.

Il y a un autre point important: une sortie de version est un évènement très lourd. On rappelle que GIMP est téléchargé des dizaines de milliers de fois par jour. On ne fait pas une nouvelle version comme on va au marché. C'est lourd en responsabilité, mais aussi techniquement, avec du code et des builds à tester à répétition, un flatpak pour x86_64 et ARM64, deux paquets macOS (aussi pour ces deux architectures) et un installeur Windows (qui marche pour x86 32 et 64-bit et possiblement aussi un installeur ARM bientôt), puis une dépêche qui me prend des jours à écrire, etc. Une sortie bien faite en gros, ça peut être des semaines de travail juste pour tous les aspects hors-code (donc tout ce temps en moins pour coder! Plus on fait de sorties, moins vite on peut améliorer GIMP; il faut donc trouver le juste milieu). Imagine une sortie d'une version majeure maintenant, surtout qu'on n'en a pas faite depuis 20 ans.
Ça fait des années que je travaille sur tout l'aspect technique (hors code de GIMP même, j'entends) pour préparer cette sortie. En cumulé, j'ai probablement passé des semaines ou des mois à créer et améliorer nos scripts d'intégration continu, qui permettent aussi d'automatiser le plus possible nos créations de binaires de sortie (le flatpak n'existait pas à l'époque mais les tarballs de source autant que les installeurs Windows ou DMG macOS, avant moi, c'était des binaires opaques que des contributeurs faisaient sur leur machine perso puis envoyaient sur les serveurs; rendre le tout plus transparent fut un de mes gros chantiers et ce fut loin d'être facile avec certains contributeurs — notamment je me souviens d'un qui n'est plus là et qui n'a pas apprécié les premières tentatives d'automatiser la création des paquets macOS). Sans compter tout le travail fait pour améliorer notre checklist de procédure de sortie. Cela existait déjà avant, comme un fichier texte dans le dépôt suivi par juste le mainteneur. J'essaie maintenant d'intégrer davantage les testeurs, les empaqueteurs, etc. En gros d'avoir une sortie avec le moins de heurts possibles, tout en étant aussi plus robuste.

Maintenant spécifiquement pour GIMP 3.0, je pense pouvoir expliquer la durée par quelques points:

• Le portage vers GTK+3 est un truc chiant et ennuyeux, donc la plupart des volontaires n'aiment pas y passer trop longtemps. Le portage vers GTK4 a l'air tout aussi chiant. Ils ont même déprécié ou retiré des fonctionnalités ajoutées/changées dans GTK+3! Honnêtement après avoir passé des mois à travailler sur notre port des actions et m'être rendu compte qu'une partie des nouvelles API sont déjà en voie de disparition dans GTK4, ça me déprime plus qu'autre chose. J'aimerais bien que les toolkits aussi fassent les choses plus progressivement. Le problème est que si les dévs de toolkit eux-même ne font que des petits "apps", ils se rendent pas compte du boulot pour un port pour une application un peu complexe.
• En dehors de ce fait, si on s'était limité à un port vers GTK+3, on pourrait se dire qu'on aurait pu y passer moins de temps, mais puisque c'est un boulot chiant, ce n'est même pas vrai. Il y aurait simplement eu des "trous" dans le développement. Autant l'employer pour implémenter des trucs cools.
• On aurait aussi pu sortir GIMP plus tôt avec un port incomplet (on a une version GTK+3 utilisable depuis quelques années, simplement on avait des centaines voire milliers de warnings) mais d'une, sortir un logiciel avec ces warnings n'est pas une pratique recommandée. Les warnings de compilation sont censés montrer des problèmes potentiels, c'est à dire des bugs probables. Or là on était noyés de warnings de dépréciation de code nous empêchant de voir les vrais bugs. Est-ce une bonne idée de sortir une version dite "stable" dans cet état? De deux, alors que certains (ceux qui traînent sur les forums technologiques, genre ici) sont à fond sur les nouveautés, énormément de gens sont en fait à fond sur la stabilité d'interface (le xkcd de rigueur?). Même si certaines choses vont immanquablement changer, on fait donc tout un travail pour s'assurer que ça ne change pas trop. C'était vrai notamment pour les actions. Je devais être sûr que je puisse sortir quelque chose avec le minimum de "sensation de changement". En gros, notre système d'actions/raccourcis est radicalement différent mais il a l'air identique (c'en est presque le plus frustrant, mais c'est important). C'est là toute la subtilité. Et si je précipite la sortie puis me rend compte après coup que je n'aurais pas été capable de cette prouesse technique, ça aurait été très embêtant et il aurait fallu changer les plans. Le problème, c'est que pour être sûr à 100% qu'il n'y a pas de problème, le mieux est de finir.
• Il y a la stabilité de tout ce qui ne se voit pas qui est important, tels les protocoles internes et fichiers de configuration. Typiquement avec les actions, le fichier de configuration des raccourcis a changé. Or on assure une migration de ces fichiers entre versions mineures, pas entre version micro. Il aurait fallu rajouter une nouvelle infrastructure pour cela (heureusement tout de même, j'ai commencé à rajouter quelques pré-étapes pour permettre cela un jour).
• Wayland aussi nous a facilement fait perdre des mois. C'est le futur parce qu'on n'a pas le choix et techniquement, c'est sûrement plus propre (autant que les micro-kernels sont plus propres que les kernels monolithiques en théorie; pourtant on sait qui de Hurd ou Linux a pris le devant de la scène dans l'histoire de l'informatique!), mais ça n'en reste pas moins un truc encore pas fini et plein de problèmes, et pourtant mis en production, avec lequel donc on est forcé de composer.
• L'API enfin est un énorme bloqueur. Nous sommes extrêmement à cheval sur sa stabilité et on ne s'est autorisé que cette version pour casser la stabilité dans les ~20 dernières années. Donc on doit le faire bien. La stabilité des interfaces font partie de ces choses sur lesquelles les gens se plaignent lorsque c'est mal fait, mais personne ne s'en rend compte lorsque c'est bien fait (même si on n'est pas parfait). On essaie d'être de la seconde catégorie. Donc personne ne remarque le travail phénoménal assuré derrière le rideau pour assurer la stabilité d'API. Au contraire, on pourrait juste presser la sortie, bâcler l'API puis se permettre de la casser tous les 4 matins ensuite. Certains font ça. Encore y a quelques jours, avec la grosse mise-à-jour récente de Thunderbird, j'ai des plug-ins qui ont cassé. Régulièrement j'ai eu des plug-ins qui ont cassé dans Firefox (moins maintenant ceci dit). Bon encore ce sont pas les pires élèves. Mes plug-ins GNOME survivent rarement plus d'une mise-à-jour. Là par contre, c'est un mauvais élève (mais il paraît que c'est fait exprès parce que le projet ne veut pas se bloquer en assurant une stabilité d'API, et c'est ça le plus dommage).

On essaie d'éviter ça (même s'il faut "jamais dire jamais", comme on dit!). On se permet un cassage avec GIMP 3 en 20 ans (et même là je me suis plus d'une fois demandé si on aurait pas pu faire mieux), et j'espère qu'on va pas en avoir beaucoup plus. Donc si on n'a que cette chance pour casser l'API, autant le faire bien.

De manière générale, nous sommes un projet un peu à l'ancienne dans les philosophies de développement, mais aussi dans la définition de ce qu'est du bon développement. Notamment vous remarquerez que les mots "stable" ou "stabilité" sont répétés beaucoup dans ce seul commentaire. C'est en effet un concept important pour nous sur plein de choses. J'ai aussi l'impression que les mainteneurs de GIMP sont une longue lignée de perfectionnistes. Saviez-vous qu'on est censé pouvoir ouvrir un fichier XCF de 1997 avec son rendu de l'époque? Nous en sommes à la version 18 de XCF avec énormément de nouveautés dans le format, mais on peut encore ouvrir les fichiers d'il y a 26 ans! Peu de projets (même libres! Quant aux logiciels propriétaires, n'en parlons même pas tellement ils ont de casseroles sur ce sujet) peuvent s'enorgueillir de cela, et même tout simplement de placer ce niveau de rétrocompatibilité dans leurs checklists lors des changements de format.

Et donc voilà, tout cela explique pourquoi cela prend du temps. Ensuite on peut tout de même améliorer la fréquence des sorties sans pour autant perdre en qualité, mais c'est alors surtout une réorganisation en profondeur qui ne peut que prendre encore plus de temps si on ne veut pas tout casser et si on veut travailler en bonne entente en communauté. Et c'est bien ce que nous faisons depuis plusieurs années.

Merci pour tous ces chouettes articles en tout cas. Et GIMP est un logiciel génial, belle vitrine du logiciel libre !

Merci! 😄 (et merci à Matthieu pour sa traduction!)

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

Mais c'est quoi "Overture Maps Foundation"? Je connaissais pas. En regardant leur news, je vois que c'est très nouvellement créé (annoncé en décembre 22, premier post en avril). Les membres principaux sont des GAFAM (Amazon, Meta, Microsoft) + TomTom, ce qui ne m'inspire pas confiance.

Et l'article en lien dit qu'ils ont utilisé les données d'OpenStreetMap pour 2 des 4 nouveaux jeux de données fournis: les bâtiments et les transports, auxquels ils rajoutent leurs propres données. En dehors de cela, le reste sont aussi des jeux de données sur lesquelles OpenStreetMap travaille, que je sache. En gros, j'ai pas l'impression qu'ils apportent de nouveaux concepts ou des projets de cartographie sur lesquels OpenStreetMap ne voudrait pas travailler par exemple. D'ailleurs ils le confirment dans leur FAQ:

What is the relationship between Overture and OpenStreetMap?

Overture is a data-centric map project, not a community of individual map editors. Therefore, Overture is intended to be complementary to OSM. We combine OSM with other sources to produce new open map data sets. Overture data will be available for use by the OpenStreetMap community under compatible open data licenses. Overture members are encouraged to contribute to OSM directly.

Ils noient le poisson avec leur différenciation data-centric vs. communauté. Comme si OSM n'était pas "data-centric" aussi (en plus d'être communautaire)! Le but d'OSM est de cartographier la planète en créant inlassablement des données de cartographie. Tu peux difficilement être plus "data-centric".
Puis ils jouent avec les mots en se disant "complémentaire", car ce n'est pas ça être complémentaire. Être complémentaire, ce serait par exemple: disons que je veux ajouter des jeux de données dans OpenStreetMap mais ce projet ne veut pas du type de données qui m'intéresse. Dans ce cas, je pourrais faire mon propre jeu de données (juste pour les infos supplémentaires) fait pour être utilisé avec le jeu de donnée de base. Par contre, travailler sur exactement la même chose en ajoutant des données supplémentaires (que le projet upstream — OpenStreetMap — voudrait bien avoir aussi de manière évidente) au lieu de les contribuer, ce n'est pas être complémentaire. C'est faire une sorte de fork en continu des données sans jamais contribuer ses propres données (ce qui leur permet un "avantage commercial" dans le jargon business).

Bien sûr si les données supplémentaires sont libres et compatibles (apparemment c'est le cas, ils le disent dans la FAQ), les contributeurs d'OSM pourraient travailler à les rapatrier (ce qu'ils suggèrent d'ailleurs de faire dans cette même entrée de FAQ), sauf tout contributeur de projet libre sait que c'est beaucoup de boulot. Chasser les patchs ou demander aux gens de jouer le jeu en contribuant est un tout autre niveau d'implication. Pour les membres de cette nouvelle fondation, gérer un jeu additionnel de données propres ou contribuer ces données directement est probablement similaire au niveau du coût, du temps ou de l'implication (voire, j'aurais même tendance à dire que gérer leur propre infrastructure leur donne plus de boulot). Par contre pour le projet upstream (OSM), c'est une perte sèche, ou au moins une grosse perte de temps (s'ils essaient de rapatrier les données de la nouvelle fondation; et encore s'il y a des contributeurs qui s'y essaient). En gros, c'est clairement pas une façon de faire très cool de ce nouvel acteur, et sûrement pas quelque chose que je qualifierai d'acte "d'ouverture" (pour faire echo au nom).
Et la dernière phrase de cette réponse de FAQ me paraît donc d'autant plus ironique:

Overture members are encouraged to contribute to OSM directly.

Non parce que "on pourrait contribuer et d'ailleurs on encourage nos membres à contribuer (wink wink 😉 entre soi, hein!) mais on le fait pas. Non parce que sinon notre fondation n'a plus aucune raison d'être. Donc au final, on va créer notre site web, notre propre infra, notre propre workflow et passer du temps et de l'effort pour ne surtout pas contribuer upstream (ce qui aurait été bien plus simple puisque tout est déjà en place) mais sur un site à part…" ⇒ c'est pas un peu se moquer du monde?

En gros, je me demande ce que cette fondation essaie de faire. Essaient-ils de tuer OpenStreetMap (et sa fondation) en les court-circuitant avec leurs propres données de base? Y a-t-il une raison (ils ont essayé de travailler avec eux, mais ça n'a pas marché? Si oui, pourquoi?)?
Y a-t-il un rapport avec cette histoire récente où un contributeur d'OpenStreetMap n'aimait pas la façon dont Bing Map contribuait à OSM?

Sincèrement je ne sais pas trop quoi penser. C'est toujours bien lorsqu'il y a de nouveaux acteurs pour créer des données libres, même si ce sont parfois des entreprises pas très glop (mieux vaut ça que si elles faisaient des données propriétaires!). Sauf que quand ils font la même chose qu'une entité déjà bien en place, et en plus dont elles utilisent justement déjà ouvertement et massivement les données, ça fait un peu vampirisation et tentative de "s'emparer du projet upstream" de manière détournée, en floutant les limites (si on sait plus qui fait quoi, dans 10 ans, les petits jeunes pourraient ne plus connaître que l'Overture Maps Foundation avec leur — très problablement — gros moyens marketing) et en affaiblissant progressivement les contributions directes (si les gens se mettent à contribuer progressivement sur les nouvelles bases qui font parler d'elles massivement par la puissance marketing de leurs membres, jusqu'au jour où les gens vont contribuer directement à ce fork; du moins c'est ce qu'ils espèrent peut-être).

Et dans tous les cas, c'est légal dans l'usage des licences. Mais ça me donne un arrière goût de tentative de prise de pouvoir sur un autre projet par une manière détournée, voire politique.

Enfin bon, je me fais peut-être des films, mais c'est quand même super bizarre comme approche, cette fondation soudainement sortie de nulle part.

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

J'aime pas trop le terme, car dès qu'il est prononcé les gens s'imaginent qu'on parle d'intelligence articielle avancée voire de LLM.

L'étude, le traitement et la génération de langues naturelles font partie du domaine de recherche de l'intelligence artificielle. Pourquoi de nos jours, tout le monde semble croire que IA == réseaux de neurones? Y a tout un monde en dehors de ces technologies particulières.

Franchement ça doit être frustrant pour les gens qui travaillent depuis des décennies sur des domaines d'IA et le grand public vient soudainement leur dire que ce qu'ils font, c'en est pas, parce que c'est pas des réseaux de neurones (et tout ça parce que quelques marketeux ont récemment réussi à faire parler d'eux récemment, plus que d'habitude). 🤦

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

Pas de prob. Je me devais juste de faire la remarque, mais ça arrive. :-)

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

Salut,

Jehan a déjà répondu dans une dépêche précédente :

Je sais pas s'il y a quiproquo ou les infos se déforment juste avec le temps, mais l'histoire du designer, je me demande d'où elle vient, car ça me dit rien:

Un spécialiste est venu un jour, une seule fois, sans jamais reparaître. L'équipe en est devenue frileuse.

Alors non. On a eu un spécialiste à une époque, pendant plusieurs années. Je l'ai connu à mes tout-débuts chez GIMP. Par contre il était imbuvable, il se prenait pour une star et les développeurs pour ses sous-fifres (ma première réunion en "réel" avec lui, lors d'un Libre Graphics Meeting, il commence en traçant un triangle sur le tableau et en expliquant qu'en haut, y a le designer qui décide, dans un autre coin, y a les développeurs qui doivent simplement implémenter ce que le designer décide sans poser de questions, et dans le dernier coin, y a les utilisateurs qu'il faut surtout pas écouter parce qu'eux-mêmes savent pas ce qu'ils veulent; j'étais atterré 🤦), et surtout il bloquait les arrivées de nouvelles fonctionnalités car tout ce qui touchait à la GUI devait passer par lui (or je l'ai connu à une époque où il était moins actif, donc ça bloquait dur; je considère perso qu'il a fait perdre quelques années à GIMP sur certaines choses).
J'ai personnellement eu quelques altercations email avec lui à cause de son comportement et il a fini par partir en écrivant un long email pour expliquer à quel point les anciens mainteneurs étaient bons (ceux que j'ai pas connu mais que tout le monde m'a dit être plutôt abrasifs… vous connaissez tous la réputation des méchants développeurs de GIMP qui apparemment date d'avant moi puisque moi j'ai surtout connu les gentils, mais une réputation, ça a la vie dure…) et nous mauvais. En fait, il serait pas parti, je serais sûrement parti moi-même à un moment donné (j'ai une habitude de pas supporter les injustices et mauvais traitements; j'ai déjà démissionné professionnellement sans demander mon reste pour cause de mauvais managers; alors imaginez dans ce qui à l'époque était principalement un hobby). Donc ça tombe bien.

Donc c'est la seule histoire de designer problématique que j'ai par rapport à GIMP. D'ailleurs je ne suis pas sûr en avoir jamais parlé en détail sur un forum public à ce jour (par contre c'est un sujet qu'on a de temps en temps en privé ou sur IRC) mais bon, ça fera bientôt 10 ans, donc bon… maintenant c'est peut-être OK de raconter ça. Néanmoins ça ne veut absolument pas dire qu'on est frileux par rapport aux designers. Dans ma vie professionnelle, j'ai travaillé avec de bons designers et je suis plus que disposé à continuer à travailler avec d'autres. "Bons" designers, ça veut dire quelqu'un qui sait travailler avec des développeurs (et des utilisateurs), qui sait aussi écouter, recevoir des retours et remarques et les prendre en compte pour modifier une spécification. Et non quelqu'un qui se prend pour un dieu. De même qu'un bon développeur n'est pas un génie du code mais quelqu'un qui sait écouter et échanger. De même pour tous les métiers d'ailleurs. En gros je met en avant les qualités sociales, l'ouverture et la bienveillance d'une personne avant les compétences pures et dures (je sais que ce n'est pas de l'avis de tous; certains pensent encore que le concept du "génie connard" est bien, à savoir qu'on peut tout laisser passer humainement de la part de quelqu'un qu'on considérerait excellent techniquement dans son métier; j'ai encore des discussions régulièrement sur ce sujet et c'est aussi un sujet classique de l'imaginaire populaire, notamment avec la télé/ciné, du héros antipathique au possible mais à qui on pardonne tout parce qu'il sauve le monde/les gens/l'entreprise).

Sinon oui, c'est sûr, de temps en temps, on a des "designers" qui passent une fois, disent qu'ils veulent tout changer puis reparaissent jamais (sûrement en se demandant pourquoi on laisse pas tout de côté pour se concentrer sur eux et qu'on réimplémente pas GIMP immédiatement, entièrement sur la base des 2 paragraphes qu'ils ont écrit en 10 minutes dans un rapport). Ça arrive souvent. Mais ça nous rend pas frileux pour autant. Ça c'est le quotidien. De même qu'on a très régulièrement les designers du dimanche qui font un message (ou un thread) sur twitter et considèrent que c'est suffisant (en général ceux-ci font la même chose pour plein de projets; leur but semble juste de montrer à quel point ils sont bons en critiquant des gros projets avec un semblant de critiques constructives, mais ils ne font que gratter la surface, sans jamais rentrer dans la partie réellement constructive: intéragir, discuter avec les développeurs et contribuer — tout court déjà, encore moins en profondeur —, en détail sur des points précis — et pas des concepts abstraits et généraux — et en itérant).

Enfin bon, au final, si, bien sûr qu'on veut des designers dans l'équipe. Mais ils seraient dans l'équipe, des membres à part entière comme les autres et pas des divinités à adorer (comme certains semblent croire que doive être le rôle de designer). Qu'on me dise pas que ça existe pas. J'ai déjà travaillé avec de tels designers!
Et ils doivent y mettre du leur, pas juste déposer 3 phrases bateaux et un peu vague dans un rapport ou sur Twitter et croire que leur job est fait.

Deux femmes graphistes leurs font des rapports de bug super précis

On a bien plus que 2 contributrices de rapports de bug précis. On a des dizaines de messages par jour sur notre outil de suivi, et pas mal d'habitués qui y font des rapports très réguliers et parfois très détaillés.

l'une étant la compagne de Jehan

Vrai ou non, ce n'est pas une caractéristique de cette personne. Si je suis en couple, je n'appelle pas ma compagne "ma compagne" (allez, disons sauf pour simplifier dans de rares cas, genre en face d'administrations) mais par son prénom et si j'intéragis professionnellement, c'est par ses compétences professionnelles. Être un ou une compagne n'est pas une caractéristique qui a le moindre intérêt et je préfère quand les gens ne voient pas autrui comme étant la compagne ou le compagnon d'un autre. Surtout quand ce sont des personnes avec des compétences techniques très importantes et pointues dont on parle. Cela ne fait que diminuer la valeur de tout le monde.

Je pense que le monde irait mieux si on ne qualifiait pas les gens par des caractéristiques qui n'ont aucun intérêt (compagne/compagnon de, femme/mari de, fils/fille de, père/mère de…). Sans compter que la vie privée des gens n'a rien à faire dans leur vie professionnelle.

En gros, cette remarque en aparté n'a aucun intérêt et n'a absolument rien à faire là. 🤔

Faut bien voir que l'interface évolue vers les besoins des professionnels, plus que vers le grand public.

Ça a en effet toujours été vrai que GIMP est un logiciel pro (dans l'industrie, on appelle même cela un "logiciel métier"). Et donc c'est vrai qu'on va prendre bien plus en considération les besoins pros très bien expliqués avec des cas d'usage très concrets. On a beaucoup de pros qui font des retours très détaillés et qui suivent le projet de près. 😄

Et beaucoup de fonctionnalités sont demandées par des pros qui ont besoin d'utiliser des fonctionnalités avancées. Ensuite comme GIMP est un logiciel de graphisme générique, cela recoupe diverses industries. En plus des usages évidents (photographie, peinture numérique, design), on sait que GIMP est pas mal utilisé par les designers de jeux indés, énormément dans l'astronomie aussi, pas mal de gens dans la création de cartes (encore plus depuis qu'on a ajouté la prise en charge des métadonnées GeoTIFF, ce qui simplifie l'usage de GIMP en soutien à des logiciels de cartographie; j'ai l'impression que maintenant pas mal dans cette communauté recommandent GIMP grâce à cela), en recherche ou médecine aussi (en histoire récente, je me souviens d'un rapport de gens qui fabriquaient du matériel médical qui traitait des images de taille genre 100k×100k — GIMP est très efficace sur les grandes images — et avaient besoin de la prises en charge dans GIMP de certaines capacités de TIFF — ce qui fut implémenté —; ou encore de quelqu'un sur un forum qui travaille en laboratoire sur la recherche de chromosomes et voulait passer à GIMP pour traiter de l'imagerie), en 3D (traitement de textures, etc. Dans les histoires dont je me souviens, on a eu un centre de formation en ligne qui nous a demandé d'implémenter une fonctionnalité que seul un logiciel propriétaire quelconque — dont je me souviens plus le nom — avait et qui permettait de traiter plusieurs types de textures représentant une même zone à la fois; ben maintenant y a 2 logiciels qui ont cette fonctionnalité: cet autre logiciel proprio et GIMP, en libre; ils ont ainsi pu utiliser GIMP pour une formation sur la photogrammétrie). Etc. Etc. Etc.

Enfin bon, on ne manque pas de rapports de bugs et de cas d'usage réels pour l'amélioration de GIMP. :-)

À tord où à raison, l'UX est souvent un sujet qui est mis en avant par les détracteurs de Gimp.

Je pense qu'une bonne partie de ceux qui critiquent n'utilisent simplement pas GIMP, voire de manière générale n'ont même pas vraiment l'usage de ce genre de logiciel (hormis pour une rotation et une découpe d'image une fois par mois, alors forcément GIMP, ça leur semble une usine à gaz inutilisable avec toutes ses fonctionnalités!).

Petite histoire vraie: depuis qu'on est sur le Microsoft Store, il m'arrive parfois de lire les commentaires des gens juste pour me faire du bien. En effet GIMP y a une super note (4.5/5 sur la base de plus de 8000 notes dont plus de 1000 avec commentaires en un an!) et il y a tellement de gens (la grosse majorité des commentaires du store) qui y disent des trucs gentils sur GIMP et sur le fait que ça les aide au quotidien et qu'il est super puissant/utilisable. 💌

Allez, pour le plaisir, petit florilège partiel sur uniquement les 5 derniers jours (je n'ai pas mis tous les commentaires positifs et il n'y avait que 2 commentaires négatifs dans cet intervalle temporel):

[Inde]

best
this app is awesome

[États Unis]

Gimp iz kewl
Tbh GIMP is kinda weird at start but when you get into it it just becomes amazing

[Pologne]

Useful app
Useful application, especially for shading when you don't want to deal with it in vector >//<

[Argentine]

I've been using GIMP for years. I LOVE IT
After all so many years using GIMP i cannot express my gratitude enough to the maintainers, testers, designers and management people that make it possible to edit freely images.

[Équateur]

The best of all
You have all the options you need, and it keeps getting better. Congratulations

Alors forcément, quand on ne lit quasiment que ce genre de commentaires, ça redonne goût à ce qu'on fait!

Et c'est dans ce genre de cas que parfois je me rends compte que certaines personnes dans la communauté Linux sont juste méchants et ne se plaignent que pour le plaisir de se plaindre, et surtout le plus bruyamment possible. C'est quand même ironique que je doive lire les commentaires des Windowsiens pour voir à quel point GIMP est apprécié quand j'utilise moi-même Linux depuis une vingtaine d'années.
Parce que si je devais me limiter par exemple à Reddit ou HackerNews, la vision que j'aurais des avis sur notre logiciel serait bien plus triste. Surtout que quand on lit les "raisons" des gens qui se plaignent, on se rend souvent vite compte qu'une majorité de ceux qui critiquent n'utilisent simplement pas GIMP.

Enfin bon, j'ai appris à m'abstraire des commentaires lambda désobligeants sur les forums, lesquels donnent parfois, mais rarement, des critiques constructives et réellement utilisables pour améliorer le logiciel. Non parce que sinon, ça fait longtemps que je serais tombé en dépression et aurait abandonné. 😰

Allez pour finir sur une note positive, deux derniers commentaires du Microsoft Store, d'il y a 10 jours et 3 semaines:

[Allemagne]

Gimp is very good.
I've already edited a lot of pictures with the app, and I have to say, it's very good.

[États Unis]

Great Free software!
There is nothing to complain about GIMP. Sure the interface is different than Photoshop, but once you get used to it you find that there is nothing you can't do with this powerful and community supported software. I highly recommend this being part of everyone's arsenal of design software.

💌

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

Là où je bossais, c'était une association de cinémas d'art et d'essai et les distributeurs qui avaient des contrats avec l'association n'étaient pas les plus gros (qui ne veulent passer que par les gros services, type Globecast, ou simplement envoyer des disques par coursiers car certains des plus gros distributeurs n'ont simplement aucune confiance en des intermédiaires de service de téléchargement de DCP).

Donc il est très vraisemblable que les DCPs que j'ai vu passer étaient plutôt la partie "petite taille" du marché total (petits films, beaucoup d'indés, moins longs que les blockbusters qui de nos jours font 2h voire 3h; peu de 4K… 3D encore plus rares…). 😄

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

projet de dépôt tiers qui s'en foute des brevets (tels que RPMFusion ou encore notre bon vieux Penguin Liberation Front

euh, ils ne se foutent pas des brevets : ils prennent en compte le fait que les brevets logiciels sont (encore longtemps j'espère) illégaux au moins en Europe :-)

Au cas où ce n'était pas clair, ce n'était pas une critique négative sur ces projets, bien au contraire.

Moi aussi je me fous de plein de trucs. Je pense ne pas être un mauvais bougre pour autant. Enfin j'espère… 😅

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

Mais à part ça, HEIF c'est super en fait, ça permet de continuer à avoir des problèmes de formats malgré les super initiatives vraiment ouvertes telles que AVIF et JPEG XL.

Je vais pinailler un peu, mais AVIF, c'est aussi du HEIF. C'est d'ailleurs bien écrit dans la dépêche. HEIF est le nom du conteneur qui est utilisé aussi bien pour AVIF comme pour HEIC.

Et donc dans toute votre discussion, en fait, on comprend bien que vous êtes en train de comparer HEIC et AVIF (et non pas HEIF et AVIF). En gros, ce que tu voulais écrire dans la phrase que j'ai citée, c'est:

Mais à part ça, HEIF HEIC c'est super en fait, ça permet de continuer à avoir des problèmes de formats malgré les super initiatives vraiment ouvertes telles que AVIF et JPEG XL.

Je n'ai pas les détails historiques, mais je suppose que le HEIC est arrivé en premier et comme il était donc peut-être le seul à utiliser HEIF, les gens mélangeaient allégrement les genres (d'ailleurs si un fichier a une extension .heif, il me semble que ce sera le plus souvent un .heic en vrai). Ça n'avait pas d'importance alors s'il était seul à utiliser ce conteneur. Enfin bon, c'est juste une supposition de ma part.

En tous cas, maintenant faut préciser HEIC ou AVIF. Parler de HEIF n'a aucun sens (enfin sauf si on veut vraiment parler du format du conteneur!).

Notons que ce pinaillage a son importance: cette confusion semblant un peu répandue, certains empaqueteurs de distributions la font aussi, et du coup on a (eu? Je sais pas si c'est encore le cas, à vérifier… Par exemple, ce fut le cas chez Fedora qui ont eu du mal à comprendre que HEIF ≠ HEIC et que les problèmes légaux étaient avec HEIC — le codage HEVC/H.265 plus particulièrement — mais il semblerait qu'ils aient finalement compris puisque je vois qu'il y a finalement un paquet depuis mi-mars qui intègre maintenant bien la prise en charge de AVIF mais pas de HEIC) des problèmes car les distributions qui font attention aux brevets logiciels n'intégraient pas la bibliothèque libheif et désactivaient entièrement notre plug-in file-heif dans GIMP, désactivant ainsi aussi bien la prise en charge de HEIC que de AVIF. C'est ballot si on veut promouvoir la variante ouverte et sans brevet (AVIF donc) utilisant du HEIF!

Alors qu'il suffit d'avoir un paquet libheif qui ne contienne que les codecs de compression et décompression pour AVIF (puisque cette bibliothèque est aussi modulaire). Notre plug-in file-heif faisant aussi une vérification à l'exécution, GIMP ne proposera alors que AVIF.

C'est d'autant plus sympa qu'il suffit qu'un projet de dépôt tiers qui s'en foute des brevets (tels que RPMFusion ou encore notre bon vieux Penguin Liberation Front, qui malheureusement n'existe plus, même s'il avait un nom et un logo assez marrants! 😜) fasse un paquet contenant simplement les codecs supplémentaires pour que GIMP ait magiquement la prise en charge de HEIC au redémarrage (avec le même paquet pour GIMP).

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

Je sais pas si tu fais beaucoup de développement, mais même s'il arrive bien entendu de s'inspirer de code existant, lire du code complexe pour le réimplémenter n'a rien d'une partie de plaisir et surtout n'a rien de simple.

Très souvent, dans un cas tel que de la prise en charge de format de fichier ou de protocole, il sera même bien plus simple de faire de l’ingénierie inverse directement sur des échantillons de fichiers existants que d'essayer de lire 5000 lignes de code existant.

Le coup du "Ça existe déjà dans le logiciel libre X, pourquoi vous reprenez pas juste le code?" est probablement l'une des déclarations les plus vaines et frustrantes qu'on lit régulièrement sur le web, de gens qui ne développent pas (ou peu).

Bien sûr, l'existence de code, ça aide. Mais lire du code complexe n'est absolument pas équivalent à une spec qui dira la même chose en un paragraphe de texte simple qu'un code qui fera des boucles, des renvois en fonctions, des break, manipulera probablement des octets (on parle de données) et des bits (flags de bit, etc. typique dans les formats de fichiers), possiblement avec des optimisations de traitement super abscons et opaques qu'on doit relire 5 fois avant de comprendre ce que ça fait et dont on aura déjà oublié à moitié la logique le lendemain quand on relira le même code (et complètement une semaine après). Parce que dès qu'on se met à manipuler des octets et des bits, il y a toujours énormément de trucs super pas clairs pour permettre des optimisations en lecture-écriture (la différence entre un algorithme dit "naïf" qui est celui implémenté en premier car il paraît logique et qui est donc aussi simple à lire, et celui optimisé quand on se rend compte que son algo naïf est aussi super lent — genre 50 fois plus lent qu'un algo optimisé mais abscons — quand on doit traiter de vrais données du monde réel, donc des images super méga grosses).

Et ça c'est sans parler du fait qu'on parle d'image et de couleur, donc avec en plus de la conversion de modèles de couleur, parfois des trucs bizarres dans la gestion des canaux, etc.

une fois qu'on les a implémentées dans un logiciel libre, en quoi le caractère "fermé" des specs pourrait nuire au caractère "ouvert" du format (si on considère le JPEG-XL comme un "format ouvert") ?

Donc non, on ne peut pas dire qu'un format sans specs accessibles soit "ouvert". Une implémentation libre de specs fermées n'est pas comparable à des specs.

Et c'est sans compter qu'une implémentation peut avoir des bugs. Sans accès à la spec, si on prend pour argent comptant ce qu'une implémentation particulière fait, on peut avoir des soucis.

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

 le format du cinéma numérique utilise en effet ce type de codage JPEG2000 avec un codage sans perte de chaque image

Le format cinéma numérique (DCP) utilise en effet JPEG2000 mais avec perte, de ce que je sais (JPEG2000, comme beaucoup de formats de nos jours, pouvant faire les deux), même si c'est avec une compression acceptable pour éviter les artefacts visibles. Cela rend d'ailleurs les films déjà bien assez gros (alors imaginez en totalement sans perte).

De mémoire, si un film d'animation simple peut faire une trentaine de GiB, un film cinéma typique (c'est à dire filmé, avec des acteurs) fera une centaine de GiB (et un film 3D peut aller dans les 200 ou 300GiB.
"De mémoire" car j'ai travaillé dans ce milieu, il y a quelques années. Et même si je n'ai pas vérifié moi-même, on m'avait bien dit que c'était du JPEG2000 avec perte.

Par contre la NASA a utilisé aussi du JPEG2000 pour des images astronomiques et là je me demande s'ils n'encodent pas sans perte.

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

Sauf que pour les uns comme pour les autres (domestiques comme sauvages), c'est pas leur faute. Si on pouvait faire des lois ou des solutions moins cruelles que de tout zigouiller (dans d'atroces souffrances probablement, parce que j'ai comme un doute s'ils ont même cherché à faire un poison indolore).

Franchement, je connais rien de plus sadique et cruel que les humains: on est la source de ces proliférations d'animaux, puis on les extermine. Et on répète les mêmes erreurs encore et encore.

Pour les animaux domestiques, je suis entièrement d'accord que c'est n'importe quoi. Mais la solution n'est pas de les exterminer. Il faut:

• Interdire le commerce d'animaux car il y a peu de chose plus merdique que le commerce d'êtres vivants de manière générale. Mais d'un seul coup, y a plus grand monde quand on dit ça ("vous vous rendez compte tous les emplois!" serait probablement la réponse la plus classique des politiques pour une telle proposition).
• Permettre aux gens de recueillir les chats sauvages mais leur interdire la reproduction (donc les faire opérer au plus vite). Le truc le plus aberrant que j'ai lu/entendu régulièrement, c'est "on les fait se reproduire une fois, comme ça ils sont contents, puis après on opère", comme si l'animal avait un besoin impératif de se reproduire… 🙄 pour ensuite donner les animaux ailleurs loin de la mère et dans des conditions inconnues.
• Laisser les animaux sauvages tranquilles et tant qu'à faire, en leur laissant des espaces à vivre. Parce que le problème des animaux sauvages, c'est surtout qu'on déforeste, imperméabilise les sols de goudrons, ou de manière générale, on s'empare de tous leurs foyers. Alors au final, ils se retrouvent à nous côtoyer sur nos espaces, voire à se nourrir de nos déchets car ils ont plus rien à bouffer, et nous à les considérer en pestiférés. 🤦

Alors certes l'Australie est un cas un peu particulier car ils ont un écosystème très particulier. Ils ont énormément d'animaux endémique et tout élément biologique externe est un risque pour leur écosystème naturel. J'ai vécu en Nouvelle Zélande, ils sont dans la même situation (on notera que la plus grosse de ces espèces envahissantes, c'est l'humain, mais personne suggère de se retirer de ces îles! 😁).

Mais bon, avant d'aller vers les solutions extrêmes d'extermination, c'est quand même fou que personne ne considère de peut-être… je sais pas moi… arrêter les industries produisant ces animaux (oui les chats sauvages, c'est pour beaucoup les descendants de ces chats domestiques puis abandonnés)? Tuer d'un côté pour continuer à produire de l'autre. Y a pas comme une aberration logique?

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

Ton lien est cassé et m'indique:

Error
Looks like something went wrong!

Et sinon j'en profite pour rappeler que GIMP n'est pas sur Github!

Le lien que tu voulais probablement faire est celui-là: https://gitlab.gnome.org/GNOME/gimp/-/blob/master/NEWS

Voire, si tu veux un permalien qui indique les changements de 2.99.16 et qui ne changera pas quand on modifiera ce fichier: https://gitlab.gnome.org/GNOME/gimp/-/blob/6d2580a421ddbb7fb8a99791fe37518b333351d6/NEWS#L9

P.S.: qui de nos jours utilise encore Github de toutes façons? Ce serait ridicule qu'un projet comme GIMP y soit.

P.P.S.: encore trop de monde, je sais. C'était juste pour lancer le troll! 😜

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

Disons que ça a la valeur que les gens veulent bien lui accorder. 🤷

Hormis cela, techniquement le truc entier repose sur une incompréhension totale du droit (droit d'auteur comme droit de propriété). En effet la valeur de la Joconde est essentiellement matérielle. L'image de la Joconde est depuis longtemps dans le domaine public. Il y a bien sûr des tentatives de recréer un nouveau droit d'auteur en se basant sur celui du "copieur", à savoir par exemple le photographe qui aurait pris une photo de la Joconde pour des cartes postales et qui donc interdirait aux gens de copier la carte postale sur base du droit d'auteur du photographe (et non du peintre d'origine puisque son droit patrimonial est terminé). Cela va en fait à l'encontre de l'interprétation actuelle des juges qui estiment qu'une œuvre sans originalité artistique n'est pas sujette à droit d'auteur (or c'est bien ce qu'on attend d'une reproduction "à l'identique", telle qu'une carte postale d'une œuvre d'art existante: on n'attend pas que le photographe y ajoute sa "touche personnelle") mais bon… ça n'empêche pas les nombreux musées ou photographes avides d'essayer d'ajouter leur droits d'auteurs.
Mais ce qui a de la valeur, c'est bien uniquement le tableau physique maintenant (sans rentrer dans la discussion plus bas si c'est uniquement du fétichisme ou bien de la spéculation ou autre moyen de faire de l'évasion fiscale…).

Quoiqu'il en soit, les NFTs reposent entièrement sur du vent et ont toujours reposé sur du vent. Il n'y a pas besoin de signature "blockchain" pour du droit d'auteur (et inversement, un NFT ne se substitue pas à un contrat de cession de droits d'auteur qui est un document qui se doit de contenir un certain nombre d'informations sur l'usage attendu pour la cession de l'œuvre; notamment le quand, où, comment…); et il n'y a rien de physique, aucune propriété à laquelle prétendre sur quelques bits de données (qui ne sont d'ailleurs en général même pas les données d'une image mais plutôt un lien vers un serveur quelconque qui peut disparaître à tout moment de ce que j'ai lu; mais même si le fichier entier de l'image était contenue dans le NFT, ce serait bidon). En gros, le truc entier ne se base sur aucun aspect légal d'aucun code (en tous cas pas en droit français et probablement d'aucun droit national autre non plus). C'est une arnaque du début à la fin, qui a visé des esprits peu critiques en recherche d'argent facile (ce qui est le cas de beaucoup d'arnaques d'ailleurs, qui sont souvent des prédations sur la base de la cupidité des proies).

En tous cas, rien à voir effectivement avec les crypto-currency, que je ne soutiens pas pour autant (loin de là! J'ai toujours trouvé bitcoin "cassé" par design; je me souviens de discussions que j'avais sur le sujet, il y a 10 ans ou plus et je ne comprenais déjà pas comment certains ne voyaient pas les problèmes techniques évidents), et qui sont effectivement devenus de purs objets spéculatifs de nos jours. Néanmoins il paraît évident qu'une majorité des usagers initiaux ne le voyaient pas, et même s'imaginaient bitcoin comme un énième système de "micro-échanges financiers". Je doute que même le(s) auteur(s) originaux (le fameux "Satoshi") s'imaginaient que cela exploserait ainsi.

Aussi j'ai du mal à avoir beaucoup d'empathie pour les gens extorqués, parce qu'on voit bien que beaucoup de ceux-ci, s'ils n'avaient pas été du côté des arnaqués, ils auraient été du côté des arnaqueurs, et seraient alors tout à fait OK avec cela et encore en faveur des NFTs de nos jours. On le ressent vraiment bien dans cet article de Numerama qui montre bien que ces gens étaient surtout en quête d'argent facile (c'est dit explicitement plusieurs fois dans l'article, avec diverses tournures, mais toutes ayant pour sens de se faire de l'argent rapidement sans labeur, et surtout sans se poser la question "sur le dos de qui?"), les yeux brillants de 1000 paillettes en voyant comment d'autres s'étaient enrichis avant eux. La différence est que certains s'en sont vraiment bien sortis (multiplication de l'investissement par quelques milliers apparemment! C'est énorme) alors que d'autres ont tout perdu. Et c'est en gros la seule différence, les premiers étant encore totalement prêts à défendre l'arnaque quand les autres vont maintenant la dénoncer.

En fait, je trouve cela juste triste.

Et donc pour revenir à l'exemple (hypothétique?) cité de "premier sprite de Mario" en NFT. Pour qu'il ait la moindre valeur, déjà il faut que ce soit l'auteur qui fasse le NFT. Ensuite même si c'était le cas… ben ça n'en reste pas moins du vent. Ce n'est pas une cession de droits d'auteurs (ainsi acheter ce NFT ne donne aucun droit d'usage de ce sprite!). D'ailleurs ça n'empêcherait pas Nintendo de continuer à utiliser ce sprite. Ni de faire des contrats de cessions avec d'autres gens. Voire de regénérer de nouveaux NFTs sur le même sprite. En gros, ce serait une belle manne pour les entreprises (et apparemment certaines l'ont compris vite, comme l'article en cite quelques unes qui se sont engouffrées dans cette mode et ont dû faire quelques jolis sousous le temps que ça a duré).

Donc ça a peut-être de la valeur pour certains parce qu'ils sont naïfs (et c'est eux qui se feront escroquer), mais absolument pas de manière absolu, puisque ça n'a absolument aucune base légale. Ou pour être plus précis, ça en a à peu près autant que si je vendais des bouteilles dans lesquelles des gens célèbres auraient soufflé avant que je pose un bouchon (je vends du "vent" quoi 🤣). C'est probablement(?) pas illégal de vendre cela si certains veulent y mettre une valeur quelconque. Mais il n'y a aucune valeur intrinsèque.

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

Idée très intéressante.

Il reste toutefois un casse-tête à régler: la paternité des contributions et surtout la connexion aux APIs de contributions! J'ai encore en mémoire cet article qui parlait du fait que l'application de Microsoft avait été bloquée d'OpenStreetMap parce qu'elle mettait l'ensemble des contributions de tous les utilisateurs de la carte de Microsoft sous un unique compte générique et qu'on ne pouvait contacter les contributeurs (en cas de problèmes), me semble-t-il. De mémoire, il y avait aussi un problème possible de qualité de contribution à cause de la GUI de l'application Microsoft?

Enfin bon, quoiqu'il en soit, il y avait des problèmes assez intrinsèque à avoir une application extérieure pour contribuer et ciblée peut-être pour le grand public plutôt que les hardcore-libristes habituels.

Faudra-t-il demander aux joueurs de créer un compte pour chaque API du jeu? (au moins, pas besoin d'en créer une pour le jeu lui-même car j'ai aucune envie de rassembler des données utilisateurs!)

Quoiqu'il en soit, l'idée reste intéressante et faisable à mon avis. C'est la discussion préalable pour la mise en lumière des problématiques et leur résolution, tout en gardant un gameplay marrant (sinon ça sert pas à grand chose, à mon avis, d'en faire un jeu) qui prendrait du temps. :-)

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

Par contre, je fais ça sur mon temps libre et il me semble impossible d'atteindre le niveau pro avec un boulot à côté. Les jeux vidéos sont une industrie de très très haut niveau. Même une petite production indie est inatteignable en amateur.

De ce que je vois, tu as déjà tout ce qu'il faut techniquement. À mon avis, il ne faut pas chercher à faire un jeu compliqué, mais quelque chose de simple et sympa.

Par exemple, les jeux d'aventure point'n click en 2D pourraient être une alternative sympa, en prenant avantage du fait d'avoir une artiste qui fera de beaux fonds et des animations de personnage de qualité. Le développement de ce type de jeu est simple (pas de moteur physique, ou sinon super limité, pas de règles complexes, etc.).

On peut imaginer un style "jeux courts avec beaux visuels". Et si possible avoir une histoire intéressante aide bien aussi (en tous cas, moi j'aime les jeux à histoire). Cela demande plus de travail en amont mais peut ensuite alléger le reste (c'est à dire que si l'histoire est très bien, on pardonne plus facilement un gameplay simple). Genre un mini jeu de détective mais avec des enquêtes intéressantes, des énigmes de qualité et une atmosphère prenante.
Je sais qu'Aryeom aime bien les histoires d'enquêtes.

Sinon si on veut jouer sur un concept "logiciel libre", j'avais eu une idée de jeu à une époque. On pourrait appeler cela: "flossmon — free them all!" (je me demande d'où me vient cette idée! 😜)

Dans ce jeu pour portables avec caméra, on pourrait trouver des mascottes (Tux, Wilber, etc.) du libre emprisonnées, ajoutées sur l'image de la caméra en réalité augmentée (mais vraiment, y a-t-il une inspiration quelconque? 😆), sauf qu'au lieu de les capturer, le but est de les libérer.

Éventuellement si on croise d'autres joueurs à proximité, on peut même collaborer. Non parce que les jeux coopératifs, c'est quand même génial! Plutôt que sans cesse chercher à s'affronter…

En fait cette idée de mascottes du libre dans la "nature", j'avais eu l'idée à un moment comme une série de photos artistiques qui reprenait l'idée des mini-monstres en réalité augmentée, mais avec pour but de leur laisser la liberté plutôt que de les mettre en boîte pour ensuite les faire combattre entre eux (une idée tordue et sadique, soyons honnête). C'était un petit clin d'œil. J'avais fait une photo de ce type mais n'ai jamais complété ma série. Ça ferait clairement un jeu marrant et pas complexe du tout à développer avec le gameplay adéquat.

Peut-être même qu'on pourrait mêler cela avec une forme de contribution à OpenStreetMap? Par exemple, pour libérer une mascotte, il faut indiquer une info manquante, genre le nombre d'étage d'un immeuble. Mais pour que les gens ne mettent pas n'importe quoi juste pour gagner des points, l'info doit être ensuite validée par un second joueur. Et la mascotte est libérée à ce moment là.
Enfin bon, c'est juste une idée vite fait jetée en l'air. Je sais pas si c'est une bonne idée de mélanger un jeu pur avec une contribution à un projet de données libres (le risque pourrait être de soit rendre la partie jeu moins marrante, soit de diminuer la qualité des contributions si les gens trouvent des failles pour gagner des points en collaborant en donnant des infos bidons par exemple).

Ça mérite un brainstorming un de ces jours !

Enfin bon, oui en effet… discuter d'idées ensemble, c'est clairement faisable.

Il y a clairement beaucoup d'idées de jeux sympas à développer.

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