calibrage moniteur Gamma 2.2 ou courbe L* ?

Démarré par Christophe Métairie, Septembre 13, 2015, 15:57:48

« précédent - suivant »
Imprimer
En bas Pages 1 2 3 4 5 6 7 8 9 10 11 12 13
Actions de l'utilisateur

ambre099

#50
Septembre 15, 2015, 20:23:18 Dernière édition: Septembre 15, 2015, 20:34:41 par ambre099
.

olivier1010

#51
Septembre 15, 2015, 20:32:36
Citation de: olivier1010 le Septembre 15, 2015, 20:17:46
Ok on est d'accord. Je pensais que vous aviez une différence à l'impression selon les profils écrans.

Il est logique que les courbes de calibration sRGB donnent un rendu intermédiaire. Reste à savoir pourquoi on obtient ces différences de rendu.

Les courbes gamma sont destinées à linéariser la liaison vidéo afin de profiter au mieux de la faible profondeur de quantification entre l'écran et le PC. Le profil écran qui tient compte de ces courbes gamma doit les décrire, et l'application doit en tenir compte pour au final avoir un rendu identique en théorie quelque soit la calibration adoptée, tout du moins sur du matériel haut de gamme supportant la calibration hardware et une liason PC / écran 30 bits.

Une explication probable de ces différences, est que Photoshop ne tient peut être pas compte de toutes les données du profil écran. Il ne lit peut être pas les courbe L* ou sRGB, il lit peut être simplement l'approximation gamma soit gamma 2.2, ce qui expliquerait les différences de luminosité dans les bas niveaux pour sRGB et L*, juste à l'endroit ou ces trois courbes diffèrent le plus.

Je ne suis même pas sur que ces courbes TRC sont toujours intégrées dans le profil écran. A ne pas confondre avec les tags vcgt qui sont les valeurs de calibration par la carte vidéo, également optionnelles. Il me semble de mémoire en tout cas pour ICCv2 que seules les valeurs gamma sont obligatoirement présentes en partenariat avec une simple matrice des primaires et que l'intégration est optionnelle. Si les courbes TRC ne sont pas présentes dans le profil ou pas lue par l'application il est logique qu'on obtienne des différences entre écran et impression selon la courbe de TRC choisie qui n'est donc connue dans ce cas que par l'écran mais pas par l'application qui a la responsabilité d'envoyer des données corrigées à l'écran à travers son profil.

Sinon si vous tenez réellement à utiliser L*, ce qui me semble un peu inutile puisque vous avez certainement un écran haut de gamme à calibration hardware et liaison 30 bits, vous pouvez toujours compenser l'affichage en mode aperçu d'épreuve en modifiant légèrement la table de correspondance inverse (B2A) du profil d'impression afin de faire concorder avec l'écran. C'est un peu du bricolage mais cela devrait marcher...

Le plus simple est peut être de rester en gamma 2.2... Puisque si votre écran est en 30 bits le L* ne devrait pas donner d'avantages notables en terme de précision de luminosité dans les basses lumières, sachant que les différences sont quand même faibles entre L* et gamma 2.2 : je pense qu'elles sont pratiquement gommées par le passage en 30 bits qui doit permettre avec une calibration en gamma 2.2 d'afficher toutes les valeurs que L* pourrait afficher sur une liaison 24 bits (un matheux pourrait il nous dire le delta maxi de pourcentage en luminance entre ces deux setups ?)

Je suis tout de même curieux de connaître la raison réelle de ces différences qui ne devraient pas exister avec un écran à calibration hardware 14 bits et une liaison vidéo 30 bits. Il faudrait peut être essayer avec un logiciel dont on est certain qu'il tient prend bien en compte les courbes TRC lors de la lecture du profil écran.

Je viens juste de vérifier que le mode écran 30 bits reste bien actif quand on passe en aperçu d'épreuve, et c'est bien le cas. Donc le problème ne vient pas de là (j'ai eu un doute à un moment).

Benaparis

#52
Septembre 15, 2015, 20:39:52

Citation de: asak le Septembre 15, 2015, 19:51:13
Effectivement  nous avons probablement la meme config. Par contre colornavigator est en couleur native ou prostar ?

Couleur Native...je serai bien curieux de connaître, pour le domaine de la photo, de l'intérêt travailler en terme de gamut autrement qu'avec les capacités propres du moniteurs.
Instagram : benjaminddb

asak

#53
Septembre 15, 2015, 20:47:22
Avoir la meme courbe de réponse que l espace de travàil.

Benaparis

#54
Septembre 15, 2015, 21:08:58
Citation de: asak le Septembre 15, 2015, 20:47:22Avoir la meme courbe de réponse que l espace de travàil.

Mais un gamut n'est pas une courbe de réponse...La courbe de réponse de mon moniteur est bien L* en revanche le gamut est bien "natif" pour utiliser toute la capacité couleur du moniteur (en l'occurence proche du Adobe), si vous utilisez ColorNavigator le distinguo est assez clair.
Instagram : benjaminddb

asak

#55
Septembre 15, 2015, 21:26:10
J étais comme toi il n y a pas longtemps. En changeant j ai trouvé que ça me semblais  plus juste notamment en faisant une BdB mais je n ai pas encore quantifié .

Benaparis

#56
Septembre 15, 2015, 21:35:14
Citation de: asak le Septembre 15, 2015, 21:26:10J étais comme toi il n y a pas longtemps. En changeant j ai trouvé que ça me semblais  plus juste notamment en faisant une BdB mais je n ai pas encore quantifié .

Ça me paraît très bizarre...en plus je ne vois pas le rapport avec la balance des blancs...ce qui m'a donné des balances de blancs impeccable c'est d'avoir réalisé un bon profil boîtier...ce qui a du sens.

Je ne suis pas un spécialiste mais encore encore fois j'insiste je ne suis pas du tout sûr et ce d'autant que je ne vois rien qui justifie, pour la photo en tout cas, de choisir un gamut différent du gamut natif de l'écran.
Instagram : benjaminddb

Miaz3

#57
Septembre 15, 2015, 21:40:11
Citationle delta maxi de pourcentage en luminance
Le delta c'est bien le end-to-end gamma ? (je viens de la video, hein) donc pour un gamma de 2.2 il faudrait qu'il soit entre 1.1 et 1.2, non ?
et pour le print vers 1.4 ?

Ensuite concernant les détails purement mathématiques il est préférable d'aller jeter un œil ici : https://fr.wikipedia.org/wiki/Loi_de_Weber-Fechner
Et pour les geek ici : http://www.normankoren.com/makingfineprints1A.html#QuickGamma

Verso92

#58
Septembre 15, 2015, 21:41:19
J'en profite pour poser la question du candide : j'avais cru comprendre que le gamut était un terme qui décrivait l'ensemble des couleurs reproductibles par un périphérique (un écran, par exemple). Voir définition WikiPédia ci-dessous :

"En synthèse des couleurs, synthèse additive ou synthèse soustractive, le gamut, ou gamut de couleur est la partie de l'ensemble des couleurs qu'un certain type de matériel, qu'il soit appareil photographique, scanner informatique, écran d'ordinateur, rétroprojecteur, vidéoprojecteur, procédé d'imprimerie ou imprimante, permet de reproduire."
Quand on parle de gamut 2.2 ou 1.8, il s'agit bien d'autre chose, n'est-ce pas ?

Plutôt lié à une courbe de réponse ?
Merci d'éclairer ma lanterne...
(c'est une vraie question, hein !  ;-)

olivier1010

#59
Septembre 15, 2015, 21:55:47
Citation de: asak le Septembre 15, 2015, 20:47:22
Avoir la meme courbe de réponse que l espace de travàil.

Dans quel but ? Il est parfois utile d'utiliser un gamma de 1.0 pour améliorer la qualité de certains traitements. Tout dépend de ce qu'on a à faire.

Les systèmes CMS permettent justement de faire correspondre des espaces couleurs avec des gamuts et gamma différents, avec en plus la possibilité de choisir le rendu lorsque les couleurs sortent du gamut, ou même forcer la correspondance pour une colorimétrie absolue, ce qui est utile dans le domaine du textile par exemple si on veut une correspondance parfaite entre les tissus et les impressions. Ils permettent aussi d'adapter les contrastes avec l'adaptation du point noir.

En ce qui concerne les courbes de calibration écran, elles servent à utiliser au mieux la liaison vidéo de faible profondeur de quantification, en pratique 8 ou 10 bits par canal. Il faut donc choisir une courbe qui s'approche de celle de la vision humaine pour obtenir un espace couleur de visualisation le plus homogène possible.

Les différences sont faibles entre L* et gamma 2.2. Et comme je le disais sont certainement gommées par la possibilité d'attaquer aujourd'hui les écrans en 10 bits par canal.

Je pense que le L* n'a plus tellement sa raison d'être aujourd'hui en 10 bits par canal, surtout s'il pose des problèmes avec les logiciels comme cela semble être le cas ici. Cela changera peut être à l'avenir pour le Rec2020 qui est un espace plus large où 10 bits redeviendra un peu juste et ou il faudra donc peut être adopter à nouveau un gamma plus évolué que le 2.2 pour retrouver une bonne homogénéité. Idéalement en Rec2020 il faudra certainement passer en 12 bits par canal sur les configurations haut de gamme, ce qui est d'ailleurs prévu dans la nouvelle norme HDMI 2.0a.

Je dirais que le L* n'a sa raison d'être que sur les écrans à calibration hardware 12 ou 14 bits, et lorsque la liaison vidéo est en 8 bits. A condition que les logiciels sachent l'interpréter, ce qui visiblement n'est pas toujours le cas.

Miaz3

#60
Septembre 15, 2015, 22:06:49
Citation de: Verso92 le Septembre 15, 2015, 21:41:19
J'en profite pour poser la question du candide : j'avais cru comprendre que le gamut était un terme qui décrivait l'ensemble des couleurs reproductibles par un périphérique (un écran, par exemple). Voir définition WikiPédia ci-dessous :

"En synthèse des couleurs, synthèse additive ou synthèse soustractive, le gamut, ou gamut de couleur est la partie de l'ensemble des couleurs qu'un certain type de matériel, qu'il soit appareil photographique, scanner informatique, écran d'ordinateur, rétroprojecteur, vidéoprojecteur, procédé d'imprimerie ou imprimante, permet de reproduire."
Quand on parle de gamut 2.2 ou 1.8, il s'agit bien d'autre chose, n'est-ce pas ?

Plutôt lié à une courbe de réponse ?
Merci d'éclairer ma lanterne...
(c'est une vraie question, hein !  ;-)

Alors, espace de couleurs ou gamut ?! ;)

asak

#61
Septembre 15, 2015, 22:15:49
At  olivier 1010
Ce n est pas moi qui te donnerai tord; mais entre photoshop et colornavgator dis moi que c est compatible CMS à mon avis non mais si tu as les info .

ambre099

#62
Septembre 15, 2015, 22:21:54
Citation de: Verso92 le Septembre 15, 2015, 21:41:19
J'en profite pour poser la question du candide : j'avais cru comprendre que le gamut était un terme qui décrivait l'ensemble des couleurs reproductibles par un périphérique (un écran, par exemple). Voir définition WikiPédia ci-dessous :

"En synthèse des couleurs, synthèse additive ou synthèse soustractive, le gamut, ou gamut de couleur est la partie de l'ensemble des couleurs qu'un certain type de matériel, qu'il soit appareil photographique, scanner informatique, écran d'ordinateur, rétroprojecteur, vidéoprojecteur, procédé d'imprimerie ou imprimante, permet de reproduire."
Quand on parle de gamut 2.2 ou 1.8, il s'agit bien d'autre chose, n'est-ce pas ?

Plutôt lié à une courbe de réponse ?
Merci d'éclairer ma lanterne...
(c'est une vraie question, hein !  ;-)

On parle de gamma 2.2 qui est la courbe de réponse tonale.

MBe

#63
Septembre 15, 2015, 22:22:28
Citation de: Verso92 le Septembre 15, 2015, 21:41:19
J'en profite pour poser la question du candide : j'avais cru comprendre que le gamut était un terme qui décrivait l'ensemble des couleurs reproductibles par un périphérique (un écran, par exemple). Voir définition WikiPédia ci-dessous :

"En synthèse des couleurs, synthèse additive ou synthèse soustractive, le gamut, ou gamut de couleur est la partie de l'ensemble des couleurs qu'un certain type de matériel, qu'il soit appareil photographique, scanner informatique, écran d'ordinateur, rétroprojecteur, vidéoprojecteur, procédé d'imprimerie ou imprimante, permet de reproduire."
Quand on parle de gamut 2.2 ou 1.8, il s'agit bien d'autre chose, n'est-ce pas ?

Plutôt lié à une courbe de réponse ?
Merci d'éclairer ma lanterne...
(c'est une vraie question, hein !  ;-)
Le gamma (appellation de la courbe de réponse des tubes cathodiques Sortie = entrée ^ gamma) ou TRC ( Tonal Response Curve) correspond à une courbe de réponse.
Le gamut correspond à un "volume" de couleurs affichables ou imprimables. (http://www.chassimages.com/forum/index.php/topic,95384.msg1639591.html#msg1639591 ;))
C'est bien, 2 caractéristiques bien différentes.

Verso92

#64
Septembre 15, 2015, 22:38:12
Citation de: ambre099 le Septembre 15, 2015, 22:21:54
On parle de gamma 2.2 qui est la courbe de réponse tonale.
Citation de: MBe le Septembre 15, 2015, 22:22:28
Le gamma (appellation de la courbe de réponse des tubes cathodiques Sortie = entrée ^ gamma) ou TRC ( Tonal Response Curve) correspond à une courbe de réponse.
Le gamut correspond à un "volume" de couleurs affichables ou imprimables. (http://www.chassimages.com/forum/index.php/topic,95384.msg1639591.html#msg1639591 ;))
C'est bien, 2 caractéristiques bien différentes.

Oups, désolé : j'ai fait une confusion malencontreuse entre les deux termes (la fatigue ?)... merci de m'avoir remis dans le droit chemin !

;-)

fred94-

#65
Septembre 15, 2015, 22:55:06
Salut,

Sinon la question ou plutôt le soucis du L* c'est quoi au final?

MBe

#66
Septembre 15, 2015, 23:02:24
Citation de: Verso92 le Septembre 15, 2015, 22:38:12
Oups, désolé : j'ai fait une confusion malencontreuse entre les deux termes (la fatigue ?)... merci de m'avoir remis dans le droit chemin !

;-)

Non non pas la fatigue, tu avais bien lu  ;)

MBe

#67
Septembre 15, 2015, 23:04:39
Citation de: Christophe Métairie le Septembre 15, 2015, 17:51:07
je me suis amusé a faire une capture d'écran des courbes des différents profils dans les ombres:

Les courbes de TRC tracées  (il n'y a pas le sRGB)

MBe

#68
Septembre 15, 2015, 23:06:07
La zone de basses lumières ou vous constatez un écart :

MBe

#69
Septembre 15, 2015, 23:21:43 Dernière édition: Septembre 15, 2015, 23:39:02 par MBe
Citation de: Christophe Métairie le Septembre 15, 2015, 09:36:16
oui Mbe, en fait je m'aperçois que j'ai inversé les 2 rendus dans ma question ( le rendu écran en L* est plus lumineux que le Gamma 2.2 ), mais le problème reste le même : la correspondance écran tirage est meilleure avec un écran en gamma 2.2  Clin d'oeil

comme quoi une question toute simple a priori donne un débat intéressant, et selon l'utilisation que l'on a des ses images certains préfèrent un écran en L* , d'autres en gamma 2.2 ...

C Métairie

Je comprends mieux.

Avec un TRC L*, dans les basses lumières, la progression est plus linéaire, en limitant les aplats (si il est possible de les voir).

Citation de: Christophe Métairie le Septembre 15, 2015, 09:36:16
le profil écran ne modifie pas la sortie papier qui est identique quel que soit le profil écran choisi, mais la correspondance entre l'écran et l'impression est plutôt bonne dans un cas ( écran en gamma 2.2 ) et assez fausse dans les très basses lumières quand l'écran est en L*
C Métairie

Je suis bien d'accord avec cette assertion.

Quelques questions / commentaires
- Avec un profil d'affichage en L*, il est préférable de travailler dans espace de travail avec un TRC  L* ou de finaliser dans tiff avec un profil L* afin de garder la cohérence.
- La compensation du point noir modifie la dynamique du fichier, est ce qu'il ne participe pas à ce défaut de correspondance? (j'avoue que j'utilise quasiment jamais cette correspondance, trouvant bien souvent que l'effet de rendu globale sur une image est trop fade avec cette compensation)

Autre réflexion : Un tracé du codage du L* du profil icc de l'écran comparé à la version théorique serait peut être instructif (?)

fred94-

#70
Septembre 15, 2015, 23:38:22
Donc l écran ne code pas le TIFF mais l espace de travail choisi+le profil icc d export "image" + profil icc d imprimante.
Le soucis de dégradation 10, 8 bits... N'est qu'une dégradation d affichage et non de codage du fichier TIFF?

J'ai bon ou pas?

Vous avez un ensemble hardware 30bits....etc, vous traiter un TIFF avec un joli dégradé de gris perfecto que vous visualisez de manière parfaite et vous m'envoyer ce fichier.

Moi je l'ouvre dans Photoshop avec le même espace de travail sur un écran pourri mais je l'imprime avec le même matos que vous sans rien touché, j'ai le même résultat ou pas?

MBe

#71
Septembre 15, 2015, 23:55:27
Pour Christophe Metairie :
Est ce que votre profil d'écran (en L*) comporte une balise vcgt? si oui, est ce bien une droite?

olivier1010

#72
Septembre 16, 2015, 01:19:16 Dernière édition: Septembre 16, 2015, 01:33:27 par olivier1010
Citation de: MBe le Septembre 15, 2015, 23:55:27
Pour Christophe Metairie :
Est ce que votre profil d'écran (en L*) comporte une balise vcgt? si oui, est ce bien une droite?

Je vois où vous voulez en venir, pour rappel cette balise est utilisée pour charger une table LUT de calibration dans la carte vidéo afin de modifier les valeurs RVB envoyées vers l'écran (calibration par la carte vidéo).

Effectivement si ces courbes ne sont pas des droites, avec un écran à calibration hardware, il y aurait une double calibration, ce qui fausse tout.

Avec Colornavigator sur un écran EIZO, les courbes VCGT évidement sont des droites (codées en 16 bits), je l'ai vérifié avec l'utilitaire gretag pour ouvrir les tables vcgt. Il existe un utilitaire encore plus pointu dans displaycalgui qui permet de voir au choix les courbes VCGT du profil, ou celles réellement chargées dans la carte vidéo pour chaque écran. Dans les deux cas elles sont droites ce qui est normal en calibration hardware et ne doit pas en être autrement.

D'autre part ce serait un non sens d'utiliser ces courbes pour lire le gamma exact du profil, puisque ces courbes VCGT ne sont pas les courbes tonales théoriques, mais les courbes nécessaires à la calibration de l'écran, elles sont donc différentes des courbes théoriques L* ou gamma 2.2.
Moi je pense que Photoshop ne tient peut être pas compte de la courbe L* ou sRGB du profil et affiche simplement en gamma 2.2 avec les calibration L* ou sRGB.

Ce gamma 2.2 est peut être écrit dans le profil écran pour chaque canal R, V et B, en tant qu'approximation pour les logiciels qui ne vont pas plus loin dans la lecture du profil. Et aussi historiquement pour la rétrocompatibilité car le gamma des trois canaux R,V et B si mes souvenirs sont bons étaient pratiquement les seules valeurs disponibles avec les coordonnées xy des primaires pour un profil écran dans les débuts des CMS.

Il serait intéressant de basculer sur le CMS microsoft, dans Photoshop, pour voir s'il y a un comportement différent. Et tester également avec d'autres applications, par exemple rawtherapee.

Une question pour Christophe, quels sont les versions icc des profils d'écran et d'impression ? V2 ou V4 ? Il serait intéressant d'essayer avec un profil d'écran V4 si vous êtes en V2 ou vice versa. Et également de modifier manuellement la table B2A du profil d'impression pour voir si vous arrivez à rattraper ces écarts de luminosité avec le profil écran L* sans détruire le reste des correspondances au niveau colorimétrie. Pour rappel la table B2A est celle dans un profil V4 qui gère la correspondance entre l'image imprimée et l'affichage écran. Elle ne modifie en rien l'image imprimée, qui est elle gérée par la table A2B.

Sinon je pense que le but du L* à l'époque de son apparition était d'homogénéiser les couleurs écran dans le cadre d'une liaison vidéo minimaliste en 8 bits par canal, tout juste suffisante pour passer sans trop de banding un espace sRGB ou plus difficilement AdobeRGB. L'augmentation de luminance est plus à mon avis une conséquence fâcheuse de certains logiciels qui ne savent pas compenser pour le L* car ils se basent peut être sur un gamma 2.2 qui est l'approximation la plus proche.

Puis est arrivé le 10 bits, qui permet d'afficher un adobeRGB parfaitement lisse avec une simple calibration (hardware tout de même) gamma 2.2. Si on regarde ce que fait Eizo, leur réglage par défaut est gamma 2.2 pour le mode photo. Une remarque qui n'engage que moi : si L* était vraiment utile et sans faille coté implémentation, on le verrait plus souvent sur des systèmes très haut de gamme dans les réglages par défaut.

Si l'on regarde ce qu'il se passe dans colornavigator 6 lorsqu'on choisit une cible avec une courbe L*, il devient impossible de sélectionner "gamma" dans les options d'écriture du profil, seule la table LUT est disponible pour la caractérisation des courbes de tons pour la génération d'un profil V2, et idem pour la génération d'un profil V4 avec en plus la possibilité de générer une courbe paramétrique, ce qui est d'ailleurs une grosse nouveauté dans les profils en V4. L'option "gamma" est une simple écriture de trois valeurs gamma dans le profil, une pour chaque canal, à l'ancienne :)

Le tout est de savoir si les logiciels utilisés sont capables de lire ces tables LUT ou ces courbes paramétriques, et si non sur quoi ils se basent pour les courbes tonales, il faudrait regarder à l'intérieur d'un profil mais je pense que lorsqu'un logiciel de calibration écrit un profil écran avec des tables LUT pour décrire les trois gradations tonales de L* ou sRGB, il écrit également pour rétrocompatibilité une valeur gamma approchante, soit 2.2 pour L* et sRGB. C'est peut être cette valeur 2.2 qui est prise en compte par Photoshop au lieu des vrais valeurs de correspondances tonales écrites dans les courbes LUT caractérisant L* dans un profil d'écran V2 ou V4.

il serait intéressant également de générer des profils V4 avec description des courbes tonales par équations paramétriques, et de voir les réactions de Photoshop et des autres logiciels.

olivier1010

#73
Septembre 16, 2015, 01:33:59 Dernière édition: Septembre 16, 2015, 01:46:05 par olivier1010
Je vois où vous voulez en venir, pour rappel cette balise est utilisée pour charger une table LUT de calibration dans la carte vidéo afin de modifier les valeurs RVB envoyées vers l'écran (calibration par la carte vidéo).

Effectivement si ces courbes ne sont pas des droites, avec un écran à calibration hardware, il y aurait une double calibration, ce qui fausse tout.

Avec Colornavigator sur un écran EIZO, les courbes VCGT évidement sont des droites (codées en 16 bits), je l'ai vérifié avec l'utilitaire gretag pour ouvrir les tables vcgt. Il existe un utilitaire encore plus pointu dans displaycalgui qui permet de voir au choix les courbes VCGT du profil, ou celles réellement chargées dans la carte vidéo pour chaque écran. Dans les deux cas elles sont droites ce qui est normal en calibration hardware et ne doit pas en être autrement.

D'autre part ce serait un non sens d'utiliser ces courbes pour lire le gamma exact du profil, puisque ces courbes VCGT ne sont pas les courbes tonales théoriques, mais les courbes nécessaires à la calibration de l'écran, elles sont donc différentes des courbes théoriques L* ou gamma 2.2.
Moi je pense que Photoshop ne tient peut être pas compte de la courbe L* ou sRGB du profil et affiche simplement en gamma 2.2 avec les calibration L* ou sRGB.

Ce gamma 2.2 est peut être écrit dans le profil écran pour chaque canal R, V et B, en tant qu'approximation pour les logiciels qui ne vont pas plus loin dans la lecture du profil. Et aussi historiquement pour la rétrocompatibilité car le gamma des trois canaux R,V et B si mes souvenirs sont bons étaient pratiquement les seules valeurs disponibles avec les coordonnées xy des primaires pour un profil écran dans les débuts des CMS.

Il serait intéressant de basculer sur le CMS microsoft, dans Photoshop, pour voir s'il y a un comportement différent. Et tester également avec d'autres applications, par exemple rawtherapee.

Une question pour Christophe, quels sont les versions icc des profils d'écran et d'impression ? V2 ou V4 ? Il serait intéressant d'essayer avec un profil d'écran V4 si vous êtes en V2 ou vice versa. Et également de modifier manuellement la table B2A du profil d'impression pour voir si vous arrivez à rattraper ces écarts de luminosité avec le profil écran L* sans détruire le reste des correspondances au niveau colorimétrie. Pour rappel la table B2A est celle dans un profil V4 qui gère la correspondance entre l'image imprimée et l'affichage écran. Elle ne modifie en rien l'image imprimée, qui est elle gérée par la table A2B.

Sinon je pense que le but du L* à l'époque de son apparition était d'homogénéiser les couleurs écran dans le cadre d'une liaison vidéo minimaliste en 8 bits par canal, tout juste suffisante pour passer sans trop de banding un espace sRGB ou plus difficilement AdobeRGB. L'augmentation de luminance est plus à mon avis une conséquence fâcheuse de certains logiciels qui ne savent pas compenser pour le L* car ils se basent peut être sur un gamma 2.2 qui est l'approximation la plus proche.

Puis est arrivé le 10 bits, qui permet d'afficher un adobeRGB parfaitement lisse avec une simple calibration (hardware tout de même) gamma 2.2. Si on regarde ce que fait Eizo, leur réglage par défaut est gamma 2.2 pour le mode photo. Une remarque qui n'engage que moi : si L* était vraiment utile et sans faille coté implémentation, on le verrait plus souvent sur des systèmes très haut de gamme dans les réglages par défaut.

Si l'on regarde ce qu'il se passe dans colornavigator 6 lorsqu'on choisit une cible avec une courbe L*, il devient impossible de sélectionner "gamma" dans les options d'écriture du profil, seule la table LUT est disponible pour la caractérisation des courbes de tons pour la génération d'un profil V2, et idem pour la génération d'un profil V4 avec en plus la possibilité de générer une courbe paramétrique, ce qui est d'ailleurs une grosse nouveauté dans les profils en V4. L'option "gamma" est une simple écriture de trois valeurs gamma dans le profil, une pour chaque canal, à l'ancienne :)

Le tout est de savoir si les logiciels utilisés sont capables de lire ces tables LUT ou ces courbes paramétriques, et si non sur quoi ils se basent pour les courbes tonales, il faudrait regarder à l'intérieur d'un profil mais je pense que lorsqu'un logiciel de calibration écrit un profil écran avec des tables LUT pour décrire les trois gradations tonales de L* ou sRGB, il écrit également pour rétrocompatibilité une valeur gamma approchante, soit 2.2 pour L* et sRGB. C'est peut être cette valeur 2.2 qui est prise en compte par Photoshop au lieu des vrais valeurs de correspondances tonales écrites dans les courbes LUT caractérisant L* dans un profil d'écran V2 ou V4.

il serait intéressant également de générer des profils écran V4 avec description des courbes tonales par équations paramétriques, et de voir les réactions de Photoshop et des autres logiciels à cette nouveauté des V4.

Verso92

#74
Septembre 16, 2015, 04:58:13 Dernière édition: Septembre 16, 2015, 05:06:03 par Verso92
Citation de: fred94- le Septembre 15, 2015, 23:38:22
Donc l écran ne code pas le TIFF mais l espace de travail choisi+le profil icc d export "image" + profil icc d imprimante.

Les couleurs contenues dans le TIFF seront codées de façon différente suivant l'espace de couleur choisi (les différences seront d'autant plus importantes que les couleurs seront en limite de gamut).
L'écran affichera l'image en fonction de son profil icc propre (correction de ses défauts d'affichage) et le logiciel permettra, dans le cas d'un épreuvage, de simuler le rendu du papier choisi (via le profil icc imprimante + encre + papier).
Citation de: fred94- le Septembre 15, 2015, 23:38:22
Le soucis de dégradation 10, 8 bits... N'est qu'une dégradation d affichage et non de codage du fichier TIFF?

Oui, bien sûr : dans certains cas, l'affichage en 3 x 10 bits permettra de limiter les cassures dans les fins dégradés visualisées à l'écran par rapport à un affichage en 3 x 8 bits.
Citation de: fred94- le Septembre 15, 2015, 23:38:22
Vous avez un ensemble hardware 30bits....etc, vous traiter un TIFF avec un joli dégradé de gris perfecto que vous visualisez de manière parfaite et vous m'envoyer ce fichier.

Moi je l'ouvre dans Photoshop avec le même espace de travail sur un écran pourri mais je l'imprime avec le même matos que vous sans rien touché, j'ai le même résultat ou pas?

Même si tu n'as pas le même espace de travail (ça ne changera que la visualisation, sauf si conversion de ta part), tu auras le "même" résultat à l'impression (sous réserve que tu utilises le même matériel pour imprimer avec les mêmes profils d'impression).
Imprimer
En haut Pages 1 2 3 4 5 6 7 8 9 10 11 12 13
Actions de l'utilisateur