Je pose la question pour obtenir des mauvaises critiques.

Didier

19/03/2019 à 17:52

Le 18/03/2019 à 19:31, Benoît a écrit :

Didier wrote:
Le 17/03/2019 à 16:15, 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.

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. ;)

Ca prouve bien que tu ne lis pas vraiment : je ne parle pas d'une
échelle de 0 à 65535, mais de 65535 valeurs; bon, rajoute le 0 (noir
complet, est-ce une couleur ?), et tu as ta puissance de 2.

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 ».

Dans cet exercice, de numérisation d'une information, l'opération de
codage se situe juste après l'échantillonnage (prise d'échantillons du
signal ou de l'information, voir Shannon), et consiste à attribuer un
code binaire à la valeur de l'échantillon, c'est bien une opération de
codage.
Rien à voir avec le "code" informatique, appellation qui a dérivé de la
programmation en langage machine ou en assembleur, et désigne maintenant
des langages quasi naturels.
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
bitsOui, au moment de l'enregistrement, mais on a une perte d'information

drastique, je doute qu'elle puisse être acceptable au niveau du résultat
final; si le programme a travaillé en 16 bits, c'est que le codage
initial a été fait en 16 bits. On peut comparer à une image en 65535
couleurs, qu'on enregistre en 255 couleurs !
Didier.

Le 18/03/2019 à 19:31, Benoît a écrit :

Didier <dbnospam@invalif.fr> wrote:

Le 17/03/2019 à 16:15, 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.

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. ;)

Ca prouve bien que tu ne lis pas vraiment : je ne parle pas d'une
échelle de 0 à 65535, mais de 65535 valeurs; bon, rajoute le 0 (noir
complet, est-ce une couleur ?), et tu as ta puissance de 2.

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 ».

Dans cet exercice, de numérisation d'une information, l'opération de
codage se situe juste après l'échantillonnage (prise d'échantillons du
signal ou de l'information, voir Shannon), et consiste à attribuer un
code binaire à la valeur de l'échantillon, c'est bien une opération de
codage.
Rien à voir avec le "code" informatique, appellation qui a dérivé de la
programmation en langage machine ou en assembleur, et désigne maintenant
des langages quasi naturels.
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
bitsOui, au moment de l'enregistrement, mais on a une perte d'information

drastique, je doute qu'elle puisse être acceptable au niveau du résultat
final; si le programme a travaillé en 16 bits, c'est que le codage
initial a été fait en 16 bits. On peut comparer à une image en 65535
couleurs, qu'on enregistre en 255 couleurs !

Didier.

Vous avez filtré cet utilisateur ! Consultez son message

Le 18/03/2019 à 19:31, Benoît a écrit :

Didier wrote:
Le 17/03/2019 à 16:15, 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.

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. ;)

Ca prouve bien que tu ne lis pas vraiment : je ne parle pas d'une
échelle de 0 à 65535, mais de 65535 valeurs; bon, rajoute le 0 (noir
complet, est-ce une couleur ?), et tu as ta puissance de 2.

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 ».

Dans cet exercice, de numérisation d'une information, l'opération de
codage se situe juste après l'échantillonnage (prise d'échantillons du
signal ou de l'information, voir Shannon), et consiste à attribuer un
code binaire à la valeur de l'échantillon, c'est bien une opération de
codage.
Rien à voir avec le "code" informatique, appellation qui a dérivé de la
programmation en langage machine ou en assembleur, et désigne maintenant
des langages quasi naturels.
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
bitsOui, au moment de l'enregistrement, mais on a une perte d'information

drastique, je doute qu'elle puisse être acceptable au niveau du résultat
final; si le programme a travaillé en 16 bits, c'est que le codage
initial a été fait en 16 bits. On peut comparer à une image en 65535
couleurs, qu'on enregistre en 255 couleurs !
Didier.

Didier

19/03/2019 à 17:53

Le 18/03/2019 à 18:33, efji a écrit :

On 18/03/2019 18:29, Didier wrote:
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.

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.

Oui, je crois finalement que tu as raison, je renonce pour ma part.
Didier.

Didier

19/03/2019 à 17:56

Le 19/03/2019 à 16:27, Benoît a écrit :

jdd wrote:
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

Il ne dit pas que ça, il parle des entiers et des virgules flottantes.
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

Un truc : en valeur entière il n'y a pas d'arrondi ! Tout ce qui est
après la virgule est oublié, disparaît et à chaque étape de calcul. Avec
des entiers on a :
9/1 = 9
9/2 = 4
9/3 = 3
9/4 = 2
9/5 = 1
9/6 = 1
...
9/10 = 0
...
Donc plus je touche à mon image plus ça dérape et l'ordre dans lequel je
fais les manips est important. Un exemple :
(9 / 5) x 100 = 1 x 100 = 100
mais
100 x 9 / 5 = 900 / 5 = 180
La multiplication et la division ne sont plus commutative. Plus du tout.

Ce n'est pas ça la commutativité.
Didier

benoit

19/03/2019 à 18:18

Didier wrote:

Le 19/03/2019 à 16:27, Benoît a écrit :
jdd wrote:
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

Il ne dit pas que ça, il parle des entiers et des virgules flottantes.
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

Un truc : en valeur entière il n'y a pas d'arrondi ! Tout ce qui est
après la virgule est oublié, disparaît et à chaque étape de calcul. Avec
des entiers on a :
9/1 = 9
9/2 = 4
9/3 = 3
9/4 = 2
9/5 = 1
9/6 = 1
...
9/10 = 0
...
Donc plus je touche à mon image plus ça dérape et l'ordre dans lequel je
fais les manips est important. Un exemple :
(9 / 5) x 100 = 1 x 100 = 100
mais
100 x 9 / 5 = 900 / 5 = 180
La multiplication et la division ne sont plus commutative. Plus du tout.
Ce n'est pas ça la commutativité.

Pardon, la division n'est pas communtative du tout (honte à moi).
Extrait de Wikipedia :
La multiplication de 3 par 2 donne le même résultat que la
multiplication de 2 par 3. En mathématiques, et plus précisément en
algèbre générale, une loi de composition interne sur un ensemble S est
dite commutative lorsque, pour tous x et y dans S, X*Y=Y*X.
Avec * pouvant être l'addition, la multiplication et plein d'autres
chose mais jamais la soustraction, la division...
Si tu conserves les chiffres après la virgule voilà ce qu'on a (en
effectuant le calcul de gauche à doite :
9 / 5 x 100 = 100 x 9 / 5 = 1,8 x 100 = 180
9/5 = 1,8 et pas = 1 qui est pourtant le résultat d'un calcul avec
« arrondi » toujours sur l'unité inférieure.
Je rappelle qu'il n'y a pas d'arrondi, on abandonne tout ce qui est
après la virgule : 100/15 = 6 et pas 6,66666 arrondi à 7.
--
Vie : n.f. maladie mortelle sexuellement transmissible
Benoit chez lui à leraillez.com

Didier <dbnospam@invalif.fr> wrote:

Le 19/03/2019 à 16:27, Benoît a écrit :
> jdd <jdd@dodin.org> wrote:
>
>> 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
>
> Il ne dit pas que ça, il parle des entiers et des virgules flottantes.
>
>>> 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
>
> Un truc : en valeur entière il n'y a pas d'arrondi ! Tout ce qui est
> après la virgule est oublié, disparaît et à chaque étape de calcul. Avec
> des entiers on a :
> 9/1 = 9
> 9/2 = 4
> 9/3 = 3
> 9/4 = 2
> 9/5 = 1
> 9/6 = 1
> ...
> 9/10 = 0
> ...
>
> Donc plus je touche à mon image plus ça dérape et l'ordre dans lequel je
> fais les manips est important. Un exemple :
> (9 / 5) x 100 = 1 x 100 = 100
> mais
> 100 x 9 / 5 = 900 / 5 = 180
> La multiplication et la division ne sont plus commutative. Plus du tout.
Ce n'est pas ça la commutativité.

Pardon, la division n'est pas communtative du tout (honte à moi).

Extrait de Wikipedia :

La multiplication de 3 par 2 donne le même résultat que la
multiplication de 2 par 3. En mathématiques, et plus précisément en
algèbre générale, une loi de composition interne sur un ensemble S est
dite commutative lorsque, pour tous x et y dans S, X*Y=Y*X.
Avec * pouvant être l'addition, la multiplication et plein d'autres
chose mais jamais la soustraction, la division...

Si tu conserves les chiffres après la virgule voilà ce qu'on a (en
effectuant le calcul de gauche à doite :

9 / 5 x 100 = 100 x 9 / 5 = 1,8 x 100 = 180

9/5 = 1,8 et pas = 1 qui est pourtant le résultat d'un calcul avec
« arrondi » toujours sur l'unité inférieure.

Je rappelle qu'il n'y a pas d'arrondi, on abandonne tout ce qui est
après la virgule : 100/15 = 6 et pas 6,66666 arrondi à 7.

--
Vie : n.f. maladie mortelle sexuellement transmissible
Benoit chez lui à leraillez.com

Vous avez filtré cet utilisateur ! Consultez son message

Didier wrote:

Le 19/03/2019 à 16:27, Benoît a écrit :
jdd wrote:
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

Il ne dit pas que ça, il parle des entiers et des virgules flottantes.
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

Un truc : en valeur entière il n'y a pas d'arrondi ! Tout ce qui est
après la virgule est oublié, disparaît et à chaque étape de calcul. Avec
des entiers on a :
9/1 = 9
9/2 = 4
9/3 = 3
9/4 = 2
9/5 = 1
9/6 = 1
...
9/10 = 0
...
Donc plus je touche à mon image plus ça dérape et l'ordre dans lequel je
fais les manips est important. Un exemple :
(9 / 5) x 100 = 1 x 100 = 100
mais
100 x 9 / 5 = 900 / 5 = 180
La multiplication et la division ne sont plus commutative. Plus du tout.
Ce n'est pas ça la commutativité.

Pardon, la division n'est pas communtative du tout (honte à moi).
Extrait de Wikipedia :
La multiplication de 3 par 2 donne le même résultat que la
multiplication de 2 par 3. En mathématiques, et plus précisément en
algèbre générale, une loi de composition interne sur un ensemble S est
dite commutative lorsque, pour tous x et y dans S, X*Y=Y*X.
Avec * pouvant être l'addition, la multiplication et plein d'autres
chose mais jamais la soustraction, la division...
Si tu conserves les chiffres après la virgule voilà ce qu'on a (en
effectuant le calcul de gauche à doite :
9 / 5 x 100 = 100 x 9 / 5 = 1,8 x 100 = 180
9/5 = 1,8 et pas = 1 qui est pourtant le résultat d'un calcul avec
« arrondi » toujours sur l'unité inférieure.
Je rappelle qu'il n'y a pas d'arrondi, on abandonne tout ce qui est
après la virgule : 100/15 = 6 et pas 6,66666 arrondi à 7.
--
Vie : n.f. maladie mortelle sexuellement transmissible
Benoit chez lui à leraillez.com

efji

19/03/2019 à 18:25

On 19/03/2019 18:18, Benoît wrote:

Didier wrote:
(9 / 5) x 100 = 1 x 100 = 100
mais
100 x 9 / 5 = 900 / 5 = 180
La multiplication et la division ne sont plus commutative. Plus du tout.

Ce n'est pas ça la commutativité.

Pardon, la division n'est pas communtative du tout (honte à moi).
Extrait de Wikipedia :

Une suggestion : si tu réfléchissais 2 secondes avant d'écrire à tors et
à travers.
Ce que tu évoques ci-dessus s'appelle l'associativité.
Les opération arithmétiques de base ne sont pas associatives dans un
ordinateur en effet en arithmétique flottante, à cause des arrondis.
En arithmétique entière elles le sont, sauf pour la division car la
division entière n'est pas l'opération inverse de la multiplication.
C'est ce que tu décris ci-dessus.
--
F.J.

jdd

19/03/2019 à 18:58

Le 19/03/2019 à 16:27, Benoît a écrit :

Un truc : en valeur entière il n'y a pas d'arrondi !

oui, mais il est facile de doubler la taille du calcul, le faire sur 16
bits au lieu de 8. Le calcul en virgule flottante utilise beaucoup de
mémoire. On peut aussi faire des shift (déplacement), à gauche ou à droite

La multiplication et la division ne sont plus commutative.

elles ne le sont jamais...

Hors, le floating point te permet d'avoir une meilleure précision dans
tes calculs, mais avec des images 14 bits (12, 10?) et pas 16.

non.
j'ai eu longtemps un tableur tout programmé en entiers, il avait la même
précision.
tu peux même faire un calcul en précision illimitée, autant de décimales
exactes que tu veux...
ca n'a rien à voir avec les données de départ
jdd
--
http://dodin.org

Pierre Maurette

19/03/2019 à 19:48

jdd :
[...]

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.

Non, dans les deux cas l'erreur finale ne dépend que du nombre de bits.
En fait en virgule flottante l'erreur maxi est plus importante pour les
grandes valeurs que pour les petites, ce qui est préférable (pour les
capteurs de lumière) à une erreur maxi constante. Voir ci-dessous.

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

Un capteur en virgule flottante (donc linéaire par niveaux
logarithmiques) serait plus adapté à la photographie. Avec 13 de
mantisse et 3 d'exposant, on aurait 8 zones (au sens du zone system)
traitées à égalité, alors qu'un capteur linéaire fournirait (fournit)
trop peu d'échantillons en zone 0 (noirs) et inutilement trop en zone 7
(hautes lumières).
--
Pierre Maurette

benoit

19/03/2019 à 20:09

efji wrote:

On 19/03/2019 18:18, Benoît wrote:
Didier wrote:
(9 / 5) x 100 = 1 x 100 = 100
mais
100 x 9 / 5 = 900 / 5 = 180
La multiplication et la division ne sont plus commutative. Plus du tout.
Ce n'est pas ça la commutativité.

Pardon, la division n'est pas communtative du tout (honte à moi).
Extrait de Wikipedia :

Une suggestion : si tu réfléchissais 2 secondes avant d'écrire à tors et
à travers.
Ce que tu évoques ci-dessus s'appelle l'associativité.

1 Commutativité : ab = ba
2 Associativité : a(bc) = (ab)c
3 Distributivité : a(b + c) = ab + ac
Comme nous avons une division au lieu d'une addition ce sertait la
distributivité qui entrerait en jeu : a(b/c) = ab / ac
Or ! (et argent, je te laisse le bronze :)
Un ordinateur fait les calculs dans l'ordre qu'on lui donne et si on
n'ajoute pas de parenthèses pour lui dire qu'il y a des calculs
inermédiaires il avance tout seul :
100 x 5 + 2 = 502 mais 100 x (5 + 2) = 100
Comme tu exécutes tes retouches l'une après l'autre c'est exactement
comme s'il n'y avait pas de parenthèses. Puisque tu oublies les chiffres
après la virgule. Prenons 100 niveaux de noir(100) et blanc(0).
Si je travaille mon image et je demande 1,5 diaph de moins (divisé par
3) et que je demande 1,5 diaph de plus voici ce que ça donne avec des
nombres entiers :
1,5 diaph de moins 100 / 3 = 33
Maintenant je rajoute 1,5 diaph : 33 x 3 = 99
Si je fais la même manip avec 2,5 diaph (6 fois moins de lumière si ej
ne me trompe pas) j'ai dans un cas 100 et dans l'autre 96 !

Les opération arithmétiques de base ne sont pas associatives dans un
ordinateur en effet en arithmétique flottante, à cause des arrondis.

Faux ! Voir la définition de l'associativité : tu fais ça avec des
additions et des multiplications mais ni divisions, soustractions (comme
la commutativité).

En arithmétique entière elles le sont, sauf pour la division car la
division entière n'est pas l'opération inverse de la multiplication.
C'est ce que tu décris ci-dessus.

Ce que je décris est l'odre dans lequel on fait les modifications et à
quel moment les arrondis inférieurs interviennent. Plus tôt tu fais des
arrondis inférieurs dans ton calcul, plus grand seront tes écarts à la
fin entre un calcul entier dans un sens, dans l'autre, ou à virgule
flottante.
--
Vie : n.f. maladie mortelle sexuellement transmissible
Benoit chez lui à leraillez.com

efji <efji@efi.efji> wrote:

On 19/03/2019 18:18, Benoît wrote:
> Didier <dbnospam@invalif.fr> wrote:
>
>>> (9 / 5) x 100 = 1 x 100 = 100
>>> mais
>>> 100 x 9 / 5 = 900 / 5 = 180
>>> La multiplication et la division ne sont plus commutative. Plus du tout.
>> Ce n'est pas ça la commutativité.
>
> Pardon, la division n'est pas communtative du tout (honte à moi).
>
> Extrait de Wikipedia :

Une suggestion : si tu réfléchissais 2 secondes avant d'écrire à tors et
à travers.

Ce que tu évoques ci-dessus s'appelle l'associativité.

1 Commutativité : ab = ba
2 Associativité : a(bc) = (ab)c
3 Distributivité : a(b + c) = ab + ac

Comme nous avons une division au lieu d'une addition ce sertait la
distributivité qui entrerait en jeu : a(b/c) = ab / ac

Or ! (et argent, je te laisse le bronze :)

Un ordinateur fait les calculs dans l'ordre qu'on lui donne et si on
n'ajoute pas de parenthèses pour lui dire qu'il y a des calculs
inermédiaires il avance tout seul :

100 x 5 + 2 = 502 mais 100 x (5 + 2) = 100

Comme tu exécutes tes retouches l'une après l'autre c'est exactement
comme s'il n'y avait pas de parenthèses. Puisque tu oublies les chiffres
après la virgule. Prenons 100 niveaux de noir(100) et blanc(0).

Si je travaille mon image et je demande 1,5 diaph de moins (divisé par
3) et que je demande 1,5 diaph de plus voici ce que ça donne avec des
nombres entiers :

1,5 diaph de moins 100 / 3 = 33

Maintenant je rajoute 1,5 diaph : 33 x 3 = 99

Si je fais la même manip avec 2,5 diaph (6 fois moins de lumière si ej
ne me trompe pas) j'ai dans un cas 100 et dans l'autre 96 !

Les opération arithmétiques de base ne sont pas associatives dans un
ordinateur en effet en arithmétique flottante, à cause des arrondis.

Faux ! Voir la définition de l'associativité : tu fais ça avec des
additions et des multiplications mais ni divisions, soustractions (comme
la commutativité).

En arithmétique entière elles le sont, sauf pour la division car la
division entière n'est pas l'opération inverse de la multiplication.
C'est ce que tu décris ci-dessus.

Ce que je décris est l'odre dans lequel on fait les modifications et à
quel moment les arrondis inférieurs interviennent. Plus tôt tu fais des
arrondis inférieurs dans ton calcul, plus grand seront tes écarts à la
fin entre un calcul entier dans un sens, dans l'autre, ou à virgule
flottante.

--
Vie : n.f. maladie mortelle sexuellement transmissible
Benoit chez lui à leraillez.com

Vous avez filtré cet utilisateur ! Consultez son message

efji wrote:

On 19/03/2019 18:18, Benoît wrote:
Didier wrote:
(9 / 5) x 100 = 1 x 100 = 100
mais
100 x 9 / 5 = 900 / 5 = 180
La multiplication et la division ne sont plus commutative. Plus du tout.
Ce n'est pas ça la commutativité.

Pardon, la division n'est pas communtative du tout (honte à moi).
Extrait de Wikipedia :

Une suggestion : si tu réfléchissais 2 secondes avant d'écrire à tors et
à travers.
Ce que tu évoques ci-dessus s'appelle l'associativité.

1 Commutativité : ab = ba
2 Associativité : a(bc) = (ab)c
3 Distributivité : a(b + c) = ab + ac
Comme nous avons une division au lieu d'une addition ce sertait la
distributivité qui entrerait en jeu : a(b/c) = ab / ac
Or ! (et argent, je te laisse le bronze :)
Un ordinateur fait les calculs dans l'ordre qu'on lui donne et si on
n'ajoute pas de parenthèses pour lui dire qu'il y a des calculs
inermédiaires il avance tout seul :
100 x 5 + 2 = 502 mais 100 x (5 + 2) = 100
Comme tu exécutes tes retouches l'une après l'autre c'est exactement
comme s'il n'y avait pas de parenthèses. Puisque tu oublies les chiffres
après la virgule. Prenons 100 niveaux de noir(100) et blanc(0).
Si je travaille mon image et je demande 1,5 diaph de moins (divisé par
3) et que je demande 1,5 diaph de plus voici ce que ça donne avec des
nombres entiers :
1,5 diaph de moins 100 / 3 = 33
Maintenant je rajoute 1,5 diaph : 33 x 3 = 99
Si je fais la même manip avec 2,5 diaph (6 fois moins de lumière si ej
ne me trompe pas) j'ai dans un cas 100 et dans l'autre 96 !

Les opération arithmétiques de base ne sont pas associatives dans un
ordinateur en effet en arithmétique flottante, à cause des arrondis.

Faux ! Voir la définition de l'associativité : tu fais ça avec des
additions et des multiplications mais ni divisions, soustractions (comme
la commutativité).

En arithmétique entière elles le sont, sauf pour la division car la
division entière n'est pas l'opération inverse de la multiplication.
C'est ce que tu décris ci-dessus.

Ce que je décris est l'odre dans lequel on fait les modifications et à
quel moment les arrondis inférieurs interviennent. Plus tôt tu fais des
arrondis inférieurs dans ton calcul, plus grand seront tes écarts à la
fin entre un calcul entier dans un sens, dans l'autre, ou à virgule
flottante.
--
Vie : n.f. maladie mortelle sexuellement transmissible
Benoit chez lui à leraillez.com

benoit

19/03/2019 à 20:09

jdd wrote:

Le 19/03/2019 à 16:27, Benoît a écrit :
Un truc : en valeur entière il n'y a pas d'arrondi !

oui, mais il est facile de doubler la taille du calcul, le faire sur 16
bits au lieu de 8. Le calcul en virgule flottante utilise beaucoup de
mémoire. On peut aussi faire des shift (déplacement), à gauche ou à droite
La multiplication et la division ne sont plus commutative.

elles ne le sont jamais...

Euhhhhhhh : a x b = b x a chez moi, donc c'est commutatif. Par contre
a / b ≠ b / a

Hors, le floating point te permet d'avoir une meilleure précision dans
tes calculs, mais avec des images 14 bits (12, 10?) et pas 16.
non.
j'ai eu longtemps un tableur tout programmé en entiers, il avait la même
précision.

Là intervient l'intelligence du programmeur. Après tout, c'étaient des
octets et donc limité à 0->255 et il savait travailler avec des
milliards.

tu peux même faire un calcul en précision illimitée, autant de décimales
exactes que tu veux...

Bin non, sauf l'application d'arrondis, tu es déjà limité par le nombre
de chiffres après la virgule quand tu fais appel à π et ses amis.

ca n'a rien à voir avec les données de départ

Très juste, on ne parle plus du tout de qualité d'écran.
--
Vie : n.f. maladie mortelle sexuellement transmissible
Benoit chez lui à leraillez.com

efji

19/03/2019 à 21:07

Mon petit Benoit, s'il te plaît, arrête de t'enfoncer..;
On 19/03/2019 20:09, Benoît wrote:

distributivité qui entrerait en jeu : a(b/c) = ab / ac

et retourne au cm2...

100 x 5 + 2 = 502 mais 100 x (5 + 2) = 100

ou en ce1...

Les opérations arithmétiques de base en flottants ne sont pas associatives dans un
ordinateur en effet en arithmétique flottante, à cause des arrondis.

Faux ! Voir la définition de l'associativité : tu fais ça avec des
additions et des multiplications mais ni divisions, soustractions (comme
la commutativité).

Et s'il te plaît baisse d'un ton.
Je répète: les opérations arithmétiques de base en flottants ne sont pas
associatives :
En simple précision :
(10^{-10}+1) - 1 = 0
10^{-10} + (1-1) = 10^{-10}
--
F.J.

Je pose la question pour obtenir des mauvaises critiques.

10 réponses

Veuillez sélectionner un problème