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

jdd (19/03/2019, 16h51)
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)

jdd
Benoît (19/03/2019, 17h27)
jdd <jdd> wrote:

> Le 19/03/2019 à 15:05, Benoît a écrit :
> 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.

> 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.
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.
Benoît (19/03/2019, 17h32)
jdd <jdd> wrote:

> Le 19/03/2019 à 15:41, Markorki a écrit :
> je ne crois pas, ce n'est pas une question de perte
> ajout de bruit


Non, des aplats peuvent apparaître suite à une compression.

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


+1

Je dirai faire un mélange de sombres et de clairs avec de plus en plus
de clairs dans un sens, ou de plus en plus de sombre dans l'autre sens.
Didier (19/03/2019, 18h52)
Le 18/03/2019 à 19:31, Benoît a écrit :
> Didier <dbnospam> wrote:
> 256 : 2, 4, 8, 16, 32, 64, 128, 256, 512, 1 024, 2 048, 4 096, 8 192,
> 16 384, 32 768, 65 536.
> 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.
> Exact et merci pour les termes.
> 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, 18h53)
Le 18/03/2019 à 18:33, efji a écrit :
> On 18/03/2019 18:29, Didier wrote:
> 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, 18h56)
Le 19/03/2019 à 16:27, Benoît a écrit :
[..]
> 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
Benoît (19/03/2019, 19h18)
Didier <dbnospam> wrote:

> Le 19/03/2019 à 16:27, Benoît a écrit :
> 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.
efji (19/03/2019, 19h25)
On 19/03/2019 18:18, Benoît wrote:
> Didier <dbnospam> wrote:
> 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.
jdd (19/03/2019, 19h58)
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
Pierre Maurette (19/03/2019, 20h48)
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).
Benoît (19/03/2019, 21h09)
efji <efji> wrote:

> On 19/03/2019 18:18, Benoît wrote:
> 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.
Benoît (19/03/2019, 21h09)
jdd <jdd> wrote:

> Le 19/03/2019 à 16:27, Benoît a écrit :
> 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
> 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.
jeanpasse (19/03/2019, 21h31)
Le mardi 19 mars 2019 13:58:46 UTC-4, Jean-Daniel Dodin a écrit :
[..]
> 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


Hum! Hum!
Quel est l'intérêt de discuter de mathématiques appliquées à des fonctions
incluses dans des logiciels? Peu importe ce que je connais, ce que je crois,
ce que j'imagine! Je n'ai pas accès aux fonctions incluses dans PS ou autre.
Tout ce que je peux faire est de constater que mon image sort de mon APN
définie selon les volontés du fabricant. J'ai un fichier qui a telles et
telles caractéristiques: tant de pixels à tant de bits déjà faits sur
lesquels je peux apporter un peu de variation de lors du dit développement.

Après je dois utiliser un logiciels qui prétends faire des miracles mais je ne
sais pas si ces miracles sont calculés en entiers ou en décimalesflottantes.
Possiblement les 2 selon le besoin. Si j'applique 5 fonctions successivement
les calculs sont-il effectués et tronqués 5 fois (oui selon moi) ou sont-ils
calculés les 5 pour une seule troncation du résultat.

Je regarde mes photos sur un écran en 8 bits ou pseudo 10 bits ou très cher vrai 10 bits.

Je crois que personne ici possède un écran 10 bit selon cet article.
J'en conclu que si l'image est bonne sur l'écran elle PEUT être encore
meilleure dans son fichier en 16 bits.

Puis je désire imprimer cette image. Combien de couleurs différentes mon
imprimante peut-elle faire? Exagérons: j'imprime un maximum de cyan sur
une surface de 1 x 1 cm. Puis j'ajoute un jet de magenta, disons 3
picolitres milieu de la surface cyan. Vue globalement ma couleur est
modifié et je peux envisager de créer des millions de nuances en y mettant
2 puis 3 puis 4 jet de magenta. Mais ces jolis calculs ne servent à rien
je dois me contenter de ce que le fabricant à fait, qu'il me vante avec
passion mais qui n'est pas tout à fait aussi miraculeux.

J'achète donc un photomètre pour bien calibrer mon imprimante ce qui améliore
mes impression mais elles ne sont toujours qu'un ensemble limité de taches
d'encres sans véritable continuité. Une gouttelette de plus ou demoins?
Oh oui la forme est améliorée mais la couleur faussée! Ou l'inverse. Je ne
peux rien y changer, le constructeur a fait la programmation de conversion
de mon image de 10 megapixels en goutelettes d'encre de tant de couleurs.

Benoit se plaint de n'avoir eu que de la bouillie lors de tests avec une sorte
de damier. Normal. Un damier ce sont des aplats et une image d'aplats ne
s'imprime pas avec un logiciel destiné à la photo. Un logiciel photo fusionne
toujours un peu les transitions de couleurs. L'accentuation que l'on peut
apporter à certaines parties de l'image ne crée pas une transition brute
d'une couleur à l'autre.

En pratique la photo est un ensemble de techniques appliquées, pas unescience
exacte.

René
efji (19/03/2019, 22h07)
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}
jdd (19/03/2019, 22h41)
Le 19/03/2019 à 20:09, Benoît a écrit :
> jdd <jdd> wrote:


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


pffff...

relis ce que j'ai dit.

j'ai déjà eu en main des programmes qui calculent autant de décimales
exactes que tu veux. Si tu en veux beaucoup c'est juste long...

c'est vrai aussi pour PI, qui est même sans doute le nombre dont on
connait le plus de décimales

jdd

Discussions similaires