Page FB inaccessible

[MFloyd]

3 x 10 bits.


Et donc, comment mettre en évidence que l'image 16 bits serait plus lumineuse que l'image 8 bits... en imprimant l'image ?

Autre moyen ?

Je dirais, garder la plus haute qualité durant tout le procès de production; pour finalement atterrir aux contraintes de l'image imprimée, ou sur écran; qui dans, beaucoup de cas, sera le maillon le plus faible.

[Verso92]

Je dirais, garder la plus haute qualité durant tout le procès de production; pour finalement atterrir aux contraintes de l'image imprimée, ou sur écran; qui dans, beaucoup de cas, sera le maillon le plus faible.

C'est évident et la question ne se pose pas.


C'était sur le fait qu'une image 16 bits serait plus lumineuse que la même en 8 bits que je butte...

[Pierock]

C'est lié à la forme logarithmique de la courbe de gamma vs la linéarité des valeurs enregistrées et codées.

[Verso92]

C'est lié à la forme logarithmique de la courbe de gamma vs la linéarité des valeurs enregistrées et codées.

Une petite démo pour l'illustrer ?

[asak]

C'est évident et la question ne se pose pas.


C'était sur le fait qu'une image 16 bits serait plus lumineuse que la même en 8 bits que je butte...

Je ne sais pas si j'ai bien pigé la question...si la pdv n'est pas sous ex il suffit de faire une convertion de RVB 16b à srgb 8 b  la différence et d'autant plus marquée si on se met en 160cds pour le RVB et 80cds pour le 8b d'autant si on présente des captures d'écran

[Verso92]

Je ne sais pas si j'ai bien pigé la question...si la pdv n'est pas sous ex il suffit de faire une convertion de RVB 16b à srgb 8 b  la différence et d'autant plus marquée si on se met en 160cds pour le RVB et 80cds pour le 8b d'autant si on présente des captures d'écran

Là, je n'ai rien compris à ton post...


Je me contente de comparer, logiquement, une image en 16 bits convertie en 8 bits avec le même matériel, dans les mêmes conditions... sinon, à quoi bon ?

[Pierock]

Une petite démo pour l'illustrer ?

Pour quelqu'un de brillant comme toi, tu peux comprendre avec l'explication. Pour ceux que les maths emmerdent, il n'y a pas mort d'homme à passer le chemin. On en a pas besoin pour prendre des photos.

Bon, j'ai fait pas mal de maths dans ma vie. . et pour ceux qui ont des souvenirs des fonctions logarithmiques vous savez que le log permet de convertir un produit en somme.

En photo, comme vous le savez aussi, à chaque STOP ou IL, on double la quantité de lumière ...

Donc quand un capteur a 15 stops de dynamique et que je veux représenter le tracé des valeurs comme une droite, j'aurais donc une droite immense qui ne peut pas tenir dans une représentation utilisable.
Essayez de doubler chaque valeurs 15 fois et vous verrez .. (1x1, 1x2, 2x2, 4x2, 8x2, 16x2, 32x2, 64x2, 128x2, 256x2, 512x2, 1024x2, 2048x2, 4096x2, 8192x2, (ce sont des produits).. Imaginez-vous la dimension de votre droite : si une unité représente 1mm, 15 stops ferait sur échelle linéaire 16384mm soit 16,384 mètres. Bonjour l'écran de votre histogramme.

Le log permet de le faire, car je peux mettre sur une ligne des nombres de grandeurs différentes sur une même échelle. Et mes 15 IL tiennent facilement sur ma droite si entre chaque unité j'ai par exemple 5mm, 15 stops seront représentés sur 7,5cm, ce sont des sommes d'unités représentant le double de la valeur précédente ... Et on comprend bien que  les grandes valeurs seront les plus "compressées" pour que l'espace entre chaque unité soit le même (donc les HL) car en linéaire ou en somme, il y a plus d'espace entre 8192 et 16364mm qu'entre 2 et 4.

Dans les 2 cas, mon capteur a toujours 15 IL que ce soit en log ou en linéaire. Avec le log je facilite les réglages d'étalonnage sur les grandes valeurs de luminance. C'est pareil avec les niveaux de son en Décibels

(et mine de rien entre 0 et 15, cela fait 16 chiffres, soit 2 x 8, soient 2 octets informatique, je dis cela cela, je ne dis rien ... pour les conspirationnistes)

NB : On parle bien de luminance et pas de couleurs, car tu le sais ce n'est pas traité par la même couche du capteur.

[Verso92]

Pour quelqu'un de brillant comme toi, tu peux comprendre avec l'explication. Pour ceux que les maths emmerdent, il n'y a pas mort d'homme à passer le chemin. On en a pas besoin pour prendre des photos.

Bon, j'ai fait pas mal de maths dans ma vie. . et pour ceux qui ont des souvenirs des fonctions logarithmiques vous savez que le log permet de convertir un produit en somme.

En photo, comme vous le savez aussi, à chaque STOP ou IL, on double la quantité de lumière ...

Donc quand un capteur a 15 stops de dynamique et que je veux représenter le tracé des valeurs comme une droite, j'aurais donc une droite immense qui ne peut pas tenir dans une représentation utilisable.
Essayez de doubler chaque valeurs 15 fois et vous verrez .. (1x1, 1x2, 2x2, 4x2, 8x2, 16x2, 32x2, 64x2, 128x2, 256x2, 512x2, 1024x2, 2048x2, 4096x2, 8192x2, (ce sont des produits).. Imaginez-vous la dimension de votre droite : si une unité représente 1mm, 15 stops ferait sur échelle linéaire 16384mm soit 16,384 mètres. Bonjour l'écran de votre histogramme.

Le log permet de le faire, car je peux mettre sur une ligne des nombres de grandeurs différentes sur une même échelle. Et mes 15 IL tiennent facilement sur ma droite si entre chaque unité j'ai par exemple 5mm, 15 stops seront représentés sur 7,5cm, ce sont des sommes d'unités représentant le double de la valeur précédente ... Et on comprend bien que  les grandes valeurs seront les plus "compressées" pour que l'espace entre chaque unité soit le même (donc les HL) car en linéaire ou en somme, il y a plus d'espace entre 8192 et 16364mm qu'entre 2 et 4.

Dans les 2 cas, mon capteur a toujours 15 IL que ce soit en log ou en linéaire. Avec le log je facilite les réglages d'étalonnage sur les grandes valeurs de luminance. C'est pareil avec les niveaux de son en Décibels

(et mine de rien entre 0 et 15, cela fait 16 chiffres, soit 2 x 8, soient 2 octets informatique, je dis cela cela, je ne dis rien ... pour les conspirationnistes)

NB : On parle bien de luminance et pas de couleurs, car tu le sais ce n'est pas traité par la même couche du capteur.

Pourquoi essayer de noyer le poisson ?


Il y a une expérience simple, réalisable par tout un chacun : il suffit d'ouvrir une image 16 bits dans Photoshop (ou équivalent), de la convertir en 8 bits, et de voir si cette image est moins lumineuse (ou pas) que l'image d'origine en 16 bits...

[Pierock]

Pourquoi essayer de noyer le poisson ?


Il y a une expérience simple, réalisable par tout un chacun : il suffit d'ouvrir une image 16 bits dans Photoshop (ou équivalent), de la convertir en 8 bits, et de voir si cette image est moins lumineuse (ou pas) que l'image d'origine en 16 bits...

Rhooo ... non pas toi !

[Verso92]

Rhooo ... non pas toi !

Trop simple ?

[Pierock]

C'est une approximation technique mais qui ne donne pas l'explication théorique, prendre une image dematricée et compressée en 8 ou 16 bits, c'est un mélange de chroma et luma avec une courbe de contraste et de saturation de represente pas le propos. La miss N.S. parle de RAW et de luminance.

On fait de l'ETTR (Expose to the right) + 1,33 pour compenser la limite RVB de l'histogramme du boitier, et récupérer plus dans les indices de luminances élévés : avant développement
et avant développement, la luminance c'est une courbe gamma en log ramenée à une droite qui contient plus d'informations de lumière dans le coté droit que dans le coté gauche du gamma.

[bruno-v]

Pour moi, une image 16 bits n'a aucune raison d'être plus lumineuse que la même en 8 bits.

pour moi aussi -> aucune
sauf à introduire un point souvent laissé dans l'ombre: le choix du moteur de rendu, perceptif/relatif/absolu. Ce n'est pas pour rien qu'il y en a plusieurs, parfois c'est proche, parfois cela génère des écarts visibles.

De la même manière qu'un son échantillonné en 24 bits n'aura pas un niveau plus élevé que le même enregistré en 16 bits, etc.

avec une nuance: lors d'une conversion entre format différents, il y a parfois besoin de faire coïncider le niveau de référence (le 0dB). Et comme le cerveau préfère toujours le signal le plus fort, il y a parfois une appréciation différente (qui ne change rien à la réalité du signal)
a+

[bruno-v]

prendre une image dematricée et compressée en 8 ou 16 bits,

traitée, pas obligatoirement compressée si le traitement est adapté au signal "complet"
(ce qui n'empêche pas de décimer si on veut gagner en vitesse de traitement)
a+

[Pierock]

au temps pour moi, mes doigts ont fourchés, je voulais dire échantillonnage et pas compression.

[bruno-v]

au temps pour moi, mes doigts ont fourchés, je voulais dire échantillonnage et pas compression.

Je me doutais bien 
C'était pour éviter la confusion avec la compression du jpg (qui reste un format particulièrement pratique et efficace)
a+

[MFloyd]

3 x 10 bits.


Et donc, comment mettre en évidence que l'image 16 bits serait plus lumineuse que l'image 8 bits... en imprimant l'image ?

Autre moyen ?

La brillance perçue d'une image n'est pas directement dépendante du nombre de bits, mais la précision avec laquelle cette brillance est reproduite, oui.

⸻

🎨 1. Ce que le nombre de bits fait vraiment
   •   Le nombre de bits par canal (bit depth) détermine combien de niveaux de luminosité peuvent être représentés dans chaque couleur (rouge, vert, bleu).
   •   Exemple :
   •   8 bits → 256 niveaux possibles (de 0 à 255) par canal
   •   10 bits → 1 024 niveaux
   •   12 bits → 4 096 niveaux

Donc :

➤ Plus il y a de bits, plus la transition entre les tons sombres et clairs est fluide.

⸻

💡 2. Brillance vs profondeur de bits
   •   La brillance (luminance) est la quantité de lumière émise par l'écran → dépend du rétroéclairage, du contraste et du calibrage, pas directement des bits.
   •   En revanche, la profondeur de bits influence la finesse des nuances lumineuses, donc la précision avec laquelle la brillance est rendue.

En résumé :

🔸 Le nombre de bits ne rend pas une image plus brillante,
🔸 mais il rend la gradation de brillance plus précise et plus naturelle.

⸻

⚙️ 3. Exemple concret

Prenons une scène avec un dégradé de ciel :
   •   En 8 bits, tu risques de voir des bandes (« banding »), car 256 niveaux ne suffisent pas pour décrire la transition douce du bleu au blanc.
   •   En 10 bits, le dégradé est parfaitement lisse, les transitions lumineuses sont continues.

⸻

📺 4. En résumé:

   •   Travaille idéalement sur un écran 10 bits réels (pas 8 bits + FRC) pour un rendu fidèle en post-production.

[bruno-v]

Prenons une scène avec un dégradé de ciel :
   •   En 8 bits, tu risques de voir des bandes (« banding »), car 256 niveaux ne suffisent pas pour
décrire la transition douce du bleu au blanc.

un des canaux R ou V ou B c'est effectivement 256 valeurs, le blanc c'est avec les 3 canaux R+V+B =24bits
tout comme les 256 niveau de gris pour le n&b, ce n'est peut-être pas parfait, mais c'est déjà suffisant.
a+

[egtegt²]

Au final elle se trompe, une image en RAW 14 bits permet de représenter 4400 milliards de couleurs différentes, une image en jpeg permet de représenter 16 millions de couleurs différentes, donc en fait on ne perd pas 99% mais 99,96% de nuances.

[...]
⚙️ 3. Exemple concret

Prenons une scène avec un dégradé de ciel :
    •    En 8 bits, tu risques de voir des bandes (« banding »), car 256 niveaux ne suffisent pas pour décrire la transition douce du bleu au blanc.
    •    En 10 bits, le dégradé est parfaitement lisse, les transitions lumineuses sont continues.

[...]

C'est vrai et faux. C'est vrai si tu as un ciel d'un bleu pur, ne contenant aucune composante ni de rouge ni de vert. Sinon la combinaison des composantes permet bien plus de nuances.

Donc si tu crées avec un logiciel graphique un dégradé de bleu pur, tu vois effectivement la différence entre 8 bits et 10 bits, dans la vrai vie un ciel avec un dégradé de bleu parfaitement pur n'existe jamais donc on a bien plus de 256 nuances. Ce qui explique que même avec un ciel avec un superbe dégradé en 8 bits, on ne voit aucun banding.

[MFloyd]

Dans la vraie vie, il y aura toujours des zones ne comprenant qu'une seule composante.

[Alain c]

Dans la vraie vie ,on a tous vu de superbes images en 8 bits, même des photos de prises de vue en  .JPEG, (photos de sport par ex).

Il y a une ancienne vidéo de cette N Satura ou je suis parfaitement d'accord avec elle, c'est celle ou elle explique qu'un commentaire avec des fautes d'orthographe ou fautes de français volontaires a beaucoup plus de réponses qu'un autre bien écrit.
C'est ce qu'elle applique en disant des contres vérités ou des énormités du genre les optiques de 2025 sont bien moins bonnes que celles d'avant le numerique; ça fait réagir et lui fait sa pub, mouiaissss ... c'est un peu ce que l'on fait ici.
Trsite et dommage pour ceux qui croient tout ce qu'elle raconte.

[Verso92]

La brillance perçue d'une image n'est pas directement dépendante du nombre de bits, mais la précision avec laquelle cette brillance est reproduite, oui.

⸻

🎨 1. Ce que le nombre de bits fait vraiment
   •   Le nombre de bits par canal (bit depth) détermine combien de niveaux de luminosité peuvent être représentés dans chaque couleur (rouge, vert, bleu).
   •   Exemple :
   •   8 bits → 256 niveaux possibles (de 0 à 255) par canal
   •   10 bits → 1 024 niveaux
   •   12 bits → 4 096 niveaux

Donc :

➤ Plus il y a de bits, plus la transition entre les tons sombres et clairs est fluide.

⸻

💡 2. Brillance vs profondeur de bits
   •   La brillance (luminance) est la quantité de lumière émise par l'écran → dépend du rétroéclairage, du contraste et du calibrage, pas directement des bits.
   •   En revanche, la profondeur de bits influence la finesse des nuances lumineuses, donc la précision avec laquelle la brillance est rendue.

En résumé :

🔸 Le nombre de bits ne rend pas une image plus brillante,
🔸 mais il rend la gradation de brillance plus précise et plus naturelle.

⸻

⚙️ 3. Exemple concret

Prenons une scène avec un dégradé de ciel :
   •   En 8 bits, tu risques de voir des bandes (« banding »), car 256 niveaux ne suffisent pas pour décrire la transition douce du bleu au blanc.
   •   En 10 bits, le dégradé est parfaitement lisse, les transitions lumineuses sont continues.

⸻

📺 4. En résumé:

   •   Travaille idéalement sur un écran 10 bits réels (pas 8 bits + FRC) pour un rendu fidèle en post-production.

Un point que j'ai peut-être omis de préciser : je parle d'image finalisées.

Et là, bien malin qui verra une différence entre 16 et 8 bits...

[Verso92]

📺 4. En résumé:

    •    Travaille idéalement sur un écran 10 bits réels (pas 8 bits + FRC) pour un rendu fidèle en post-production.

Essais réalisés à l'époque (en photographiant l'écran) :

[Verso92]

C'est vrai et faux. C'est vrai si tu as un ciel d'un bleu pur, ne contenant aucune composante ni de rouge ni de vert. Sinon la combinaison des composantes permet bien plus de nuances.

Donc si tu crées avec un logiciel graphique un dégradé de bleu pur, tu vois effectivement la différence entre 8 bits et 10 bits, dans la vrai vie un ciel avec un dégradé de bleu parfaitement pur n'existe jamais donc on a bien plus de 256 nuances. Ce qui explique que même avec un ciel avec un superbe dégradé en 8 bits, on ne voit aucun banding.

Oui.


Après, les dés sont pipés, aussi : sur mon PC, seul Photoshop est capable d'afficher en 3 x 10 bits.

Le dégradé synthétique (fichier RamP) est moins marqué en 10 bits qu'en 8 bits sous PS, et... disparait complètement sous Capture One (dithering) !

[Verso92]

Dans la vraie vie, il y aura toujours des zones ne comprenant qu'une seule composante.

Je viens d'essayer avec une image comportant un ciel dégradé.

Développement (Capture One) avec export en TIFF 8 bis et 16 bits : aucune différence visible sous Photoshop...


Ci-dessous la version Jpeg avec la compression mini, pour illustration :

[MFloyd]

Beaucoup de material applique automatiquement du dithering.

Les cartes graphiques d'Apple, AMD, Nvidia ou Intel appliquent souvent un dithering de sortie :
   •   C'est un algorithme dans le pipeline de rendu qui ajoute un bruit contrôlé avant conversion en 8/10 bits.
   •   Il agit en temps réel sur les dégradés d'image (notamment en HDR ou lors de conversion de profils ICC).

👉 Sur macOS, ce dithering est géré au niveau du système (Core Graphics / Metal),
et impossible à désactiver via les réglages standards.