La courbe tonale BT1886. Est elle intéressante pour la photo ?

[olivier1010]

Quelques info :
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.1886-0-201103-I!!PDF-E.pdf

http://www.spectracal.com/Documents/White%20Papers/BT.1886.pdf
Il serait intéressant de comparer avec L*, sRGB et DICOM.

Elle devrait offrir les mêmes avantages dans les noirs (bonne différenciation des niveaux), avec pour gros avantage une bonne compatibilité et une standardisation.

J'ai remarqué que Nec Spectraview proposait cette courbe.

ColorNavigator peut également l'utiliser en passant par sa fonction d'import.

[MBe]

Bonjour Olivier, j'ai pas eu le temps de regarder dans les détails cette courbe, est que tu n'aurais pas tracé cette courbe en comparaison de L* et DICOM et ou Srgb?
Il doit y a avoir un intérêt, mais dans le cas présent je n'ai pas trouvé.

[olivier1010]

Oui j'ai tracé les courbes.
La courbe BT-1886 intégrant le décalage du point noir, je l'ai tracé avec compensation du point noir pour pouvoir comparer facilement avec les autres courbes, et sans tenir compte également du décalage numérique, qui est spécifié pour cette courbe lors d'une utilisation en vidéo ( For content  mastered  per  Recommendation  ITU-R  BT.7093,  10-bit  digital  code values "D" map into values of V per the following équation: V = (D–64)/876).

Pour la photo évidemment on utiliserait la courbe sans tenir compte du décalage numérique qui n'a de sens qu'en vidéo pour libérer les zones super-white et super-black. Pour info ce réglage de décalage numérique est disponible sur les écrans haut de gamme, dans les menus de réglage. Il est indépendant du système de gestion des couleurs et peut s'appliquer sur n'importe quelle signal vidéo entrant. Dans le cas où on l'utilise, l'application qui envoie les données vers l'écran doit évidemment utiliser le même codage. En général ce standard est utilisé sur du matériel avec entrée sortie vidéo SDI, mais il est aussi disponible sur les écrans haut de gamme à entrée Display port / HDMI / DVI.

Revenons à la courbe BT-1886, donc dépouillée de ses caractéristiques purement vidéo.
La comparaison avec L*, sRGB, DICOM et Gamma 2.2 montre un pied de courbe qui monte très vite, elle offre donc un bon discernement dans les bas niveaux comme sRGB, L* et DICOM.

Comme L*, sRGB et DICOM la pente dans sa partie basse est raisonnable, proche de sRGB avec une valeur approximative de 12, ce qui évite des éventuels problèmes de précision dans les conversions numériques avec certains CMS.

Contrairement à L* et sRGB, qui utilisent une partie linéaire dans les bas niveaux, BT-1886 maintient sa forme logarithmique, ce qui évite donc toute rupture dans la pente. Il y a peut être des avantages à ce niveau.

Enfin BT-1886 a un gamma global proche de 2.2 (pour une luminance mini de 0.3 et maxi de 100 cd/m²). Ce qui la rend assez proche de sRGB dans sa forme globale.

Ci-dessous la comparaison :

[olivier1010]

Elle la comparaison sur l'ensemble de la courbe (j'ai supprimé gamma 2.2 pour plus de clarté) :

[olivier1010]

Un article intéressant qui commente la courbe BT-1886 dans le contexte d'une utilisation vidéo.

http://www.root6.com/support-2/tips/whats-the-best-setting-for-gamma-with-rec-709-video/
La dernière remarque est plus générale et particulièrement intéressante, en résumé :

Un gamma faible comme 2.2 est plus adapté à un environnement lumineux mal contrôlé. Un gamma élevé comme 2.4 plus adapté à un environnement peu lumineux bien contrôlé.

J'aurais tendance pour la photo à conseiller sRGB dans un environnement lumineux peu contrôlé avec des utilisateurs peu attentifs aux considérations liés à l'étalonnage et disposant d'écrans à calibration software, et à conseiller L* voir DICOM dans un environnement bien contrôlé avec des écrans à calibration hardware et des utilisateurs sensibilisés aux techniques d'étalonnage et aux impératifs liés à l'éclairage ambiant de la pièce.

DICOM également offre des avantages indéniables comme la prise en compte de l'éclairage ambiant directement dans la forme de la courbe si l'étalonnage est réalisé à distance de l'écran, et l'adaptation de la forme de la courbe en fonction des luminances mini et maxi de l'écran.

A noter qu'il est toujours possible de compenser l'éclairage ambiant dans certains logiciels d'étalonnage quelque soit la courbe tonale utilisée, mais la correction apportée n'est pas documentée, contrairement à celle qu'on peut obtenir en calibrant en DICOM.

DICOM me semble la solution la plus sérieuse si on désire obtenir le maximum de précision quelque soit les circonstances : réglages de luminance et environnement lumineux. Il est peut être préférable quand même en DICOM, surtout si l'on travaille en couleur, d'utiliser le mode d'affichage 30 bits à cause du gamma très élevé dans les hautes luminances (proche de 3.0) qui pourrait peut être causer un peu de banding dans les hauts niveaux en 24 bits (à vérifier).

Je pense que BT1886 est un compromis qui permet d'assurer une bonne continuité technique dans le domaine de la vidéo, ainsi que pour la première fois standardiser la courbe tonale écran, mais elle ne semble pas avoir un intérêt évident en photo sachant qu'elle est très proche de sRGB qui est un standard bien établi.

Une dernière remarque, lorsqu'on utilise un écran haut de gamme à calibration hardware, un éclairage ambiant faible et un CMS performant, il n'y a pratiquement aucune différence visuelle quelque soit la courbe tonale utilisée, surtout si l'on utilise un mode d'affichage 30 bits.

Le choix d'une courbe tonale pour la photo, tout du moins sur du matériel haut de gamme et avec un environnement contrôlé, sera plus lié à des considérations de compatibilité ou disponibilité de la courbe sur le plan technique.

Dans un environnement moins contrôlé et avec du matériel moins haut de gamme, le choix de la courbe se pose moins, sachant qu'il est préférable de rester sur un gamma natif pour des raisons liés aux conversions hasardeuses en 8 bits, sRGB est le choix naturel.

Concernant Gamma 2.2, qui bouche trop dans les premiers niveaux, il n'a plus vraiment de raison d'être aujourd'hui, si ce n'est permettre un effet marketing avec la mise en avant de la disponibilité et de la supériorité de L* dans les logiciels d'étalonnage. L* qui n'a d'ailleurs pas un intérêt décisif lorsqu'on le compare à sRGB, sauf peut être permettre des conversions plus précises avec certains CMS si l'espace couleur source est également en L*.

L* ne mérite certainement pas le battage marketing qu'il a connu. DICOM par contre mériterait certainement un peu plus d'attention.

[MBe]

Merci Olivier pour les graphes de ces courbres comparatives à la  BT1886, je partage tes commentaires, toutes ses courbes présentent une pente bien plus élevée que le gamma 2,2 dans les faibles lumières.
Pour la courbe sRGB, l'handicap est que les profilers ne la proposent pas et et que peu d'utilisateurs prendront la peine d'importer la table.

Tu évoques également l'aspect cms, c'est un sujet qui reste assez nébuleux du fait de communication assez restreintes (hors Lcms et Argyll), qu'il n'est peu ou pas possible de choisir son cms (à ma connaissance, seul PS le permet (?)), que le paramétrage d'un cms au niveau Windows est pas simple sans parler de la documentation. Du côté cms, j'ai un peu l'impression de plus subir* que de rester maître de la situation, quel est ton avis?

*Beaucoup d'applications photo ne mentionnent pas le cms utilisé.

[olivier1010]

Merci Olivier pour les graphes de ces courbres comparatives à la  BT1886, je partage tes commentaires, toutes ses courbes présentent une pente bien plus élevée que le gamma 2,2 dans les faibles lumières.
Pour la courbe sRGB, l'handicap est que les profilers ne la proposent pas et et que peu d'utilisateurs prendront la peine d'importer la table.

Tu évoques également l'aspect cms, c'est un sujet qui reste assez nébuleux du fait de communication assez restreintes (hors Lcms et Argyll), qu'il n'est peu ou pas possible de choisir son cms (à ma connaissance, seul PS le permet (?)), que le paramétrage d'un cms au niveau Windows est pas simple sans parler de la documentation. Du côté cms, j'ai un peu l'impression de plus subir* que de rester maître de la situation, quel est ton avis?

*Beaucoup d'applications photo ne mentionnent pas le cms utilisé.

Concernant le sRGB mon point de vue est un peu différent :
- Concernant les écrans à calibration hardware, il me semble qu'il est toujours possible d'utiliser L*, ce qui en pratique devrait offrir des résultats aussi bons que sRGB, sauf cas spécifique ou un problème de compatibilité se présente. Dans les tests que j'ai réalisé, je n'ai pas vu de problème spécifique, en tout cas avec les applications Adobe. Donc dans ce cas on peut choisir L* et bénéficier d'un affichage performant dès les premiers niveaux de luminance, avec en bonus une colorimétrie de meilleur qualité grâce à la calibration hardware, surtout sur les écrans qui disposent d'une LUT interne 3D.

- Concernant les écrans à calibration software, que je ne conseille pas mais qui en pratique peuvent être la seule solution pour un amateur à cause du prix des écrans à calibration hardware (minimum 700 euros environ), leur conception pose souvent le problème de la température de couleur du rétroéclairage non ajustable, ainsi que de la courbe tonale non ajustable si ce n'est par les réglages contraste et luminosité.
Avec ces écrans, changer la température de couleur du point blanc et / ou la courbe gamma native (normalement proche de sRGB) en passant par la LUT 1D (8 bits en général, 10 bits au mieux) de la carte vidéo aura forcement des conséquences néfastes sur la continuité de l'espace couleur (apparition d'une légère postérisation) d'une part, et sur le Delta E global d'autre part.
Les logiciels d'étalonnage courants utilisés en calibration software risquent bien de ne pas montrer pas ces conséquences, pire ils peuvent les masquer car ils utilisent un jeu de patch réduits pour la validation, souvent les mêmes patchs ayant servi pour l'étalonnage ce qui masque d'autant plus les problèmes précités.

Donc concernant la calibration software, un écran moderne bureautique de bonne qualité non calibré risque bien de produire un affichage de meilleure qualité que s'il était calibré par un logiciel de calibration externe utilisant la table LUT de la carte vidéo (au passage cette méthode me semble d'ailleurs totalement dépassée technologiquement).

Il y a bien dans les profils écrans générés pour ce type d'écran une table de correspondance couleur de bonne taille, faisant office de LUT 3D, mais je doute qu'elle soit utilisé par la majeur partie des applications graphiques. Ces tables de toutes façons ne règlent qu'un seul problème, celui de la précision delta E, pas celui de la postérisation de l'image. Et lorsqu'elles ne sont pas utilisées par l'application graphique, elles n'ont aucun effet sur l'affichage. Enfin, elles peuvent ralentir l'affichage voir faire planter un logiciel à cause de la forte charge qu'elles induisent sur le processeur de l'unité central.

Donc deux conseils me viennent à l'esprit :

- Le plus évident, ne pas utiliser d'écrans qui ne disposent pas d'une calibration hardware lorsqu'on recherche une qualité d'affichage optimale, car la calibration software d'un écran demande une grande maîtrise pour ne pas induire plus de problèmes qu'elle n'en résout. Cette maîtrise en générale n'est pas acquise par la plupart des utilisateurs de ce type d'écrans.

- Dans le cas ou un écran à calibration software est utilisé, il est peut être plus judicieux d'altérer le moins possible les réglages usines de l'écran, c'est à dire ne pas toucher à sa température de couleur native, ainsi qu'à sa courbe tonale native. Dans ce cas, la disponibilité de la courbe sRGB dans le logiciel de calibration ne se pose pas, car on choisira un  gamma natif et une température couleur native dans le logiciel qui se contentera de générer les courbes TRC natives de l'écran et une table de correspondance couleur dans le profil écran, sans altérer la LUT de la carte vidéo.
Évidement pour arriver à un bon résultat il faudra au moins que les réglages luminosité et contraste de l'écran soient ajustés au mieux, ce qui lorsque cette opération doit être faite manuellement peut être très fastidieux, car ces deux réglages influent non seulement sur le point noir et point blanc de l'écran, mais aussi sur sa courbe tonale... Une réminiscence de l'époque des tubes CRT.
Mes conclusions finales :

- si la courbe tonale sRGB n'est pas disponible, on peut quand même l'utiliser à condition de laisser l'écran en gamma natif. Il devrait dans ce cas s'approcher naturellement de sRGB. La calibration sera d'autant plus difficile, c'est pourquoi j'aurais tendance à fortement déconseiller les écrans qui ne disposent pas de la calibration hardware car ils induisent à la fois une forte difficulté de calibration chez des utilisateurs souvent néophytes à ce niveau, le tout associé à des fortes limitations techniques qui les empêche de rivaliser avec des écrans à calibration hardware.

- utiliser de préférence un écran à calibration hardware, qui règlera la plupart des problèmes, voir tous les problèmes pour ceux disposant d'un rétroéclairage RGB ajustable, d'une LUT 3D et d'une table interne d'uniformisation de la dalle. De plus la calibration hardware simplifie et sécurise la procédure d'étalonnage, tout en libérant l'unité centrale des calculs liés à la LUT 3D.

A noter que l'uniformisation de la dalle n'est pas possible avec une calibration software, les systèmes ICC ne prenant pas en charge ces corrections. C'est un argument de plus en faveur de la calibration hardware.
------------

Concernant les CMS, j'ai pu remarquer deux choses :

- Certaines applications semblent utiliser un système de conversion ancien, cela me semble être le cas d'Indesign dont les conversions LAB vers RGB donnent des résultats étrangement très différents par rapport aux autres applications, y compris celles des autres applications du même éditeur. Je n'ai pas plus investigué, me disant que pour ce logiciel, il fallait mieux utiliser des valeurs RGB (ou CMYK en impression quadri) pour éviter les surprises sur les tons directs.

- J'ai remarqué des différences sensibles entre les divers CMS, en terme de précision de calcul dans les bas niveaux de luminance. Les imprécisions maximum que j'ai pu observer sont de l'ordre de Delta L = 2 dans les très bas niveaux de luminance. Je n'ai pas fait une étude complète sur le sujet, j'ai juste remarqué cela dans des mesures que j'ai réalisé sur des patchs en niveaux de gris, c'est pour cela que je parle de Delta L et non Delta E. Je pense que ces différences sont causées soit par le mode de précision utilisé dans les calculs, (entiers 16 bits ou 32 bits flottant par exemple), ou par des algorithmes légèrement différents d'un CMS à l'autre. LCMS semble bien mieux s'en sortir que Adobe CMS et Microsoft CMS. Je n'ai pas d'expérience avec les autres CMS.

Difficile de tirer des conclusions sans une étude complète sur le sujet, mais ce qui est certain c'est que pour des applications critiques, il est indispensable de vérifier le comportement et la précision d'un CMS ou d'une application en situation réelle avant de lui faire aveuglément confiance.

On peut dire aussi sans trop se tromper que certaines applications font l'impasse sur les nouvelles technologies CMS, afin de conserver peut être une compatibilité avec les premières versions, ou parce que la modification de code de bas niveau serait trop invasive, surtout lorsque des développeurs initiaux sont peut être partis en retraite