Ecran 16bits, quel choix ?

[Will95]

Je regarde l'offre en écran avec dalle 16bits, je ne trouve que du 24" et 30" chez Eizo, et les 24 et 26" de chez Quato.

Nec visiblement n'en fait pas ...

En connaissez-vous d'autre ?

Sinon le Quato 262 me plait bien, performance identique à Eizo, moins cher/plus grand. Seul regret : du 26" en 1920 x 1200 ... Le CG245W d'Eizo est excellent, mais j'aurais voulu un peu plus grand, et le 30" est hors budget.

[canonbeber]

LaCie 526 ?

[canonbeber]

Nec visiblement n'en fait pas ...

Nec spectra view 27"

[Will95]

Nec spectra view 27"

Si c'est le Spectraview 271, il n'est pas 16bits, mais 10bits

[Will95]

LaCie 526 ?

C'est aussi un 1920 x 1200, quand a l'ecran ils disent 12bits LUT avec précision de calcul 16-bit, je ne saispas si c'est pareil que Eizo

[SimCI]

Cinemage ?

http://cinetal.com/products/cinemage.asp

http://cinetal.com/products/PDF/bseriesinfo.pdf

[canonbeber]

Nec PA 241

[Verso92]

Nec PA 241

Tu es sûr ?

[GRAPHICRESEAU]

Bonjour.

Eizo et Nec proposent des dalles en 10bits, Lut en 12bits sur les séries SX et CG chez EIZO (14bits en Nec PA et SpectraView) et calcul interne en 16bits.

[Verso92]

Eizo et Nec proposent des dalles en 10bits [...]

Il me semblait bien, aussi...

[MarcF44]

Il me semblait bien, aussi...

Et c'est déjà énorme...ma dalle de portable doit être en 6 bits...

[Will95]

Bonjour.

Eizo et Nec proposent des dalles en 10bits, Lut en 12bits sur les séries SX et CG chez EIZO (14bits en Nec PA et SpectraView) et calcul interne en 16bits.

Merci pour cette précision 

[Verso92]

Pourriez vous préciser ces informations intéressantes :

- Qu'entendez vous par "dalle en 10 bits" ?

La dalle permet de retranscrire des informations codées sur 3 x 10 bits (à condition que le reste suive, bien sûr, ce qui n'a rien d'évident) au lieu des 3 x 8 bits habituels.

- La LUT en 12 bits ne concernerait-elle pas que la série CG chez EIZO, dite à calibrage matériel ? Sinon, de quelle LUT s'agit-il sur la série SX ?

La LUT de l'écran...

- De quel type de calcul interne parlez vous en disant qu'il sont sur 16 bits ?

En numérique, les calculs sont la plupart du temps faits sur une largeur de bits plus importante pour minimiser les erreurs d'arrondis et de troncature (quand la mémoire le permet, bien sûr).

[Verso92]

En fait, je ne comprenais pas bien ce que GraphicRéseau nomme ici « dalle ». C'est donc finalement non pas un sous-ensemble de l'écran (la dalle proprement dite) mais l'appareil dans son ensemble. Quand donc  GraphicRéseau dit « dalle en 10 bits », il veut dire simplement « écran acceptant en entrée des nombres RGB définis sur 10 bits".

En fait, je pense qu'on parle bien de la dalle elle-même qui travaille en 10 bits. Bien sûr, l'électronique de l'écran doit être capable de lui fournir les infos sur 10 bits (au moins)...

Je me demande alors si ces 30 bits sont disposés dans un mot de 32 bits (auquel cas les données sont à cheval sur deux octets consécutifs ce qui provoque des traitements assez lourds) ou sont, bêtement, sur 48 bits avec une composante par paire d'octets. GraphicRéseau peut il nous le dire ?

Les ordinateurs et l'électronique de l'écran ne manipulent pas forcément des octets...

Oui, mais il me semblait que les Eizo possédant une LUT interne étaient les modèles dits « à calibrage matériel » c'est à dire les CG. Or GraphicRéseau évoquait une LUT également pour les modèles SX... d'où ma question.

Je pense que tous les écrans doivent par principe posséder des LUT. Ceux à "calibrage matériel" sont ceux qui permettent à l'utilisateur de venir y écrire des données liées à l'étalonnage...

Je suis bien d'accord, mais je voulais savoir quelle était la nature de ces calculs. J'imagine qu'il y a par exemple l'application des corrections gamma stockées dans la LUT interne (si l'écran en a une). Mais je pense qu'il y en a bien d'autres, assez mystérieux pour moi. Il y a par exemple, peut-être, des calculs destinés à uniformiser le comportement de la dalle en tous ses points, des calculs induits par le paramétrage de l'écran par l'utilisateur. Je suppose en particulier que le choix d'une valeur de température de couleur de blanc dans le menu Eizo provoque des calculs d'affichage...

Il s'agit bien de ce genre de calculs. Mais je ne saurais t'en dire plus...

[David D]

Bonjour.

Eizo et Nec proposent des dalles en 10bits, Lut en 12bits sur les séries SX et CG chez EIZO (14bits en Nec PA et SpectraView) et calcul interne en 16bits.

Bonjour,

Calcul en 16 bit signifi simplement que les valeurs sont inscritent sur deux octets ou bien qu'elles sont convertient dans un espace 16 bit intermédiaire le temps du calcul ?

Je me pose aussi des questions vis a vis des lut qui ont une dynamique plus importante que la dalle qu'elles commandent. Les valeur qui sortent de la lut sont directement injectés dans la dalle. Les point blanc et noir de la lut sont ils alignés sur les valeurs de tensions maximale et minimale admise par la dalle avant "saturation" ?  La Lut est elle simplement surquantifié ou bien va t'elle au dela de la dynamique admise par la dalle ?

J'espère que mes questions restent compréhensible    Merci de m'éclairer 

[Verso92]

Calcul en 16 bit signifi simplement que les valeurs sont inscritent sur deux octets ou bien qu'elles sont convertient dans un espace 16 bit intermédiaire le temps du calcul ?

Calcul sur 16 bits signifie simplement calcul sur 16 bits. Ni plus, ni moins.

Quand tu fais des opérations sur douze bits, par exemple, il convient toujours de le faire sur une largeur supérieure si tu veux limiter les erreurs d'arrondis et de troncature (c'est toujours le cas en traitement numérique du signal...).

[David D]

Désolé mais je ne saisi toujours pas 

Prenont un exemple simple en fesant abstraction de pas mal de chose.

J'ai une valeur codé sur 12 bit qui sort d'un apn.
J'ai une table LUT Classique composé de corespondance pour 2 puisance 14 valeurs (14 bit).
J'ai une dalle dont les propriété phisique permettent de reproduire 2 puissance 10 valeurs pour chaque canal RVB.

On va prendre la valeur 2048 qui est la valeur "médiane" d'une dynamique 12 bit.
La valeur est transposé dans un espace 16 bit. Elle s'apelle désormé 32768 (2^16/2) et je l'enregistre sur deux octet dans un fichier tiff
De la, elle se retransforme pour devenir 16384 (2^14/2)
La Lut fait son travail et trouve une corespondance à 16384. On va dire 16500
La valeur de sortie (16500) retourne dans un espace 16 bit et devient (au alentour de) 34000
Cette valeur 34000 est associé a une tension injecté dans la dalle
Sachant qu'au final, les propriétés de la dalle font qu on aura au max 2^10 valeurs par canal possible en sortie.

Est ce que je suis loin de la vérité ? Peut tu coriger ce raisonnement ?

Merci ! 

[Verso92]

Désolé mais je ne saisi toujours pas 

Prenont un exemple simple en fesant abstraction de pas mal de chose.

J'ai une valeur codé sur 12 bit qui sort d'un apn.
J'ai une table LUT Classique composé de corespondance pour 2 puisance 14 valeurs (14 bit).
J'ai une dalle dont les propriété phisique permettent de reproduire 2 puissance 10 valeurs pour chaque canal RVB.

On va prendre la valeur 2048 qui est la valeur "médiane" d'une dynamique 12 bit.
La valeur est transposé dans un espace 16 bit. Elle s'apelle désormé 32768 (2^16/2) et je l'enregistre sur deux octet dans un fichier tiff
De la, elle se retransforme pour devenir 16384 (2^14/2)
La Lut fait son travail et trouve une corespondance à 16384. On va dire 16500
La valeur de sortie (16500) retourne dans un espace 16 bit et devient (au alentour de) 34000
Cette valeur 34000 est associé a une tension injecté dans la dalle
Sachant qu'au final, les propriétés de la dalle font qu on aura au max 2^10 valeurs par canal possible en sortie.

Est ce que je suis loin de la vérité ? Peut tu coriger ce raisonnement ?

Merci ! 

Il n'y a pas d'erreur de raisonnement à proprement parler, mais je crains que tu n'aies pas compris quelles sont les données qui sont manipulées derrière tout ça.

Déjà, il faut voir que la carte graphique transmettra à l'écran une image codée sur 3 x 10 bits dans le meilleur des cas (bien souvent, ce sera 3 x 8 bits). Ensuite, il va y avoir beaucoup de calculs sur les données de type bitmap de l'image avant qu'elles ne soient affichées sur l'écran. Je ne connais pas suffisamment le sujet pour t'en expliquer d'avantage, mais la LUT de l'écran va intervenir en fonction d'un certain nombre de grandeurs comme le gamut de l'écran, etc. Il est en tout cas illusoire de penser que ce sont les données bitmap de l'image qui vont directement adresser la matrice de l'écran...

[David D]

J'imagine que le procédé est bien plus complexe.
Les données sont manipulés mais le résultat est tjrs fonction de la valeur bitmap de base. Sinon on aurait de la bouillie en visu.

Ce qui m'interesse c'est plus le travail effectué par l'écran et sa manière de faire.

De quel type de donnée parles tu ?
Les valeurs RVB (bitmap) du fichier sont convertis par le cmm dans l'espace lab. Après je ne sais pas trop ce qui se passe. J'imagine qu'ils sont reconverti dans un espace rvb de type "écran" qui dépend du profil couleur de celui ci (les tables donc). Les données passe par la carte graphique qui peut aussi apliquer des modifications avec une table vcgt par exemple (tout dépend de la config). La valeur arrive enfin dans l'écran ou elle est encore triturée par des courbes dépendant des réglages internes.

Après tout dépend de la méthode de réglage. Calibration soft ou hard.

J'aimerai juste comprendre les chiffre présenté par les constructeur et les enjeux qu'il y a derrière en terme de qualité de rendu.

Entre la LUT de l'écran , la méthode de calcul , la lut de la carte graphique , les capacités physique de la dalle ...  Ca fait beaucoup de chose à considérer. J'aimerai bien comprendre le circuit dans le détail.

[fantec]

Déjà, il faut voir que la carte graphique transmettra à l'écran une image codée sur 3 x 10 bits dans le meilleur des cas (bien souvent, ce sera 3 x 8 bits).

Cela dépend de la connectivité (DVI ou display-port) et de la résolution. Sur le display-port, les composantes peuvent être transmis sur 6, 8, 10, 12 ou 16 bits tant que l'on reste en deça du débit max (pour un 30", la limite sera à 10 bits par composante pour du 2560x1600 à 60 Hz). Sur le DVI, un mode permet d'envoyer 8 bits sur le second lien (dual-DVI) mais cela implique que la résolution ne dépasse pas les 1920x1080 (sur un 30" à 60 Hz, c'est soit du 2560x1600 en 24 bits, soit du 1920x1080 en 48 bits).

[Verso92]

Cela dépend de la connectivité (DVI ou display-port) et de la résolution. Sur le display-port, les composantes peuvent être transmis sur 6, 8, 10, 12 ou 16 bits tant que l'on reste en deça du débit max (pour un 30", la limite sera à 10 bits par composante pour du 2560x1600 à 60 Hz). Sur le DVI, un mode permet d'envoyer 8 bits sur le second lien (dual-DVI) mais cela implique que la résolution ne dépasse pas les 1920x1080 (sur un 30" à 60 Hz, c'est soit du 2560x1600 en 24 bits, soit du 1920x1080 en 48 bits).

Pas seulement : il faut que le pilote de la carte graphique le permette, que le logiciel le supporte, et que l'OS soit Seven pour ceux qui sont sur PC, etc...

Entre la LUT de l'écran , la méthode de calcul , la lut de la carte graphique , les capacités physique de la dalle ...  Ca fait beaucoup de chose à considérer. J'aimerai bien comprendre le circuit dans le détail.

Là, je serais bien incapable de t'aider...

[gibrocksonne]

Je me demande alors si ces 30 bits sont disposés dans un mot de 32 bits (auquel cas les données sont à cheval sur deux octets consécutifs ce qui provoque des traitements assez lourds) ou sont, bêtement, sur 48 bits avec une composante par paire d'octets. GraphicRéseau peut il nous le dire ?

T'en fais pas, tous ces calculs sont faits par un ASIC dont l'unité de calcul est certainement sur 30 bits.

J'ai une valeur codé sur 12 bit qui sort d'un apn.
J'ai une table LUT Classique composé de corespondance pour 2 puisance 14 valeurs (14 bit).
J'ai une dalle dont les propriété phisique permettent de reproduire 2 puissance 10 valeurs pour chaque canal RVB.

Les 12 bits de l'APN devraient être décalés de 2 bits à gauche (x4) avant de rentrer dans la lut, les 2 LSB de la LUT étant à 0.
Entre la sortie de la LUT et la dalle, on a 14bits vers 10bits, les 4 LSB sont tronqués pour ne faire plus que 10 bits.

D'une manière générale les bits supplémentaires servent à réduire les erreurs de calculs dans les étapes intermédiaires.

[Olivier-P]

Bcp de mélanges ... 

Les LUT des écrans sont dans le meilleurs des cas sur une grande quantification, c'est pour faire des compensations savantes dans la dalle de l'écran avec sa propre carte graphique interne. Ces LUT ne sont pas atteignables par nous, sauf dans le cas du pilotage dit Hardawe où les sondes attaquent directement cette LUT. Infos sonde de qualité, pour calculer les compromis et glissements de chroma, les ingénieurs se servent donc d'une quanti gigantesque. Un peu à la manière des espaces de travail caché dans les logiciels pro au dématricage, avec un Prophoto sur 16bits, ou simplement avec votre flux de travail quand vous travaillez en 16b, vos manip permettent de triturer gamma et constraste etc sans pertes. C'est le mm principe pour faire tres tres tres court !
Attention ce ne sont pas des travaux en flux, mais des calculs basiques, pas recalculés pour faire simples.
Donc pas de quanti lourde qui planterait ou ralentirait.
Rien à voir avec les flux directs des CG actives.

Pour les envois d'informations externes cette fois ci, les 10bits sont donc la valeurs des infos pour nourrir votre vision ... l'écran revendique de pouvoir afficher ces finesses ... mais ici on se heurte à un gros probleme que les cartes graphiques modernes n'adressent du 10b réel que dans tres peu de cas. Et savoir lequel ... Et tres souvent uniquement dans la chaine de prod Broadcast.
On a des CG qui émettent du 10b depuis pas mal de temps en version grand public, par exemple avec les Matrox, mais cette fonction (ancienne) est uniquement une quanti refaite à partir de 8b du ramdac de la carte .. et aussi ce sont souvent les sorties analogiques seules qui ont longtemps bénéficié de ces valeurs, le calcul se faisant en numérique 10b pour ensuite produire une fréquence analogique de qualité, toujours sur systemes Broadcast ( cinéma pro etc ) et sur écran analogiques.
C'est utile aussi pour nourrir toute la post prod en broadcast, et pas pour se faire plaisir aux yeux, comme l'est la réclame pour nos écrans.
Dans la chaine pro en flux tendu, tout comme en photo dans PS en 16b, ils ont besoin de travailler avec des valeurs supérieures aux 256 des 8b, laquelle est castratrice.

Ainsi, quand pour nous on invoque, en systeme fixe, d'avoir un apport pour la vision seule, c'est un peu un contre sens. On travaille déjà en 16b dans nos log. On ne voit qu'en 8b, mais c'est absolument secondaire. L'écran pro en photo, a un ICC sur 16b aussi, et une CG interne, on l'a vu : en 10b déjà ou 12b etc ...
Alors, que veux t on nous vendre ? un flux réel en 10b ? Attention, c'est quasi invisible sauf en loupe, ou vision de tres pres, et attention 2 c'est dangereux pour tuer le flux et les rendements. D'où ces 8b des Matrox, qui nourrrissent un 10b externe ... bonsoir l'intéret. Car evidement, jamais on ne sortira à partir des 12b de la LUT interne, je l'ai déjà dit c'est un calcul fixe et TRES lent à produire. Rien à voir avec le flux réel de la CG de l'ordi, ni celle active de l'écran, celles ci sont toutes les deux en 8b ! Sinon à ne plus jamais passer un jeu en 3D de 1999 

La nouvelle génération revendique les 10b (hélas je pense toujours traduit à la volée apres les 8b normaux), mais les pilotes sont assez nébuleux, je n'ai pas réussi à savoir, depuis ces info récentes, si tout ceci n'était - pour les CG grand public - que des surquanti simples à partir de sorties 8b, ce qui se passait jusqu'alors, ou alors des algo qui puisent sur une partie hardware 10b et dans ce cas on étoufferait le flux pour presque rien. Le DPport mange en effet plus de ressources si la CG envoie ses 10b, lequels sont calculés et gourmands. Amha, je dirais que cette histoire est impossible, bien entendu. On en avait discuté il y a un an ou deux, et tout pense à croire que des 10b natifs sont totalement impossibles sauf à attendre les réalisations dans l'industrie 3D de véritables cartes en 16b, et des OS qui vont bien avec.

En attendant, cette "reconversion passive de 8 en 10" ne nous sert pas. Nous sommes déjà en 16b pour notre flux photo, fixe et particulier. Seul le cinema en a besoin de ces flux 10b, mm "faux" ou faciles, car ils doivent eux travailler ces données mobiles. Pas nous.

A suivre dans le futur

[Olivier-P]

Et un petit PS, et le sujet mériterait des pages et des pages.
Ce ne sont pas les 8b finaux qui sont un pb, pour nous autres visionnant une image applatie, c'est le taux d'erreur qui s'est glissé dans la chaine RVB, de la CG à l'icc. La quanti finale n'est pas un soucis.

Donc avoir une sortie 10b, un icc logiciel et non pas matériel (hardware), donc en 8b de la CG. Les algo, hardaware ou software, ne relateront que toutes les imprécisions en 8b. Mieux définir une erreur est toujours une erreur.

Donc sonde spectro, attaque de la LUt en 12b et production d'un ICC en 16b, on garde au moins la précision de l'écran interne ok pour une sortie 10b écran ?
Non plus ... !
Quand vous etes passé dans le CMS (gestion des couleurs) de PS, la correction de l'espace de travail s'est fait sur une correction en 8b, car l'OS d'une part, le logiciel de l'autre part, ne gerent que le 8b de la CG. C'est là où justement les pilotes 10d qui nous sont donnés sont extremement importants à saisir. Ils revendiquent de nourrir l'écran par la CG en 10b. Ok, mais pas suffisant.

Incertitudes pour les CMS, et des OS et surtout des logiciels ! Adobe le promets en partie, mais les OS trainent.
On est donc dépendant du point faible, et chacun parait ignorer ce fait.
A priori et j'espère me tromper*, on nous donne pas toute la chaine utile certes et on ne nous la promet pas pour l'avenir de façon claire et nette.
En vision, on ne peut pas gagner, à un moment, dans cette aventure 10b, pour la photo sous CMS.
-
Car comme chacun le sait, le maillon faible commande à toute la chaine.
* j'espere vraiment. Néanmoins ce serait étonnant qu'une niche infime emnène le tout, ce sont les joueurs qui provoqueront les bascules en 16n natif sur CG un jour. Là gros sous et rentabilité.

[restoc]

Merci Olivier p de tenter de faire une synhsèse.

On s'apercoit qu'il nous manque effectivement de vraies certitudes factuelles sur ce qui se passe à chaque étage des composants et logiciels  industriels.

Je pense  qu'adobe et ses conversions Cms dépasse depuis longtemps le calcul puis la sortie au moins en fichier en huit bits puisque c'est une option  survivante pour les OS et hardware des pc ou mac les plus vieux.
Aprés ce qu'en font les CG, les standards de transmission, la connetique et les différents sous systemes de l'écran est un vrai pb.
Toutefois, je pense que depuis longtemps, les exigences des images de synthses pour l'industrie lourde de la production broadcast des films haut de gamme qui génére des nuances calculées sur 48 bits + bits de calages utilise des ecrans tels feu le 2480 dreamweaver de HP largement au dessus de huit bits pour faire le design puis le controlede  qualité final qui sont d'une exigence extreme.

Les solutions existent mais sont elles disponibles, standardisées et abordables? c'est toute la question.
Choisir un ecran sur le seul critere du nb de bits "marketing" serait une belle erreur comme le titre du fil. Ce n'est heureusement pas que çà qui définit une trés bonne chaîne d' affichage.

D'ailleurs Olivier-p ta synthèse prouve bien qu'il faut raisonner en chaine d'affichage et pas seulement en écran .
Amis consommateurs groupons nous pour avoir enfin toute la transparence !!