Antinomie entre dynamique des capteurs et restitution en sRVB ?

[Verso92]

Voilà je n'ai pas la lecture du tiff 16 bits dans PS éléments!
ou du moins je crois car je n'ai jamais eu à lire un tiff 16 bits!

Photoshop Element et le TIFF n'ont rien à voir là-dedans : quand tu promènes ta pipette dans n'importe quel logiciel de développement, les valeurs vont de 0 à 255.

Pourtant, on est bien évidemment pas dans un espace codé sur 8 bits, et il n'est pas encore question de fichier...

[Verso92]

oui enfin ça, c'est une justification purement mathématique (théorique). Dans le monde réel, déjà sur beaucoup d'appareils 14 bits c'est plus qu'il n'en faut car le ou les derniers bits sont noyés dans le bruit (c'est d'ailleurs le cas pour tous les appareils dès qu'on monte en iso, puisque la dynamique diminue), et encore je ne compte que le bruit de lecture, pas le bruit photonique. Et couper le bruit en 4 n'a jamais apporté grand chose...à part peut-être une certaine satisfaction intellectuelle 

Je ne crois pas, non : le silicium coûte cher... tout ça pour une petite ligne (les calculs dans l'Expeed en 16 bits) que presque personne ne lira dans la présentation commerciale de l'appareil ?


Dans toutes les applications que je connais (sur lesquelles j'ai travaillé), il a toujours fallu surdimensionner la quantification des données, sous peine de ne pas retrouver la précision requise en fin de calcul (FFT, etc).

Une autre expérience que j'avais faite, à l'époque : sur certaines diapos difficiles, le fait de numériser en multi-échantillonnage avec un scanner 12 bits* (soit du pseudo-16 bits) améliorait spectaculairement le résultat dans les ombres (recul du bruit). La même expérience reconduite avec un scanner 16 bits réels n'apportait plus de gain sur ce critère...


*Nikon Coolscan Ls-2000.

[astrophoto]

Je ne crois pas, non : le silicium coûte cher... tout ça pour une petite ligne (les calculs dans l'Expeed en 16 bits) que presque personne ne lira dans la présentation de l'appareil ?

presque personne, vraiment ? Je crois que tu sous-estimes la force du marketing et des brochures. Combien de fois a-t-on lu sur la section MF que la supériorité des MF était liée (au moins en partie) au fait qu'ils ont un convertisseur 16 bits, alors que c'est une "légende urbaine" ? 
Et puis les processeurs travaillent généralement en multiples de 8 bits, ce qui ne démontre rien sur l'avantage que ça procurerait en photo.

Dans toutes les applications que je connais (sur lesquelles j'ai travaillé), il a toujours fallu surdimensionner la quantification des données, sous peine de ne pas retrouver la précision requise en fin de calcul (FFT, etc).

Et ça inclut ce qu'on fait ici en photo, cad le développement et traitement de raw (12 ou 14 bits) ? Dans ce cas tu dois être capable de me démontrer par l'expérience que passer un raw de 14 à 16 apporte un plus par rapport à le laisser à 14 

En astro, on utilise les données brutes raw pendant une grande partie du traitement et malgré le fait qu'on essaye de tirer toute la quintessence des images (y compris pour aller chercher un faible signal perdu dans du bruit), personne n'a jamais vu d'intérêt à multiplier les données par 4 (pour passer de 14 bits à 16 bits) : quand elles sont en 14 bits on les laisse comme ça 

[Franciscus Corvinus]

On travaille sur 16 bits tout simplement parce qu'on sait faire des processeurs bons marchés qui travaillent sur 16 bits. On sait faire des processeurs qui travaillent sur 14 bit, mais c'est tellement rare... que c'est plus cher.

Mon expérience s'accorde avec Astrophoto sur le fait que les bits au dela de 12-14 ne font pas de différence *visible sur l'image* au post-traitement. Mais je n'ai peut-etre pas essayé d'image suffisamment catasrophique.

Quand aux 10 bits pour l'écran et la valeur 255, il serait peut-etre plus commode de penser en termes de 8 bits entiers plus 2 bits apres la virgule. Donc le 255 est en faiti un 255.00. Pareil pour les 16 bits: 8 bits pour l'entier et 8 bits apres la virgule.

[Nikojorj]

En gros, on peut récupérer des hautes et/ou basses lumières, qui sur un capteur peu dynamique seraient toutes blanches (ou noires) et donc irrécupérables.
L'écran ou le papier, eux, ne montrent (aux admirateurs ébahis) que l'image après traitement.

Tout à fait!
Pour être précis, les plages noires ne sont pas toutes noires mais plutôt noyées dans le bruit, comme le rappelle bien Thierry ci-dessus (qui je crois avait proposé une jolie expérience avec des DNG tronqués, dans le forum Canon, il y a pas mal d'années... résultat 10 bits utiles 12 bof 14 non, si je me souviens bien, les images sont de toutes façons passées aux oubliettes et je ne retrouve plus le fil).

[Verso92]

Combien de fois a-t-on lu sur la section MF que la supériorité des MF était liée (au moins en partie) au fait qu'ils ont un convertisseur 16 bits, alors que c'est une "légende urbaine" ? 

Par curiosité, je serais intéressé par un lien montrant que les convertisseurs des Blad (par exemple) ne sont pas 16 bits...  ;-)

Et puis les processeurs travaillent généralement en multiples de 8 bits, ce qui ne démontre rien sur l'avantage que ça procurerait en photo.

Cela n'a rien à voir. Du moins, dans le cas de l'Expeed, qui est un ASIC : tout bit de mémoire en plus "coûte" du silicium...

[astrophoto]

Par curiosité, je serais intéressé par un lien montrant que les convertisseurs des Blad (par exemple) ne sont pas 16 bits...  ;-)

non non, ce que je voulais dire c'est que la "supériorité" des MF sur certains aspects n'est pas dû au 16 bits. Je ne mets pas la parole de Blad en doute sur le fait que leurs convertisseurs sont bien 16 bits 

[egtegt²]

Il ne faut pas oublier que passer de 8 à 16 bits multiplie par 256 le nombre de nuances disponibles. Sachant que le 8 bits est déjà pas si loin de l'optimal, je ne pense pas que ça soit réellement utile de tellement augmenter le nombre de nuances.

Je serais assez curieux de tester si ça existe un écran 12 bits par rapport à un écran 10 bits. Ca m'étonnerait que la différence soit visible.

[Verso92]

Il ne faut pas oublier que passer de 8 à 16 bits multiplie par 256 le nombre de nuances disponibles. Sachant que le 8 bits est déjà pas si loin de l'optimal, je ne pense pas que ça soit réellement utile de tellement augmenter le nombre de nuances.

Attention à ne pas prendre le problème à l'envers...

Sur une image finalisée en 16 bits, il n'y aura pas d'inconvénient majeur à repasser en 8 bits, par exemple : la différence, si elle existe, sera ténue. D'ailleurs, ceux qui impriment leurs images à partir de PC le savent par défaut, puisque Windows ne sait imprimer qu'en 8 bits.


L'intérêt d'un nombre de bits élevé, c'est pour les calculs (ceux effectués lors du développement du fichier, en ce qui concerne la photo).

Je serais assez curieux de tester si ça existe un écran 12 bits par rapport à un écran 10 bits. Ca m'étonnerait que la différence soit visible.

Encore faudrait-il que les écrans 12 bits existent...  ;-)


Pour la différence entre un affichage 8 bits et un affichage 10 bits sur un écran 10 bits, voir ci-dessous (photographies de l'écran) :

[Jean-Claude]

L n'est pas du tout égal à R + V + B c'est  L + a + b qui l'est

ou éventuellement Lr + Lv + Lb qui serait égal à L

Le mode Lab et un tout autre système de références que le RVB qui ne supporte pas d'égalités directes.

Tu peux même faire tenir une dynamique de 20 IL dans 8 bit si tu veux, il y aurait juste un problème d'une énorme perte de finesse qui donne  lieu à des ruptures de tonalités.

[Jean-Claude]

Par curiosité, je serais intéressé par un lien montrant que les convertisseurs des Blad (par exemple) ne sont pas 16 bits...  ;-)

Cela n'a rien à voir. Du moins, dans le cas de l'Expeed, qui est un ASIC : tout bit de mémoire en plus "coûte" du silicium...

par ex. Blad joint à chaque RAW .3F de boitier de 50 Mpix une bonne vingtaine de Mega de métadonnées décrivant le comportement réel de chaque pixel du boitier en question. Les fichiers .3F sont comprimés en priorité taille (taille fixe). Ces métadonnées sont utilisées lors de l'import dans leur derawtiseur pour générer le RAW ordi .fff qui a été profilé, égalisé en réponse des pixels sur la surface du capteur et par rapport à une entrée 16bit sans bit manquant. Ce RAW ordi .fff est débarassé des métadonnées de capteur et archivé en compression variable (priorité qualité)

ce n'est quand même pas du marketing que de ralentir un boitier afin de joindre à chaque fichier RAW les données individuelles de réponse capteur du boitier. Et ils en parlent d'ailleurs très peu qu'à demi mot de leur technique propre.

Apparemment Blad a du donner la manière de faire pour leurs fichiers à Adobe, puisqu'ils disent dans les manuels de. oitiere que les derawtiseurs à Adobe donnent la même qualité que leur soft maison.

[chelmimage]

L n'est pas du tout égal à R + V + B c'est  L + a + b qui l'est

ou éventuellement Lr + Lv + Lb qui serait égal à L

Le mode Lab et un tout autre système de références que le RVB qui ne supporte pas d'égalités directes.

Tu peux même faire tenir une dynamique de 20 IL dans 8 bit si tu veux, il y aurait juste un problème d'une énorme perte de finesse qui donne  lieu à des ruptures de tonalités.

J'avais donné la formule plus haut comme suit..

Je pensais à la formule:
L= 0,3 R+0,59 V+0,11 B.
Comme R,V, et B sont limités à 255, L est également limité à 255?
Et c'est peut être dans cette dynamique de représentation RVB (sans le s) qu'il y a antinomie avec la dynamique du capteur?

[egtegt²]

Attention à ne pas prendre le problème à l'envers...

Sur une image finalisée en 16 bits, il n'y aura pas d'inconvénient majeur à repasser en 8 bits, par exemple : la différence, si elle existe, sera ténue. D'ailleurs, ceux qui impriment leurs images à partir de PC le savent par défaut, puisque Windows ne sait imprimer qu'en 8 bits.
L'intérêt d'un nombre de bits élevé, c'est pour les calculs (ceux effectués lors du développement du fichier, en ce qui concerne la photo).

Je suis d'accord, mais en général on a besoin d'un niveau de magnitude en plus pour éviter les erreurs d'arrondi, donc en gros 3 bits, 4 bits si on aime pinailler. Donc pour une image en 8 bits, 12 bits sont suffisants pour éviter les erreurs d'arrondi. Même si on pousse l'exigence finale à 10 bits, 14 bits suffisent. Au delà, l'intérêt est tout de même fortement limité vu que les moyens d'affichage les plus performants, qu'il s'agisse d'impression ou d'écran, ne dépassent pas 10 bits.

A mon sens, le passage de 14 à 16 bits n'existe que parce que 16 bits sont en général plus simples à traiter que 14 en informatique. En terme de qualité d'image, ils sont à mon avis totalement inutiles (En termes d'image de marque par contre, ça se discute )

Encore faudrait-il que les écrans 12 bits existent...  ;-)
Pour la différence entre un affichage 8 bits et un affichage 10 bits sur un écran 10 bits, voir ci-dessous (photographies de l'écran) :

C'est pour ça que j'avais écrit "S'ils existent", je suppose que ça existe peut-être à titre expérimental.

Je ne doute pas qu'il existe une différence entre 8 et 10 bits, même si je suppose qu'elle est plus simple à démontrer sur une couleur uniforme que sur une photo.

[Verso92]

Je suis d'accord, mais en général on a besoin d'un niveau de magnitude en plus pour éviter les erreurs d'arrondi, donc en gros 3 bits, 4 bits si on aime pinailler. Donc pour une image en 8 bits, 12 bits sont suffisants pour éviter les erreurs d'arrondi. Même si on pousse l'exigence finale à 10 bits, 14 bits suffisent. Au delà, l'intérêt est tout de même fortement limité vu que les moyens d'affichage les plus performants, qu'il s'agisse d'impression ou d'écran, ne dépassent pas 10 bits.

A l'occasion, il faudrait que je remette en route mon Coolscan Ls-2000, pour montrer ici (en Jpeg 8 bits, donc) les différences entre une numérisation sur 12 bits ou en pseudo-16 bits...  ;-)

A mon sens, le passage de 14 à 16 bits n'existe que parce que 16 bits sont en général plus simples à traiter que 14 en informatique.

Comme expliqué précédemment, cet argument ne tient pas dans le cas d'un ASIC (Expeed).


Dimensionner la mémoire à 16 bits si 14 suffisent, juste pour faire "joli" dans les docs commerciales, je n'y crois pas un seul instant...

[egtegt²]

Comme expliqué précédemment, cet argument ne tient pas dans le cas d'un ASIC.
Dimensionner la mémoire à 16 bits, juste pour faire "joli", je n'y crois pas un seul instant...

Tu oublie qu'une photo n'a pas vocation à rester sur l'appareil, elle va être traitée sur un ordinateur qui lui travaille en multiples de 8.

Pour l'ASIC, je ne suis pas expert, mais vu les appareils qui travaillent en 16 bits et leur prix, je ne suis pas persuadé que le surcoût pour passer de 14 à 16 bits soit significatif. Et en informatique, je peux te citer des tonnes d'exemples de complexité ajoutée, pas nécessairement pour faire joli au départ, mais qui en fin de compte se résument à ça. Pas qu'en informatique d'ailleurs.

Les marques comme Hasselblad ou Leica vendant très cher, elles ont souvent tendance à faire de la surqualité pour appuyer leur discours commercial élitiste. Dans certains cas c'est un vrai plus, dans d'autres, c'est plus anecdotique.

L'argument comme quoi les 16 bits servent à éviter les erreurs d'arrondi sur les 14 bits vraiment captés se défend ... si on oublie que les 14 bits sont là pour éviter les erreurs d'arrondi à 10 bits

[Verso92]

Tu oublie qu'une photo n'a pas vocation à rester sur l'appareil, elle va être traitée sur un ordinateur qui lui travaille en multiples de 8.

Les LUT de mon écran sont en 14 bits...  ;-)

Pour l'ASIC, je ne suis pas expert, mais vu les appareils qui travaillent en 16 bits et leur prix, je ne suis pas persuadé que le surcoût pour passer de 14 à 16 bits soit significatif.

Dans un ASIC, on fait la chasse à ce genre de chose : le silicium coûte cher*.


*en terme d'intégration, de consommation, etc.


Après, je me souviens de joutes serrées, au boulot, pour essayer d'imposer un convertisseur A/N 12 bits. Malgré un rapport d'étude étayé réalisé par un collègue démontrant le bénéfice du CAN 12 bits pour notre produit, nous n'avons pas eu gain de cause : ça s'est terminé par un 10 bits, moins onéreux (les maitrises d'œuvre ont toujours le dernier mot, et ce sont des gens près de leurs sous !  ;-)...

[astrophoto]

A l'occasion, il faudrait que je remette en route mon Coolscan Ls-2000, pour montrer ici (en Jpeg 8 bits, donc) les différences entre une numérisation sur 12 bits ou en pseudo-16 bits...  ;-)

comparaison n'est pas raison...ton expérience avec ton scanner est sûrement très pertinente mais elle n'est peut-être pas (je dirais même : certainement pas) extrapolable à nos APN  Donc merci de nous procurer plutôt des exemples en relation directe avec le sujet du fil 

Les marques comme Hasselblad ou Leica vendant très cher, elles ont souvent tendance à faire de la surqualité pour appuyer leur discours commercial élitiste. Dans certains cas c'est un vrai plus, dans d'autres, c'est plus anecdotique.

L'argument comme quoi les 16 bits servent à éviter les erreurs d'arrondi sur les 14 bits vraiment captés se défend ... si on oublie que les 14 bits sont là pour éviter les erreurs d'arrondi à 10 bits

c'est exactement ça...et rajouter de la marge à de la marge, en psycho ça porte un nom : la peur de manquer 

Les 16 bits, c'est comme le nombre de pixels : beaucoup de gens y attachent une grande importance...pour au final afficher des images en HD sur Facebook 

[chelmimage]

Les LUT de mon écran sont en 14 bits...  ;-)

Je me pose toujours la question: un écran  avec 4 trillions de couleurs adressables, étalonné, des primaires connues, avec des gamuts réglables, à température de couleur maîtrisée, est ce que ce n'est pas aussi bien qu'une mire colorchecker? 

[chelmimage]

J'ai même oublié les Delta E garantis peut être?

[Jean-Claude]

Il est vrai que que les gens de Hasselblad travaillent en zéro compromis ce qui parfois les fait passer à côté de certaines choses. Pas assez bon pour eux ne veut pas dire pas assez bon pour l'utilisateur qui pourrait parfois largement accepter un petit compromis qui ne le pénalise pas trop.

J'ai deux exemples parlant qui me viennent à l'esprit au sujet du X1D
Il  a été privé au départ d'obturateur électronique du fait du long temps de scan de 1/30s du capteur Sony. Il a fallu une grosse levée de boucliers surtout d'un de leurs nouveaux consultants internes pour accepter d'implémenter l'obturateur électronique avec ses effets secondaires que l'on connais pour ce modèle de capteur.
Deuxième exemple ou ils n'ont pas lâché prise, l'absence d'ISO auto en mode M. Leur argument absolument juste est que l'ISO auto en mode M pourrait amener sur ce boitier à de petites erreurs d'expo variables avec un maximum de 0,17 IL (également du à la technologie Sony de ce capteur). Il n'ont pas laché malgré les insistances répétées du même consultant qui récemment a démissionné 
(je tiens ces témoignages de source directe du consultant )

[Verso92]

Donc merci de nous procurer plutôt des exemples en relation directe avec le sujet du fil 

Je vais essayer de décapoter l'Expeed de mon D850 et supprimer les quatre bits de poids faibles (je sais pas si la bino du boulot suffira) et je reviendrai vous dire koi...  ;-)

Je me pose toujours la question: un écran  avec 4 trillions de couleurs adressables, étalonné, des primaires connues, avec des gamuts réglables, à température de couleur maîtrisée, est ce que ce n'est pas aussi bien qu'une mire colorchecker? 

Là, tu fais l'âne pour avoir du son : on t'a déjà longuement répondu sur ce point.

[Verso92]

Je vais essayer de décapoter l'Expeed de mon D850 et supprimer les quatre bits de poids faibles (je sais pas si la bino du boulot suffira) et je reviendrai vous dire koi...  ;-)

Un peu de patience : pour l'instant, je n'ai pas encore atteint l'Expeed.

[chelmimage]

Un peu de patience : pour l'instant, je n'ai pas encore atteint l'Expeed.

Bon, il ne faut pas que je te distraie...

[ChatOuille]

Un peu de patience : pour l'instant, je n'ai pas encore atteint l'Expeed.

Il suffit de court-circuiter les contacts de ces 4 bits. Ils prennent alors la valeur zéro.
Ai-je l'ai sérieux ?

[ChatOuille]

Pour la différence entre un affichage 8 bits et un affichage 10 bits sur un écran 10 bits, voir ci-dessous (photographies de l'écran) :

Il y a manifestement moins de banding en 10 bits. Mais je ne comprends pas très bien car j'affiche en 8 bits (je crois).