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 xryl669 . En réponse à la dépêche GIMP 2.10.34 est sorti. É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.