Le dimanche 17 mars 2019 11:15:41 UTC-4, efji a écrit :On 17/03/2019 15:49, Benoît wrote:
> efji wrote:
>
>> On 17/03/2019 02:46, Benoît wrote:
>>>
>>> PS et TIFF enregistrent en 16 bit donc 4 bits inutilisés. Quand
>>> j'enregistre une image 12 bits, je vais occupper 2 octects, donc 16
>>> bits. À partir de là il y a deux possibilités : soit je préviens que
>>> l'image est en 12 bits et les quatre premiers bits du premier octet
>>> sont à ignorer, soit je recalcule mon chiffre 12 bits en 16 bits.
>>
>> On a déjà discuté de ça très longuement et tu n'as toujours pas
>> compris. Tu semble croire que plus on a de bits plus on est fort, et
>> qu'on s'en rajoute ou enlève comme ça. Il n'y a pas de tiff 12 bits
>> mais seulement 8 ou 16. Sur un écran 10 bits ton tiff 16 bits sera
>> probablement un peu mieux défini au niveau des dégradés car au lieu
>> d'afficher 123 puis 124 il pourra afficher 123.25, 123.5 et 123.75
>> entre les deux, à condition que l'image de départ contienne
>> l'information, ce qui est loin d'être évident.
>
> 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.
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 si
l'on veut se plaindre du "banding" à l'impression, n'est-ce pas?
Le dimanche 17 mars 2019 11:15:41 UTC-4, efji a écrit :
> On 17/03/2019 15:49, Benoît wrote:
> > efji <efji@efi.efji> wrote:
> >
> >> On 17/03/2019 02:46, Benoît wrote:
> >>>
> >>> PS et TIFF enregistrent en 16 bit donc 4 bits inutilisés. Quand
> >>> j'enregistre une image 12 bits, je vais occupper 2 octects, donc 16
> >>> bits. À partir de là il y a deux possibilités : soit je préviens que
> >>> l'image est en 12 bits et les quatre premiers bits du premier octet
> >>> sont à ignorer, soit je recalcule mon chiffre 12 bits en 16 bits.
> >>
> >> On a déjà discuté de ça très longuement et tu n'as toujours pas
> >> compris. Tu semble croire que plus on a de bits plus on est fort, et
> >> qu'on s'en rajoute ou enlève comme ça. Il n'y a pas de tiff 12 bits
> >> mais seulement 8 ou 16. Sur un écran 10 bits ton tiff 16 bits sera
> >> probablement un peu mieux défini au niveau des dégradés car au lieu
> >> d'afficher 123 puis 124 il pourra afficher 123.25, 123.5 et 123.75
> >> entre les deux, à condition que l'image de départ contienne
> >> l'information, ce qui est loin d'être évident.
> >
> > 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.
>
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 si
l'on veut se plaindre du "banding" à l'impression, n'est-ce pas?
Le dimanche 17 mars 2019 11:15:41 UTC-4, efji a écrit :On 17/03/2019 15:49, Benoît wrote:
> efji wrote:
>
>> On 17/03/2019 02:46, Benoît wrote:
>>>
>>> PS et TIFF enregistrent en 16 bit donc 4 bits inutilisés. Quand
>>> j'enregistre une image 12 bits, je vais occupper 2 octects, donc 16
>>> bits. À partir de là il y a deux possibilités : soit je préviens que
>>> l'image est en 12 bits et les quatre premiers bits du premier octet
>>> sont à ignorer, soit je recalcule mon chiffre 12 bits en 16 bits.
>>
>> On a déjà discuté de ça très longuement et tu n'as toujours pas
>> compris. Tu semble croire que plus on a de bits plus on est fort, et
>> qu'on s'en rajoute ou enlève comme ça. Il n'y a pas de tiff 12 bits
>> mais seulement 8 ou 16. Sur un écran 10 bits ton tiff 16 bits sera
>> probablement un peu mieux défini au niveau des dégradés car au lieu
>> d'afficher 123 puis 124 il pourra afficher 123.25, 123.5 et 123.75
>> entre les deux, à condition que l'image de départ contienne
>> l'information, ce qui est loin d'être évident.
>
> 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.
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 si
l'on veut se plaindre du "banding" à l'impression, n'est-ce pas?
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.
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.
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.
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é.
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.
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é.
> 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.
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é.
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.
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é.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.
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é.
> 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.
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é.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.
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.
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.
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.
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à :
https://www.generation-nt.com/reponses/pb-degrade-escalier-entraide-4284712.html
... fil déjà initié par un certain Benoît !!;-((
ou directement là :
https://www.flickr.com/photos/orchimous/albums/72157681185085536
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à :
https://www.generation-nt.com/reponses/pb-degrade-escalier-entraide-4284712.html
... fil déjà initié par un certain Benoît !!;-((
ou directement là :
https://www.flickr.com/photos/orchimous/albums/72157681185085536
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à :
https://www.generation-nt.com/reponses/pb-degrade-escalier-entraide-4284712.html
... fil déjà initié par un certain Benoît !!;-((
ou directement là :
https://www.flickr.com/photos/orchimous/albums/72157681185085536
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 ;)
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 ;)
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 ;)
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 :
**ou(non exclusif)** compression très faible.
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 :
**ou(non exclusif)** compression très faible.
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 :
**ou(non exclusif)** compression très faible.
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 à unsimple "integer" c'est une valeur entière, pas de virgule et calculs
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 ;)
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
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
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 à unsimple "integer" c'est une valeur entière, pas de virgule et calculs
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 ;)
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
Le 19/03/2019 à 15:41, Markorki a écrit :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.
je ne crois pas, ce n'est pas une question de perteLe jpg comprime **à_perte**. Pour éviter la création d'aplats :
ajout de bruit
oui**ou(non exclusif)** compression très faible.non.
l'a-plat vient d'une transition le long d'une ligne régulière, le flou
(local, au besoin) va disperser la transition (étaler les points sombres
et les points clairs)
Le 19/03/2019 à 15:41, Markorki a écrit :
> 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.
je ne crois pas, ce n'est pas une question de perte
> Le jpg comprime **à_perte**. Pour éviter la création d'aplats :
ajout de bruit
oui
> **ou(non exclusif)** compression très faible.
>
non.
l'a-plat vient d'une transition le long d'une ligne régulière, le flou
(local, au besoin) va disperser la transition (étaler les points sombres
et les points clairs)
Le 19/03/2019 à 15:41, Markorki a écrit :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.
je ne crois pas, ce n'est pas une question de perteLe jpg comprime **à_perte**. Pour éviter la création d'aplats :
ajout de bruit
oui**ou(non exclusif)** compression très faible.non.
l'a-plat vient d'une transition le long d'une ligne régulière, le flou
(local, au besoin) va disperser la transition (étaler les points sombres
et les points clairs)