Problème de rendus des dégradés en noir et blanc

[Olivier Chauvignat]

Je la détruis dans PSE ??

Que devrais-je faire ? Rester en TIFF dans PSE ?

Je souhaite intervenir dans certaines zones seulement, donc je dois utiliser PSE, non ?

Comme déja dit, vous devez rester en 16 bits (tiff ou .psd)
Donc exit PSE dont c'est la limitation majeure (pas de 16 bits)

Si vous ne retouchez pas, vous pouvez faire votre NB entièrement dans Lightroom.

[Olivier Chauvignat]

Le 8bit doit être suffisant pour du noir et blanc

C'est marrant, on est en train de dire exactement le contraire.

Le noir et blanc, ca se travaille. C'est pas simplement "une photo sans couleurs". On retravaille notamment le contraste et la luminosité. Or tout travail sur la tonalité (c'est a dire sur la luminosité et le contraste) "tire" énormément sur les ressources du fichier.

Donc :

- Un noir et blanc se construit en RAW, si possible dans LR/ACR qui ont des outils fins et puissants pour cela.
- Si on le passe dans PSD pour retouche, on le fait en 16 bits psd ou tiff, on ne touche pas à la luminosité contraste, sauf pour le contrastage final et exclusivement si on utilise des techniques "expert" de contrastage

Notez que le contraste ne se fait qu'a la fin. On ne travaille jamais en bitmap (psd/tiff) sur un fichier contrasté, mais uniquement sur un fichier "doux", sinon on va "casser" les dégradés. On ne contraste qu'après avoir fini le travail de retouche.

[gerarto]

Ce n'est pas parce que PSE n'est pas l'outil vraiment adapté que le problème vient obligatoirement de là...

Quand même une précision qui a son importance. PSE sait faire quelques opérations en 16 bits, dont les courbes et le contraste : même si ce n'est pas l'idéal pour du travail léché (et que ça fait sursauter O.C., probablement à juste titre), il faut quand même lui rendre cette justice !

Avant d'aller plus loin, un essai à faire par frede : dans ACR (en 16 bits, évidemment), passer en noir et blanc en désaturant (saturation à -100), puis régler le contraste, etc en y allant assez fort, et voir s'il y a ce phénomène de dégradé à ce stade, puis idem en ouvrant l'image dans PSE toujours en 16 bits, puis enfin en passant en 8 bits et en faisant la "conversion en N&B", même si l'image est déjà en N&B..

NB : pas la peine de me dire que ce n'est pas comme ça qu'on fait du N&B : c'est évident, pour l'instant on cherche juste à comprendre le problème...

[pikepeak]

C'est marrant, on est en train de dire exactement le contraire.

Le noir et blanc, ca se travaille. C'est pas simplement "une photo sans couleurs". On retravaille notamment le contraste et la luminosité. Or tout travail sur la tonalité (c'est a dire sur la luminosité et le contraste) "tire" énormément sur les ressources du fichier.

Donc :

- Un noir et blanc se construit en RAW, si possible dans LR/ACR qui ont des outils fins et puissants pour cela.
- Si on le passe dans PSD pour retouche, on le fait en 16 bits psd ou tiff, on ne touche pas à la luminosité contraste, sauf pour le contrastage final et exclusivement si on utilise des techniques "expert" de contrastage

Notez que le contraste ne se fait qu'a la fin. On ne travaille jamais en bitmap (psd/tiff) sur un fichier contrasté, mais uniquement sur un fichier "doux", sinon on va "casser" les dégradés. On ne contraste qu'après avoir fini le travail de retouche.

Merci pour ces éclaircissements.

[kaf]

C'est marrant, on est en train de dire exactement le contraire.

Je ne sais pas si je trouve ça marrant ou navrant en fait

Le noir et blanc, ca se travaille. C'est pas simplement "une photo sans couleurs". On retravaille notamment le contraste et la luminosité. Or tout travail sur la tonalité (c'est a dire sur la luminosité et le contraste) "tire" énormément sur les ressources du fichier.

Pour essayer d'illustrer concrètement le problème: en 8 bits, un n&b contient 256 niveaux de gris. Ni plus, ni moins. C'est ridiculement faible comme profondeur d'encodage, et il est évidement que la postérisation est inévitable dès que l'on va toucher au contraste ou à la luminosité. Tout simplement parce que le fichier ne contient pas assez d'informations.

[gerarto]

Bon, j'ai essayé de reproduire le phénomène constaté par frede en essayant de suivre sa procédure, si je l'ai bien comprise.

J'ai cherché un raw avec un ciel dégradé au maximum, je l'ai ouvert dans PSE 10 avec ACR 6.6.0. J'ai poussé les curseurs de lumière d'appoint et luminosité pour avoir un écart maximal dans le ciel (sans HL grillées). J'ai ensuite ouvert l'image dans PSE, puis passée immédiatement en 8 bits. Puis, "Convertir en Noir et Blanc", style (au hasard) "Paysages panoramiques". Et enfin, Accentuation/Luminosité-Contraste : contraste + 100% !

Ben, vous savez quoi : je n'ai pas le début d'un commencement de gris "en courbes de niveau" ! Et pourtant j'ai fait un vrai massacre.

Donc, et je m'en doute un peu depuis le début, ce n'est pas forcément la méthode qui est mauvaise (à défaut d'être la meilleure, on est bien d'accord ! ), mais peut-être un autre problème...

Première piste : problème de carte graphique ?

Deuxième piste : pour avoir un début, je dis bien un début, de postérisation, il me faut passer en 256 couleurs "exactes" (par Mode/Couleurs indexées). La postérisation devient très visible si je choisis la palette "Système Mac OS" et catastrophique si je choisis la palette "Système windows", toujours dans couleur indexées.

L'exemple en question : 

[Olivier Chauvignat]

autre truc tout con : est-ce que l'image a été visualisée à 100% ?

Parce que zoomée, une image peut présenter de la postérisation qui n'existe pas en fait...

[remico]

Je ne sais pas si je trouve ça marrant ou navrant en fait

Pour essayer d'illustrer concrètement le problème: en 8 bits, un n&b contient 256 niveaux de gris. Ni plus, ni moins. C'est ridiculement faible comme profondeur d'encodage, et il est évidement que la postérisation est inévitable dès que l'on va toucher au contraste ou à la luminosité. Tout simplement parce que le fichier ne contient pas assez d'informations.

C'est le cas de toutes les images jpg que l'on peut trouver sur le web, il n'est pas plus aisé de différencier 256 nuances de gris que 256 nuances de bleu, libre à chacun de trouver cette limite suffisante ou pas.

De plus le codage jpg a un système de codage de fréquences qui fait que tous les pixels ne sont pas uniformes. Chacun peut le constater en prenant une image et l'enregistrant en qualité mini 1%, il y a des pixels uniformes et d'autres non. Info trouvée ici :
http://www.anael.eu/bts_ig/AMSI/Chapitre_5.5_-_le_JPEG.pdf

Un autre utilisateur de Photoshop a rencontré ce problème de banding sur filtre et explique sa solution :
http://slodive.com/photoshop/how-to-correct-banding-in-your-gradients-using-photoshop/

[kaf]

C'est le cas de toutes les images jpg que l'on peut trouver sur le web, il n'est pas plus aisé de différencier 256 nuances de gris que 256 nuances de bleu, libre à chacun de trouver cette limite suffisante ou pas.

Sauf qu'en couleur, on peut jouer sur trois composantes et tricher un peu pour lisser un dégradé, ce qui n'est pas possible en noir et blanc. Il y a 256 nuances, pas plus, on ne peut pas en ajouter.

De plus le codage jpg a un système de codage de fréquences qui fait que tous les pixels ne sont pas uniformes. Chacun peut le constater en prenant une image et l'enregistrant en qualité mini 1%, il y a des pixels uniformes et d'autres non. Info trouvée ici :
http://www.anael.eu/bts_ig/AMSI/Chapitre_5.5_-_le_JPEG.pdf

Vous n'avez pas compris l'article. Les pixels sont forcément uniformes, ce sont les blocs qui ne le sont pas nécessairement. Un bloc est un carré composés de pixels. De plus, cet article n'a rien à voir avec le problème dont on parle ici.

[remico]

Extrait de l'aide de Photoshop sur le site Adobe :

Pour créer un fondu plus régulier avec un faible effet de bandes, sélectionnez Simuler

J'en déduis que :

1/ Il peut y avoir éventuellement des effets de bande avec les dégradés
2/ Cette option Simuler atténue le problème.

http://help.adobe.com/fr_FR/photoshop/cs/using/WSfd1234e1c4b69f30ea53e41001031ab64-77e1a.html

Vous n'avez pas compris l'article. Les pixels sont forcément uniformes, ce sont les blocs qui ne le sont pas nécessairement. Un bloc est un carré composés de pixels. De plus, cet article n'a rien à voir avec le problème dont on parle ici.

J'avais mal compris effectivement. Les pixels sont groupés en carré 8x8 et chaque carré reçoit une information de fréquence. Certains carré de 8x8 sont uniforme et d'autres pas. Ceux qui ne sont pas uniformes sont eux mêmes composés de pixels non-uniformes, il suffit d'enregistrer une image jpg à qualité 1% pour visualiser les groupes de 8x8 (que j'avais pris pour des pixels individuels)

Cela concerne le rendu des transition de dégradé dans le fichier final en 8bit quant à la façon dont le logiciel traite les données en interne je l'ignore et souhaite continuer de l'ignorer.

[frede]

En tout cas, merci à tous pour vos conseils.

Ayant été absent ce we, je vais essayer cette semaine, de mettre en pratique vos façon de procéder.

Je vous tiendrai au courant des effets obtenus.

[frede]

Bonjour,

Voilà, j'ai fait des essais et ... mon problème est résolu  . Merci à tous pour cela.

J'ai donc utilisé ACR en restant bien en 16 bits et j'ai transféré mon fichier en tiff sur un ordi avec PS CS4. Là, j'ai pu augmenté les contrastes sur certaines zones et je n'ai constaté aucune apparition de dégradé ou d'effet de postérisation.

Par acquis de conscience, j'ai réessayé avec PS Element (sur le même poste que prédédemment) et là à nouveau les effets indérisables.

Conclusion: La solution résidait dans

- L'échantillonnage en 16 bits au lieu de 8 bits à la sortie de ACR
- L'utilisation de PS CS4 à priori moins destructif que Element

Plus qu'à essayer avec Lightroom (dès que j'aurai reçu mon OSX 10.6).

Encore merci à tous pour votre aide.