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 ]
Les transformations entre la plupart des modèles de couleur sont bien bijectives. De même que les transformations entre espaces de couleur (si on travaille en flottant). Il s'agit de bête calcul de matrice 3×3 dans un sens, et son inverse dans l'autre.
Vous remarquerez d'ailleurs que tous ces modèles ont 3 axes, ce n'est pas un hasard. Les recherches ont simplement montré que l'on peut reproduire l'ensemble des couleurs avec 3 primaires. Le "jeu" est donc simplement de choisir des primaires/axes appropriées et c'est la raison principale pour laquelle il existe divers modèles et divers espaces.
Il y eut ainsi le moment où on a essayé de faire des modèles plus proches de "comment l'humain perçoit les couleurs", ce qui a donné les HSV et HSL. Mais on s'est rendu compte que ces modèles n'étaient pas si bons mathématiquement (même s'ils restent utilisés et sont intéressants, notamment quelques outils colorimétriques dans GIMP se basent sur ces modèles, en terme d'UX).
Les gens ont alors cherché à voir les couleurs en 2D, ce qui a donné le modèle xyY, qui permet le fameux diagramme en fer à cheval où on représente les espaces de couleurs, en ignorant l'axe Y. En effet dans ce modèle, on représente entièrement les teintes (c'est à dire la perception des couleurs telles qu'on les nomme) sur un plan avec les axes xy, et l'axe Y ne représente que la luminance sans impacter la perception de teinte. On peut ainsi s'imaginer les "variations" d'une même couleur où on ne change que la luminance sur l'axe perpendiculaire au papier/à l'écran. Ce modèle a d'ailleurs quelques propriétés intéressantes, comme le fait que tout mélange de 2 couleurs se trouve sur le segment entre les 2 points. C'est pourquoi on arrive à représenter tout espace de couleur comme un triangle sur le plan 2D xy.
Mais ce type de modèle a aussi des problèmes, par exemple la non-uniformité perceptuelle (certaines couleurs très proches sur ce modèle ont l'air très différentes alors que sur d'autres zones, des couleurs éloignées ont l'air identiques). Les gens ont alors essayé de faire des modèles perceptuellement uniformes (ou presque), ce qui a donné les CIELAB et surtout CIELUV.
Et ainsi de suite. Mais le fait est qu'hormis la création de modèle pour satisfaire des buts/usages particuliers, les couleurs sont entièrement et très aisément transformables d'un modèle à l'autre.
La raison pour laquelle il pourra y avoir une très légère différence du résultat dans un A/R entre 2 modèles serait l'imprécision mathématique d'un processeur. Mais bon, si on ne fait qu'un A/R, la perte est probablement trop minime pour s'en préoccuper (ce serait moins le cas si on code ça sur 8-bit, ce pourquoi notamment il est conseillé de travailler en flottant de nos jours pour le travail graphique). Hormis ce point de limitation technique, si, mathématiquement les transformations sont théoriquement bijectives, sans perte, hormis si on décidait d'écrêter en dehors de [0; 1], c'est à dire hors du gamut d'un espace de couleur. Sauf que justement l'un des autres grands avantages du travail en flottant est qu'on évite d'écrêter lors d'étapes intermédiaires permettant réellement de travailler presque sans perte, et en plus très simplement (calcul de multiplication de matrice basique, niveau lycée).
Ensuite quand je disais dans mon paragraphe d'intro que c'est vrai pour "la plupart des modèles de couleur", c'est parce que certains modèles sont basés sur des logiques physiques différentes. Je parle de CMYK. Un passage RGB🔄CMYK n'est effectivement pas bijectif (il n'est pas impossible de tomber sur des valeurs assez différentes lors d'un A/R entre les 2 modèles).
Et sans compter les "couleurs" de type "couleurs métalliques" ou "couleurs fluorescentes", etc. Bien sûr, selon une théorie de couleur pure, on ne considérerait peut-être pas cela comme une couleur, mais un humain considérera bien un bleu et un bleu métal comme 2 couleurs différentes (même si ça pourrait être considéré exactement le même bleu selon d'autres critères). Et là même en CMYK, on ne les représente pas. En général, c'est là où on utilise les "spot colors" qui sont encore un autre modèle, en général sur une base de catalogues.
Mais hormis ce type de transformation et autres exceptions particulières, les transformations entre la plupart des autres modèles sont bien bijectives et se font par de très simples opérations mathématiques. 😄
Ces derniers mois, j'ai donné des conférences sur le traitement d'image et de manière générale sur les sciences des couleurs dans une école d'ingénieur des Mines (Saint Étienne) et dans un IUT (Valence). Bien sûr, dans le temps d'une conférence (2H, bien qu'aux Mines, on a aussi eu des ateliers, donc ce fut même un séminaire d'une journée complète avec conf + atelier sur le traitement d'image avec GEGL), ce n'est qu'un survol très rapide des nombreux concepts. Quiconque croit pouvoir comprendre la problématique de la couleur en informatique en quelques heures se méprend totalement. Cela fait des années que je travaille en plein dedans et je découvre encore des choses, il m'arrive encore de finalement comprendre des trucs (alors que je n'avais même pas réalisé que je n'avais pas compris avant!), etc. D'ailleurs puisque j'ai écrit ce commentaire presque de tête, il n'est pas impossible que quelques erreurs s'y soient glissées. Cela ne fait que démontrer d'autant plus la complexité du sujet (un "classique" quand je lis un texte sur la théorie de la couleur est de comprendre sur le coup et de me dire "ah bah oui", puis d'avoir complètement perdu la logique une semaine après, si je ne l'ai pas relu ou appliqué dans du code entretemps).
Quand on regarde l'historique des logiciels de graphisme, on se rend d'ailleurs compte que l'ensemble de l'industrie a fait erreurs sur erreurs pendant des décennies sur le sujet de la couleur et essaie de les réparer progressivement (parfois en faisant de nouvelles erreurs ironiquement!).
Je parle bien de gros noms de l'industrie qui ont multiplié des bourdes sur les dernières décennies (et encore très récemment; ce ne sont pas forcément toutes de vieilles histoires).
Et en recherche c'est pareil, les chercheurs ont l'air de se tirer la bourre. Quand on discute avec certains ou qu'on lit certains textes de référence, il n'est pas rare que ça commence en gros par "tout le monde a tort, sauf moi!" Et nous, on navigue dedans.
Donc oui, c'est pas facile. Quiconque est intéressé par une conf sur ce sujet dans une université/école/entreprise peut me contacter d'ailleurs. Maintenant que j'ai commencé à en faire quelques unes, je me dis que c'est un sujet intéressant à expliquer et discuter. Donc je suis partant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Imaginons que j'ai deux écrans. Avec la pipette, je voudrais prélever la couleur de fond de mon éditeur de texte qui est sur l'écran 1. Je fais la même chose avec le même logiciel sur l'écran 2. Peu importe comment la couleur rend à l'écran, je m'attends à avoir les valeurs (s)RVB brutes qui ont servi à la composition de l'écran, qui devraient donc être les mêmes sur les deux écrans.
Ce n'est la même valeur que parce que la couleur n'est probablement pas gérée dans ton cas (comme c'est le cas pour la plupart des gens, et c'est normal, pas un reproche bien sûr!).
Ça veut aussi dire que la même image aura des couleurs différentes sur tes 2 écrans. Comme on dit: que la personne qui n'a jamais remarqué qu'une même image rend différemment sur 2 écrans — ou bien sur son tél et son ordi, etc. — me jette la première pierre!
Pour moi le profil colorimétrique ne devrait que servir pour l'affichage sur le périphérique afin que la couleur (s)RVB brute s'affiche correctement sur celui-ci, mais pas lors d'un prélèvement de couleur. Après, si on a un écran calibré et que le prélèvement de couleur renvoie la couleur "altérée" par un profil colorimétrique, je comprend qu'on a alors besoin de connaître ce profil.
Ben voilà, tu as répondu toi-même. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Alors qu'il existe effectivement des modèles absolus (genre CIE LAB, etc.), où un n-uplet (en général un triplet) correspond à une couleur unique, ce n'est pas le cas du modèle de couleur RGB. Ce modèle est relatif à un certain contexte (l'espace de couleur), à savoir ses 3 couleurs primaires (oui "rouge", "vert" et "bleu", mais quels sont-ils? Les primaires de sRGB ou d'adobeRGB ne sont pas les mêmes rouges, verts et bleus par exemple!), de même que ses courbes de réponses/fonctions de transfert (comment on associe un chiffre, le long d'un des axes de couleurs, à une luminance, donc une couleur? On pensera de suite à la correction gamma bien que ce soit un cas simple; sRGB par exemple ne suit pas exactement une courbe gamma, même si souvent certains vont l'approximer avec une courbe de gamma 2.2). On va aussi définir le point blanc et le point noir.
Ce "contexte" est défini dans un profil de couleur (un petit fichier qui peut être à part, ou bien en métadonnées d'une image par exemple).
En gros, si on te donne une couleur (r1, g1, b1), ça ne veut rien dire sans l'espace de couleur associé. Alors bien sûr, si on te donne (255, 0, 0), c'est le rouge le plus vif de ton espace (si on est en espace entier sur 8-bit). Bon déjà, aparté: c'est même pas forcément vrai! Tu pourrais tout à fait avoir un profil qui redéfinit les composantes. J'en ai un sur mon disque par exemple qui fait une rotation des composantes, ce qui fait qu'avec ce profil, cette couleur serait en fait la couleur la plus verte, et non rouge! Mais bon, c'est un profil de test (ça permet de rapidement tester si mon code de conversion de couleur n'est pas complètement cassé: si mon rouge est vert, alors c'est bon, je suis dans la bonne direction! Ahahah! 🤣) et évidemment en général, on ne va pas utiliser ce type de profil. Prenons le cas normal donc: c'est bel et bien le rouge le plus rouge. Ben oui, sauf que le rouge le plus rouge dans l'espace sRGB n'est pas le rouge le plus rouge de l'espace adobeRGB (je l'ai dit plus haut). Ainsi sRGB(255, 0, 0) ≈ adobeRGB(219, 0, 0). Si tu passes juste le triplet d'un espace à l'autre sans convertir, tu verras immédiatement qu'il y a un problème!
Ajoute à cela que ton écran lui n'est ni en sRGB, ni en adobeRGB. Il est en ce que le hasard de sa réalité matériel lui permet, et c'est pour ça qu'on va calibrer son écran (avec une sonde colorimétrique ou un spectrophotomètre) pour créer son profil de couleur propre. C'est ce qui nous permet d'afficher une couleur comme elle devrait l'être. Ainsi si tu as un écran à gamut large et que tu veux un rouge sRGB(255, 0, 0), t'as pas intérêt à lui donner les chiffres (255, 0, 0). C'est le bon moyen pour avoir des couleurs pêtantes à l'écran. Et c'est d'ailleurs la raison pour laquelle tu vois plein de gens se plaindre sur divers forums sur le web que leur super écran Wide Gamut super cher affiche que des couleurs sur-saturées. C'est parce que la plupart des logiciels ne gèrent pas la couleur et passent des chiffres RGB vers l'écran sans jamais rien convertir.
Donc pour répondre à ta question:
Il doit me manquer une subtilité, parce que je ne vois pas la difficulté posée par la capture d'une couleur à l'écran. Si on récupère une couleur donnée, GIMP ne peut-il pas simplement calculer la couleur qui, si elle était posée dans l'image courante
Ben justement, si on n'a pas ce contexte, à savoir le profil de couleur de l'écran: non, on ne peut pas!
Comme je viens de le montrer, si l'OS me donne des couleurs RGB sans un profil de couleur, ça peut être "n'importe quelle couleur". Même sans avoir de profil extrême (comme le profil de test qui fait une rotation des canaux), va changer le profil (sans convertir les valeurs) entre un espace de couleur large et un espace étroit et tu verras une différence de couleur évidente. Au cas où je suis pas clair, je parle pas de différences subtiles, mais vraiment de couleurs évidemment différentes à l'œil nu.
demander au serveur X ou au compositeur Wayland d'envoyer la couleur précédemment récupérée ?
C'est là où le bât blesse. Donner le triplet de chiffres n'est pas assez. Avec X, on peut récupérer n'importe quel pixel de l'écran, puis on peut demander le profil de l'écran. Donc on a bien toutes les informations pour convertir dans un autre espace.
Avec Wayland, puisque le but est de cacher les informations des autres applications mais aussi système à l'application appelante, on peut seulement demander à un "portail" de faire une capture ou de "piquer" une couleur, puis le logiciel passe la main et attend. Enfin on a une réponse. Mais on ne sait pas du tout ce qui s'est passé entretemps.
Dans le cas de capture d'écran, on ne sait pas si on a une capture d'un seul écran, partiel ou total, ou de plusieurs, ni duquel. Dans le cas d'un prélèvement de couleur, on ne sait pas de quel pixel (c'est à dire quelle coordonnées) de quel écran on a pris la couleur.
D'ailleurs on ne sait même pas s'il y a un seul écran ou plusieurs branché sur cette machine (ou zéro)! Et on ne peut pas le savoir. On n'a tout simplement aucune information sur les écrans, ni leurs dimensions, et bien entendu il est donc impossible de demander leur profil de couleur au système. C'est le principe en fait.
La solution est donc soit que le portail donne le profil de couleur de l'écran (ce qui pose un problème pour les captures multi-écran re-composées en une image unique, notons), soit qu'il convertisse dans un espace connu (si possible bien sûr suffisamment grand pour englober l'ensemble des couleurs visibles) ou un modèle absolu. Mais si il te dit "tiens c'est du RGB" mais sans te dire lequel, ni te donner la possibilité d'avoir cette réponse par d'autres moyens. Alors il t'a juste donné des nombres sans trop de sens.
Notons que — aux dernières nouvelles — Wayland ne permet de toutes façon pas la gestion de couleur tout court (pas de calibration d'écran possible sous Wayland), alors bon… c'est la première étape déjà! La second étape sera d'avoir les APIs pour récupérer l'information adéquate.
Bon dans le cas "général", ça reste acceptable, parce que le grand public va de toutes façon pas calibrer leur écran ni travailler avec des images avec un profil autre que sRGB. Dans ce contexte, on va prendre un triplet en supposant que c'est du sRGB sur l'écran, l'utiliser comme tel sur une image qui va supposer de même et qui sera affichée sur le même écran, toujours en supposant que l'écran est sRGB. En gros, tout est absolument erroné, mais on s'en fiche car on propage la même erreur partout.
Mais si on veut travailler les couleurs dans un contexte professionnel, on va calibrer son écran, possiblement utiliser des profils de couleur autre que sRGB sur ses images, etc. On veut pas juste copier des chiffres d'un espace de couleur à l'autre en espérant que tout ira pour le mieux.
Pour info, voilà la demande de fonctionnalité où je demande que le portail Freedesktop de prélèvement de couleur gère les couleurs. La conclusion de la discussion à ce stade est que:
L'interface actuelle devrait rester telle quel au niveau interface, sauf qu'elle devrait être documenté comme retournant uniquement du sRGB; puis les diverses implémentations de ce portail (KDE, GNOME, etc.) devraient donc être changée pour convertir en et retourner uniquement du sRGB. Ainsi toute application qui ne souhaite pas gérer les couleurs continuera d'utiliser ce portail (ils perdent les couleurs hors-gamut, mais c'est acceptable dans un usage basique et au moins les couleurs à l'intérieur de cet espace deviendraient juste).
Il faudrait faire une nouvelle interface qui convertirait et retournerait les couleurs dans un espace connu et plus grand. Le contributeur qui a répondu proposait PQ/Rec2020 (l'espace de couleur UHDTV).
En tous cas, c'est pour l'instant là où on en est au niveau discussion, mais rien n'est implémenté (des infos que j'ai) et pour l'instant l'interface actuelle retourne simplement une couleur dont on ne connaît pas l'espace de couleur associé. Ce n'est pas acceptable dans un usage sérieux de travail de la couleur.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Non, je ne sais pas ce que pensent les autres. Et je crois que ce n'est pas la bonne question.
Je sais que mon commentaire précédent peut donner l'impression qu'on se plaint du développement de GTK, mais c'est pas du tout là où je voulais en venir. J'expliquais juste en quoi un tel port est complexe et long (contrairement à ce que certains avancent).
Oui, je pense que les dévs GTK auraient pu mieux gérer le passage, mais c'est toujours plus simple à dire qu'à faire. Au final on utilise et on a quand même besoin que GTK évolue (et ce même si on préférerait que la bibliothèque évolue plus souplement, sans tout casser à chaque fois, c'est sûr) et même si on n'est pas d'accord sur tout, ça ne veut pas dire qu'on veut forker GTK par exemple. On est déjà trop peu de développeurs pour GIMP/GEGL/babl pour en plus s'ajouter une autre dépendance majeure. 😅
On prend les passages à de nouvelles versions du toolkit comme une nécessité qu'il faut simplement faire. Un peu comme les corvées de ménage. C'est typiquement la définition de la "dette technologique" en fait. C'est du travail qui n'apporte pas grand chose si ce n'est s'assurer qu'on reste dans la course en suivant le mouvement plus général des changements dans les standards informatiques, les systèmes d'exploitation, etc.
C'est pareil pour nous, et j'imagine pour les autres gros logiciels que tu cites (même si je veux pas trop m'avancer non plus; comme j'ai dit, je sais pas ce que pense autrui!). On fait ces ports parce qu'il faut bien les faire et parce qu'on peut pas rester à jamais sur un toolkit non maintenu et qui ne gère pas (bien ou du tout) le matériel ou logiciels modernes (par exemple: les écrans haute-densité, les tablettes graphiques dont les pilotes utilisent l'API Windows Ink et plus seulement Wintab sur Windows, Wayland pour GNU/Linux…). On se pose pas trop de questions sur si oui ou non GTK aurait pu mieux prendre le virage pour prendre en charge ces nouveaux matériels, logiciels ou usages sans forcer à des mois de travail pour porter, ou sur comment ou pourquoi. On grommelle 💢 certes, mais on fait. Et c'est tout. Je laisse à d'autres le soin de faire des blogs posts pour faire des théories et expliquer pourquoi autrui ne fait pas bien (ce qu'on ne fait pas soi-même), en claquant bruyamment la porte (et en allant par exemple chez Qt, même si ceux-ci ne font pas forcément mieux de ce que je comprends). Il y en a certes qui adorent faire ce genre de choses. 🙄
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ahah tu rigoles, mais cet exemple précis m'est venu à l'esprit quand j'ai écrit mon commentaire. ;-)
D'ailleurs ça me fait penser que je parlais de "Karaté Kid" à des "djeunz" (la trentaine quand même) l'autre jour et ils étaient genre "c'est quoi?" Les références se perdent ma bonne dame!
Enfin bon, en excluant cet exemple caricatural (mais drôle pour les geeks un peu plus âgés!), de manière générale, les bases, c'est comme expliquer aux gens qu'ils faut apprendre les maths pour faire de l’ingénierie, alors que oui, de nos jours les logiciels vont tout calculer pour toi. Etc.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ce qui est important c'est de sensibiliser le public et la médecine que ces cas existent, mais pas besoin à mon sens d'un congé spécial, juste pouvoir considérer qu'une règle douloureuse rentre dans la prise en charge existante.
Sauf que dans ce cas là, avec les carences d'indemnités de 3 jours, c'est équivalent de proposer à ces femmes un congé sans solde ou presque (les règles douloureuses, la durée est variable mais c'est pas non plus à rallonge) à chaque cycle.
Limite quand tu dis "sensibiliser le public et la médecine que ces cas existent, mais pas besoin à mon sens d'un congé spécial", tu es surtout en train de dire "c'est bon, on a compris, ça existe, maintenant tes douleurs, si tu pouvais les avoir en silence dans ton coin et bien sûr en rognant sur ta paie. La société va pas non plus payer pour tes douleurs! T'es née femme, pas de bol, tant pis pour toi!"
Sans compter que devoir demander un document au docteur tous les mois est un bon moyen de simplement empêcher énormément de femmes d'accéder à ce droit (comme expliqué dans mon autre commentaire, avoir des RDVs médicaux en temps et en heure est une gageure de nos jours).
Donc si, il faut traiter cela spécialement, car c'est bien différent. Ce n'est pas une maladie qu'on a exceptionnellement, une fois, et pendant une longue durée d'affilée (et donc la carence est acceptable). Ce n'est d'ailleurs pas une "exception" du tout pour ces femmes qui ont ce problème. Il n'y a rien à envier à leur condition et leur accorder ce type de congé pour se reposer ne devrait même pas être en question d'après moi.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Si je suis en arrêt, rien ne m'oblige d'en donner la raison exacte à mon employeur si je n'ai pas envie de le faire, le justificatif du médecin suffit.
D'une, je sais pas comment ça se passe par chez vous, mais avoir des RDVs médicaux devient de plus en plus difficile. Il n'est pas rare de prendre un RDV chez son médecin traitant pour dans 2 semaines (d'ici là ta maladie a largement eu le temps de disparaître, par contre entretemps, tu as bien souffert, sans médicaments, et sans justificatif; de même pour les règles si une femme devait avoir un justificatif juste pour ça!). Et encore, c'est si tu as un médecin traitant tout court. Je sais pas si tu as entendu parler du problème des déserts médicaux (un peu partout en France). Après un déménagement, j'ai été sans médecin traitant pendant 3 ans (enfin non, officiellement j'avais encore l'ancien, à quelques centaines de KMs de là et qui refusait de faire des ordonnances, etc. en télé-RDV; ce que je comprends aussi bien sûr). Et c'était pas faute d'avoir appelé tous les médecins environnants très régulièrement pendant ces 3 ans. Je n'ai d'ailleurs réussi à avoir un nouveau médecin que par chance très récemment.
De deux, l'arrêt maladie a un délai de carence de 3 jours. 3 jours sans paie donc à chaque arrêt. On parle donc d'un évènement régulier de quelques jours à chaque fois. J'espère que tu vois le problème. En gros, ce serait comme dire qu'on a le droit de prendre un congé mais il n'y a pas d'indemnité, ou presque. En fait, je pense même que c'est déjà faisable ce que tu proposes.
Au contraire, un mécanisme adapté à ces douleurs récurrentes éviterait ces écueils, à savoir la perte de temps pour obtenir un justificatif (voire l'impossibilité tout court si pas de médecin traitant ou si les RDVs rapides sont impossibles) et la perte de salaire. Je me dis qu'un système avec un document du médecin unique, une fois (pour justifier qu'une femme est suivie pour des problèmes de règles douloureuses), serait suffisant. Après tout, on parle de gens qui ont des douleurs lourdes et récurrentes. Ce n'est pas une fois par an. Et c'est vraiment pas drôle pour ces femmes là.
rien ne m'oblige d'en donner la raison exacte à mon employeur si je n'ai pas envie de le faire
Je suppose que ce qui motive cette phrase est le tabou de parler des règles. Je pense qu'on est entre adultes et si certains rigolent encore de ce types de sujets, faudrait juste qu'ils grandissent. Entretenir un tabou n'est jamais le moyen pour améliorer les choses.
Là on parle quand même d'un phénomène qui est tout à fait naturel et arrive à à peu près la moitié de la population mondiale. Franchement, entretenir encore du tabou autour du sujet des règles féminines est ridicule.
On se farcit déjà les "les femmes ça peut partir en congé maternité", sera-t-il vraiment bénéfique d'y rajouter "peut-être qu'elle va partir tous les mois en congé menstruel, dans le doute prenons plutôt le monsieur" ?
Alors je dis pas qu'il n'y a pas d'idiots qui vont réagir ainsi. Il est même probable qu'il y en ait beaucoup plus que je n'ose imaginer. Néanmoins c'est comme le tabou. C'est pas en disant "oui mais y a des idiots donc faisons comme si de rien n'était et cachons le malaise de société" que les choses évolueront. À un moment donné, il faut un peu rentrer dedans pour faire changer les mentalités justement. Ou alors ce sera encore un problème dans 50 ans (comme ça l'était déjà y a 50 ans, et depuis toujours, mais jusque là justement, les gens ne faisaient rien parce que… y avait toujours une bonne raison quoi!).
Je voudrais tout de même noter que cela ne coûte de toutes façons rien à l'employeur (si on se base sur le système de congé maladie actuel, sauf qu'on retirerait les 3 jours de carence pour ce cas particulier). Les indemnités sont versées par la sécurité sociale et les indemnités complémentaires employeurs ne sont dûes qu'avec une carence de 7 jours (donc sur ce sujet, un employeur ne paierait vraisemblablement rien, ou rarement et très peu). Ceci dit, si des employeurs sont dans de bonnes situations financières et faisaient des accords/contrats pour compléter le salaire sans carence, honnêtement dans ce cas, je ne trouverais pas cela une mauvaise idée du tout. On travaille mieux dans de bonnes conditions de travail!
Enfin si le problème est non pas le coût mais le temps d'arrêt. Honnêtement, quelques jours par mois, faut arrêter de croire que c'est un problème (seuls les mauvais employeurs aux tendances mini-dictateur a ce type de discours). Si votre entreprise est en péril car des employées doivent s'absenter quelques jours par mois, vous avez un sérieux problème et ce n'est pas dû au fait que vous engagiez des femmes! Je crois que beaucoup trop de gens sont juste tellement habitués à l'absurdité du système entreprenariale moderne pour ne plus se rendre compte de l'absurdité grandissante de beaucoup de parties de ce système. Quand je travaille avec une femme et qu'elle doit s'absenter quelques jours pour douleurs… ben sérieux, ça change quoi? On attendra quelques jours pour certains trucs dont cette femme est responsable, et pour les choses dont on est responsables, on peut continuer de travailler. Les problèmes que certains ne manquent pas d'évoquer:
Si vous étiez à quelques jours près dans le projet et ne pouvez vous permettre du retard. Typiquement, deadline avec client mécontent et possiblement même des pénalités de retard. Ben là j'ai envie de dire, faut revoir vos techniques de gestion de projets. C'est typique le problème des mauvais managers qui mettent la pression aux employés, promettent des projets aux dates impossibles aux clients sans consulter ceux qui font réellement le boulot, etc. Le problème n'est pas les personnes en arrêt maladie dans ce cas, c'est le manager.
Si vous ne pouvez pas continuer votre boulot car vous êtes dépendant du résultat de l'absente. Ben encore une fois, faut questionner les méthodes de travail. Et vous comptiez faire quoi pendant quelques jours en attendant que cette personne finisse? Vous tourner les pouces? Ou alors c'est juste que votre emploi ne sert à rien et que vous reposez entièrement sur le boulot réel effectué par la femme absente (donc son absence met à jour l'inutilité des autres, et c'est ça le vrai problème).
Si c'est un boulot qui doit se faire en continu et il n'y a personne pour remplacer. Si la continuité du boulot est un prérequis, ce n'est pas la faute de l'employée si cela ne peut être assuré. L'employée, en dehors de règles douloureuses régulières, peut aussi tomber malade, peut prendre des jours de congés, voire de longues vacances, etc. En quoi cela serait-il différent?
Etc.
En gros, il n'y a vraiment que de mauvaises raisons de penser que c'est un problème.
Perso si je travaille avec quelqu'un, c'est que je considère que cette personne fait du bon boulot. Donc j'ai choisi de travailler avec elle. Pas en fonction de son genre. Et dans ce contexte, choisir quelqu'un d'autre sur un critère aussi futile n'a simplement aucun sens. Tu pourrais aussi bien "prendre le monsieur" et rien ne dit qu'il ne va pas juste pointer présent tous les jours en glandant au bureau.
Enfin voilà, pour moi, c'est une bonne étape et c'est limite honteux que ce sujet ne commence à être évoqué politiquement que maintenant (d'ailleurs c'est pas encore voté, donc faut pas crier victoire trop vite). Quant aux freins psychologiques, encore une fois, je dis pas qu'ils n'existent pas, mais ce n'est pas en freinant encore plus fort qu'on les fera sauter. Au contraire, il faut aller de l'avant et faire évoluer les mentalités. De toutes façons dans une entreprise avec de bonnes conditions de travail et une mentalité professionnelle et saine, un tel congé menstruel ne serait absolument pas un problème pour le travail, je l'ai montré plus haut.
Bien au contraire! En permettant de bonnes conditions sociales et de santé des employés, on ne peut qu'améliorer la qualité du travail: parce que forcer une femme avec de fortes douleurs, et qui ne fera donc pas grand chose de toutes façons, à être présente, ça a un intérêt limité; alors que bien reposée, elle n'en serait que plus productive à son retour.
(je n'ai pas accès à l'article, peut-être qu'il y a des éléments de réponse dedans)
J'y ai pas accès non plus, mais j'ai trouvé d'autres articles (par exemple celui-ci). Je note d'ailleurs que ta peur de la discrimination à l'embauche est partagée par beaucoup de femmes aussi (77% des personnes évoquent cette peur dans un sondage apparemment, d'après cet article).
Je pense aussi que même chez les femmes, beaucoup n'ont pas de problèmes de règles vraiment douloureuses (après tout, c'est un problème qui touche une femme sur 10, ce qui est à la fois beaucoup et à la fois veut dire que 9 femmes sur 10 ne voient peut-être juste pas le problème, ou pas autant).
Perso j'en connais et même juste vu de l'extérieur, c'est pas drôle du tout. Je n'ai envie de souhaiter cela à personne et la seule chose que j'aurais envie de dire à une employée qui aurait ce type de douleurs régulières, c'est de rentrer chez elle et de prendre sa journée, au moins dans les pires journées.
En même temps, je suis quelqu'un qui promeut l'idée qu'on ne devrait pas avoir à travailler autant, qu'on ne devrait travailler que dans de bonnes conditions, que le télé-travail, c'est bien, qu'avoir une vie sociale épanouie, c'est ce que je souhaite à tous, etc.
Donc perso, je suis à 100% pour une telle loi, et j'espère qu'elle passera (avec suffisamment de jours et une bonne indemnisation).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Crois le ou ne le crois pas, mais 30 ans après (ça ne me rajeunit pas :-) ), je me sens encore humilié par cette expérience. Je ne suis pas plombier; ça m'arrive souvent d'encadrer des jeunes ou des stagiaires, et je ne leur ai jamais proposé de passer du temps sur une tâche automatisable.
Alors je ne connais pas du tout le contexte plus précis, et peut-être que ton maître de stage était vraiment un salaud et que tout ce qu'il voulait faire, c'était t'humilier (enfin là dis comme ça avec ton histoire, ça ne m'était pas venu à l'esprit en fait; au contraire, je trouvais que c'était une histoire de quelqu'un qui prenait sa tâche de maître de stage à cœur en expliquant les bases de son métier). J'en sais rien, j'étais pas là et je connais pas cette personne.
Mais dans un contexte un tout petit plus général d'apprentissage (ce qui est le cas du stage de 3ème, on t'apprend pas un métier où il faut absolument être le plus performant sur de vrais chantiers en peu de temps; on te fait découvrir le monde du travail), il n'est absolument pas absurde de commencer par les bases. Ça n'a absolument rien d'humiliant. C'est comme ça qu'on apprend et qu'on comprend. Typiquement je pourrais tout à fait comprendre que ce plombier voulait t'apprendre à utiliser une scie à métaux, avant de passer à la disqueuse (en fait, il t'aurait laissé avec une disqueuse sans surveillance poussée à cet âge, c'est surtout là que je me serais posé beaucoup de questions!).
Je suis d'ailleurs absolument persuadé que dans son métier de plombier, encore maintenant, il utilise très régulièrement sa scie à métaux (et il a intérêt à être adroit avec; chez un client, il va pas passer 1 heure à couper un tuyau en expliquant au client "vous comprenez, normalement j'utilise ma disqueuse!"). On ne peut pas toujours utiliser les outils les plus modernes partout et dans tous les cas!
Pour faire des rapprochements, quand je vois Aryeom qui donne des cours d'illustration, elle explique aux gens de s'entraîner à faire des traits, ou des courbes, des exercices qu'elle fait elle-même pour garder la main (des feuilles entières de traits droits ou courbés, ou des spirales, etc. Et pas seulement sur l'ordi, aussi sur papier, en physique…)! Ce n'est pas une punition, c'est la pratique de base du dessin. Maintenant certains veulent juste se plaindre s'ils ne trouvent pas tout de suite la fonctionnalité de correction automatique de traits, parce qu'ils ne veulent plus se fouler à essayer de faire de beaux traits eux-même. Ou bien en retouche, on leur apprend d'abord les outils de base tels que l'outil de clone ou de correction. On peut faire de l'inpainting ensuite si on veut (y a de très bons outils pour ça, dans les plug-ins G'MIC ou Resynthesizer par exemple) mais avant d'aller là, on apprend les concepts de base.
En tant que programmeur, hier encore, quelqu'un qui a soumis un projet GSoC sur GIMP me demandait ce que j'utilisais comme plug-ins vim, notamment pour l'auto-complétion (beaucoup semblent s'imaginer que l'auto-complétion est le truc magique pour trouver le code qu'on connaît pas; nope désolé, y a pas de magie!). Je lui explique que la recherche de strings avec Ctrl-P et le saut sur les mots clés avec Ctrl-] (remappé tout de même pour ouvrir un nouveau tab vim plutôt qu'un buffer dans l'onglet courant) me suffisait pour des cas très simples. Et qu'en dehors de cela, grep surtout (et find aussi un peu, dans une moindre mesure) est le meilleur ami du développeur. Sinon y a les recherches web et dans la doc des librairies utilisées.
On peut essayer d'avoir des usages aussi avancés qu'on veut, dans la plupart des métiers, il y a toujours un moment où on revient aux bases. Un moment où juste se reposer sur un outil qu'on ne comprend pas ne suffit plus, mais où la solution est d'essayer de comprendre et corriger un problème à sa racine et de le réparer avec des outils ou techniques simples.
Et cela n'a rien d'insultant. Au contraire.
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 ]
[^] # Re: Fonctions non bijectives
Posté par Jehan (site web personnel, Mastodon) . En réponse au message De la gestion de couleurs. Évalué à 7.
Les transformations entre la plupart des modèles de couleur sont bien bijectives. De même que les transformations entre espaces de couleur (si on travaille en flottant). Il s'agit de bête calcul de matrice 3×3 dans un sens, et son inverse dans l'autre.
Vous remarquerez d'ailleurs que tous ces modèles ont 3 axes, ce n'est pas un hasard. Les recherches ont simplement montré que l'on peut reproduire l'ensemble des couleurs avec 3 primaires. Le "jeu" est donc simplement de choisir des primaires/axes appropriées et c'est la raison principale pour laquelle il existe divers modèles et divers espaces.
Il y eut ainsi le moment où on a essayé de faire des modèles plus proches de "comment l'humain perçoit les couleurs", ce qui a donné les HSV et HSL. Mais on s'est rendu compte que ces modèles n'étaient pas si bons mathématiquement (même s'ils restent utilisés et sont intéressants, notamment quelques outils colorimétriques dans GIMP se basent sur ces modèles, en terme d'UX).
Les gens ont alors cherché à voir les couleurs en 2D, ce qui a donné le modèle xyY, qui permet le fameux diagramme en fer à cheval où on représente les espaces de couleurs, en ignorant l'axe Y. En effet dans ce modèle, on représente entièrement les teintes (c'est à dire la perception des couleurs telles qu'on les nomme) sur un plan avec les axes xy, et l'axe Y ne représente que la luminance sans impacter la perception de teinte. On peut ainsi s'imaginer les "variations" d'une même couleur où on ne change que la luminance sur l'axe perpendiculaire au papier/à l'écran. Ce modèle a d'ailleurs quelques propriétés intéressantes, comme le fait que tout mélange de 2 couleurs se trouve sur le segment entre les 2 points. C'est pourquoi on arrive à représenter tout espace de couleur comme un triangle sur le plan 2D xy.
Mais ce type de modèle a aussi des problèmes, par exemple la non-uniformité perceptuelle (certaines couleurs très proches sur ce modèle ont l'air très différentes alors que sur d'autres zones, des couleurs éloignées ont l'air identiques). Les gens ont alors essayé de faire des modèles perceptuellement uniformes (ou presque), ce qui a donné les CIELAB et surtout CIELUV.
Et ainsi de suite. Mais le fait est qu'hormis la création de modèle pour satisfaire des buts/usages particuliers, les couleurs sont entièrement et très aisément transformables d'un modèle à l'autre.
La raison pour laquelle il pourra y avoir une très légère différence du résultat dans un A/R entre 2 modèles serait l'imprécision mathématique d'un processeur. Mais bon, si on ne fait qu'un A/R, la perte est probablement trop minime pour s'en préoccuper (ce serait moins le cas si on code ça sur 8-bit, ce pourquoi notamment il est conseillé de travailler en flottant de nos jours pour le travail graphique). Hormis ce point de limitation technique, si, mathématiquement les transformations sont théoriquement bijectives, sans perte, hormis si on décidait d'écrêter en dehors de
[0; 1], c'est à dire hors du gamut d'un espace de couleur. Sauf que justement l'un des autres grands avantages du travail en flottant est qu'on évite d'écrêter lors d'étapes intermédiaires permettant réellement de travailler presque sans perte, et en plus très simplement (calcul de multiplication de matrice basique, niveau lycée).Ensuite quand je disais dans mon paragraphe d'intro que c'est vrai pour "la plupart des modèles de couleur", c'est parce que certains modèles sont basés sur des logiques physiques différentes. Je parle de CMYK. Un passage RGB🔄CMYK n'est effectivement pas bijectif (il n'est pas impossible de tomber sur des valeurs assez différentes lors d'un A/R entre les 2 modèles).
Et sans compter les "couleurs" de type "couleurs métalliques" ou "couleurs fluorescentes", etc. Bien sûr, selon une théorie de couleur pure, on ne considérerait peut-être pas cela comme une couleur, mais un humain considérera bien un bleu et un bleu métal comme 2 couleurs différentes (même si ça pourrait être considéré exactement le même bleu selon d'autres critères). Et là même en CMYK, on ne les représente pas. En général, c'est là où on utilise les "spot colors" qui sont encore un autre modèle, en général sur une base de catalogues.
Mais hormis ce type de transformation et autres exceptions particulières, les transformations entre la plupart des autres modèles sont bien bijectives et se font par de très simples opérations mathématiques. 😄
Ces derniers mois, j'ai donné des conférences sur le traitement d'image et de manière générale sur les sciences des couleurs dans une école d'ingénieur des Mines (Saint Étienne) et dans un IUT (Valence). Bien sûr, dans le temps d'une conférence (2H, bien qu'aux Mines, on a aussi eu des ateliers, donc ce fut même un séminaire d'une journée complète avec conf + atelier sur le traitement d'image avec GEGL), ce n'est qu'un survol très rapide des nombreux concepts. Quiconque croit pouvoir comprendre la problématique de la couleur en informatique en quelques heures se méprend totalement. Cela fait des années que je travaille en plein dedans et je découvre encore des choses, il m'arrive encore de finalement comprendre des trucs (alors que je n'avais même pas réalisé que je n'avais pas compris avant!), etc. D'ailleurs puisque j'ai écrit ce commentaire presque de tête, il n'est pas impossible que quelques erreurs s'y soient glissées. Cela ne fait que démontrer d'autant plus la complexité du sujet (un "classique" quand je lis un texte sur la théorie de la couleur est de comprendre sur le coup et de me dire "ah bah oui", puis d'avoir complètement perdu la logique une semaine après, si je ne l'ai pas relu ou appliqué dans du code entretemps).
Quand on regarde l'historique des logiciels de graphisme, on se rend d'ailleurs compte que l'ensemble de l'industrie a fait erreurs sur erreurs pendant des décennies sur le sujet de la couleur et essaie de les réparer progressivement (parfois en faisant de nouvelles erreurs ironiquement!).
Je parle bien de gros noms de l'industrie qui ont multiplié des bourdes sur les dernières décennies (et encore très récemment; ce ne sont pas forcément toutes de vieilles histoires).
Et en recherche c'est pareil, les chercheurs ont l'air de se tirer la bourre. Quand on discute avec certains ou qu'on lit certains textes de référence, il n'est pas rare que ça commence en gros par "tout le monde a tort, sauf moi!" Et nous, on navigue dedans.
Donc oui, c'est pas facile. Quiconque est intéressé par une conf sur ce sujet dans une université/école/entreprise peut me contacter d'ailleurs. Maintenant que j'ai commencé à en faire quelques unes, je me dis que c'est un sujet intéressant à expliquer et discuter. Donc je suis partant.
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é à 5. Dernière modification le 28 avril 2023 à 23:37.
Ce n'est la même valeur que parce que la couleur n'est probablement pas gérée dans ton cas (comme c'est le cas pour la plupart des gens, et c'est normal, pas un reproche bien sûr!).
Ça veut aussi dire que la même image aura des couleurs différentes sur tes 2 écrans. Comme on dit: que la personne qui n'a jamais remarqué qu'une même image rend différemment sur 2 écrans — ou bien sur son tél et son ordi, etc. — me jette la première pierre!
Ben voilà, tu as répondu toi-même. :-)
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.
Alors qu'il existe effectivement des modèles absolus (genre CIE LAB, etc.), où un n-uplet (en général un triplet) correspond à une couleur unique, ce n'est pas le cas du modèle de couleur RGB. Ce modèle est relatif à un certain contexte (l'espace de couleur), à savoir ses 3 couleurs primaires (oui "rouge", "vert" et "bleu", mais quels sont-ils? Les primaires de sRGB ou d'adobeRGB ne sont pas les mêmes rouges, verts et bleus par exemple!), de même que ses courbes de réponses/fonctions de transfert (comment on associe un chiffre, le long d'un des axes de couleurs, à une luminance, donc une couleur? On pensera de suite à la correction gamma bien que ce soit un cas simple; sRGB par exemple ne suit pas exactement une courbe gamma, même si souvent certains vont l'approximer avec une courbe de gamma 2.2). On va aussi définir le point blanc et le point noir.
Ce "contexte" est défini dans un profil de couleur (un petit fichier qui peut être à part, ou bien en métadonnées d'une image par exemple).
En gros, si on te donne une couleur
(r1, g1, b1), ça ne veut rien dire sans l'espace de couleur associé. Alors bien sûr, si on te donne(255, 0, 0), c'est le rouge le plus vif de ton espace (si on est en espace entier sur 8-bit). Bon déjà, aparté: c'est même pas forcément vrai! Tu pourrais tout à fait avoir un profil qui redéfinit les composantes. J'en ai un sur mon disque par exemple qui fait une rotation des composantes, ce qui fait qu'avec ce profil, cette couleur serait en fait la couleur la plus verte, et non rouge! Mais bon, c'est un profil de test (ça permet de rapidement tester si mon code de conversion de couleur n'est pas complètement cassé: si mon rouge est vert, alors c'est bon, je suis dans la bonne direction! Ahahah! 🤣) et évidemment en général, on ne va pas utiliser ce type de profil. Prenons le cas normal donc: c'est bel et bien le rouge le plus rouge. Ben oui, sauf que le rouge le plus rouge dans l'espace sRGB n'est pas le rouge le plus rouge de l'espace adobeRGB (je l'ai dit plus haut). AinsisRGB(255, 0, 0) ≈ adobeRGB(219, 0, 0). Si tu passes juste le triplet d'un espace à l'autre sans convertir, tu verras immédiatement qu'il y a un problème!Ajoute à cela que ton écran lui n'est ni en sRGB, ni en adobeRGB. Il est en ce que le hasard de sa réalité matériel lui permet, et c'est pour ça qu'on va calibrer son écran (avec une sonde colorimétrique ou un spectrophotomètre) pour créer son profil de couleur propre. C'est ce qui nous permet d'afficher une couleur comme elle devrait l'être. Ainsi si tu as un écran à gamut large et que tu veux un rouge
sRGB(255, 0, 0), t'as pas intérêt à lui donner les chiffres(255, 0, 0). C'est le bon moyen pour avoir des couleurs pêtantes à l'écran. Et c'est d'ailleurs la raison pour laquelle tu vois plein de gens se plaindre sur divers forums sur le web que leur super écran Wide Gamut super cher affiche que des couleurs sur-saturées. C'est parce que la plupart des logiciels ne gèrent pas la couleur et passent des chiffres RGB vers l'écran sans jamais rien convertir.Donc pour répondre à ta question:
Ben justement, si on n'a pas ce contexte, à savoir le profil de couleur de l'écran: non, on ne peut pas!
Comme je viens de le montrer, si l'OS me donne des couleurs RGB sans un profil de couleur, ça peut être "n'importe quelle couleur". Même sans avoir de profil extrême (comme le profil de test qui fait une rotation des canaux), va changer le profil (sans convertir les valeurs) entre un espace de couleur large et un espace étroit et tu verras une différence de couleur évidente. Au cas où je suis pas clair, je parle pas de différences subtiles, mais vraiment de couleurs évidemment différentes à l'œil nu.
C'est là où le bât blesse. Donner le triplet de chiffres n'est pas assez. Avec X, on peut récupérer n'importe quel pixel de l'écran, puis on peut demander le profil de l'écran. Donc on a bien toutes les informations pour convertir dans un autre espace.
Avec Wayland, puisque le but est de cacher les informations des autres applications mais aussi système à l'application appelante, on peut seulement demander à un "portail" de faire une capture ou de "piquer" une couleur, puis le logiciel passe la main et attend. Enfin on a une réponse. Mais on ne sait pas du tout ce qui s'est passé entretemps.
Dans le cas de capture d'écran, on ne sait pas si on a une capture d'un seul écran, partiel ou total, ou de plusieurs, ni duquel. Dans le cas d'un prélèvement de couleur, on ne sait pas de quel pixel (c'est à dire quelle coordonnées) de quel écran on a pris la couleur.
D'ailleurs on ne sait même pas s'il y a un seul écran ou plusieurs branché sur cette machine (ou zéro)! Et on ne peut pas le savoir. On n'a tout simplement aucune information sur les écrans, ni leurs dimensions, et bien entendu il est donc impossible de demander leur profil de couleur au système. C'est le principe en fait.
La solution est donc soit que le portail donne le profil de couleur de l'écran (ce qui pose un problème pour les captures multi-écran re-composées en une image unique, notons), soit qu'il convertisse dans un espace connu (si possible bien sûr suffisamment grand pour englober l'ensemble des couleurs visibles) ou un modèle absolu. Mais si il te dit "tiens c'est du RGB" mais sans te dire lequel, ni te donner la possibilité d'avoir cette réponse par d'autres moyens. Alors il t'a juste donné des nombres sans trop de sens.
Notons que — aux dernières nouvelles — Wayland ne permet de toutes façon pas la gestion de couleur tout court (pas de calibration d'écran possible sous Wayland), alors bon… c'est la première étape déjà! La second étape sera d'avoir les APIs pour récupérer l'information adéquate.
Bon dans le cas "général", ça reste acceptable, parce que le grand public va de toutes façon pas calibrer leur écran ni travailler avec des images avec un profil autre que sRGB. Dans ce contexte, on va prendre un triplet en supposant que c'est du sRGB sur l'écran, l'utiliser comme tel sur une image qui va supposer de même et qui sera affichée sur le même écran, toujours en supposant que l'écran est sRGB. En gros, tout est absolument erroné, mais on s'en fiche car on propage la même erreur partout.
Mais si on veut travailler les couleurs dans un contexte professionnel, on va calibrer son écran, possiblement utiliser des profils de couleur autre que sRGB sur ses images, etc. On veut pas juste copier des chiffres d'un espace de couleur à l'autre en espérant que tout ira pour le mieux.
Pour info, voilà la demande de fonctionnalité où je demande que le portail Freedesktop de prélèvement de couleur gère les couleurs. La conclusion de la discussion à ce stade est que:
En tous cas, c'est pour l'instant là où on en est au niveau discussion, mais rien n'est implémenté (des infos que j'ai) et pour l'instant l'interface actuelle retourne simplement une couleur dont on ne connaît pas l'espace de couleur associé. Ce n'est pas acceptable dans un usage sérieux de travail de la couleur.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bientôt GTK 4
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien The GTK+3 port of GIMP is officially finished - @zemarmot. Évalué à 5.
Non, je ne sais pas ce que pensent les autres. Et je crois que ce n'est pas la bonne question.
Je sais que mon commentaire précédent peut donner l'impression qu'on se plaint du développement de GTK, mais c'est pas du tout là où je voulais en venir. J'expliquais juste en quoi un tel port est complexe et long (contrairement à ce que certains avancent).
Oui, je pense que les dévs GTK auraient pu mieux gérer le passage, mais c'est toujours plus simple à dire qu'à faire. Au final on utilise et on a quand même besoin que GTK évolue (et ce même si on préférerait que la bibliothèque évolue plus souplement, sans tout casser à chaque fois, c'est sûr) et même si on n'est pas d'accord sur tout, ça ne veut pas dire qu'on veut forker GTK par exemple. On est déjà trop peu de développeurs pour GIMP/GEGL/babl pour en plus s'ajouter une autre dépendance majeure. 😅
On prend les passages à de nouvelles versions du toolkit comme une nécessité qu'il faut simplement faire. Un peu comme les corvées de ménage. C'est typiquement la définition de la "dette technologique" en fait. C'est du travail qui n'apporte pas grand chose si ce n'est s'assurer qu'on reste dans la course en suivant le mouvement plus général des changements dans les standards informatiques, les systèmes d'exploitation, etc.
C'est pareil pour nous, et j'imagine pour les autres gros logiciels que tu cites (même si je veux pas trop m'avancer non plus; comme j'ai dit, je sais pas ce que pense autrui!). On fait ces ports parce qu'il faut bien les faire et parce qu'on peut pas rester à jamais sur un toolkit non maintenu et qui ne gère pas (bien ou du tout) le matériel ou logiciels modernes (par exemple: les écrans haute-densité, les tablettes graphiques dont les pilotes utilisent l'API Windows Ink et plus seulement Wintab sur Windows, Wayland pour GNU/Linux…). On se pose pas trop de questions sur si oui ou non GTK aurait pu mieux prendre le virage pour prendre en charge ces nouveaux matériels, logiciels ou usages sans forcer à des mois de travail pour porter, ou sur comment ou pourquoi. On grommelle 💢 certes, mais on fait. Et c'est tout. Je laisse à d'autres le soin de faire des blogs posts pour faire des théories et expliquer pourquoi autrui ne fait pas bien (ce qu'on ne fait pas soi-même), en claquant bruyamment la porte (et en allant par exemple chez Qt, même si ceux-ci ne font pas forcément mieux de ce que je comprends). Il y en a certes qui adorent faire ce genre de choses. 🙄
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mais quel monde merveilleux !
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien Cette présentatrice météo n’existe pas - numerama. Évalué à 5.
Ahah tu rigoles, mais cet exemple précis m'est venu à l'esprit quand j'ai écrit mon commentaire. ;-)
D'ailleurs ça me fait penser que je parlais de "Karaté Kid" à des "djeunz" (la trentaine quand même) l'autre jour et ils étaient genre "c'est quoi?" Les références se perdent ma bonne dame!
Enfin bon, en excluant cet exemple caricatural (mais drôle pour les geeks un peu plus âgés!), de manière générale, les bases, c'est comme expliquer aux gens qu'ils faut apprendre les maths pour faire de l’ingénierie, alors que oui, de nos jours les logiciels vont tout calculer pour toi. Etc.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: TL;DR
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien L’idée d’un congé menstruel progresse - letemps.ch. Évalué à 6. Dernière modification le 21 avril 2023 à 15:05.
Sauf que dans ce cas là, avec les carences d'indemnités de 3 jours, c'est équivalent de proposer à ces femmes un congé sans solde ou presque (les règles douloureuses, la durée est variable mais c'est pas non plus à rallonge) à chaque cycle.
Limite quand tu dis "sensibiliser le public et la médecine que ces cas existent, mais pas besoin à mon sens d'un congé spécial", tu es surtout en train de dire "c'est bon, on a compris, ça existe, maintenant tes douleurs, si tu pouvais les avoir en silence dans ton coin et bien sûr en rognant sur ta paie. La société va pas non plus payer pour tes douleurs! T'es née femme, pas de bol, tant pis pour toi!"
Sans compter que devoir demander un document au docteur tous les mois est un bon moyen de simplement empêcher énormément de femmes d'accéder à ce droit (comme expliqué dans mon autre commentaire, avoir des RDVs médicaux en temps et en heure est une gageure de nos jours).
Donc si, il faut traiter cela spécialement, car c'est bien différent. Ce n'est pas une maladie qu'on a exceptionnellement, une fois, et pendant une longue durée d'affilée (et donc la carence est acceptable). Ce n'est d'ailleurs pas une "exception" du tout pour ces femmes qui ont ce problème. Il n'y a rien à envier à leur condition et leur accorder ce type de congé pour se reposer ne devrait même pas être en question d'après moi.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: TL;DR
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien L’idée d’un congé menstruel progresse - letemps.ch. Évalué à 8.
D'une, je sais pas comment ça se passe par chez vous, mais avoir des RDVs médicaux devient de plus en plus difficile. Il n'est pas rare de prendre un RDV chez son médecin traitant pour dans 2 semaines (d'ici là ta maladie a largement eu le temps de disparaître, par contre entretemps, tu as bien souffert, sans médicaments, et sans justificatif; de même pour les règles si une femme devait avoir un justificatif juste pour ça!). Et encore, c'est si tu as un médecin traitant tout court. Je sais pas si tu as entendu parler du problème des déserts médicaux (un peu partout en France). Après un déménagement, j'ai été sans médecin traitant pendant 3 ans (enfin non, officiellement j'avais encore l'ancien, à quelques centaines de KMs de là et qui refusait de faire des ordonnances, etc. en télé-RDV; ce que je comprends aussi bien sûr). Et c'était pas faute d'avoir appelé tous les médecins environnants très régulièrement pendant ces 3 ans. Je n'ai d'ailleurs réussi à avoir un nouveau médecin que par chance très récemment.
De deux, l'arrêt maladie a un délai de carence de 3 jours. 3 jours sans paie donc à chaque arrêt. On parle donc d'un évènement régulier de quelques jours à chaque fois. J'espère que tu vois le problème. En gros, ce serait comme dire qu'on a le droit de prendre un congé mais il n'y a pas d'indemnité, ou presque. En fait, je pense même que c'est déjà faisable ce que tu proposes.
Au contraire, un mécanisme adapté à ces douleurs récurrentes éviterait ces écueils, à savoir la perte de temps pour obtenir un justificatif (voire l'impossibilité tout court si pas de médecin traitant ou si les RDVs rapides sont impossibles) et la perte de salaire. Je me dis qu'un système avec un document du médecin unique, une fois (pour justifier qu'une femme est suivie pour des problèmes de règles douloureuses), serait suffisant. Après tout, on parle de gens qui ont des douleurs lourdes et récurrentes. Ce n'est pas une fois par an. Et c'est vraiment pas drôle pour ces femmes là.
Je suppose que ce qui motive cette phrase est le tabou de parler des règles. Je pense qu'on est entre adultes et si certains rigolent encore de ce types de sujets, faudrait juste qu'ils grandissent. Entretenir un tabou n'est jamais le moyen pour améliorer les choses.
Là on parle quand même d'un phénomène qui est tout à fait naturel et arrive à à peu près la moitié de la population mondiale. Franchement, entretenir encore du tabou autour du sujet des règles féminines est ridicule.
Alors je dis pas qu'il n'y a pas d'idiots qui vont réagir ainsi. Il est même probable qu'il y en ait beaucoup plus que je n'ose imaginer. Néanmoins c'est comme le tabou. C'est pas en disant "oui mais y a des idiots donc faisons comme si de rien n'était et cachons le malaise de société" que les choses évolueront. À un moment donné, il faut un peu rentrer dedans pour faire changer les mentalités justement. Ou alors ce sera encore un problème dans 50 ans (comme ça l'était déjà y a 50 ans, et depuis toujours, mais jusque là justement, les gens ne faisaient rien parce que… y avait toujours une bonne raison quoi!).
Je voudrais tout de même noter que cela ne coûte de toutes façons rien à l'employeur (si on se base sur le système de congé maladie actuel, sauf qu'on retirerait les 3 jours de carence pour ce cas particulier). Les indemnités sont versées par la sécurité sociale et les indemnités complémentaires employeurs ne sont dûes qu'avec une carence de 7 jours (donc sur ce sujet, un employeur ne paierait vraisemblablement rien, ou rarement et très peu). Ceci dit, si des employeurs sont dans de bonnes situations financières et faisaient des accords/contrats pour compléter le salaire sans carence, honnêtement dans ce cas, je ne trouverais pas cela une mauvaise idée du tout. On travaille mieux dans de bonnes conditions de travail!
Enfin si le problème est non pas le coût mais le temps d'arrêt. Honnêtement, quelques jours par mois, faut arrêter de croire que c'est un problème (seuls les mauvais employeurs aux tendances mini-dictateur a ce type de discours). Si votre entreprise est en péril car des employées doivent s'absenter quelques jours par mois, vous avez un sérieux problème et ce n'est pas dû au fait que vous engagiez des femmes! Je crois que beaucoup trop de gens sont juste tellement habitués à l'absurdité du système entreprenariale moderne pour ne plus se rendre compte de l'absurdité grandissante de beaucoup de parties de ce système. Quand je travaille avec une femme et qu'elle doit s'absenter quelques jours pour douleurs… ben sérieux, ça change quoi? On attendra quelques jours pour certains trucs dont cette femme est responsable, et pour les choses dont on est responsables, on peut continuer de travailler. Les problèmes que certains ne manquent pas d'évoquer:
En gros, il n'y a vraiment que de mauvaises raisons de penser que c'est un problème.
Perso si je travaille avec quelqu'un, c'est que je considère que cette personne fait du bon boulot. Donc j'ai choisi de travailler avec elle. Pas en fonction de son genre. Et dans ce contexte, choisir quelqu'un d'autre sur un critère aussi futile n'a simplement aucun sens. Tu pourrais aussi bien "prendre le monsieur" et rien ne dit qu'il ne va pas juste pointer présent tous les jours en glandant au bureau.
Enfin voilà, pour moi, c'est une bonne étape et c'est limite honteux que ce sujet ne commence à être évoqué politiquement que maintenant (d'ailleurs c'est pas encore voté, donc faut pas crier victoire trop vite). Quant aux freins psychologiques, encore une fois, je dis pas qu'ils n'existent pas, mais ce n'est pas en freinant encore plus fort qu'on les fera sauter. Au contraire, il faut aller de l'avant et faire évoluer les mentalités. De toutes façons dans une entreprise avec de bonnes conditions de travail et une mentalité professionnelle et saine, un tel congé menstruel ne serait absolument pas un problème pour le travail, je l'ai montré plus haut.
Bien au contraire! En permettant de bonnes conditions sociales et de santé des employés, on ne peut qu'améliorer la qualité du travail: parce que forcer une femme avec de fortes douleurs, et qui ne fera donc pas grand chose de toutes façons, à être présente, ça a un intérêt limité; alors que bien reposée, elle n'en serait que plus productive à son retour.
J'y ai pas accès non plus, mais j'ai trouvé d'autres articles (par exemple celui-ci). Je note d'ailleurs que ta peur de la discrimination à l'embauche est partagée par beaucoup de femmes aussi (77% des personnes évoquent cette peur dans un sondage apparemment, d'après cet article).
Je pense aussi que même chez les femmes, beaucoup n'ont pas de problèmes de règles vraiment douloureuses (après tout, c'est un problème qui touche une femme sur 10, ce qui est à la fois beaucoup et à la fois veut dire que 9 femmes sur 10 ne voient peut-être juste pas le problème, ou pas autant).
Perso j'en connais et même juste vu de l'extérieur, c'est pas drôle du tout. Je n'ai envie de souhaiter cela à personne et la seule chose que j'aurais envie de dire à une employée qui aurait ce type de douleurs régulières, c'est de rentrer chez elle et de prendre sa journée, au moins dans les pires journées.
En même temps, je suis quelqu'un qui promeut l'idée qu'on ne devrait pas avoir à travailler autant, qu'on ne devrait travailler que dans de bonnes conditions, que le télé-travail, c'est bien, qu'avoir une vie sociale épanouie, c'est ce que je souhaite à tous, etc.
Donc perso, je suis à 100% pour une telle loi, et j'espère qu'elle passera (avec suffisamment de jours et une bonne indemnisation).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mais quel monde merveilleux !
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien Cette présentatrice météo n’existe pas - numerama. Évalué à 10. Dernière modification le 20 avril 2023 à 17:35.
Alors je ne connais pas du tout le contexte plus précis, et peut-être que ton maître de stage était vraiment un salaud et que tout ce qu'il voulait faire, c'était t'humilier (enfin là dis comme ça avec ton histoire, ça ne m'était pas venu à l'esprit en fait; au contraire, je trouvais que c'était une histoire de quelqu'un qui prenait sa tâche de maître de stage à cœur en expliquant les bases de son métier). J'en sais rien, j'étais pas là et je connais pas cette personne.
Mais dans un contexte un tout petit plus général d'apprentissage (ce qui est le cas du stage de 3ème, on t'apprend pas un métier où il faut absolument être le plus performant sur de vrais chantiers en peu de temps; on te fait découvrir le monde du travail), il n'est absolument pas absurde de commencer par les bases. Ça n'a absolument rien d'humiliant. C'est comme ça qu'on apprend et qu'on comprend. Typiquement je pourrais tout à fait comprendre que ce plombier voulait t'apprendre à utiliser une scie à métaux, avant de passer à la disqueuse (en fait, il t'aurait laissé avec une disqueuse sans surveillance poussée à cet âge, c'est surtout là que je me serais posé beaucoup de questions!).
Je suis d'ailleurs absolument persuadé que dans son métier de plombier, encore maintenant, il utilise très régulièrement sa scie à métaux (et il a intérêt à être adroit avec; chez un client, il va pas passer 1 heure à couper un tuyau en expliquant au client "vous comprenez, normalement j'utilise ma disqueuse!"). On ne peut pas toujours utiliser les outils les plus modernes partout et dans tous les cas!
Pour faire des rapprochements, quand je vois Aryeom qui donne des cours d'illustration, elle explique aux gens de s'entraîner à faire des traits, ou des courbes, des exercices qu'elle fait elle-même pour garder la main (des feuilles entières de traits droits ou courbés, ou des spirales, etc. Et pas seulement sur l'ordi, aussi sur papier, en physique…)! Ce n'est pas une punition, c'est la pratique de base du dessin. Maintenant certains veulent juste se plaindre s'ils ne trouvent pas tout de suite la fonctionnalité de correction automatique de traits, parce qu'ils ne veulent plus se fouler à essayer de faire de beaux traits eux-même. Ou bien en retouche, on leur apprend d'abord les outils de base tels que l'outil de clone ou de correction. On peut faire de l'inpainting ensuite si on veut (y a de très bons outils pour ça, dans les plug-ins G'MIC ou Resynthesizer par exemple) mais avant d'aller là, on apprend les concepts de base.
En tant que programmeur, hier encore, quelqu'un qui a soumis un projet GSoC sur GIMP me demandait ce que j'utilisais comme plug-ins vim, notamment pour l'auto-complétion (beaucoup semblent s'imaginer que l'auto-complétion est le truc magique pour trouver le code qu'on connaît pas; nope désolé, y a pas de magie!). Je lui explique que la recherche de strings avec
Ctrl-Pet le saut sur les mots clés avecCtrl-](remappé tout de même pour ouvrir un nouveau tab vim plutôt qu'un buffer dans l'onglet courant) me suffisait pour des cas très simples. Et qu'en dehors de cela,grepsurtout (etfindaussi un peu, dans une moindre mesure) est le meilleur ami du développeur. Sinon y a les recherches web et dans la doc des librairies utilisées.On peut essayer d'avoir des usages aussi avancés qu'on veut, dans la plupart des métiers, il y a toujours un moment où on revient aux bases. Un moment où juste se reposer sur un outil qu'on ne comprend pas ne suffit plus, mais où la solution est d'essayer de comprendre et corriger un problème à sa racine et de le réparer avec des outils ou techniques simples.
Et cela n'a rien d'insultant. Au contraire.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]