gratifiant > rec.media.* > rec.photo.materiel

efji (17/03/2019, 17h15)
On 17/03/2019 15:49, Benoît wrote:
> efji <efji> wrote:
> Je crois que je me suis mal exprimé. Relis bien la première phrase.


Je relis, je relis. "4 bits inutilisés" ça n'a aucun sens. Ce n'est pas
comme ça que c'est codé.

> Le tiff est bien en 16 bits, mais il sait stocker une image qui n'a que
> 12 bits d'info, tout comme le fait qu'une image 8bit peut être
> enregistrée en tant que tiff 16 bits. Il peut aussi être en 8bits, mais
> ce n'était pas le sujet.


Tu compliques tout ce qui est simple :
Imagine que les niveaux de chaque couleur sont codés entre 0 et 255.
Avec un codage sur 8 bit tu as accès à toutes les valeurs entières entre
0 et 255. Avec un codage 10 bits (ça n'existe pas mais c'est pour te
faire comprendre) tu aurais accès en plus aux quarts de valeurs :
123.25, 123.50, 123.75. avec un codage 16 bits tu as accès aux 1/256e de
valeurs. Mais évidemment il faut que ta source initiale le permette.
Quand tu enregistres une image 8 bits dans un tiff 16 bits tu gardes
exactement la même information et personne n'invente les valeurs
intermédiaires.

> variées là ça apparaît. Sur un de mes ciels j'ai ajouté un dégradé de
> blanc au bleu. Impeccable à l'écran, des aplats bien visibles au tirage.


Mauvais tirage. Change de tirage.
Mon expérience est exactement inverse : certains petits défauts visibles
à l'écran (par exemple des artecfacts jpeg visibles à 100%)
disparaissent la plupart du temps au tirage.
Alf92 (17/03/2019, 17h58)
efji :

> Mauvais tirage. Change de tirage.
> Mon expérience est exactement inverse : certains petits défauts visibles
> à l'écran (par exemple des artecfacts jpeg visibles à 100%)
> disparaissent la plupart du temps au tirage.


j'ai aussi constaté ça.
c'est que le tirage présente moins d'infos que l'original et que les
défauts sont les premiers à disparaitre, ou c'est qu'il y a qques part
un algo d'optimisation/amélioration sur la chaine d'impression ?
jdd (17/03/2019, 18h25)
Le 17/03/2019 à 16:58, Alf92 a écrit :
> efji :
> j'ai aussi constaté ça.
> c'est que le tirage présente moins d'infos que l'original et que les
> défauts sont les premiers à disparaitre, ou c'est qu'il y a qques part
> un algo d'optimisation/amélioration sur la chaine d'impression ?

il y a très longtemps, vers la foin de l'argentique, j'avais fait faire
des tirages et en même temps des scans sur CD.

quand j'ai voulu regarder les scans, il y avait un grain de folie,
invisible sur les tirages. Juste un très bon logiciel sur
l'imprimante... rien que la ma deskjet faisait déjà du très bon boulot

jdd
Benoît (17/03/2019, 22h37)
efji <efji> wrote:

> On 17/03/2019 15:49, Benoît wrote:
> Je relis, je relis. "4 bits inutilisés" ça n'a aucun sens. Ce n'est pas
> comme ça que c'est codé.


Si ! Le tiff ne le fait pas, mais ton appareil oui. Admettons qu'il y
ait un pixel noir à 100% suivi d'un blanc 100% : en 16 bits j'ai (les
valeurs sont fausses voir plus bas).
00001111-11111111 puis 00000000-00000000, en 12 bits j'ai
11111111-11110000 puis 00000000-xxxxxxxx : j'ai besoin d'un octet de
moins pour stocker l'information, je passe de 4 octets à 3 octets.
L'appareil enregistre son 12 bits de cette façon là, il y a des octets
qui contiennent des données concernant deus pixels, et c'est pourquoi
lorsque tu enregistres une image 12 bits en 16 bits elle est plus
grosse.

En plus elle ne contient pas plus d'information ! Imagines un appareil
qui enregistre des images noir OU blanc. Avec un bit j'ai un pixel, il
est noir 1 ou blanc 0. Avec un octet je peux donc avoir les infos de 256
pixels. An 8 bits je vais enregistré 11111111 ou 00000000 (là pour le
coup je suis juste en terme d'encodage des couleurs).

> Tu compliques tout ce qui est simple :
> Imagine que les niveaux de chaque couleur sont codés entre 0 et 255.
> Avec un codage sur 8 bit tu as accès à toutes les valeurs entières entre
> 0 et 255. Avec un codage 10 bits (ça n'existe pas mais c'est pour te
> faire comprendre) tu aurais accès en plus aux quarts de valeurs :
> 123.25, 123.50, 123.75. avec un codage 16 bits tu as accès aux 1/256e de
> valeurs. Mais évidemment il faut que ta source initiale le permette.
> Quand tu enregistres une image 8 bits dans un tiff 16 bits tu gardes
> exactement la même information et personne n'invente les valeurs
> intermédiaires.


Absolument sauf que si tu retouches, tu as plus de lattitude et moins de
débordement. J'augmente la luminosité du rouge de 10%, mon 128 passe à
141 dans un cas et 140,75 dans l'autre et je continue mes retouches...
je me retrouve avec des ruptures franches de couleurs.

> > variées là ça apparaît. Sur un de mes ciels j'ai ajouté un dégradé de
> > blanc au bleu. Impeccable à l'écran, des aplats bien visibles au tirage.

> Mauvais tirage. Change de tirage.


Pas du tout, en zommant sur la zone j'ai vu la rupture.

> Mon expérience est exactement inverse : certains petits défauts visibles
> à l'écran (par exemple des artecfacts jpeg visibles à 100%)
> disparaissent la plupart du temps au tirage.


Bin oui ! Fait tirer un damier de 8x8 (un rose noir ou violet) en
20x20cm : tu as un tas de boue. J'ai testé ça dans ma jeunesse et même
PS ne savait pas me faire une image 8000x8000 parfaitement nette. J'ai
du écrire du code pour le faire « à la main ». En fait ce n'était pas
des damiers N/B mais des tirages d'images très basse résolution en très
grand format (par rapport à elle) et en conservant le côté « damier ».

Et si tu veux une idée du gus qui met les mains dans le moteur, j'ai
écris un logiciel à qui tu donnes une image en 64 couleurs (je ne suis
pas allé plus loin cf ce qui suit) en document XPress pour des plans de
point de croix (truc où tu couds une image en changeant de couleur de
fil pour chaque point) :
- Tu prends l'image, donc 64 couleurs sur 256, tu remplaces chaque pixel
par un caractère, en fait tu rammènes tes 64 couleurs dans une zone
d'octet qui n'a pas d'utilisation hors le texte donc à partir du 33e ;
- Tu dessines ta propre police de caractère pour ces 64 couleurs avec un
chaque caractère étant un carré avec un symbole bien différent dedans. -
Tu bosses pour que tes caractères soient bien collés les uns aux autres
droite/gauche et dessus/dessous. Pas d'espace, que des lignes ;
- Tu importes ce texte dans dans la zone de « plan » d'un modèle Xpress
qui a en plus des traits épais tous les dix caractères et des un peu
plus fins tous les 5/15/25... pour que celui qui lit le document sachent
bien où il se trouve ;
- Tu importe d'autres fichiers avec quelques fioritures genre A = fil de
couleur 3268...

Et ton document est prêt pour l'impression nickel-chrome.

OK ? Il n'y connaît rien le benêt Benoît ? Il lui arrive de se tromper,
juste moins souvent que les autres.
Et Hop !
Didier (18/03/2019, 19h29)
Le 17/03/2019 à 16:15, efji a écrit :
[..]
> Quand tu enregistres une image 8 bits dans un tiff 16 bits tu gardes
> exactement la même information et personne n'invente les valeurs
> intermédiaires.

Pour être plus exact, avec 10 bits tu codes les couleurs sur une échelle
de 0 à 4 fois 255, etc ...
8 bits -> 255 valeurs possibles
16 bits -> 65535 valeurs possibles (j'espère que je ne me trompe pas
dans le calcul)
Le fait de ne pas pouvoir coder entre les valeurs entières de l'échelle
provoque ce qu'on appelle "le bruit de quantification", soit l'écart
entre la valeur exacte et la valeur entière la plus proche retenue par
l'algorithme de quantification.
Mais on ne code pas sur des valeurs non entières de l'échelle.
Didier.
efji (18/03/2019, 19h33)
On 18/03/2019 18:29, Didier wrote:

[..]
> l'algorithme de quantification.
> Mais on ne code pas sur des valeurs non entières de l'échelle.
> Didier.


Absolument, mais il me semblait que c'était plus clair pour le coco à
qui je m'adressais :)
En fait si 0 correspond au noir et 1 au blanc, on code le niveau de gris
entre 0 et 1 par pas de 1/255 en 8 bits et 1/65535 en 16 bits. En donc
1/1023 en 10 bits.
Benoît (18/03/2019, 20h31)
Didier <dbnospam> wrote:

> Le 17/03/2019 à 16:15, efji a écrit :
> Pour être plus exact, avec 10 bits tu codes les couleurs sur une échelle
> de 0 à 4 fois 255, etc ...
> 8 bits -> 255 valeurs possibles


256 : 2, 4, 8, 16, 32, 64, 128, 256, 512, 1 024, 2 048, 4 096, 8 192,
16 384, 32 768, 65 536.

> 16 bits -> 65535 valeurs possibles (j'espère que je ne me trompe pas
> dans le calcul)


Juste de 1, c'est pas grand chose, sauf qu'un multiple de 2 ne peut être
impair. ;)

> Le fait de ne pas pouvoir coder entre les valeurs entières de l'échelle
> provoque ce qu'on appelle "le bruit de quantification", soit l'écart
> entre la valeur exacte et la valeur entière la plus proche retenue par
> l'algorithme de quantification.


Exact et merci pour les termes.

> Mais on ne code pas sur des valeurs non entières de l'échelle.


Qu'entends-tu par « coder » ? Pour moi le code est le programme qui sait
ou peut gérer les valeurs « non-entières ». Ce que je veux dire c'est
que tu peux très bien avoir un programme qui sait travailler sur 16
octets et enregistrer le résultat sur 8. Tu peux donc faire plusieurs
modifications en 16 bits pour enregistrer le fichier résultant en 8
bits.

C.f. Edward Lorenz et sa découverte de l'effet papillon. Un grand moment
dans ma vie d'amoureux des maths et de la programmation. C'est mieux que
l'origine (fable ?) du bug.
jeanpasse (19/03/2019, 06h13)
Le dimanche 17 mars 2019 11:15:41 UTC-4, efji a écrit :
[..]
> Mon expérience est exactement inverse : certains petits défautsvisibles
> à l'écran (par exemple des artecfacts jpeg visibles à 100%)
> disparaissent la plupart du temps au tirage.


Rendu à la transposition des pixels de l'image - de 8 à 16 bits -en taches
taches d'encres - de 4, 8 10 ou 12 couleurs - taches plus ou moins régulières
et baveuses nous sommes très loin de l'image d'origine vue sur écran,
directement de l'apn ou d'origine argentique.
Imprimée ce n'est plus la même image.

Il faudrait donc étudier ces questions sur l'ensemble des processus sil'on veut se plaindre du "banding" à l'impression, n'est-ce pas?

René
Benoît (19/03/2019, 14h55)
<jeanpasse> wrote:

> Le dimanche 17 mars 2019 11:15:41 UTC-4, efji a écrit :
> Rendu à la transposition des pixels de l'image - de 8 à 16 bits - en
> taches taches d'encres - de 4, 8 10 ou 12 couleurs - taches plus ou moins
> régulières et baveuses nous sommes très loin de l'image d'origine vue sur
> écran, directement de l'apn ou d'origine argentique. Imprimée ce n'est
> plus la même image.


Oui, là c'est suite à des « retouches » : création d'un ciel dégradé
PUIS d'autres modifications sur l'ensemble de l'image. Cela avait beau
être du 14bits cela a généré des aplats dans le dégradé, dans la zone où
justement ce dégradé était assez léger en luminosité mais sur une grande
zone. Si on fait très attention et qu'on regarde longtemps l'image ils
finissent par être visibles, ou plutôt détectable. En fait c'est en
voyant l'impression que j'ai pu les voir.

> Il faudrait donc étudier ces questions sur l'ensemble des processus si
> l'on veut se plaindre du "banding" à l'impression, n'est-ce pas?


Exactement. J'ai appris une bonne leçon, maintenant à moi de ne pas
refaire l'erreur, mais laquelle ? C'est là qu'il faut que bosse en
faisant très attention la prochaine fois. Surtout il faut que je trouve
une technique pour la détecter. Renforcer le contraste le plus possible
et voir ce qui se passe au fur et à mesure qu'il augmente ? Baisser les
luminosités (très foncé, moyen, clair, très blanc) une par une, par
paire... ? Trouver un des outils PS qui va justement créer des bandes et
voir des fines et une beaucoup plus épaisse ?
efji (19/03/2019, 15h10)
On 19/03/2019 13:55, Benoît wrote:
> Oui, là c'est suite à des « retouches » : création d'un ciel dégradé
> PUIS d'autres modifications sur l'ensemble de l'image. Cela avait beau
> être du 14bits cela a généré des aplats dans le dégradé, dans la zone où


Tu n'étais certainement pas "en 14 bits" car ça n'existe pas !

Ton apn sort du raw 14 bits (qui sont, je le rappelle, des bits
monochromes). Pour simplement le visualiser il faut le traduire en autre
chose, en particulier autre chose en 3 couleurs par pixels. Tant que tu
manipules le soft qui lite le raw, tout va bien. Si tu commences à
vouloir faire de la retouche, comme par exemple "rajouter un dégradé",
il faut exporter ton image et la réimporter dans ton logiciel de
retouche. Pour l'exporter tu as simplement deux choix : 3x8 bits/pixel
ou 3x16 bits/pixel.

Si tu l'exportes en 3x8bits tu es en 8 bits pour toute la suite de la
séquence et c'est probablement ce que tu as fait. L'autre possibilité
est simplement que ton soft ne sait générer que des dégradés 8 bits,
donc même si ton codage est sur 16 bits, l'information n'est pas là et
si tu touches trop au contraste tu peux obtenir des bandes dans le dégradé.
[..]
Benoît (19/03/2019, 15h21)
efji <efji> wrote:

> On 19/03/2019 13:55, Benoît wrote:
> > Oui, là c'est suite à des « retouches » : création d'un ciel dégradé
> > PUIS d'autres modifications sur l'ensemble de l'image. Cela avait beau
> > être du 14bits cela a généré des aplats dans le dégradé, dans la zone où

> Tu n'étais certainement pas "en 14 bits" car ça n'existe pas !


L'image originale si. Mais PS l'ouvre comme une 16 bits bien sûr.

> Ton apn sort du raw 14 bits (qui sont, je le rappelle, des bits
> monochromes). Pour simplement le visualiser il faut le traduire en autre
> chose, en particulier autre chose en 3 couleurs par pixels. Tant que tu
> manipules le soft qui lite le raw, tout va bien. Si tu commences à
> vouloir faire de la retouche, comme par exemple "rajouter un dégradé",
> il faut exporter ton image et la réimporter dans ton logiciel de
> retouche. Pour l'exporter tu as simplement deux choix : 3x8 bits/pixel
> ou 3x16 bits/pixel.


cf ci-dessus

> Si tu l'exportes en 3x8bits tu es en 8 bits pour toute la suite de la
> séquence et c'est probablement ce que tu as fait. L'autre possibilité
> est simplement que ton soft ne sait générer que des dégradés 8 bits,
> donc même si ton codage est sur 16 bits, l'information n'est pas là et
> si tu touches trop au contraste tu peux obtenir des bandes dans le dégradé.


Je ne vois pas PS proposer de filtres qui fonctionnent uniquement en 8
bits. Ensuite j'ai envoyé une image 16bits, qui a peut-être été basculée
en 8bits à l'impression ce qui a accru la visibilité des bandes. Cela
étant, les bandes étaient là sur la 16 bits, juste difficiles à
détecter. Le type de défaut qu'on ne voit qu'à l'impression et
difficilement sur un écran.

D'autant que PS peut t'afficher des bandes qui disparaîssent quand tu
zoomes dessus.
[..]
Benoît (19/03/2019, 16h05)
efji <efji> wrote:

[..]
> est simplement que ton soft ne sait générer que des dégradés 8 bits,
> donc même si ton codage est sur 16 bits, l'information n'est pas là et
> si tu touches trop au contraste tu peux obtenir des bandes dans le dégradé.


J'ai trouvé un site qui explique pas mal de choses.
<https://photographylife.com/what-is-color-banding-and-how-to-fix-it>

Et un qui explique mieux (j'y arrive pas, il faut que je demande à un
copain matheux) la différence entre le 16 bit integer et le 16 bit
floating point. J'ai une petite idée, mais je n'ose pas la divulguer ;)
Markorki (19/03/2019, 16h33)
Benoît a écrit :
> Oui, là c'est suite à des « retouches » : création d'un ciel dégradé
> PUIS d'autres modifications sur l'ensemble de l'image. Cela avait beau
> être du 14bits cela a généré des aplats dans le dégradé, dans la zone où
> justement ce dégradé était assez léger en luminosité mais sur une grande
> zone. Si on fait très attention et qu'on regarde longtemps l'image ils
> finissent par être visibles, ou plutôt détectable. En fait c'est en
> voyant l'impression que j'ai pu les voir.


J'ai déjà abordé ce sujet : selon le taux de compression (donné par la valeur
minimale de différence de
couleur entrainant l'encodage de nouveaus points , voir l'algo de compression du
jpg), les dégradés se voient comme des aplats séparés nettement ou ne se voient
pas du tout. Le nombre de bits n'a rien à voir là-dedans, voir cette archive là :

.... fil déjà initié par un certain Benoît !!;-((

ou directement là :
Markorki (19/03/2019, 16h41)
Markorki a écrit :
> Benoît a écrit :
> J'ai déjà abordé ce sujet : selon le taux de compression (donné par la valeur
> minimale de différence de
> couleur entrainant l'encodage de nouveaus points , voir l'algo de compression du
> jpg), les dégradés se voient comme des aplats séparés nettement ou ne se voient
> pas du tout. Le nombre de bits n'a rien à voir là-dedans, voir cette archive là :
>
> ... fil déjà initié par un certain Benoît !!;-((
> ou directement là :
>


J'ajoute que je trouve ton article sur le color-banding absolument fumeux, voire
à côté de la plaque.
Tu peux échapper à ce pb en n'utilisant que du format tiff non comprimé, ou du
jpg "sans perte", qui représente un volume de fichier comparable au tiff.
Le jpg comprime **à_perte**. Pour éviter la création d'aplats : ajout de bruit
**ou(non exclusif)** compression très faible.
jdd (19/03/2019, 16h48)
Le 19/03/2019 à 15:05, Benoît a écrit :

> J'ai trouvé un site qui explique pas mal de choses.
> <https://photographylife.com/what-is-color-banding-and-how-to-fix-it>


et qui met une page pour dire ce qui peut être dit en quelques mots: le
"banding" est dû au fait que la transition se fait selon une ligne.
Ajouter un peu de flou permet de répartir la transition sur une zone ou
elle sera encore moins perceptible
> Et un qui explique mieux (j'y arrive pas, il faut que je demande à un
> copain matheux) la différence entre le 16 bit integer et le 16 bit
> floating point. J'ai une petite idée, mais je n'ose pas la divulguer ;)

simple "integer" c'est une valeur entière, pas de virgule et calculs
exacts, mais entre entiers. floating point: virgule flottante, calculs
faciles en mathématiques, mais erreur d'arrondi inévitable et difficile
à gèrer. Quand on a le choix, le calcul en entiers est bien préférable,
on ne fait d'arrondi que là ou on en a vraiment besoin

jdd

Discussions similaires