GIMP 2.10.34 est sorti

• # Petite correction des titres de sections

  Posté par Matthieu (site web personnel) le 27 avril 2023 à 12:08. Évalué à 4. Dernière modification le 27 avril 2023 à 12:09.

  

  Oups, j'ai oublié de retirer le texte en anglais de certains titres de sections pendant la traduction de certains passages de cette dépêche…

  Si un membre de l'équipe de modération passe par là, est-il possible de retirer les passages "(Original: <du texte en anglais>)" qui restent dans trois des titres de sections, pour ne garder que les titres en français ? Merci beaucoup et désolé pour cette étourderie :)

  • [^] # Re: Petite correction des titres de sections

    Posté par bobble bubble le 27 avril 2023 à 12:20. Évalué à 5.

    

    Fait.
    Merci pour cette chouette dépêche :)

  • [^] # Re: Petite correction des titres de sections

    Posté par Jona le 27 avril 2023 à 13:58. Évalué à 4. Dernière modification le 27 avril 2023 à 13:58.

    

    Ah, je pensais que c'était intentionnel ! 😅

    • [^] # Re: Petite correction des titres de sections

      Posté par antistress (site web personnel) le 27 avril 2023 à 14:37. Évalué à 7. Dernière modification le 27 avril 2023 à 14:37.

      

      Flatpack s'écrit sans c (une occurrence à corriger)

      • [^] # Re: Petite correction des titres de sections

        Posté par Arkem le 28 avril 2023 à 06:55. Évalué à 1.

        

        Flatpack s'écrit sans c (une occurrence à corriger)

        Fait

    • [^] # Re: Petite correction des titres de sections

      Posté par Matthieu (site web personnel) le 27 avril 2023 à 19:47. Évalué à 4.

      

      Effectivement à certains endroits on avait gardé les termes originaux en anglais pour plus de clarté, mais là c'était bien une erreur de ma part :)

      Au passage merci Jona d'avoir initié cette dépêche et de l'avoir menée jusqu'à sa publication !

• # Gestion des couleurs et capture

  Posté par 🚲 Tanguy Ortolo (site web personnel) le 27 avril 2023 à 14:39. Évalué à 9.

  

  J'avoue avoir du mal à comprendre le problème qui se pose lors de la capture d'une couleur à l'écran, concernant la gestion des couleurs.

  Corrigez-moi si je me trompe, mais il me semble qu'une gestion des couleurs, c'est une opération qui consiste à prendre des couleurs envoyées par un logiciel pour affichage à l'écran ou pour impression, et à les transformer pour envoyer effectivement au périphérique des valeurs dont on sait que, compte tenu de ses défauts, il les affichera ou les imprimera d'une façon qui correspondra à ce que ces couleurs devraient être.

  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, lui ferait, compte tenu des paramètres de cette image, demander au serveur X ou au compositeur Wayland d'envoyer la couleur précédemment récupérée ?

  • [^] # Re: Gestion des couleurs et capture

    Posté par Sytoka Modon (site web personnel) le 27 avril 2023 à 17:58. Évalué à 2.

    

    Je ne sais pas, le logiciel est peut-être 16 bits couleur et l'écran un bon vieux VGA… En passant par une API, on a peut-être un meilleure précision ?

  • [^] # Re: Gestion des couleurs et capture

    Posté par Jehan (site web personnel, Mastodon) le 27 avril 2023 à 18:47. É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). 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:

    1. 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).
    2. 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 ]

    • [^] # Re: Gestion des couleurs et capture

      Posté par 🚲 Tanguy Ortolo (site web personnel) le 27 avril 2023 à 20:02. Évalué à 7.

      

      Désolé, mais je ne comprends toujours pas. 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.

      Mais je mets ça à côté du fait que GIMP lui-même s'affiche à l'écran, et demande bel et bien au compositeur Wayland d'afficher de points avec des couleurs sous forme de triplets RGB qui ne veulent certes rien dire sans profil de couleur, mais qu'il affiche tout de même.

      Je ne sais pas ce que les développeurs veulent faire, mais tel que je conçois les choses, lorsque je capture la couleur d'un point de l'écran, tout ce que je m'attends à avoir comme résultat dans GIMP, c'est une couleur qui, si je la dessine sur l'image, s'affichera exactement comme celle du point que j'ai capturé.

      Or, je dois vraiment manquer quelque chose, parce que ça me semble assez trivial en fait : pour qu'un point de la fenêtre de GIMP s'affiche exactement de la même couleur que celui qu'on a capturé, il me semble qu'il suffit que GIMP demande à Wayland d'afficher un point avec une couleur spécifié par exactement le même triplet RGB, qui certes ne veut rien dire sans profil de couleur, mais qui sera tout de même affiché, et affiché pareil, ce qui est ce que j'attends.

      Or donc, pour que GIMP demande au compositeur Wayland d'afficher un avec une couleur RGB donnée sans profil, il suffit… que cette couleur, dans l'espace colorimétrique de l'image, soit convertie par GIMP en le triplet RGB sans profil attendu. Or GIMP sait manifestement faire une certaine correspondance couleur de l'image → triplet RGB sans profil envoyé au compositeur, puisqu'il affiche les images d'une façon ou d'une autre. La correspondance inverse devrait être faisable, non ?

      • [^] # Re: Gestion des couleurs et capture

        Posté par 🚲 Tanguy Ortolo (site web personnel) le 27 avril 2023 à 20:10. Évalué à 6.

        

        Ce sera peut-être plus clair en expliquant le processus que j'imagine, comme ça il devrait être plus facile de voir quelle étape n'est pas possible et pourquoi.

        1. GIMP demande à capturer la couleur d'un point donné de l'écran.
        2. GIMP obtient un triplet RGB sans profil de couleur. On sait qu'un logiciel quelconque a demandé au compositeur d'afficher un point d'une couleur spécifiée par ce triplet.
        3. Maintenant, on se pose la question suivante : quelle couleur, dans l'image actuellement éditée dans GIMP, serait affichée en demandant au compositeur d'afficher un point avec une couleur spécifiée par ce même triplet ?
        4. La réponse devrait pouvoir s'obtenir en appliquant une fonction inverse de celle que GIMP utilise pour demander l'affichage des points de l'image (en supposant qu'elle est affichée à l'échelle d'un point de l'image pour un point de l'écran).

        • [^] # Re: Gestion des couleurs et capture

          Posté par tisaac (Mastodon) le 27 avril 2023 à 22:10. Évalué à 6.

          

          la pipette à couleurs présente dans l'ancrable Couleurs qui peut prélever une couleur n'importe où sur l'écran et qui s'appuie sur l'infrastructure fournie par l'OS ou par le bureau que vous êtes en train d'utiliser.

          La pipette ne fonctionne pas que dans GIMP => quand tu veux prendre une couleur hors GIMP, tu as bien potentiellement tous les problèmes exposés par Jehan, non ?

          Surtout, ne pas tout prendre au sérieux !

        • [^] # Re: Gestion des couleurs et capture

          Posté par Le Pnume le 28 avril 2023 à 09:24. Évalué à 6. Dernière modification le 28 avril 2023 à 09:25.

          

          Je vois au moins 1 pb, le multi écran.
          Tu as gimp sur l’écran 1 et tu utilises la pipette sur l’écran 2, d’après l'explication de Jehan, sans calibrage de tes 2 écrans, tu risques fort de ne pas avoir la couleur que tu désires sur ton écran 1.

        • [^] # Re: Gestion des couleurs et capture

          Posté par xryl669 le 28 avril 2023 à 10:52. Évalué à 8.

          

          Visiblement, sous Wayland, la pipette utilise une fonction qui retourne l'échantillonnage (triplet de couleur) du buffer de donnée image, et donc ni sa position, ni l'application concernée.

          Impossible donc pour Gimp de savoir que l'utilisateur a cliqué sur une image de Gimp (qui peut être mise à l'échelle par Wayland d'ailleurs (ce qui est très souvent le cas en 4K), donc avoir subit une interpolation. Bref, l'interface "sécurité" de Wayland qui isole les applications / le gestionnaire de fenêtre joue parfaitement son rôle, si bien que le résultat est inutile.

          Dans un monde pro, par exemple sur Apple, tu peux avoir un échantillonnage des pixels, et il est associé aux informations de profil de couleur (ce qui est, à la fois sécure et correct). Mais Wayland est très basique (trop) et visiblement, le bât blesse ici car l'information est manquante. Si en plus il faut attendre que ce soit aux clients de Wayland de faire le calcul de ceci, c'est mort avant plusieurs années, si jamais c'est fait un jour. Normalement, avec un bon protocole de fenêtre, chaque fenêtre/buffer pourrait avoir son propre profil de couleur et ce serait au gestionnaire de fenêtre de faire la conversion finale pour avoir la même chose sur un écran calibré donné. Typiquement, c'est ce que tu as dans Final Cut par exemple, lorsque tu preview un rush UHDTV sur un écran sRGB. L'image est très sombre (voire noire) sans ajustement de profil, pourtant elle est parfaitement visible dans la fenêtre de preview sous MacOS. Mais imagine la galère entre une fenêtre Gtk dans un environnement KDE qui n'ont aucune notion du profil des images/buffer.

          Je me suis déjà fait avoir une fois en travaillant sur un RAW pour impression avec une forte dynamique sur MacOS, qui rendait nickel sur l'écran du Mac calibré et qui, une fois imprimé en tableau pour un client, était tout écrasé. L'imprimeur n'a jamais voulu reconnaître qu'il ne prenait pas en compte le profil de couleur de l'image fournie seulement du sRGB par défaut (lequel ?). Bref, j'aurais dû convertir l'image avant l'export en sRGB type Windows et là, peut être que j'aurais eu les bonnes dynamiques.

      • [^] # Re: Gestion des couleurs et capture

        Posté par Jehan (site web personnel, Mastodon) le 10 mai 2023 à 22:06. Évalué à 10.

        

        Sommaire

        • Notre contexte: logiciels de graphisme
        • Élargissons tout de même le contexte (histoire de)
        • Le but de la gestion des couleurs: des couleurs justes et une référence

        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.

        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: Gestion des couleurs et capture

      Posté par ted (site web personnel) le 28 avril 2023 à 22:45. Évalué à 5.

      

      Merci pour les explication, mais comme Tanguy, j'ai encore un peu de mal sur le principe.

      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.

      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.

      Un LUG en Lorraine : https://enunclic-cappel.fr

      • [^] # Re: Gestion des couleurs et capture

        Posté par Jehan (site web personnel, Mastodon) le 28 avril 2023 à 23:35. Évalué à 5. Dernière modification le 28 avril 2023 à 23:37.

        

        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 ]

  • [^] # Re: Gestion des couleurs et capture

    Posté par Pierre Jarillon (site web personnel) le 28 avril 2023 à 10:09. Évalué à 9.

    

    Il doit me manquer une subtilité, parce que je ne vois pas la difficulté posée par la capture d'une couleur à l'écran.

    La perception des couleurs est un phénomène biologique. Si c'était un phénomène physique, ce serait beaucoup plus simple !
    Il y a de très bonnes vidéos sur Youtube perception des couleurs, je ne les ai pas toutes vues, aussi je vous conseille celle de David Louapre intitulée Qu'est-ce qu'une couleur ?.

    L'un des problèmes que pose la perception des couleurs est que le spectre de sensibilité d'un cône est décalé en moyenne de 5 nm entre les hommes et les femmes. Certaines femmes possèdent un quatrième type de cône et les daltoniens sont essentiellement des hommes. Dire que certains parlent d'égalité des sexes !

    Pour aller plus loin, voyez ce petit article consacré à Bases génétiques de la vision des couleurs.

    On a beau faire des chaines d'étalonnage de la chaine de couleur appareil photo - écran - imprimante, le résultat ne sera qu'approchant, car les spectres des pixels de la photo et ceux de l'écran ont des chances de mal coïncider et de ne pas correspondre à la couleur soustractive de l'image imprimée.

    Pour finir, j'évite de parler couleurs avec ma femme, parce que j'ai forcément toujours tort !

    • [^] # Re: Gestion des couleurs et capture

      Posté par Maderios le 28 avril 2023 à 11:43. Évalué à 10.

      

      Dire que certains parlent d'égalité des sexes

      Parler "d'égalité des sexes" n'a pas de sens puisque femmes et hommes sont biologiquement différents. Il s'agit en fait d'un raccourci pour parler de l'égalité en droits des sexes. Idem pour l'égalité des droits de tous les humains.

      • [^] # Re: Gestion des couleurs et capture

        Posté par devnewton 🍺 (site web personnel) le 26 mai 2023 à 08:58. Évalué à 2.

        

        Parler d'égalité des êtres humains n'a pas de sens puisque les humains sont tous différents, même les jumeaux :-)

        Lorsqu'on parle d'égalité pour les hommes et les femmes, on ne parle pas d'identité, d'uniformité ou d'égalité mathématique.

        Tu devrais faire un voyage en polysémie !

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Gestion des couleurs et capture

          Posté par Gil Cot ✔ (site web personnel, Mastodon) le 26 mai 2023 à 22:27. Évalué à 2.

          

          Il n’y a pas vraiment de polysémie mais bien des raccourcis malheureux… : tous les humains naissent libres et égaux en droits… (et pas identiques entre clones comme on le ferait grammaticalement dire à la phrase en la rabotant…) D’ailleurs, tu écris bien « égalité pour les » et non « égalité des » comme ç’aurait été le cas si l’égalité pouvait avoir un autre sens. ;)
          Ceci dit, mon utopie serait un monde équitable qu’il faudrait (pas juste le droit de pouvoir être présent au spectacle mais le droit de pouvoir le voir)
          

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: Gestion des couleurs et capture

            Posté par devnewton 🍺 (site web personnel) le 27 mai 2023 à 08:16. Évalué à 5.

            

            Marrant sur le dessin de droite, j'aurais plutôt vu tout le monde en train de jouer dans un parc.

            Là on a des pauvres qui n'ont pas de quoi de payer une place pour voir d'autres s'approprier un grand espace…

            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

            • [^] # Re: Gestion des couleurs et capture

              Posté par Gil Cot ✔ (site web personnel, Mastodon) le 27 mai 2023 à 09:15. Évalué à 3. Dernière modification le 27 mai 2023 à 09:17.

              

              Pour le premier point, tu as dépassé l’équité pour atteindre la liberté :-D
              

              Pour le second point, c’est un peu légaliste…
              
              …et très teinté de capitalisme moralisateur :-)
              
              (edit: sorry, but I hope it's still friday somewhere)

              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: Gestion des couleurs et capture

            Posté par Maderios le 29 mai 2023 à 19:08. Évalué à 0.

            

            "tous les humains naissent libres et égaux en droits"

            C'est tiré de "La déclaration des droits de l'homme et du citoyen" et dès l'énoncé, ce n'est pas respecté en France. Il faut croire que la moitié de l'humanité, les femmes, ne font pas partie des êtres humains. La France est presque le seul pays à remplacer le mot "Humains" par "Homme". C'est très symptomatique de notre culture. Les Droits des femmes sont quotidiennement bafoués, dont l'égalité salariale, dont la répartition des taches, dont l'accès aux responsabilités, dont la reconnaissance des mérites, etc… La liste est longue. Il faut dire que les Révolutionnaires de 1789 on commencé très fort en refusant tous Droits civiques aux femmes. L'abolition des privilèges s'arrêtait au respect de la norme patriarcale en vigueur depuis des millénaires. Cela continue, à gauche comme à droite, malgré les beaux discours militants/politiques qui défendent l'égalité.

            • [^] # Re: Gestion des couleurs et capture

              Posté par devnewton 🍺 (site web personnel) le 29 mai 2023 à 23:28. Évalué à 2.

              

              La France est presque le seul pays à remplacer le mot "Humains" par "Homme".

              Normal, le français n'ayant pas de genre neutre, c'est normal d'employer le genre dominant pour désigner à la fois les hommes et les femmes.

              On fait pareil avec les canards ou les moules, bien que leurs droits fondamentaux soient moins défendus :-)

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

              • [^] # Re: Gestion des couleurs et capture

                Posté par tisaac (Mastodon) le 29 mai 2023 à 23:36. Évalué à 3. Dernière modification le 29 mai 2023 à 23:41.

                

                Ben non, ton argument ne justifie pas que l'on utilise le terme Homme plutôt que Humain qui est un terme épicène.

                Surtout, ne pas tout prendre au sérieux !

              • [^] # Re: Gestion des couleurs et capture

                Posté par Gil Cot ✔ (site web personnel, Mastodon) le 29 mai 2023 à 23:50. Évalué à 2.

                

                Ici pas besoin d'avoir un genre neutre …puisqu'il y a justement une expression neutre bien compris de tout le monde. Mais comme tu l’écris, on a littéralement privilégié « le genre dominant » dans tous les sens et acceptations du terme puisque tu défends sa normalité (i.e. légitimer une domination…)

                Au fait, on utilise déjà un mot neutre pour les moules… et il n’en existe pas pour les canards (contrairement aux êtres humains.)Bref, exemples sans rapport.

                “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                • [^] # Re: Gestion des couleurs et capture

                  Posté par devnewton 🍺 (site web personnel) le 30 mai 2023 à 09:52. Évalué à 2.

                  

                  Beaucoup de gens ont vraiment du mal avec le fait qu'un mot peut avoir plusieurs sens : quand j'utilise dominant dans le précédent commentaire, c'est pour désigner le genre majoritairement utilisé.

                  Quand on parle des infirmières, on emploie le féminin, car la plupart des membres de cette profession sont des femmes, pas parce que les infirmières dominent les infirmiers.

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                  • [^] # Re: Gestion des couleurs et capture

                    Posté par Gil Cot ✔ (site web personnel, Mastodon) le 31 mai 2023 à 05:03. Évalué à 2.

                    

                    Ah ha… Peut-on dire que les gens ont du mal avec le fait qu’il y ait plusieurs chemins quand on en propose justement plusieurs ? (je m’en souviendrai pour les prochains labyrinthes que je créerai ; je dirai que les joueurs et joueuses sont bien/trop ce-que-tu-veux-de-nul en ne prenant pas systématiquement le bon chemin) :D
                    Tu vois que tu t'y perds toi-même parce-que beaucoup de gens vont faire comme toi, « désigner le genre majoritairement utilisé » et parler des infirmiers (à moins que tu insinuais que la plupart des membres de l’espèce humaine… ah oui cette stat justifiante…) ;)

                    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                    • [^] # Re: Gestion des couleurs et capture

                      Posté par devnewton 🍺 (site web personnel) le 31 mai 2023 à 18:07. Évalué à 3.

                      

                      On s'y perds, car c'est l'usage qui prime, pas la logique ou le sens.

                      Si les gens disent disent la wifi, est-ce parce que ça sonne bien ou [interprétation psychanalytique censuré] ?

                      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.