ç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 ]
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 ]
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, HEIFHEIC 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 ]
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 ]
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 ]
Pour être tout à fait franc, j'y ai pensé à diverses reprises en voyant les news de devnewton. Pourquoi pas faire un petit jeu libre ensemble? Quelqu'un qui a de l'expérience côté développement de jeux libres, a un peu de bouteille (même si je suis pas à fond sur les choix techniques — a.k.a. java! 😱 — mais bon si je suis pas le dév principal, alors je suis d'avis de suivre les choix de ce dernier) et en plus est en faveur des licences libres…
Ensuite j'ai jamais voulu commenter sur cela, parce que je veux pas m'avancer.
Quoi qu'il en soit, quand on finira notre pilote, on va sûrement faire un autre projet, et pas continuer ZeMarmot car on a visé trop gros en qualité/durée, donc temps de production, relativement aux fonds qu'on est capable de lever (c'est à dire que si on avait été capable de lever 20 fois plus, alors on aurait pu engager des gens et là ça aurait marché mieux; mais à 2, on passe des années à s'épuiser, à déprimer, etc.).
Pour notre prochain projet:
On devrait être capable de lever un peu plus de fonds (depuis 2015, on aurait un peu plus de reconnaissance… enfin j'espère! 😅);
mais on s'attend pas pour autant à des milles et des cents, donc on visera un projet court et plus simple visuellement par défaut;
on espère avoir assez pour engager plus de personnes (même si pour projet court);
faire un projet court permet aussi de moins s'essouffler, surtout lorsqu'on est peu à tout faire (ce qui peut devenir moralement pesant; ce qui est notre cas actuellement);
par contre notre crédo, c'est de faire cela le plus professionnellement possible (au sens "rémunéré", au niveau qualité, je vois pas de problème avec ce que fait devnewton). Il faut voir si cela convient à devnewton (certains veulent faire leur projets à la mode kiss-cool, en hobby, ce qui est tout à fait ok, mais notre production souhaite notamment montrer que l'art audiovisuelle professionnel peut aussi être entièrement libre; surtout s'ils ont un CDI, il est compréhensible de ne pas vouloir le bazarder pour un projet de quelques mois).
En gros, c'est une possibilité tout à fait envisageable et qui perso m'intéresserait bien. Je pourrais imaginer qu'on organise un projet de petit jeu libre avec tout (code et art) sous licences libres. Si en plus, on peut le faire le plus multi-plateforme possible (notamment les OS téléphones pour suivre la mode?!), ce serait cool. Mais comme je disais plus haut, je veux pas m'avancer non plus. Aryeom doit aussi être d'accord pour un tel projet déjà. Et puis comme le temps est limité, on préférerait peut-être s'orienter vers un autre projet.
Mais c'est tout à fait discutable (ça ne coûte rien de discuter un peu pour voir si on peut faire un truc cool ensemble et surtout si on aime les mêmes genres et si on a les mêmes attentes), si jamais devnewton veut nous contacter. 😉
P.S.: et pour le son, on a aussi des musiciens à recommander qui sont professionnels de leur art tout en étant aussi à fond sur les licences libres. On peut donc faire un jeu 100% libre sans problème.
P.P.S.: m'en veuillez pas pour le petit lancement de troll sur Java plus haut. Faut bien égayer un peu ses weekends!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Battle for Wesnoth fut parmi mes plus anciennes contributions sur un logiciel libre. J'ai traduit le scénario tutoriel en français (à l'époque, de mémoire, ce n'était pas du tout traduit, ou bien quasiment pas; je sais plus trop).
On retrouve encore mon nom dans les "attributions" de la traduction française: https://wiki.wesnoth.org/Credits (certains remarqueront que le nom de famille n'est pas le mien, mais c'était un pseudo; le prénom est le même! 😉).
Souvenirs souvenirs…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'avais fait une longue réponse y a 10 jours où j'essayais de répondre à tes divers points. Je l'ai encore, mais je ne vais pas la poster. La raison est que je crois que tu t'es totalement embrouillé dans la base même de ta logique, donc si j'essaie de répondre à tes questions qui partent sur des incompréhensions à la base, ma réponse ne peut que t'embrouiller encore plus.
Le problème est évident dès ta seconde phrase:
Si je demande à connaître la couleur à tel point de l'écran, le portail me donne un triplet RGB qui ne veut rien dire sans profil de couleur. Soit.
Puis ensuite tu fais toute une argumentation sur cette base. En gros, tu commences en acceptant la problématique de base qui est que les données de couleur que tu reçois sont fausses… puis tu nous dis plus ou moins par la suite "mais faisons abstraction de cela, je comprends pas pourquoi les couleurs finales seront fausses". Tu vois le problème, j'espère?
Je vais donc faire une réponse plus généraliste sur ce que je pense être tes incompréhensions de base:
Notre contexte: logiciels de graphisme
Déjà tu sembles croire que juste passer des valeurs RGB sans profil marche, puisqu'après tout, tous les logiciels s'affichent bien! Or c'est faux. Ça marchouille pour le cas général où on ne fait pas attention aux couleurs. Et oui, c'est le cas d'une majorité des gens et des logiciels. On s'en fiche peut-être du gris utilisé dans l'interface graphique de son logiciel de calendrier, voire même du rendu de son traitement de texte (même si on a quelques images, ce n'est pas forcément le point central du document et je peux comprendre que dans pas mal de cas, on accepte les couleurs approximatives) ou tout logiciel de bureautique.
Dans cet article, on parle du cas des gens qui font attention aux couleurs: les graphistes, photographes, peintres numérique. Donc déjà, faut se mettre dans ce contexte. Ce n'est pas une dépêche sur LibreOffice. C'est une dépêche sur GIMP.
[Note: néanmoins dans la réalité, tout logiciel devrait aussi gérer au mieux les couleurs — et probablement les plus gros, tels que LibreOffice, le font-ils —; d'ailleurs même les navigateurs web s'y sont mis; mon propos n'est donc pas de dire que cela devrait être uniquement l'apanage des logiciels de graphisme, mais que je peux comprendre que certains ne voient pas autant le besoin absolu pour les logiciels de bureautique; par contre quand on parle de logiciel de graphisme, ce ne devrait même pas être en question]
Dans notre contexte précis donc, les gens ne veulent pas que "ça marchouille", ils veulent que "ça marche", ou du moins, au mieux (car malheureusement c'est un sujet complexe et même quand on fait au mieux, ce n'est en général pas parfait pour autant).
Élargissons tout de même le contexte (histoire de)
Ensuite même si on change de contexte et qu'on prenait le cas du grand public, on se rend compte que le "ça marchouille" n'est pas vrai même dans ce cas. Il est presque vrai uniquement quand on prend les écrans basiques. Mais dès qu'on prend par exemple des écrans avec des gamuts "natifs" très différents du cas plus général, les couleurs deviennent vraiment cassées. Et ça reste un cas très général, car beaucoup de gens de nos jours vont acheter des écrans ou télés à gamut large dès qu'ils ont un peu de moyens (parce que le marketing leur dit "c'est mieux"). En fait, c'est même pire que ça: je lisais encore il y a quelques jours que beaucoup de constructeurs vont avoir exprès des mauvaises configurations de base pour faire pêter les couleurs et ainsi faire ressortir d'autant plus leur modèle sur les étalages. Quiconque a déjà vu des écrans de télé aux supermarché sait de quoi je parle: les vendeurs passent en général la même vidéo sur tous les écrans simultanément. Or avez-vous déjà comparé les couleurs sur tous les écrans? Est-ce les mêmes couleurs d'après vous d'un écran à l'autre? Ben non, en général, les couleurs sont méchamment différentes d'une télé à l'autre et malheureusement très souvent, certains vont même avoir tendance à choisir la télé qui rend les couleurs les plus pêtantes, comme si c'était une preuve de qualité (astuce: ce n'est pas le cas! La qualité serait d'avoir les couleurs telles que les créateurs les ont choisies!).
Sur la base de cette constatation, on peut ainsi revoir son appréciation même du "ça marchouille" (et le "ça marche", n'en parlons pas!).
En fait le processus marketing de nos jours est tellement absurde que les constructeurs font tout pour que leurs écrans aient des couleurs qui puissent ressortir le plus parmi les concurrents sur les étalages. En conclusion, ils font tout pour que les couleurs soient les plus mauvaises possible parce que ça se vendra mieux! La logique commerciale est en fait qu'il faut que l'écran "se démarque", ce qui signifie montrer des couleurs différentes. Alors que la logique du graphiste, c'est justement l'inverse, qu'il ne faut absolument pas qu'un écran se démarque! Ce que vous voulez, c'est que tous vos écrans montrent les mêmes couleurs. Que l'écran du collègue aussi montre les couleurs que vous avez sur le votre. Que l'écran du public qui verra votre œuvre montre encore les mêmes couleurs. Que le mélange d'encre lors d'une impression ressemble aux couleurs sur votre écran. Etc.
Si vous cherchez "wide gamut screen saturated colors" sur votre moteur de recherche web préféré, vous verrez l'ampleur du problème. C'est un problème majeur que la plupart des gens qui achètent ce type d'écran ont de nos jours.
Notons encore que ce n'est même pas juste quelque chose de nouveau, qui serait arrivé avec les écrans large gamut. L'exemple historique le plus flagrant est: le matos/OS Apple! Quand les gens ne calibraient pas leurs écrans (ce qui était le cas de la majorité, même des professionnels du graphisme je pense, il y a 20 ans — j'y étais pas mais je vois bien que l'industrie a commencé réellement à appliquer les principes colorimétriques modernes il y a une quinzaine d'années environ), la calibration par défaut des écrans appliquait un gamma de 1.8 chez Apple alors qu'il était de 2.2 pour le reste de l'industrie. C'était le cas jusqu'à environ 2009/2010. Et c'est pourquoi à l'époque, les gens se plaignaient constamment de différences de couleur en passant une image de macOS à tout autre système (Windows, Linux, etc.). L'image était beaucoup plus sombre sur macOS.
La raison de pourquoi Apple étaient les seuls à utiliser 1.8 est une histoire ridicule de matériel qui illustre tout à fait ce que je disais sur un autre commentaire sur l'industrie qui a fait erreur sur erreur.
Et la raison pour laquelle ils sont passés à 2.2 est uniquement pour ce que tu proposes: afin de pouvoir enfin "marchouiller" en faisant comme tout le monde. Mais il faut bien comprendre que ce n'est pas une solution pour autant. Ça fait juste des différences moins flagrantes mais ça n'est pas de la gestion de couleur pour autant.
D'ailleurs ce problème ne changeait le résultat que pour les gens qui ne calibraient pas leurs écrans ou avaient des logiciels qui ne géraient pas les profils de couleurs ou travaillaient sur des images sans profil. Pour ceux qui cochaient déjà ces 3 conditions, ce changement de gamma ne les impactaient pas (et ils n'avaient pas le problème de couleurs plus sombres en passant d'un ordi Windows/Linux à OSX). C'est bien ça qu'il faut comprendre: ce genre de choix absolus n'impactent que les setups qui ne font pas de gestion de couleur, parce que non, ça ne marche pas par défaut en réalité.
Le but de la gestion des couleurs: des couleurs justes et une référence
Je vois bien que tu parles du contexte où aucun logiciel ne gère les couleurs, où on ne travaille que sur des images sRGB (ou sans profil, ce qui en général est équivalent… ou pas! Comme le montre le cas Apple!), où l'écran n'est pas calibré et où on ne travaille que sur un seul écran: oui, si tu prends une couleur sur l'écran ou sur une image, que tu la remontres sur le même écran en réutilisant le triplet RGB tel quel, ça fonctionnera (dans un sens très limité du verbe "fonctionner"). Disons que dans ce cas un peu particulier, tu n'as pas à te soucier de la couleur, tu passes les données en entrée et en sortie sans y appliquer de sémantique en te disant que de toutes façons l'entrée et la sortie sont le même périphérique. Mais si jamais l'entrée et la sortie sont différents, ou simplement si à n'importe quel point intermédiaire du flot de travail, on a besoin de gérer la couleur (c'est à dire si on passe par un logiciel comme GIMP qui va permettre de réutiliser la couleur dans diverses images qui peuvent avoir toute sorte de profil et donc on a besoin de "comprendre" cette couleur, lui donner un sens, et pas juste la faire traverser sans la traiter), ben tu ne peux pas te passer de la sémantique de ta couleur.
Encore une fois, on parle du cas des professionnels ou amateurs éclairés du graphisme. Ces personnes veulent pouvoir travailler sur plus que du sRGB d'une part.
D'autre part, je rappelle que le but de la calibration est qu'on veut pouvoir comparer les couleurs sur plusieurs systèmes de sortie, pas juste son unique écran à soi. Typiquement c'est parce qu'on crée des œuvres à partager. Pour les gens qui font des œuvres numériques (illustrations, photographies, films…), cela peut signifier plusieurs écrans: si on choisit des couleurs, on aimerait que la couleur reste la même sur l'écran des autres.
Alors certes, là tu vas me dire: oui mais on l'a bien vu, les écrans du grand public ne gèrent de toutes façons pas les couleurs correctement! Mais alors imagine si tu (en tant qu'auteur) as un écran qui vire vers le bleu par exemple. Et tu choisis tes couleurs ainsi. Donc comme ton écran tire sur le bleu, tu choisiras des couleurs d'autant plus dans le rouge et le vert sans même t'en rendre compte (pour compenser ce que tu vois à l'écran). Imagine maintenant que ceux qui regardent ont des écrans qui tirent déjà vers le vert et rouge. Et en plus toi, tu leur donnes à regarder des images qui ont déjà (par erreur) une teinte rougeâtre/verdâtre! Les erreurs s'additionnent. Ils verront des couleurs totalement saturées.
En gros, il te faut tout de même une référence pour ne pas accumuler les erreurs (tu ne peux certes pas contrôler les écrans de ton public, mais le tien au moins, tu peux le contrôler!).
Pour le cas où on veut imprimer: il faut pouvoir avoir un minimum de similarités entre les couleurs. Tu vas pas réimprimer ton truc 20 fois.
Il y a aussi le cas où tu travailles avec d'autres. Dans ce cas, tout le monde calibre ses périphériques de sortie pour travailler sur les mêmes couleurs. Imagine que la personne qui fait du color grading, qui a fait sur mesure sa grande salle spéciale sans fenêtre, avec des murs repeints en "gris milieu" et son matos hors de prix… cette personne qui a fait tout ces efforts et a dépensé vraisemblablement des dizaines de milliers d'euros dans ce setup ne calibrait pas son écran et se disait que travailler avec les couleurs natives approximatives suffisait. Comme toi, il se dit qu'il travaille avec un "triplet RGB qui ne veut rien dire sans profil de couleur. Soit." Soit? Est-ce vraiment un lemme acceptable pour la base de son travail de couleur?
Et il envoie son résultat à ses collègues qui feraient de même. Je veux dire, on est d'accord que ce serait extrêmement ridicule d'aller si loin dans la création d'un environnement idéalement neutre pour travailler les couleurs, tout ça pour au final afficher n'importe quoi, non? 😉 Est-ce que tu penses vraiment que ce lemme de base "triplet RGB qui ne veut rien dire sans profil de couleur. Soit." est acceptable?
Il faut donc revoir ton lemme de base, et à partir de là, tu comprendras que l'ensemble de ton commentaire est inutile (au sens "faux", pas inutile dans le contexte de la conversation, d'ailleurs je n'ai pas cliqué sur "inutile" et personne l'a fait, à ce que je vois 😜). Tu ne peux juste pas faire une argumentation qui fonctionne sur une base erronée. C'est aussi simple que ça.
J'explique comment fonctionnent les filtres, notamment en tant que parfois simples graphes d'operations GEGL. Il peut ainsi y avoir des opérations de base qui sont codés en C (mais mon atelier ne rentre pas là-dedans). À partir de là, on peut créer d'autres opérations en reliant des opérations existantes.
Le matin, après la conférence où j'ai surtout survolé énormément de sujets théoriques sur la couleur et le traitement d'image (l'idée étant de donner un aperçu du sujet et donner envie d'en savoir/comprendre plus; c'est pas comme si en 2H, on peut vraiment expliquer ce que beaucoup ne comprennent pas complètement après des années à travailler dessus!), on a eu un premier atelier où j'ai montré quelques usages d'effets, notamment en cumulant plusieurs effets. Que ce soit des trucs marrants comme juste "faire un sabre laser" à des trucs qui font plus sérieux comme implémenter de la détection de contours en faisant une simple différence de deux flous gaussiens. Ce qui existe déjà car c'est un usage classique; et l'effet s'appelle étonnamment (ou non! 😜) "difference of gaussians", sauf que dans le cadre de l'atelier, je le "réimplémente" très simplement en appliquant les étapes une par une.
Dans GIMP, comme un utilisateur normal, parce que je pense que même pour un développeur, il est important de voir comment les utilisateurs travaillent réellement pour faire de bons choix (et ne pas voir que l'aspect "code"). Puis on a bougé vers l'outil de "graphe GEGL" où on peut créer des effets en créant des graphes avec une syntaxe textuelle. C'est un super outil pour tester des graphes d'effets très rapidement sans avoir à rentrer dans du code pur et dur dès le début.
L'après-midi, on a fait un peu de code en créant des plug-ins pour GIMP en Python 3 (j'ai fait exprès de choisir Python pour ne pas avoir à se farcir des problèmes de compilation; On veut pas transformer ça en cours sur le C ou les problèmes de build!). Ce n'était pas des plug-ins très complexes, ni forcément pour faire des choses extraordinaires, l'idée était de montrer une logique incrémentale de "comment on modifie une image". Sur un premier plug-in, on a simplement itéré sur chaque pixel du buffer d'un calque. Sur un second, je rajoute une difficulté en montrant que le premier plug-in "casse" si on a un canal alpha (opacité). Puis je passe progressivement à des transformations par graphes d'opérations, d'abord avec une, puis plusieurs, puis en utilisant non plus un seul mais plusieurs calques en entrée dans le graphe, etc. L'idée est de complexifier progressivement et de montrer que c'est finalement assez simple. Il faut juste piger la logique de ce traitement d'image par graphe, comme un flux d'opérations par lequel passe un (ou des) buffer(s) en entrée puis on récupère un buffer en sortie. Ça démystifie aussi beaucoup ce travail de traitement d'images (qui finalement est une des bases de l'informatique de nos jours, puisqu'on met des interfaces graphiques partout).
On mêle à cela quelques pièges intéressants qui montrent que les concepts de modèles et d'espaces de couleur restent toujours en arrière plan de ce type de travail. Un exemple très simple est une simple "inversion" des couleurs. Faire le choix de travailler en linéaire ou non donnera un rendu complètement différent (il n'y a pas de "bon choix", ça dépend vraiment de ce qu'on veut).
En gros, c'est ce genre de trucs. C'était la première fois que je donnais un tel séminaire et ça s'est très bien passé, donc je suis plutôt content de moi. Je pense que c'est une bonne introduction au monde du traitement d'image. Et ce, même si on fait le choix de continuer sans GIMP ni GEGL ensuite. Tout cela reste des concepts et des logiques de traitement d'image classiques que l'on retrouvera dans beaucoup d'autres logiciels/outils/bibliothèques graphiques. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
un profil de couleurs est un jeu de données relatif à un appareil de capture d'image (appareil photo, scanner) ou de production d'image (moniteur, projecteur et écran, imprimante).
Oui. C'est surtout le choix de ton système de coordonnées en fait. En gros, le profile indique les primaires (l'axe et la valeur du 1.0), définit le point blanc et le point noir, et aussi la fonction de transformation entre une valeur de ton système et une luminance typiquement.
Et donc, si je comprends bien, tout ce bordel n'a l'air nécessaire que parce que les fabricants de matériels sont infoutus de fournir des appareils qui acquièrent ou affichent les couleurs de façon fidèle.
Tu peux le décrire ainsi. Mais si c'était si facile de produire des appareils qui affichent des couleurs exactement selon un modèle théorique, on l'aurait déjà fait. Je crois que c'est une vision trop classique de l'industrie où on s'imagine qu'on a un contrôle parfait du monde matériel. Ben la réalité est que non. On sait effectivement créer des petites diodes qui font de la lumière, mais on n'en est pas encore à parfaitement contrôler leur rendu. D'autant plus que selon le matériel utilisé, le fournisseur, les aléas du matériel, et j'en passe, 2 écrans du même modèle de 2 séries différentes seront différents. Que dis-je! 2 écrans de la même série de productions seront différents!
Puis il y a ce qu'on appelle le vieillissement (oui le matériel vieillit aussi et donc change).
Et la lumière ambiante! Ça va aussi impacter grandement ta perception de la couleur! Les gens qui font par exemple du "color grading" pour le cinéma vont travailler dans des salles sans fenêtres (sinon ils devraient refaire la calibration absolument tout le temps), avec des murs "gris milieu" (18% de luminance, puisque c'est à peu près — bien sûr il y a des désaccords mais ça reste en général autour de cette valeur — la valeur qu'on va considérer comme étant perceptuellement le gris le plus au milieu entre le blanc et le noir). Parfait pour la dépression! 😂 Tu peux chercher sur le web des trucs genre "color grading room at home"; de nos jours, on trouve plein de blogs et d'articles où on explique comment reproduire ça chez soi, pour les gens qui veulent vraiment un environnement "pro" chez soi pour le travail de la couleur… et là tu vois que ça s'arrête absolument pas sur ton ordi/écran/imprimante. Ça va bien plus loin.
En plus, avoir un appareil "étalonné en usine" signifie que tu ne peux pas en changer le moindre paramètre. Or certains aiment avoir son écran très lumineux, d'autres faiblement lumineux. Etc. Ben chaque changement de luminosité que tu fais ainsi invalide entièrement ta calibration (tu dois recalibrer). Ton idéal d'appareil étalonné à vie ne marcherait qu'avec des machines non paramétrables.
Et puis, qu'est-ce que le blanc? Hein, dis moi? 😉
Il y a pas mal de réponse à cela, mais une des réponses pourrait être le mélange de l'ensemble des couleurs monochromatiques. Or va créer ça avec un écran! À la place, on se dit, on met toutes les diodes à fond (donc 3 couleurs seulement au final) et on a une approximation acceptable, non? Sauf qu'en plus on disait déjà plus haut que l'on ne contrôle pas le matériel. Et c'est ainsi qu'on se retrouve avec un blanc un peu bleuté ou un peu orangé…
Et maintenant imprime ta couleur blanche et met la sur ton mur blanc?! Whaaaa! Ton blanc n'est pas blanc! En fait, il n'est même plus bleuté/orangé. Pourquoi? Ben ton papier déjà, il est de quelle couleur?! Ah bah oui, parce qu'en plus plus haut, quand tu disais:
on lui donne un papier couvert de sRGB(42, 12, 51)
Donc tu penses que ton sRGB(42, 12, 51) va donc rendre pareil sur tout papier? Tu penses que si tu l'imprimes sur une feuille blanche ("blanche" ahahah) et une noire (pareil ahahah!), ce sera la même couleur?
Alors déjà laisse moi corriger une grosse erreur dans ta croyance sur la calibration d'imprimante: on ne calibre pas une imprimante! On calibre… un couple (imprimante, papier)! Ben oui, selon le papier que tu utilises (le modèle, la marque, etc.), tu dois recalibrer. Oups, petit oubli: en fait tu calibres pour le triplet (imprimante, papier, encres)! (ben oui, encres différentes == différentes couleurs, tu peux aussi prendre des compatibles, etc. Et si en plus tu mélanges les cartouches entre 2 fabricants! Tu multiplies les cas!)
Donc non, ça c'est juste pas possible:
Pareil pour une imprimante, j'imagine bien une machine étalonnée d'avance pour que, quand on lui donne un aplat sRGB(42, 12, 51) (oui, du RGB, pas du CMJN, le fait d'utiliser quatre couleurs c'est son affaire, pas celle de l'utilisateur !), crache une feuille avec exactement ça dessus.
Hormis si tu veux que l'usine achète tous les papiers de tous les fabricants du monde, de même toutes les encres du monde, puis calibre l'imprimante avec chacun de ces papiers et encres et fournissent une énorme base de données de tous ces profils où le client mettrait la référence du papier et des encres pour récupérer le profil idéal. Ajoute à cela que tu dois refaire cela à chaque série de production (comme je disais: variation légère du matériel, des fournisseurs, du processus d'usinage qui évolue ou que sais-je!). Et tu te retrouves avec un truc juste impossible à faire… pour en plus avoir un profil générique qui n'est pas adapté exactement à ton imprimante.
Mais revenons à nos moutons: qu'est-ce que le blanc? Puisqu'on a rarement du blanc parfait — et encore ce concept existe-t-il même vraiment? — le blanc est surtout une vue de l'esprit. Tu vas surtout choisir ce qu'est le blanc. Oui toi. Typiquement, tu vas décider que ton mur est blanc (bon je vais supposer cela, ne pas me prendre au mot et me dire que non, si tu as décidé de peindre ta chambre en bleu ou autre! 😜)! Ben oui, quand t'as acheté ta peinture, y avait bien écrit blanc sur le pot de peinture. "Blanc c'est blanc" quoi!
Donc voilà, tu as décidé que ton mur est blanc. Et c'est là que tu mets une peinture à fond blanc… et tu te rends compte qu'elle jure complètement avec ton mur! Forcément, le peintre a tort: ton mur est blanc, tu l'as lu sur le pot!
Ajoute à cela la lumière! Comme la plupart des cas, ta lumière est un peu jaunâtre. Donc que se passe-t-il quand ta lumière se reflète sur ton mur blanc? Ben ton blanc est un peu jaunâtre! Et puis y a la couleur du soleil. Il se trouve que le soleil a une couleur plutôt jaune (bon le regardez pas trop longtemps! 😎). Mais qu'à cela ne tienne, ton mur est blanc! Tu l'as décidé. Et pourtant quand tu compareras tes couleurs, tu auras un rendu différent. Je ne parle même pas juste du blanc, mais bien de toutes les couleurs. Revenons à nos moutons 🐑 blancs… enfin non à nos écrans, quoi! Et compare la même image sur ton écran bien calibré avec une impression. Mais quelque chose ne va pas! C'est parce que le point blanc est différent (possiblement! Y a plein d'autres raisons possibles!). Quand tu regardes dans ton petit monde numérique, tu as choisi un point blanc géré par le profil de ton écran, mais dans ton petit monde physique, tu as choisi un point blanc parce que ton cerveau aura décidé que ton mur est blanc. Or pas de bol, ton mur est pas le même blanc. Et la comparaison fait que tu vois les couleurs différemment!
La problématique de comparaison des couleurs est une véritable mine d'or pour les illusions d'optiques. J'en montre quelques exemples dans mes confs aussi d'ailleurs. Y a des trucs vraiment marrants. C'est pas pour rien que la perception des couleurs est une science à part entière et un champs de travail énorme depuis plus d'un siècle.
Enfin bon, c'est donc bien pour cela qu'il y a tout ce foin autour du choix de "quel point blanc choisir pour la calibration de mon écran?" Typiquement pour les gens dont l'œuvre sera sur écran (cinéma, TV…), l'industrie s'est plutôt décidé pour l'illuminant D65 comme point blanc. Mais ceux qui impriment (photographes, peintres numériques, packaging…) vont plutôt viser l'illuminant D50 qu'on va considérer être proche de la lumière du jour vers midi. Certains vont ainsi calibrer leur écran avec point blanc en D50 quand d'autres vont le calibrer en D65. Il y a aussi ceux qui vont te dire d'utiliser le "blanc natif" de ton écran. De toutes façons, certains vont conseiller de ne surtout pas comparer les couleurs sur l'écran et sur papier côte à côte, ce qui permet même de calibrer ton écran en D65 comme tout le monde. Ne pas faire de comparaison directe permet à tes yeux de leur donner le temps de se recalibrer à chaque fois (oui le cerveau est très fort! Il se recalibre de lui-même en fonction du blanc choisi). Et ainsi on peut comparer quand même les couleurs, il faut juste ne pas les regarder en même temps!
Etc. Etc. Etc.
Quoiqu'il en soit, le coup du "calibré en usine", c'est un bon discours marketing (je dis pas ça au hasard, ce que tu proposes, les constructeurs aiment bien le dire sur leurs modèles d'écran les plus chers justement; ça n'empêche pas les gens de calibrer parce que le discours marketing vaut ce qu'il vaut!) mais comme tu le vois, ça ne veut à peu près rien dire en réalité.
Je sais que c'est plus compliqué que ça, en particulier parce que les différents périphériques sont capables d'acquérir ou de sortir des couleurs dans des gamuts plus ou moins étendus
L'histoire du gamut, c'est le truc que beaucoup de gens vont sortir parce qu'ils ne comprennent pas grand chose de plus. Mais dans la vraie vie, pas tout le monde n'a besoin de faire plein d'images avec des couleurs super-pêtantes de partout.
Le vrai but, c'est surtout d'avoir un standard de représentation des couleurs. Ce qu'on voit sur son écran, on veut voir la même chose sur un autre écran. De même qu'on veut voir la même chose qu'on en imprime. Etc. C'est surtout cela la vraie raison de la gestion des couleurs. On veut pouvoir faire plus ou moins confiance en ce qu'on voit. Beaucoup d'artistes/graphistes passent un temps fou à choisir les couleurs qu'ils veulent. C'est pas pour avoir des couleurs aléatoires au final!
Et pour ça faut calibrer. Et surtout faut adapter à son environnement et son besoin précis.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Loupé
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien La récursivité sur linuxfr. Évalué à 5. Dernière modification le 18 août 2023 à 15:16.
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 ]
[^] # Re: 🙄
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Sortie de darktable 4.4.0, non, 4.4.1, pardon, 4.4.2. Évalué à 9.
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é.
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? 😉
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 ]
[^] # Re: Loupé
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien La récursivité sur linuxfr. Évalué à 9. Dernière modification le 18 août 2023 à 13:23.
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
musttaildans 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.
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 ]
# 🙄
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Sortie de darktable 4.4.0, non, 4.4.1, pardon, 4.4.2. Évalué à 10. Dernière modification le 18 août 2023 à 12:15.
Emphase rajoutée dans ce commentaire:
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":
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 ]
[^] # Re: mouais
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien Desktop Linux has a Firefox problem. Évalué à 10.
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 ]
[^] # Re: Pourquoi attendre pour publier une version 3.0 ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Sortie de GIMP 2.99.16 : édition Wilber Week 2023 !. Évalué à 10.
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).
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):
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:
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! 😄 (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 ]
# C'est quoi cette fondation?
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien Overture Maps Foundation Releases Its First World-Wide Open Map Dataset. Évalué à 10.
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:
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:
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 ]
[^] # Re: Natural Language Generation
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Wikifunctions est le nouveau projet de le fondation Wikimedia, un wiki de fonctions éditables par . Évalué à 9.
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 ]
[^] # Re: UI
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Sortie de GIMP 2.99.16 : édition Wilber Week 2023 !. Évalué à 4.
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 ]
[^] # Re: UI
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Sortie de GIMP 2.99.16 : édition Wilber Week 2023 !. Évalué à 10. Dernière modification le 26 juillet 2023 à 21:49.
Salut,
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:
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.
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.
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à. 🤔
Ç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. :-)
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]
[États Unis]
[Pologne]
[Argentine]
[Équateur]
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]
[États Unis]
💌
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Vous pratiquez le JPEG2000 sans le savoir
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Des formats d'image. Évalué à 3.
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 ]
[^] # Re: Avis sur HEIF
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Des formats d'image. Évalué à 3.
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 ]
[^] # Re: Avis sur HEIF
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Des formats d'image. Évalué à 6.
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:
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.heicen 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
libheifet désactivaient entièrement notre plug-infile-heifdans 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
libheifqui ne contienne que les codecs de compression et décompression pour AVIF (puisque cette bibliothèque est aussi modulaire). Notre plug-infile-heiffaisant 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 ]
[^] # Re: Format ouvert et spécifications ouvertes
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Des formats d'image. Évalué à 4.
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.
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 ]
[^] # Re: Vous pratiquez le JPEG2000 sans le savoir
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Des formats d'image. Évalué à 4.
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 ]
[^] # Re: radical
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien Des robots tueurs de chats sauvages en Australie. Évalué à 5.
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:
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 ]
# Github, c'est tout cassé!
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien Gimp 2.99.16 (développement) vient de sortir. Évalué à 10.
Ton lien est cassé et m'indique:
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 ]
[^] # Re: Ah bon ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien « 95% des projets NFT ne valent plus rien » : après l’emballement, la désillusion. Évalué à 3. Dernière modification le 07 juin 2023 à 11:41.
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 ]
[^] # Re: sympa
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Opensara? Plop ! Plop !. Évalué à 4.
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 ]
[^] # Re: sympa
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Opensara? Plop ! Plop !. Évalué à 7.
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).
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 ]
[^] # Re: sympa
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Opensara? Plop ! Plop !. Évalué à 10.
Pour être tout à fait franc, j'y ai pensé à diverses reprises en voyant les news de devnewton. Pourquoi pas faire un petit jeu libre ensemble? Quelqu'un qui a de l'expérience côté développement de jeux libres, a un peu de bouteille (même si je suis pas à fond sur les choix techniques — a.k.a. java! 😱 — mais bon si je suis pas le dév principal, alors je suis d'avis de suivre les choix de ce dernier) et en plus est en faveur des licences libres…
Ensuite j'ai jamais voulu commenter sur cela, parce que je veux pas m'avancer.
Quoi qu'il en soit, quand on finira notre pilote, on va sûrement faire un autre projet, et pas continuer ZeMarmot car on a visé trop gros en qualité/durée, donc temps de production, relativement aux fonds qu'on est capable de lever (c'est à dire que si on avait été capable de lever 20 fois plus, alors on aurait pu engager des gens et là ça aurait marché mieux; mais à 2, on passe des années à s'épuiser, à déprimer, etc.).
Pour notre prochain projet:
En gros, c'est une possibilité tout à fait envisageable et qui perso m'intéresserait bien. Je pourrais imaginer qu'on organise un projet de petit jeu libre avec tout (code et art) sous licences libres. Si en plus, on peut le faire le plus multi-plateforme possible (notamment les OS téléphones pour suivre la mode?!), ce serait cool. Mais comme je disais plus haut, je veux pas m'avancer non plus. Aryeom doit aussi être d'accord pour un tel projet déjà. Et puis comme le temps est limité, on préférerait peut-être s'orienter vers un autre projet.
Mais c'est tout à fait discutable (ça ne coûte rien de discuter un peu pour voir si on peut faire un truc cool ensemble et surtout si on aime les mêmes genres et si on a les mêmes attentes), si jamais devnewton veut nous contacter. 😉
P.S.: et pour le son, on a aussi des musiciens à recommander qui sont professionnels de leur art tout en étant aussi à fond sur les licences libres. On peut donc faire un jeu 100% libre sans problème.
P.P.S.: m'en veuillez pas pour le petit lancement de troll sur Java plus haut. Faut bien égayer un peu ses weekends!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Une de mes plus anciennes contributions au logiciel libre
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Wesnoth : Il y a mille façons de contribuer.... Évalué à 7.
Battle for Wesnoth fut parmi mes plus anciennes contributions sur un logiciel libre. J'ai traduit le scénario tutoriel en français (à l'époque, de mémoire, ce n'était pas du tout traduit, ou bien quasiment pas; je sais plus trop).
On retrouve encore mon nom dans les "attributions" de la traduction française: https://wiki.wesnoth.org/Credits (certains remarqueront que le nom de famille n'est pas le mien, mais c'était un pseudo; le prénom est le même! 😉).
Souvenirs souvenirs…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Gestion des couleurs et capture
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.34 est sorti. Évalué à 10.
Sommaire
J'avais fait une longue réponse y a 10 jours où j'essayais de répondre à tes divers points. Je l'ai encore, mais je ne vais pas la poster. La raison est que je crois que tu t'es totalement embrouillé dans la base même de ta logique, donc si j'essaie de répondre à tes questions qui partent sur des incompréhensions à la base, ma réponse ne peut que t'embrouiller encore plus.
Le problème est évident dès ta seconde phrase:
Puis ensuite tu fais toute une argumentation sur cette base. En gros, tu commences en acceptant la problématique de base qui est que les données de couleur que tu reçois sont fausses… puis tu nous dis plus ou moins par la suite "mais faisons abstraction de cela, je comprends pas pourquoi les couleurs finales seront fausses". Tu vois le problème, j'espère?
Je vais donc faire une réponse plus généraliste sur ce que je pense être tes incompréhensions de base:
Notre contexte: logiciels de graphisme
Déjà tu sembles croire que juste passer des valeurs RGB sans profil marche, puisqu'après tout, tous les logiciels s'affichent bien! Or c'est faux. Ça marchouille pour le cas général où on ne fait pas attention aux couleurs. Et oui, c'est le cas d'une majorité des gens et des logiciels. On s'en fiche peut-être du gris utilisé dans l'interface graphique de son logiciel de calendrier, voire même du rendu de son traitement de texte (même si on a quelques images, ce n'est pas forcément le point central du document et je peux comprendre que dans pas mal de cas, on accepte les couleurs approximatives) ou tout logiciel de bureautique.
Dans cet article, on parle du cas des gens qui font attention aux couleurs: les graphistes, photographes, peintres numérique. Donc déjà, faut se mettre dans ce contexte. Ce n'est pas une dépêche sur LibreOffice. C'est une dépêche sur GIMP.
[Note: néanmoins dans la réalité, tout logiciel devrait aussi gérer au mieux les couleurs — et probablement les plus gros, tels que LibreOffice, le font-ils —; d'ailleurs même les navigateurs web s'y sont mis; mon propos n'est donc pas de dire que cela devrait être uniquement l'apanage des logiciels de graphisme, mais que je peux comprendre que certains ne voient pas autant le besoin absolu pour les logiciels de bureautique; par contre quand on parle de logiciel de graphisme, ce ne devrait même pas être en question]
Dans notre contexte précis donc, les gens ne veulent pas que "ça marchouille", ils veulent que "ça marche", ou du moins, au mieux (car malheureusement c'est un sujet complexe et même quand on fait au mieux, ce n'est en général pas parfait pour autant).
Élargissons tout de même le contexte (histoire de)
Ensuite même si on change de contexte et qu'on prenait le cas du grand public, on se rend compte que le "ça marchouille" n'est pas vrai même dans ce cas. Il est presque vrai uniquement quand on prend les écrans basiques. Mais dès qu'on prend par exemple des écrans avec des gamuts "natifs" très différents du cas plus général, les couleurs deviennent vraiment cassées. Et ça reste un cas très général, car beaucoup de gens de nos jours vont acheter des écrans ou télés à gamut large dès qu'ils ont un peu de moyens (parce que le marketing leur dit "c'est mieux"). En fait, c'est même pire que ça: je lisais encore il y a quelques jours que beaucoup de constructeurs vont avoir exprès des mauvaises configurations de base pour faire pêter les couleurs et ainsi faire ressortir d'autant plus leur modèle sur les étalages. Quiconque a déjà vu des écrans de télé aux supermarché sait de quoi je parle: les vendeurs passent en général la même vidéo sur tous les écrans simultanément. Or avez-vous déjà comparé les couleurs sur tous les écrans? Est-ce les mêmes couleurs d'après vous d'un écran à l'autre? Ben non, en général, les couleurs sont méchamment différentes d'une télé à l'autre et malheureusement très souvent, certains vont même avoir tendance à choisir la télé qui rend les couleurs les plus pêtantes, comme si c'était une preuve de qualité (astuce: ce n'est pas le cas! La qualité serait d'avoir les couleurs telles que les créateurs les ont choisies!).
Sur la base de cette constatation, on peut ainsi revoir son appréciation même du "ça marchouille" (et le "ça marche", n'en parlons pas!).
En fait le processus marketing de nos jours est tellement absurde que les constructeurs font tout pour que leurs écrans aient des couleurs qui puissent ressortir le plus parmi les concurrents sur les étalages. En conclusion, ils font tout pour que les couleurs soient les plus mauvaises possible parce que ça se vendra mieux! La logique commerciale est en fait qu'il faut que l'écran "se démarque", ce qui signifie montrer des couleurs différentes. Alors que la logique du graphiste, c'est justement l'inverse, qu'il ne faut absolument pas qu'un écran se démarque! Ce que vous voulez, c'est que tous vos écrans montrent les mêmes couleurs. Que l'écran du collègue aussi montre les couleurs que vous avez sur le votre. Que l'écran du public qui verra votre œuvre montre encore les mêmes couleurs. Que le mélange d'encre lors d'une impression ressemble aux couleurs sur votre écran. Etc.
Si vous cherchez "wide gamut screen saturated colors" sur votre moteur de recherche web préféré, vous verrez l'ampleur du problème. C'est un problème majeur que la plupart des gens qui achètent ce type d'écran ont de nos jours.
Notons encore que ce n'est même pas juste quelque chose de nouveau, qui serait arrivé avec les écrans large gamut. L'exemple historique le plus flagrant est: le matos/OS Apple! Quand les gens ne calibraient pas leurs écrans (ce qui était le cas de la majorité, même des professionnels du graphisme je pense, il y a 20 ans — j'y étais pas mais je vois bien que l'industrie a commencé réellement à appliquer les principes colorimétriques modernes il y a une quinzaine d'années environ), la calibration par défaut des écrans appliquait un gamma de 1.8 chez Apple alors qu'il était de 2.2 pour le reste de l'industrie. C'était le cas jusqu'à environ 2009/2010. Et c'est pourquoi à l'époque, les gens se plaignaient constamment de différences de couleur en passant une image de macOS à tout autre système (Windows, Linux, etc.). L'image était beaucoup plus sombre sur macOS.
La raison de pourquoi Apple étaient les seuls à utiliser 1.8 est une histoire ridicule de matériel qui illustre tout à fait ce que je disais sur un autre commentaire sur l'industrie qui a fait erreur sur erreur.
Et la raison pour laquelle ils sont passés à 2.2 est uniquement pour ce que tu proposes: afin de pouvoir enfin "marchouiller" en faisant comme tout le monde. Mais il faut bien comprendre que ce n'est pas une solution pour autant. Ça fait juste des différences moins flagrantes mais ça n'est pas de la gestion de couleur pour autant.
D'ailleurs ce problème ne changeait le résultat que pour les gens qui ne calibraient pas leurs écrans ou avaient des logiciels qui ne géraient pas les profils de couleurs ou travaillaient sur des images sans profil. Pour ceux qui cochaient déjà ces 3 conditions, ce changement de gamma ne les impactaient pas (et ils n'avaient pas le problème de couleurs plus sombres en passant d'un ordi Windows/Linux à OSX). C'est bien ça qu'il faut comprendre: ce genre de choix absolus n'impactent que les setups qui ne font pas de gestion de couleur, parce que non, ça ne marche pas par défaut en réalité.
Le but de la gestion des couleurs: des couleurs justes et une référence
Je vois bien que tu parles du contexte où aucun logiciel ne gère les couleurs, où on ne travaille que sur des images sRGB (ou sans profil, ce qui en général est équivalent… ou pas! Comme le montre le cas Apple!), où l'écran n'est pas calibré et où on ne travaille que sur un seul écran: oui, si tu prends une couleur sur l'écran ou sur une image, que tu la remontres sur le même écran en réutilisant le triplet RGB tel quel, ça fonctionnera (dans un sens très limité du verbe "fonctionner"). Disons que dans ce cas un peu particulier, tu n'as pas à te soucier de la couleur, tu passes les données en entrée et en sortie sans y appliquer de sémantique en te disant que de toutes façons l'entrée et la sortie sont le même périphérique. Mais si jamais l'entrée et la sortie sont différents, ou simplement si à n'importe quel point intermédiaire du flot de travail, on a besoin de gérer la couleur (c'est à dire si on passe par un logiciel comme GIMP qui va permettre de réutiliser la couleur dans diverses images qui peuvent avoir toute sorte de profil et donc on a besoin de "comprendre" cette couleur, lui donner un sens, et pas juste la faire traverser sans la traiter), ben tu ne peux pas te passer de la sémantique de ta couleur.
Encore une fois, on parle du cas des professionnels ou amateurs éclairés du graphisme. Ces personnes veulent pouvoir travailler sur plus que du sRGB d'une part.
D'autre part, je rappelle que le but de la calibration est qu'on veut pouvoir comparer les couleurs sur plusieurs systèmes de sortie, pas juste son unique écran à soi. Typiquement c'est parce qu'on crée des œuvres à partager. Pour les gens qui font des œuvres numériques (illustrations, photographies, films…), cela peut signifier plusieurs écrans: si on choisit des couleurs, on aimerait que la couleur reste la même sur l'écran des autres.
Alors certes, là tu vas me dire: oui mais on l'a bien vu, les écrans du grand public ne gèrent de toutes façons pas les couleurs correctement! Mais alors imagine si tu (en tant qu'auteur) as un écran qui vire vers le bleu par exemple. Et tu choisis tes couleurs ainsi. Donc comme ton écran tire sur le bleu, tu choisiras des couleurs d'autant plus dans le rouge et le vert sans même t'en rendre compte (pour compenser ce que tu vois à l'écran). Imagine maintenant que ceux qui regardent ont des écrans qui tirent déjà vers le vert et rouge. Et en plus toi, tu leur donnes à regarder des images qui ont déjà (par erreur) une teinte rougeâtre/verdâtre! Les erreurs s'additionnent. Ils verront des couleurs totalement saturées.
En gros, il te faut tout de même une référence pour ne pas accumuler les erreurs (tu ne peux certes pas contrôler les écrans de ton public, mais le tien au moins, tu peux le contrôler!).
Pour le cas où on veut imprimer: il faut pouvoir avoir un minimum de similarités entre les couleurs. Tu vas pas réimprimer ton truc 20 fois.
Il y a aussi le cas où tu travailles avec d'autres. Dans ce cas, tout le monde calibre ses périphériques de sortie pour travailler sur les mêmes couleurs. Imagine que la personne qui fait du color grading, qui a fait sur mesure sa grande salle spéciale sans fenêtre, avec des murs repeints en "gris milieu" et son matos hors de prix… cette personne qui a fait tout ces efforts et a dépensé vraisemblablement des dizaines de milliers d'euros dans ce setup ne calibrait pas son écran et se disait que travailler avec les couleurs natives approximatives suffisait. Comme toi, il se dit qu'il travaille avec un "triplet RGB qui ne veut rien dire sans profil de couleur. Soit." Soit? Est-ce vraiment un lemme acceptable pour la base de son travail de couleur?
Et il envoie son résultat à ses collègues qui feraient de même. Je veux dire, on est d'accord que ce serait extrêmement ridicule d'aller si loin dans la création d'un environnement idéalement neutre pour travailler les couleurs, tout ça pour au final afficher n'importe quoi, non? 😉 Est-ce que tu penses vraiment que ce lemme de base "triplet RGB qui ne veut rien dire sans profil de couleur. Soit." est acceptable?
Il faut donc revoir ton lemme de base, et à partir de là, tu comprendras que l'ensemble de ton commentaire est inutile (au sens "faux", pas inutile dans le contexte de la conversation, d'ailleurs je n'ai pas cliqué sur "inutile" et personne l'a fait, à ce que je vois 😜). Tu ne peux juste pas faire une argumentation qui fonctionne sur une base erronée. C'est aussi simple que ça.
Si tu veux suivre un peu l'avancée du travail pour la gestion des couleurs dans Wayland, tu peux regarder le travail en cours sur le color management protocol ou l'implémentation de référence.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Fonctions non bijectives
Posté par Jehan (site web personnel, Mastodon) . En réponse au message De la gestion de couleurs. Évalué à 8. Dernière modification le 09 mai 2023 à 23:11.
C'était un atelier où:
En gros, c'est ce genre de trucs. C'était la première fois que je donnais un tel séminaire et ça s'est très bien passé, donc je suis plutôt content de moi. Je pense que c'est une bonne introduction au monde du traitement d'image. Et ce, même si on fait le choix de continuer sans GIMP ni GEGL ensuite. Tout cela reste des concepts et des logiques de traitement d'image classiques que l'on retrouvera dans beaucoup d'autres logiciels/outils/bibliothèques graphiques. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Petite réponse
Posté par Jehan (site web personnel, Mastodon) . En réponse au message De la gestion de couleurs. Évalué à 9.
Oui. C'est surtout le choix de ton système de coordonnées en fait. En gros, le profile indique les primaires (l'axe et la valeur du 1.0), définit le point blanc et le point noir, et aussi la fonction de transformation entre une valeur de ton système et une luminance typiquement.
Tu peux le décrire ainsi. Mais si c'était si facile de produire des appareils qui affichent des couleurs exactement selon un modèle théorique, on l'aurait déjà fait. Je crois que c'est une vision trop classique de l'industrie où on s'imagine qu'on a un contrôle parfait du monde matériel. Ben la réalité est que non. On sait effectivement créer des petites diodes qui font de la lumière, mais on n'en est pas encore à parfaitement contrôler leur rendu. D'autant plus que selon le matériel utilisé, le fournisseur, les aléas du matériel, et j'en passe, 2 écrans du même modèle de 2 séries différentes seront différents. Que dis-je! 2 écrans de la même série de productions seront différents!
Puis il y a ce qu'on appelle le vieillissement (oui le matériel vieillit aussi et donc change).
Et la lumière ambiante! Ça va aussi impacter grandement ta perception de la couleur! Les gens qui font par exemple du "color grading" pour le cinéma vont travailler dans des salles sans fenêtres (sinon ils devraient refaire la calibration absolument tout le temps), avec des murs "gris milieu" (18% de luminance, puisque c'est à peu près — bien sûr il y a des désaccords mais ça reste en général autour de cette valeur — la valeur qu'on va considérer comme étant perceptuellement le gris le plus au milieu entre le blanc et le noir). Parfait pour la dépression! 😂 Tu peux chercher sur le web des trucs genre "color grading room at home"; de nos jours, on trouve plein de blogs et d'articles où on explique comment reproduire ça chez soi, pour les gens qui veulent vraiment un environnement "pro" chez soi pour le travail de la couleur… et là tu vois que ça s'arrête absolument pas sur ton ordi/écran/imprimante. Ça va bien plus loin.
En plus, avoir un appareil "étalonné en usine" signifie que tu ne peux pas en changer le moindre paramètre. Or certains aiment avoir son écran très lumineux, d'autres faiblement lumineux. Etc. Ben chaque changement de luminosité que tu fais ainsi invalide entièrement ta calibration (tu dois recalibrer). Ton idéal d'appareil étalonné à vie ne marcherait qu'avec des machines non paramétrables.
Et puis, qu'est-ce que le blanc? Hein, dis moi? 😉
Il y a pas mal de réponse à cela, mais une des réponses pourrait être le mélange de l'ensemble des couleurs monochromatiques. Or va créer ça avec un écran! À la place, on se dit, on met toutes les diodes à fond (donc 3 couleurs seulement au final) et on a une approximation acceptable, non? Sauf qu'en plus on disait déjà plus haut que l'on ne contrôle pas le matériel. Et c'est ainsi qu'on se retrouve avec un blanc un peu bleuté ou un peu orangé…
Et maintenant imprime ta couleur blanche et met la sur ton mur blanc?! Whaaaa! Ton blanc n'est pas blanc! En fait, il n'est même plus bleuté/orangé. Pourquoi? Ben ton papier déjà, il est de quelle couleur?! Ah bah oui, parce qu'en plus plus haut, quand tu disais:
Donc tu penses que ton sRGB(42, 12, 51) va donc rendre pareil sur tout papier? Tu penses que si tu l'imprimes sur une feuille blanche ("blanche" ahahah) et une noire (pareil ahahah!), ce sera la même couleur?
Alors déjà laisse moi corriger une grosse erreur dans ta croyance sur la calibration d'imprimante: on ne calibre pas une imprimante! On calibre… un couple
(imprimante, papier)! Ben oui, selon le papier que tu utilises (le modèle, la marque, etc.), tu dois recalibrer. Oups, petit oubli: en fait tu calibres pour le triplet(imprimante, papier, encres)! (ben oui, encres différentes == différentes couleurs, tu peux aussi prendre des compatibles, etc. Et si en plus tu mélanges les cartouches entre 2 fabricants! Tu multiplies les cas!)Donc non, ça c'est juste pas possible:
Hormis si tu veux que l'usine achète tous les papiers de tous les fabricants du monde, de même toutes les encres du monde, puis calibre l'imprimante avec chacun de ces papiers et encres et fournissent une énorme base de données de tous ces profils où le client mettrait la référence du papier et des encres pour récupérer le profil idéal. Ajoute à cela que tu dois refaire cela à chaque série de production (comme je disais: variation légère du matériel, des fournisseurs, du processus d'usinage qui évolue ou que sais-je!). Et tu te retrouves avec un truc juste impossible à faire… pour en plus avoir un profil générique qui n'est pas adapté exactement à ton imprimante.
Mais revenons à nos moutons: qu'est-ce que le blanc? Puisqu'on a rarement du blanc parfait — et encore ce concept existe-t-il même vraiment? — le blanc est surtout une vue de l'esprit. Tu vas surtout choisir ce qu'est le blanc. Oui toi. Typiquement, tu vas décider que ton mur est blanc (bon je vais supposer cela, ne pas me prendre au mot et me dire que non, si tu as décidé de peindre ta chambre en bleu ou autre! 😜)! Ben oui, quand t'as acheté ta peinture, y avait bien écrit blanc sur le pot de peinture. "Blanc c'est blanc" quoi!
Donc voilà, tu as décidé que ton mur est blanc. Et c'est là que tu mets une peinture à fond blanc… et tu te rends compte qu'elle jure complètement avec ton mur! Forcément, le peintre a tort: ton mur est blanc, tu l'as lu sur le pot!
Ajoute à cela la lumière! Comme la plupart des cas, ta lumière est un peu jaunâtre. Donc que se passe-t-il quand ta lumière se reflète sur ton mur blanc? Ben ton blanc est un peu jaunâtre! Et puis y a la couleur du soleil. Il se trouve que le soleil a une couleur plutôt jaune (bon le regardez pas trop longtemps! 😎). Mais qu'à cela ne tienne, ton mur est blanc! Tu l'as décidé. Et pourtant quand tu compareras tes couleurs, tu auras un rendu différent. Je ne parle même pas juste du blanc, mais bien de toutes les couleurs. Revenons à nos moutons 🐑 blancs… enfin non à nos écrans, quoi! Et compare la même image sur ton écran bien calibré avec une impression. Mais quelque chose ne va pas! C'est parce que le point blanc est différent (possiblement! Y a plein d'autres raisons possibles!). Quand tu regardes dans ton petit monde numérique, tu as choisi un point blanc géré par le profil de ton écran, mais dans ton petit monde physique, tu as choisi un point blanc parce que ton cerveau aura décidé que ton mur est blanc. Or pas de bol, ton mur est pas le même blanc. Et la comparaison fait que tu vois les couleurs différemment!
La problématique de comparaison des couleurs est une véritable mine d'or pour les illusions d'optiques. J'en montre quelques exemples dans mes confs aussi d'ailleurs. Y a des trucs vraiment marrants. C'est pas pour rien que la perception des couleurs est une science à part entière et un champs de travail énorme depuis plus d'un siècle.
Enfin bon, c'est donc bien pour cela qu'il y a tout ce foin autour du choix de "quel point blanc choisir pour la calibration de mon écran?" Typiquement pour les gens dont l'œuvre sera sur écran (cinéma, TV…), l'industrie s'est plutôt décidé pour l'illuminant D65 comme point blanc. Mais ceux qui impriment (photographes, peintres numériques, packaging…) vont plutôt viser l'illuminant D50 qu'on va considérer être proche de la lumière du jour vers midi. Certains vont ainsi calibrer leur écran avec point blanc en D50 quand d'autres vont le calibrer en D65. Il y a aussi ceux qui vont te dire d'utiliser le "blanc natif" de ton écran. De toutes façons, certains vont conseiller de ne surtout pas comparer les couleurs sur l'écran et sur papier côte à côte, ce qui permet même de calibrer ton écran en D65 comme tout le monde. Ne pas faire de comparaison directe permet à tes yeux de leur donner le temps de se recalibrer à chaque fois (oui le cerveau est très fort! Il se recalibre de lui-même en fonction du blanc choisi). Et ainsi on peut comparer quand même les couleurs, il faut juste ne pas les regarder en même temps!
Etc. Etc. Etc.
Quoiqu'il en soit, le coup du "calibré en usine", c'est un bon discours marketing (je dis pas ça au hasard, ce que tu proposes, les constructeurs aiment bien le dire sur leurs modèles d'écran les plus chers justement; ça n'empêche pas les gens de calibrer parce que le discours marketing vaut ce qu'il vaut!) mais comme tu le vois, ça ne veut à peu près rien dire en réalité.
L'histoire du gamut, c'est le truc que beaucoup de gens vont sortir parce qu'ils ne comprennent pas grand chose de plus. Mais dans la vraie vie, pas tout le monde n'a besoin de faire plein d'images avec des couleurs super-pêtantes de partout.
Le vrai but, c'est surtout d'avoir un standard de représentation des couleurs. Ce qu'on voit sur son écran, on veut voir la même chose sur un autre écran. De même qu'on veut voir la même chose qu'on en imprime. Etc. C'est surtout cela la vraie raison de la gestion des couleurs. On veut pouvoir faire plus ou moins confiance en ce qu'on voit. Beaucoup d'artistes/graphistes passent un temps fou à choisir les couleurs qu'ils veulent. C'est pas pour avoir des couleurs aléatoires au final!
Et pour ça faut calibrer. Et surtout faut adapter à son environnement et son besoin précis.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]