Télécharger les profils ICC pour la photographie

[Nikojorj]

Si tu y vois des avantages pour l'affichage c'est déjà suffisamment significatif pour y avoir recours non?
L'utilisation d'un espace couleur en L* est là pour garantir la cohérence avec l'affichage.

Ben justement, c'est ce concept de "cohérence" que j'ai du mal à saisir.

[fred134]

Si cela vous amuse de faire joujou avec les curseurs dans un sens puis dans un autre pour garder le "même contraste" apparent libre à vous.

Exact, je ne l'avais pas constaté jusque là avec les quelques images que j'avais développées en espace de travail linéaire, mais en essayant d'autres images la conversion dans PS entre espaces de gamma différents change les tonalités, même en 16 bits.

Bizarre. Un défaut du moteur de conversion ou de l'affichage, à votre avis ?

[Samoreen]

Si cela vous amuse de faire joujou avec les curseurs dans un sens puis dans un autre pour garder le "même contraste" apparent libre à vous.

Essayez de nous convaincre en montrant quelque chose de probant. Par exemple, partez d'un fichier RAW, comparez le processus habituel (je charge dans Lightroom, je fais quelques réglages, avec une excursion éventuelle dans PS - réglé en Prophoto pour simplifier -, je reviens dans LR et j'imprime) avec votre processus à partir du même fichier, pour arriver à l'impression, en détaillant ce que vous faites (parce que jusque là, je n'ai rien lu de très clair) et démontrez nous que votre flux est meilleur, plus court, plus précis avec des arguments qui nous donnent envie de tester.

Essayez de faire ça

- sans faire du LR-bashing toutes les 2 lignes (je crois parfois lire du Linuxien tapant sur Windows à tours de bras)
- en étant précis et clair (pas de sabir abscons destiné aux initiés ou plutôt aux non-initiés afin d'être sûr qu'ils ne comprennent rien)
- en vous assurant que tout ça est réalisable à la fois par les utilisateurs de Mac OS et de Windows
- en démontrant clairement que la qualité du résultat obtenu est supérieure et/ou que cela nous fait gagner du temps

Quand j'aurai tout ça noir sur blanc, mon attention sera probablement plus soutenue. Pour le moment, je n'ai pas le sentiment de devoir manipuler les curseurs de LR plus que de raison et le flux de travail depuis LR est plutôt efficace et rapide. Quand je lis que LR et ACR font n'importe quoi, je suis dans le doute, vu que depuis que j'accroche des tirages issus de LR sur les cimaises, personne ne s'en est jamais rendu compte. Je ne demande qu'à être convaincu que je suis dans l'erreur.

[Jean Delmas]

Je fais une petite remarque : LR utilise en interne Melissa, c'est à dire un D50 avec un sRGB TRC (donc env 2.2 'approximation'). Le sortir en ProPhoto D50 G1.8 est une erreur car Gamma 1.8. Il faut l'exporter à ce moment là en Melissa D50 sRGB TRC pour en assurer la cohérence (ou en Iridient D50 sRGB TRC).

Bonjour Salomé, bonjour à tous et à toutes.

1 - Melissa RGB n'est pas « l'espace interne de LR »

Comme Nikojorj l'a remarqué plus haut, Melissa n'est pas utilisé par LR pour ses calculs internes mais pour son interface utilisateur. Par exemple, c'est dans Melissa RGB que le logiciel donne les nombres RGB affichés dans les histogrammes ou en réponse à la pipette. C'est aussi dans Melissa RGB que sont définis les aperçus affichés par le module développement (les autres modules préférant Adobe RGB (1998)).

Cet espace n'est pas le même que celui que LR utilise « en interne ». Je suppose que vous entendez par là l'espace dans lequel sont codés les nombres RGB sur lesquels LR opère ses calculs quand l'utilisateur manipule ses curseurs et autres instruments d'optimisation d'image. Cet espace-là, n'est pas Melissa mais un espace ayant les mêmes primaires et un gamma=1 comme dans la plupart des logiciels de développement RAW.  Adobe, comme P1, a sagement choisi d'effectuer ses calculs dans un espace sans correction gamma, situant ainsi l'espace des calculs dans la continuité tonale linéaire de l'espace du capteur.

2 - Mauvaises nouvelles des pertes de niveaux tonals dues aux erreurs de quantification en sortie de développement RAW

Quand LR exporte une image sous la forme d'un fichier TIFF RGB, il encode ce dernier avec la courbe inverse de la « courbe de réponse tonale nominale de l'espace ». Si l'espace de sortie choisi est Adobe RGB (1998), il élève donc les nombres RGB « internes » à la puissance 1/2,2. Si c'est ProPhoto RGB ou eciRGB (v1) il les élève à la puissance 1/1,8. Si c'est eciRGB_v2 ou ProStar RGB, il transforme les nombres RGB avec la formule inverse de L* (c'est-à-dire avec la formule permettant de calculer la luminance relative Y à partir de la clarté L*).

Bien entendu, cette cuisine s'opère sur des nombres entiers et génère donc des erreurs de quantification plus ou moins grandes selon la courbe tonale de sortie. C'est ainsi que, pour une résolution tonale de 16 bits, le nombre de niveaux tonals de sortie passe de 65536 aux valeurs décevantes qui suivent :

- Pour un encodage avec gamma = 2,2 -> Nombre de niveaux tonals en sortie = 47006
- Pour un encodage avec gamma = 1,8 -> Nombre de niveaux tonals en sortie = 51566
- Pour un encodage avec L*               -> Nombre de niveaux tonals en sortie = 44507

Manque de pot, mais c'est la faute à l'arithmétique (que l'on doit respecter car c'est la reine des mathématiques), vous voyez que, pour cette première étape d'encodage de l'image (c'est-à-dire en gros du capteur vers l'espace RGB de sortie), c'est l'exportation avec une courbe de réponse L* qui fait perdre le plus grand nombre de niveaux tonals et c'est celle basée sur 1,8 qui en fait perdre le plus faible nombre...

Mais rassurez vous Salomé, heureuse héritière d'un outil sans pareil, cette dégradation du nombre de niveaux tonals n'a AUCUNE espèce de conséquence pratique. Vous pouvez donc vous assoupir tranquillement sur les gazons fleuris de l'université anglaise que vous qualifiez modestement de « prestigieuse » (si c'est Oxford, rappelez mon admiration à Monsieur Pinney, historien de la photographie) en développant vos images dans un espace RGB dont la courbe de réponse tonale est L* car le nombre de niveaux qui subsistent est très supérieur au seuil minimal mettant vos images à l'abri de tout d'artefact visible. De même que les modestes et innocents photographes qui développent leurs images dans ProPhoto RGB peuvent continuer de faire la sieste sans crainte sur les bancs publics, même s'ils règlent leurs écrans sur une courbe de réponse différente de gamma= 1,8, comme gamma=2,2 ou L*.

Pour ces questions de quantification, mais aussi pour celles, bien plus graves, qui concernent les écrêtages de gamut, vous pouvez consulter la récente étude (2014) de Roy S. Berns, dont MBe a rappelé ici le lien il y a qq semaines : https://www.google.fr/search?q=camera+encoding+evaluation&ie=utf-8&oe=utf-8&rls={moz:distributionID}:{moz:locale}:{moz:official}&gws_rd=cr&ei=7RRaVfT6C6aAywOPsoCoBw

Cette étude aborde un domaine photographique exigeant en matière de colorimétrie, celui de la reproduction des œuvres d'art et des autres objets patrimoniaux. Dans sa partie consacrée aux erreurs de quantification, Berns conclut qu'avec une résolution tonale de 16 bits, les différences obtenues entre gamma=1,8 et gamma=2,2 ou L* sont négligeables. Berns rappelle en outre que la recherche d'un « gamma optimal » n'a de sens que si la résolution tonale n'est que de 8 bits. Et il conclut finalement que le « Studio for Scientific Imaging and Archiving of Cultural Heritage » continuera de définir ses images dans ProPhoto RGB... Bon, cette décision péremptoire n'est peut-être que provisoire et pourrait changer s'il parcourre ce fil.

3 - Perte de niveaux à l'affichage par erreur de quantification

Pour en terminer avec les mauvais tours que nous jouent les erreurs de quantification, examinons ce qui se passe chez un photographe possédant un écran dont le comportement natif est la courbe gamma 2,2 (ce qui n'est pas rare) et qui, séduit par les austérités de la Très Sainte Clarté L*, décide de le calibrer sur la courbe L*. Supposons qu'il fasse cette opération en chargeant les données correctives dans la LUT de sa carte graphique. Eh bien, si la carte graphique fait ses calculs sur 8 bits (ce qui n'est pas rare non plus), son affichage perdra 8,59% des niveaux d'entrée (8,35% si la carte graphique travaille sur 12 bits).

Tabernacle ! Un raisonnement basé sur la « cohérence » des courbes tonales militerait donc ici pour la conservation du comportement natif de l'écran à la place de la courbe L* ?  Rassurez vous, adopter L* pour l'affichage reste un bon choix et présente un avantage qualitatif (*) marginal mais incontestable pour les écrans qui le permettent. Et les inconvénients ci-dessus dus à la quantification ne pèsent pas bien lourd vis-à-vis de cet avantage.

De même qu'avec une résolution tonale de 16 bits, « l'inconvénient de cohérence » présenté par ProPhoto RGB et sa courbe gamme 1,8 compte pour du ghee (beurre clarifié à la clarté L*) à coté des écrêtages de gamut provoqués par un espace comme eciRGB_v2 qui présente l'avantage de L* mais aussi et surtout les inconvénients sévères d'un gamut trop petit pour les impressions à jet d'encre modernes. Et quid de ProStar RGB alors ? Eh bien le gaillard possède tous les avantages, celui du gamut de ProPhoto RGB et ceux de la courbe de réponse L*. C'est donc un choix optimal, mais ne rêvons pas, il n'apporte probablement aucun progrès visible à l'affichage de ceux qui, comme Berns, utilisent aujourd'hui déjà ProPhoto RGB.

Les photographes qui trouvent que leur noirs affichés sont moins bouchés avec un écran réglé sur L* sont des artisans attentifs et bien équipés d'un écran pour arts graphique soigneusement étalonné. En revanche, je ne vois pas par quel prodige de la Très Sainte Clarté leur affichage (et même leurs impressions !) pourraient être améliorés  en 16 bits par une définition des images dans un espace RGB ayant L* comme courbe tonale...

Quant à la bonne idée consistant à créer un espace de travail RGB avec L* comme courbe de réponse tonale, merci Salomé de lever les doutes de votre ami blogueur taquin et sceptique. Je confirme que c'est par un mail du sympathique Bruce Lindbloom daté du 20 septembre 2007 (c'était un jeudi) qu'il m'a annoncé que c'était probablement lui qui en avait eu le premier l'idée dans une conférence donnée en 1989 au SIGGRAPH dont il m'a envoyé un exemplaire en PJ que j'ai conservé depuis sous mon oreiller.

(*) A quoi devons nous cet avantage ? Mais à la sempiternelle racine cubique ! Je rappelle que la courbe L* est un bon modèle de notre perception des luminances parce que, la clarté L* variant linéairement avec la racine cubique de la luminance, elle se conforme au fait que, quand on multiplie une luminance par 2x2x2, notre perception ne ressent qu'un doublement de la luminosité (2 est la racine cubique de 2x2x2). Voila pourquoi la courbe L* est vraiment intéressante et non parce qu'elle donne une clarté de 50% (127 sur l'échelle 0-255) pour le gris moyen de luminance relative=18%, car la courbe gamma=2,47 et bien d'autres encore possèdent la même agréable propriété.

[fred134]

J'aimerais bien comprendre pourquoi j'ai une différence de rendu dans PS CC (à l'affichage) sur une même image :
- en ProPhoto RGB (gamma 1.8 ) ou ProStarRGB ("gamma" L*) d'une part, que je ne distingue pas plus que ça l'un de l'autre - il faudra que j'essaye avec des images plus difficiles,
- en Espace couleurs "personnalisé" à partir du ProPhoto RGB, avec gamma à 1 (que je crois être un ProPhoto linéaire, mais j'ai pu louper quelque chose).

Il y a une très nette différence dans les valeurs sombres quand je convertis de l'un à l'autre. Alors qu'en 16 bits il me semble que cela ne devrait pas être le cas.

Pb d'affichage, de conversion, ou autre ?

[THG]

Essayez de nous convaincre en montrant quelque chose de probant. Par exemple, partez d'un fichier RAW, comparez le processus habituel (je charge dans Lightroom, je fais quelques réglages, avec une excursion éventuelle dans PS - réglé en Prophoto pour simplifier -, je reviens dans LR et j'imprime) avec votre processus à partir du même fichier, pour arriver à l'impression, en détaillant ce que vous faites (parce que jusque là, je n'ai rien lu de très clair) et démontrez nous que votre flux est meilleur, plus court, plus précis avec des arguments qui nous donnent envie de tester.

Essayez de faire ça

- sans faire du LR-bashing toutes les 2 lignes (je crois parfois lire du Linuxien tapant sur Windows à tours de bras)
- en étant précis et clair (pas de sabir abscons destiné aux initiés ou plutôt aux non-initiés afin d'être sûr qu'ils ne comprennent rien)
- en vous assurant que tout ça est réalisable à la fois par les utilisateurs de Mac OS et de Windows
- en démontrant clairement que la qualité du résultat obtenu est supérieure et/ou que cela nous fait gagner du temps

Quand j'aurai tout ça noir sur blanc, mon attention sera probablement plus soutenue. Pour le moment, je n'ai pas le sentiment de devoir manipuler les curseurs de LR plus que de raison et le flux de travail depuis LR est plutôt efficace et rapide. Quand je lis que LR et ACR font n'importe quoi, je suis dans le doute, vu que depuis que j'accroche des tirages issus de LR sur les cimaises, personne ne s'en est jamais rendu compte. Je ne demande qu'à être convaincu que je suis dans l'erreur.

Je sais que ça va en énerver certains mais...

CQFD

et, en bonus

+1000

[THG]

on s'en fout. t'es HS, là
Avançons sur le sujet, merci.
je vais imprimer qq images d'un baptême. je regarderai le gap obtenu de mon côté et ferais un retour, le cas échéant.

Non on ne s'en fout pas. Et pas du tout même.

Dès lors qu'on arrive dans un forum de but en blanc pour jeter au visage des lecteurs que Lr c'est du n'importe quoi, j'en attends des explications.

[Nikojorj]

J'aimerais bien comprendre pourquoi j'ai une différence de rendu dans PS CC (à l'affichage) sur une même image :
- en ProPhoto RGB (gamma 1.8 ) ou ProStarRGB ("gamma" L*) d'une part, que je ne distingue pas plus que ça l'un de l'autre - il faudra que j'essaye avec des images plus difficiles,
- en Espace couleurs "personnalisé" à partir du ProPhoto RGB, avec gamma à 1 (que je crois être un ProPhoto linéaire, mais j'ai pu louper quelque chose).

Il y a une très nette différence dans les valeurs sombres quand je convertis de l'un à l'autre. Alors qu'en 16 bits il me semble que cela ne devrait pas être le cas.

Pas chez moi (PS CS6 sous W7 pro), et ça me rassure (par définition de "convertir", les chiffres changent et les valeurs visuelles restent, pas besoin de "faire joujou avec les curseurs" ).
Je penche pour un bug qq part.

[Pat20d]

Le même fichier développé dans ACR en Prophoto ou en Prostar et transféré dans PS ne me montre aucune différence visible. La pipette montre quelques écarts mais indiscernable sur le résultat à l'écran pour moi en tout cas.
La conversion de Prophoto à Prostar ne montre pas non plus une différence visible.
Pas fait l'essai sur une impression.
Windows 7 64 bits, PS CC, écran Eizo CG277 pour le matériel, et des yeux de 63 ans, c'est peut être là qu'est l'os 

[tenmangu81]

Exact, je ne l'avais pas constaté jusque là avec les quelques images que j'avais développées en espace de travail linéaire, mais en essayant d'autres images la conversion dans PS entre espaces de gamma différents change les tonalités, même en 16 bits.

Ben non, il me semble que sur un affichage réglé avec des gamma différents, les images affichées devraient être différentes. C'est tout l'intérêt de calibrer son écran avec une TRC L*, qui se rapproche plus de la vision humaine.
Mais peut-être ai-je mal compris ton intervention ?

[Pat20d]

[..]
Je penche pour un bug qq part.

J'ai déjà constaté que pour une raison ou un enchainement que je n'ai pas identifié, les couleurs dans PS CC ne sont pas/plus correctes. En effet il y a un écart significatif entre l'image affichée par ACR et PS. L'arrêt et relance de PS a résolu le problème....

Difficile de reproduire le problème que je n'avais jamais constaté avec PS CS6  

[tenmangu81]

Le même fichier développé dans ACR en Prophoto ou en Prostar et transféré dans PS ne me montre aucune différence visible. La pipette montre quelques écarts mais indiscernable sur le résultat à l'écran pour moi en tout cas.
La conversion de Prophoto à Prostar ne montre pas non plus une différence visible.
Pas fait l'essai sur une impression.
Windows 7 64 bits, PS CC, écran Eizo CG277 pour le matériel, et des yeux de 63 ans, c'est peut être là qu'est l'os  

Ca c'est normal aussi, et heureusement.
[at]  Fred, s'agit-il de conversion d'un espace dans un autre, ou de différences d'affichage suivant le gamma de l'écran ?

[Nikojorj]

De ce que j'en comprends chez fred134, il s'agit d'un changement d'aspect de l'image en la convertissant dans un autre profil - le genre de truc qui n'arrive normalement que dans la bibliothèque de l'Université de l'Invisible, ou éventuellement dans quelques vallées reculées des montagnes du Bélier.

[Pat20d]

Ca c'est normal aussi, et heureusement.
[..]

Ce n'est pas ce que laisse croire certaines interventions 

[Benaparis]

Bonjour Salomé, bonjour à tous et à toutes.

1 - Melissa RGB n'est pas « l'espace interne de LR »

Comme Nikojorj l'a remarqué plus haut, Melissa n'est pas utilisé par LR pour ses calculs internes mais pour son interface utilisateur. Par exemple, c'est dans Melissa RGB que le logiciel donne les nombres RGB affichés dans les histogrammes ou en réponse à la pipette. C'est aussi dans Melissa RGB que sont définis les aperçus affichés par le module développement (les autres modules préférant Adobe RGB (1998)).

Cet espace n'est pas le même que celui que LR utilise « en interne ». Je suppose que vous entendez par là l'espace dans lequel sont codés les nombres RGB sur lesquels LR opère ses calculs quand l'utilisateur manipule ses curseurs et autres instruments d'optimisation d'image. Cet espace-là, n'est pas Melissa mais un espace ayant les mêmes primaires et un gamma=1 comme dans la plupart des logiciels de développement RAW.  Adobe, comme P1, a sagement choisi d'effectuer ses calculs dans un espace sans correction gamma, situant ainsi l'espace des calculs dans la continuité tonale linéaire de l'espace du capteur.

2 - Mauvaises nouvelles des pertes de niveaux tonals dues aux erreurs de quantification en sortie de développement RAW

Quand LR exporte une image sous la forme d'un fichier TIFF RGB, il encode ce dernier avec la courbe inverse de la « courbe de réponse tonale nominale de l'espace ». Si l'espace de sortie choisi est Adobe RGB (1998), il élève donc les nombres RGB « internes » à la puissance 1/2,2. Si c'est ProPhoto RGB ou eciRGB (v1) il les élève à la puissance 1/1,8. Si c'est eciRGB_v2 ou ProStar RGB, il transforme les nombres RGB avec la formule inverse de L* (c'est-à-dire avec la formule permettant de calculer la luminance relative Y à partir de la clarté L*).

Bien entendu, cette cuisine s'opère sur des nombres entiers et génère donc des erreurs de quantification plus ou moins grandes selon la courbe tonale de sortie. C'est ainsi que, pour une résolution tonale de 16 bits, le nombre de niveaux tonals de sortie passe de 65536 aux valeurs décevantes qui suivent :

- Pour un encodage avec gamma = 2,2 -> Nombre de niveaux tonals en sortie = 47006
- Pour un encodage avec gamma = 1,8 -> Nombre de niveaux tonals en sortie = 51566
- Pour un encodage avec L*               -> Nombre de niveaux tonals en sortie = 44507

Manque de pot, mais c'est la faute à l'arithmétique (que l'on doit respecter car c'est la reine des mathématiques), vous voyez que, pour cette première étape d'encodage de l'image (c'est-à-dire en gros du capteur vers l'espace RGB de sortie), c'est l'exportation avec une courbe de réponse L* qui fait perdre le plus grand nombre de niveaux tonals et c'est celle basée sur 1,8 qui en fait perdre le plus faible nombre...

Mais rassurez vous Salomé, heureuse héritière d'un outil sans pareil, cette dégradation du nombre de niveaux tonals n'a AUCUNE espèce de conséquence pratique. Vous pouvez donc vous assoupir tranquillement sur les gazons fleuris de l'université anglaise que vous qualifiez modestement de « prestigieuse » (si c'est Oxford, rappelez mon admiration à Monsieur Pinney, historien de la photographie) en développant vos images dans un espace RGB dont la courbe de réponse tonale est L* car le nombre de niveaux qui subsistent est très supérieur au seuil minimal mettant vos images à l'abri de tout d'artefact visible. De même que les modestes et innocents photographes qui développent leurs images dans ProPhoto RGB peuvent continuer de faire la sieste sans crainte sur les bancs publics, même s'ils règlent leurs écrans sur une courbe de réponse différente de gamma= 1,8, comme gamma=2,2 ou L*.

Pour ces questions de quantification, mais aussi pour celles, bien plus graves, qui concernent les écrêtages de gamut, vous pouvez consulter la récente étude (2014) de Roy S. Berns, dont MBe a rappelé ici le lien il y a qq semaines : https://www.google.fr/search?q=camera+encoding+evaluation&ie=utf-8&oe=utf-8&rls={moz:distributionID}:{moz:locale}:{moz:official}&gws_rd=cr&ei=7RRaVfT6C6aAywOPsoCoBw

Cette étude aborde un domaine photographique exigeant en matière de colorimétrie, celui de la reproduction des œuvres d'art et des autres objets patrimoniaux. Dans sa partie consacrée aux erreurs de quantification, Berns conclut qu'avec une résolution tonale de 16 bits, les différences obtenues entre gamma=1,8 et gamma=2,2 ou L* sont négligeables. Berns rappelle en outre que la recherche d'un « gamma optimal » n'a de sens que si la résolution tonale n'est que de 8 bits. Et il conclut finalement que le « Studio for Scientific Imaging and Archiving of Cultural Heritage » continuera de définir ses images dans ProPhoto RGB... Bon, cette décision péremptoire n'est peut-être que provisoire et pourrait changer s'il parcourre ce fil.

3 - Perte de niveaux à l'affichage par erreur de quantification

Pour en terminer avec les mauvais tours que nous jouent les erreurs de quantification, examinons ce qui se passe chez un photographe possédant un écran dont le comportement natif est la courbe gamma 2,2 (ce qui n'est pas rare) et qui, séduit par les austérités de la Très Sainte Clarté L*, décide de le calibrer sur la courbe L*. Supposons qu'il fasse cette opération en chargeant les données correctives dans la LUT de sa carte graphique. Eh bien, si la carte graphique fait ses calculs sur 8 bits (ce qui n'est pas rare non plus), son affichage perdra 8,59% des niveaux d'entrée (8,35% si la carte graphique travaille sur 12 bits).

Tabernacle ! Un raisonnement basé sur la « cohérence » des courbes tonales militerait donc ici pour la conservation du comportement natif de l'écran à la place de la courbe L* ?  Rassurez vous, adopter L* pour l'affichage reste un bon choix et présente un avantage qualitatif (*) marginal mais incontestable pour les écrans qui le permettent. Et les inconvénients ci-dessus dus à la quantification ne pèsent pas bien lourd vis-à-vis de cet avantage.

De même qu'avec une résolution tonale de 16 bits, « l'inconvénient de cohérence » présenté par ProPhoto RGB et sa courbe gamme 1,8 compte pour du ghee (beurre clarifié à la clarté L*) à coté des écrêtages de gamut provoqués par un espace comme eciRGB_v2 qui présente l'avantage de L* mais aussi et surtout les inconvénients sévères d'un gamut trop petit pour les impressions à jet d'encre modernes. Et quid de ProStar RGB alors ? Eh bien le gaillard possède tous les avantages, celui du gamut de ProPhoto RGB et ceux de la courbe de réponse L*. C'est donc un choix optimal, mais ne rêvons pas, il n'apporte probablement aucun progrès visible à l'affichage de ceux qui, comme Berns, utilisent aujourd'hui déjà ProPhoto RGB.

Les photographes qui trouvent que leur noirs affichés sont moins bouchés avec un écran réglé sur L* sont des artisans attentifs et bien équipés d'un écran pour arts graphique soigneusement étalonné. En revanche, je ne vois pas par quel prodige de la Très Sainte Clarté leur affichage (et même leurs impressions !) pourraient être améliorés  en 16 bits par une définition des images dans un espace RGB ayant L* comme courbe tonale...

Quant à la bonne idée consistant à créer un espace de travail RGB avec L* comme courbe de réponse tonale, merci Salomé de lever les doutes de votre ami blogueur taquin et sceptique. Je confirme que c'est par un mail du sympathique Bruce Lindbloom daté du 20 septembre 2007 (c'était un jeudi) qu'il m'a annoncé que c'était probablement lui qui en avait eu le premier l'idée dans une conférence donnée en 1989 au SIGGRAPH dont il m'a envoyé un exemplaire en PJ que j'ai conservé depuis sous mon oreiller.

(*) A quoi devons nous cet avantage ? Mais à la sempiternelle racine cubique ! Je rappelle que la courbe L* est un bon modèle de notre perception des luminances parce que, la clarté L* variant linéairement avec la racine cubique de la luminance, elle se conforme au fait que, quand on multiplie une luminance par 2x2x2, notre perception ne ressent qu'un doublement de la luminosité (2 est la racine cubique de 2x2x2). Voila pourquoi la courbe L* est vraiment intéressante et non parce qu'elle donne une clarté de 50% (127 sur l'échelle 0-255) pour le gris moyen de luminance relative=18%, car la courbe gamma=2,47 et bien d'autres encore possèdent la même agréable propriété.

Bonjour et merci Monsieur Delmas pour ces explications,

Vous confirmer donc qu'utiliser L* pour l'affichage écran est donc un choix pertinent pour ceux qui le peuvent (ce que j'ai fait sur mon Eizo CG alors que sur mon MacBook Pro j'ai choisi le gamma de 1,8). J'avoue que ce seul aspect m'a convaincu pour régler désormais mon écran de référence de la sorte.

En revanche, et corrigez moi si je me trompe, utiliser un espace en L* pour le fichier n'a aucune espèce d'importance. J'ai pour ma part constaté dans Photoshop qu'à l'affichage je n'avais aucune différence visuelle entre une photo tiff 16bits en ProstarRGB (qui est l'espace que j'ai choisi pour assurer la continuité de gamut avec le Prophoto que j'avais fini par adopter il y a peu) et cette même photo en Prophoto ; en revanche j'ai pu constater un histogramme sensiblement different (ce qui semble logique à la lumière des calculs que vous avez présenté), si je me réfère à la compréhension que j'ai eu de vos propos il vaut mieux que je me fie à ma perception qu'à une légère différence d'histogramme qui n'aura pas d'influence notable lors de l'exploitation de la photo à l'impression?

Merci d'avance.

[Auvergnat63]

Cette étude aborde un domaine photographique exigeant en matière de colorimétrie, celui de la reproduction des œuvres d'art et des autres objets patrimoniaux. Dans sa partie consacrée aux erreurs de quantification, Berns conclut qu'avec une résolution tonale de 16 bits, les différences obtenues entre gamma=1,8 et gamma=2,2 ou L* sont négligeables. Berns rappelle en outre que la recherche d'un « gamma optimal » n'a de sens que si la résolution tonale n'est que de 8 bits. Et il conclut finalement que le « Studio for Scientific Imaging and Archiving of Cultural Heritage » continuera de définir ses images dans ProPhoto RGB... Bon, cette décision péremptoire n'est peut-être que provisoire et pourrait changer s'il parcourre ce fil.

Je vais retenir ça de l'excellente intervention de Jean D. histoire d'arrêter l'enculage de mouches. Je sais bien que Salomé s'était défini(e) au début comme trisexuel(le), je me demande si ce qualificatif n'avait pas un repport étroit avec la maltraitance des diptères sus-citée...

Et LOL sur la dernière phrase...

[Benaparis]

[at]  Benaparis: on corrige une photo principalement par ce que l'on voit à l'écran. Donc si sur l'écran l'affichage est différent, les corrections que l'on fera seront influencées par ces différences. C'est, pour moi, ce que je pense important dans cette histoire.

On est parfaitement d'accord, et si je suis convaincu de la calibration de mon écran en L* ce qui semble ne pas faire débat ici et rien que cet aspect est pour moi un gain en confort très précieux, en revanche je n'ai pas constaté de différence visuelle entre un Prostar et un Prophoto.

[at] Benaparis
Je précise aussi que mon profil d'écran est en iccV4 ce qui concoure encore à cette finesse d'affichage dans les parties denses.

J'utilise ColorNavigator d'Eizo il ne me semble pas avoir vu la possibilité de spécifier cette version d'ICC. Ceci expliquant peut être cela.

[Jean Delmas]

 [at]  Benaparis,

Vous avez tout à fait raison.

Les pertes de niveaux de quantification d'une image étant « un peu plus » importantes quand on exporte un RAW dans un espace avec une courbe tonale L*, l'histogramme résultant sera « un peu différent » (et d'ailleurs « un peu moins bon » en quantité de lacunes) de celui obtenu avec Gamma = 1,8 ou 2,2. Après vos travaux d'optimisation divers, l'histogramme se déforme ensuite de manière différentiée selon la courbe tonale et difficile à prévoir. Ce sont ces différences que vous observez à la pipette.

L'important, finalement, c'est de bien voir que, si vos calculs sont menés avec une résolution tonale de 16 bits, ces différences dues aux erreurs de quantification n'ont aucune conséquence pratique sur la qualité visuelle de vos images, sur celle de vos futures impressions et sur la capacité de vos fichiers TIFF à subir d'éventuelles corrections supplémentaires en postproduction.

[fred134]

Pas chez moi (PS CS6 sous W7 pro), et ça me rassure (par définition de "convertir", les chiffres changent et les valeurs visuelles restent, pas besoin de "faire joujou avec les curseurs" ).
Je penche pour un bug qq part.

C'est probablement moi le bug, je suis nul en PS...:-)

Je réexplique ma manip :
- j'ai créé dans PS CC un espace de travail "RGB personnalisé", basé sur le ProPhoto RGB. J'ai uniquement changé le champ "gamma" en mettant la valeur 1.
Je croyais avoir ainsi obtenu un ProPhoto linéaire. Est-ce OK ?

- j'exporte une photo depuis LR en TIFF 16bits Prophoto RGB.

- si je l'ouvre en ProPhoto RGB ou convertie dans l'espace de travail linéaire, les valeurs très sombres s'affichent différemment (plus sombres en linéaire).
- idem si je fais une conversion d'espace couleur de l'un à l'autre.
NB : en reconvertissant la version linéaire à Prophoto RGB j'obtiens bien l'image initiale.

Un exemple de valeur à la pipette : un 10 ProPhoto RGB s'affiche quasiment noir dans la version linéaire. Alors que en 16bits la valeur est 191 en linéaire, ce qui ne devrait pas poser de pb de précision. (NB la pipette en mode linéaire affiche bien sûr 1 puisqu'elle est en 8 bits.)

[fred134]

Ca c'est normal aussi, et heureusement.
[at]  Fred, s'agit-il de conversion d'un espace dans un autre, ou de différences d'affichage suivant le gamma de l'écran ?

Il s'agit bien d'une différence d'affichage dans PS, lors de la conversion d'un espace à l'autre.
Je ne touche pas à mon écran.

Ben non, il me semble que sur un affichage réglé avec des gamma différents, les images affichées devraient être différentes. C'est tout l'intérêt de calibrer son écran avec une TRC L*, qui se rapproche plus de la vision humaine.

Ca ne change pas l'aspect (il faut redémarrer l'appli qui affiche l'image, LR ou PS par ex), mais peut améliorer les gradations dans les noirs, du moins c'est ce que j'ai pu constater et c'est aussi ce que veut la logique (ouf sur ce coup-là :-)

[Nikojorj]

- j'ai créé dans PS CC un espace de travail "RGB personnalisé", basé sur le ProPhoto RGB. J'ai uniquement changé le champ "gamma" en mettant la valeur 1.
Je croyais avoir ainsi obtenu un ProPhoto linéaire. Est-ce OK ?

Pareil pour moi.

- si je l'ouvre en ProPhoto RGB ou convertie dans l'espace de travail linéaire, les valeurs très sombres s'affichent différemment (plus sombres en linéaire).
- idem si je fais une conversion d'espace couleur de l'un à l'autre.

C'est là où ça me fait bizarre, tu ne devrais pas avoir de différence (enfin, pas visible, que des erreurs d'arrondi négligeables, comme l'explique bien mieux que moi Jean Delmas) en convertissant d'un espace à l'autre.

PS CC dernière version? Quel OS?

[fred134]

C'est là où ça me fait bizarre, tu ne devrais pas avoir de différence (enfin, pas visible, que des erreurs d'arrondi négligeables, comme l'explique bien mieux que moi Jean Delmas) en convertissant d'un espace à l'autre.

PS CC dernière version? Quel OS?

Ben oui, la théorie est évidente, je n'ai pas de pb avec elle :-)

W7 64, PS CC 14.1.2 (pas la dernière version, vu mon usage je n'avais pas envie de m'embêter avec les upgrades)

NB : vu mon usage assez faible de PS, je dois avoir la plupart des options par défaut.

[tenmangu81]

- j'ai créé dans PS CC un espace de travail "RGB personnalisé", basé sur le ProPhoto RGB. J'ai uniquement changé le champ "gamma" en mettant la valeur 1.
Je croyais avoir ainsi obtenu un ProPhoto linéaire. Est-ce OK ?

Pareil pour moi.

Quel est votre usage de ce ProPhoto linéaire ?

[fred134]

Quel est votre usage de ce ProPhoto linéaire ?

Essentiellement ajuster les points noirs et blanc de photos développées en linéaire, dont je veut préserver un contraste linéaire (plus "naturel"). J'ai commencé en repro, parce que je trouvais que dans certains cas le résultat était nettement meilleur. Je tente aussi des fois le coup pour d'autres types d'images (ex : brume) pour voir.
Je ne suis pas du tout spécialiste, hein, mais je trouve que des fois c'est un plus.

[Nikojorj]

En ce qui me concerne, le test des affirmations lues céans. Épicétou (hors LR qui l'utilise à l'insu de mon plein gré bien sûr!).