Je pose la question pour obtenir des mauvaises critiques.

[j***@hotmail.com]

En bref en 2015 j'ai acheté un écran LG31MU97-B 4096x2160 pixels, 1700$ payé
1400 $ chez mon fournisseur habituel.
Des l'installation un des fils a eu un problème de contacts.
Au service technique autorisé Capri ils me l'ont brisé d'avantage, l'écran
avait un demi cercle non rétroéclairé. Sous garantie, après 2 mois j'en ai
enfin obtenu un nouveau. J'étais bien heureux.

Il y a 15 jours un bris d'aqueduc sur ma rue a forcé l'arrêt et la remise du
service électrique... mon écran a eu un choc, est devenu tout noir, et n'en
est pas revenu. Hors garantie et discontinué LG me dit de retourner chez Capri.
Disons que je n'ai pas vraiment confiance... dois-je tenter (et débourser) pour
une réparation ou dois-je en acheter un autre.

Le seul écran de 4096x2160 pixels est
https://www.vistek.ca/store/425696/eizo-cg319x4kbk-311-led-monitor-4096x2160-ips-2xhdmi-2xdisplaypor
beaucoup trop cher pour mon usage.

Je dois donc rétrograder en 3840x2160 pixels avec de bonnes qualités
graphiques. J'ai les choix entre:

NEC encore trop cher: https://www.necdisplay.com/p/displays/pa322uhd-bk-2

DELL : https://www.dell.com/fr-ca/work/shop/dell-ultrasharp-up3216q-%C3%A9cran-led-32-pouce/apd/210-afln/moniteurs-et-accessoires-des-moniteurs

autre DELL : https://www.dell.com/fr-ca/work/shop/moniteur-usb-c-4k-dell-ultrasharp-32-u3219q/apd/210-aqzz/moniteurs-et-accessoires-des-moniteurs

ASUS : https://www.asus.com/ca-fr/Commercial-Monitors/PA328Q/

BENQ : https://business-display.benq.eu/fr/findproduct/monitor/graphic-art-photography/sw320.html

ou VIEWSONIC : https://color.viewsonic.com/products/VP3268-4K.php

Ma question est : à quelle(s) entreprise(s) ne dois-je pas faire confiance?
Avez-vous eu de mauvaises expériences avec l'une ou l'autre?

Merci pour vos déconseils

René

[efji]

Post by j***@hotmail.com
En bref en 2015 j'ai acheté un écran LG31MU97-B 4096x2160 pixels, 1700$ payé
1400 $ chez mon fournisseur habituel.

$ canadiens je suppose.

Post by j***@hotmail.com
Des l'installation un des fils a eu un problème de contacts.
Au service technique autorisé Capri ils me l'ont brisé d'avantage, l'écran
avait un demi cercle non rétroéclairé. Sous garantie, après 2 mois j'en ai
enfin obtenu un nouveau. J'étais bien heureux.
Il y a 15 jours un bris d'aqueduc sur ma rue a forcé l'arrêt et la remise du
service électrique... mon écran a eu un choc, est devenu tout noir, et n'en
est pas revenu. Hors garantie et discontinué LG me dit de retourner chez Capri.
Disons que je n'ai pas vraiment confiance... dois-je tenter (et débourser) pour
une réparation ou dois-je en acheter un autre.
Le seul écran de 4096x2160 pixels est
https://www.vistek.ca/store/425696/eizo-cg319x4kbk-311-led-monitor-4096x2160-ips-2xhdmi-2xdisplaypor
beaucoup trop cher pour mon usage.

Pourquoi pas 5k :
https://www.apple.com/shop/product/HKN62LL/A/lg-ultrafine-5k-display
ou 4k :
https://www.apple.com/shop/product/HKMY2VC/A/lg-ultrafine-4k-display

[j***@hotmail.com]

Post by efji

Post by j***@hotmail.com
En bref en 2015 j'ai acheté un écran LG31MU97-B 4096x2160 pixels, 1700$ payé
1400 $ chez mon fournisseur habituel.

$ canadiens je suppose.

Post by j***@hotmail.com
Des l'installation un des fils a eu un problème de contacts.
Au service technique autorisé Capri ils me l'ont brisé d'avantage, l'écran
avait un demi cercle non rétroéclairé. Sous garantie, après 2 mois j'en ai
enfin obtenu un nouveau. J'étais bien heureux.
Il y a 15 jours un bris d'aqueduc sur ma rue a forcé l'arrêt et la remise du
service électrique... mon écran a eu un choc, est devenu tout noir, et n'en
est pas revenu. Hors garantie et discontinué LG me dit de retourner chez Capri.
Disons que je n'ai pas vraiment confiance... dois-je tenter (et débourser) pour
une réparation ou dois-je en acheter un autre.
Le seul écran de 4096x2160 pixels est
https://www.vistek.ca/store/425696/eizo-cg319x4kbk-311-led-monitor-4096x2160-ips-2xhdmi-2xdisplaypor
beaucoup trop cher pour mon usage.

https://www.apple.com/shop/product/HKN62LL/A/lg-ultrafine-5k-display
https://www.apple.com/shop/product/HKMY2VC/A/lg-ultrafine-4k-display

Je sais que c'est bon. Le prix est presque bien mais le $ canadien est bas... 27 pouces c'est petit, j'avais 31.
Je ne voudrais pas changer ma carte graphique... ni avoir un écran au fini
brillant.
Ma conjointe a un ASUS 4K, 28 po, fini mat, tactile c'est bien, mais pas un
modèle satisfaisant pour le photo.

J'ai déjà eu du Viewsonic CRT qui est resté impeccable. Apprendre que leurs
nouveaux écrans plats soient aussi bons, je n'hésiterais pas.

En fait ils semblent tous pareils à l'électronique près je suppose.
Est-ce que LG est le seul à éviter (pour moi) %-(

René

[efji]

Post by j***@hotmail.com

Post by efji

Post by j***@hotmail.com
En bref en 2015 j'ai acheté un écran LG31MU97-B 4096x2160 pixels, 1700$ payé
1400 $ chez mon fournisseur habituel.

$ canadiens je suppose.

Post by j***@hotmail.com
Des l'installation un des fils a eu un problème de contacts.
Au service technique autorisé Capri ils me l'ont brisé d'avantage, l'écran
avait un demi cercle non rétroéclairé. Sous garantie, après 2 mois j'en ai
enfin obtenu un nouveau. J'étais bien heureux.
Il y a 15 jours un bris d'aqueduc sur ma rue a forcé l'arrêt et la remise du
service électrique... mon écran a eu un choc, est devenu tout noir, et n'en
est pas revenu. Hors garantie et discontinué LG me dit de retourner chez Capri.
Disons que je n'ai pas vraiment confiance... dois-je tenter (et débourser) pour
une réparation ou dois-je en acheter un autre.
Le seul écran de 4096x2160 pixels est
https://www.vistek.ca/store/425696/eizo-cg319x4kbk-311-led-monitor-4096x2160-ips-2xhdmi-2xdisplaypor
beaucoup trop cher pour mon usage.

https://www.apple.com/shop/product/HKN62LL/A/lg-ultrafine-5k-display
https://www.apple.com/shop/product/HKMY2VC/A/lg-ultrafine-4k-display

Je sais que c'est bon. Le prix est presque bien mais le $ canadien est bas... 27 pouces c'est petit, j'avais 31.
Je ne voudrais pas changer ma carte graphique... ni avoir un écran au fini
brillant.
Ma conjointe a un ASUS 4K, 28 po, fini mat, tactile c'est bien, mais pas un
modèle satisfaisant pour le photo.
J'ai déjà eu du Viewsonic CRT qui est resté impeccable. Apprendre que leurs
nouveaux écrans plats soient aussi bons, je n'hésiterais pas.
En fait ils semblent tous pareils à l'électronique près je suppose.
Est-ce que LG est le seul à éviter (pour moi) %-(

Je ne comprends pas cette dernière phrase.

J'avoue ne rien y connaitre en écrans haut de gamme, mais ce que je sais
c'est que 95% des graphistes et photographes sont sous mac et que leurs
écrans à la fois fixes et portables dépassent de 3 têtes tout ce que
j'ai pu avoir auparavant (mais encore une fois je n'ai jamais eu d'écran
comme ceux que tu proposes). Ces LG sont ceux proposés en "accessoire"
pour les nouveaux mac mini (qui ne sont pas du tout "mini", ni en perf
ni en prix, mais plutôt des mac-pro sans écran ni clavier), donc je
suppose qu'il sont au moins du niveau des autres écrans mac.

[j***@hotmail.com]

Post by efji

Post by j***@hotmail.com

Post by efji

Post by j***@hotmail.com
En bref en 2015 j'ai acheté un écran LG31MU97-B 4096x2160 pixels, 1700$ payé
1400 $ chez mon fournisseur habituel.

$ canadiens je suppose.

Post by j***@hotmail.com
Des l'installation un des fils a eu un problème de contacts.
Au service technique autorisé Capri ils me l'ont brisé d'avantage, l'écran
avait un demi cercle non rétroéclairé. Sous garantie, après 2 mois j'en ai
enfin obtenu un nouveau. J'étais bien heureux.
Il y a 15 jours un bris d'aqueduc sur ma rue a forcé l'arrêt et la remise du
service électrique... mon écran a eu un choc, est devenu tout noir, et n'en
est pas revenu. Hors garantie et discontinué LG me dit de retourner chez Capri.
Disons que je n'ai pas vraiment confiance... dois-je tenter (et débourser) pour
une réparation ou dois-je en acheter un autre.
Le seul écran de 4096x2160 pixels est
https://www.vistek.ca/store/425696/eizo-cg319x4kbk-311-led-monitor-4096x2160-ips-2xhdmi-2xdisplaypor
beaucoup trop cher pour mon usage.

https://www.apple.com/shop/product/HKN62LL/A/lg-ultrafine-5k-display
https://www.apple.com/shop/product/HKMY2VC/A/lg-ultrafine-4k-display

Je sais que c'est bon. Le prix est presque bien mais le $ canadien est bas... 27 pouces c'est petit, j'avais 31.
Je ne voudrais pas changer ma carte graphique... ni avoir un écran au fini
brillant.
Ma conjointe a un ASUS 4K, 28 po, fini mat, tactile c'est bien, mais pas un
modèle satisfaisant pour le photo.
J'ai déjà eu du Viewsonic CRT qui est resté impeccable. Apprendre que leurs
nouveaux écrans plats soient aussi bons, je n'hésiterais pas.
En fait ils semblent tous pareils à l'électronique près je suppose.
Est-ce que LG est le seul à éviter (pour moi) %-(

Je ne comprends pas cette dernière phrase.
J'avoue ne rien y connaitre en écrans haut de gamme, mais ce que je sais
c'est que 95% des graphistes et photographes sont sous mac et que leurs
écrans à la fois fixes et portables dépassent de 3 têtes tout ce que
j'ai pu avoir auparavant (mais encore une fois je n'ai jamais eu d'écran
comme ceux que tu proposes). Ces LG sont ceux proposés en "accessoire"
pour les nouveaux mac mini (qui ne sont pas du tout "mini", ni en perf
ni en prix, mais plutôt des mac-pro sans écran ni clavier), donc je
suppose qu'il sont au moins du niveau des autres écrans mac.

Je ne suis pas un pro à temps plein. Ma conjointe et moi avons toujours été
bohèmes-autodidactes malgré d'assez bonnes études. Nous avons fait beaucoup
de choses non simplement parce qu'elles se présentaient et qu'elles apportaient
de quoi manger mais parce que c'étais sans patron. Jamais riches ou toujours pauvres je n'ai pas été Apple mais Commodore.
Pour les écrans il faut éviter ceux qui sont proposés "gamer". Les caractéristiques en sont vitesse d'affichage et luminosité/contraste excessifs,
loin de photo/colorimétrie.

Mon LG était très facile à calibrer, grand champ de vision, mais j'ai sentis quelques petites défaillances qui sont disparues après avoir éteint/rallumé.
Je penche pour une électronique de piètre qualité installée sur la même dalle
que le Eizo puisque ce sont les 2 seules marques à offrir 4096x2160 pixels.
Pour l'instant je penche vers Viewsonic... jusqu'à ce qu'un me dise : NON NON!

Apple/Mac avec Adobe a eu une très vigoureuse approche des entreprises de
graphisme/publicité/impression. En utilisant Corel je pouvais ouvrir
n'importe quel fichier. Sous Apple/Adobe les gens du métier ne lisaient
que du Apple/Adobe, d'ou le monopole devenu standard. Corel a fini par
ajouter les sorties en PSD et PDF imprimeur. Il n'y a plus de discussion violentes.
A l'origine Corel était meilleur que Adobe mais la publicité de Corel dirigée
vers les entreprises sans goût esthétique (enseigne logo machine à découpe)
alors que Apple/Adobe ont toujours soigné l'image en s'adressant aux agences
à gros budget.
J'ai fait plusieurs travaux qui allaient chez un des plus
importants imprimeurs au Canada avec des impression vraiment identiques à mon
cher CRT Viewsonic. Une fois avec le LG. Maintenant je ne fais plus ce genre de travail. C'est la preuve que Viewsonic/Intercontinental c'est vraiment bien.
Pour la qualité de mon travail ce n'est pas une preuve, je sais.

René

[jdd]

Le 16/03/2019 à 04:30, ***@hotmail.com a écrit :

cher CRT Viewsonic. Une fois avec le LG. Maintenant je ne fais plus ce
genre de travail. C'est la preuve que Viewsonic/Intercontinental c'est
vraiment bien.

j'ai été impressionné par la qualité colorimétrique des dalles
actuelles, depuis déjà quelques années, je ne calibre plus mes écrans
depuis longtemps (mais l'éclairage de mon poste de travail est contrôlé)

jdd

[Benoît]

Post by j***@hotmail.com
cher CRT Viewsonic. Une fois avec le LG. Maintenant je ne fais plus ce
genre de travail. C'est la preuve que Viewsonic/Intercontinental c'est
vraiment bien.
j'ai été impressionné par la qualité colorimétrique des dalles
actuelles, depuis déjà quelques années, je ne calibre plus mes écrans
depuis longtemps (mais l'éclairage de mon poste de travail est contrôlé)

J'utilise un MacBook Pro Retina fin 2013 : 10bits/couleur. Soit 4 fois
plus que les écrans « standards » sur 8 bits.

Avec ColorMunki Display je calibre mon écran tous les 15 jours, par
principe. Il règle surtout la colorimétrie, puis la luminosité en
fonction de celle de la pièce. Si l'écran vieillit cela sera corrigé,
jusqu'à un certain point. Si on le laisse branché l'outil permet aussi
de modifier la luminosité en fonction de la lumière ambiante.

De toute façon les écrans Apple d'aujourd'hui fonctionnent comme les
iPhone et beaucoup de portables : ils utilisent les caméras internes
pour règler la luminosité en fonction de l'environnement. Sur mon écran
je fais un premier réglage avec ColorMunki et je ne touche plus à la
luminosité, la machine s'en charge.

[efji]

Post by Benoît
J'utilise un MacBook Pro Retina fin 2013 : 10bits/couleur. Soit 4 fois
plus que les écrans « standards » sur 8 bits.

Tu es sûr de ça ?
J'en doute fort, surtout sur un macbook de 2013.
Il y a une controverse sur les 10 bits sur les macbook pro de 2017 (et
il semble in fine qu'ils ne l'aient pas mais que seule leur carte
graphique les supportent sur un écran externe) mais rien d'aussi vieux
que 2013. Ils ont introduit le 10 bits en 2017 sur l'imac mais seulement
avec l'écran 5K.

J'ai un macbook pro de 2018 et je n'ai noté aucune différence avec celui
de 2013 que j'avais avant. Tu connais un moyen de tester ça ?

De toute façon je ne vois pas quel soft ou format est capable de gérer ça.

[Benoît]

Post by efji

Post by Benoît
J'utilise un MacBook Pro Retina fin 2013 : 10bits/couleur. Soit 4 fois
plus que les écrans « standards » sur 8 bits.

Tu es sûr de ça ?
J'en doute fort, surtout sur un macbook de 2013.
Il y a une controverse sur les 10 bits sur les macbook pro de 2017 (et
il semble in fine qu'ils ne l'aient pas mais que seule leur carte
graphique les supportent sur un écran externe) mais rien d'aussi vieux
que 2013. Ils ont introduit le 10 bits en 2017 sur l'imac mais seulement
avec l'écran 5K.

Sur le MacBook Pro Retina mi-2014 il semble que le gamut soit 88% de
l'Adobe RGB et 99% du sRGB.

Le problème est que si tu ne paramètres pas ton écran correctement, ce
que tu verras n'as rien à voir avec ce qui est supposé être affiché et
tes retouches seront fausses.

Post by efji
J'ai un macbook pro de 2018 et je n'ai noté aucune différence avec celui
de 2013 que j'avais avant. Tu connais un moyen de tester ça ?
De toute façon je ne vois pas quel soft ou format est capable de gérer ça.

Ce n'est pas un logiciel qui va pouvoir te dire s'il y a une différence,
c'est du matériel qui, avec son logiciel, saura dire que si je demande
d'afficher telle couleur RGB, je « vois » cette couleur. Et je créé un
fichier de profil écran correspondant. Tu as aujourd'hui des outils pour
tout calibrer. Il te fournisse un document papier à conserver
présieucement, et un fichier :
- Je scanne un document que je connais et je vois ce que je récupère =
profil spécifique de ce scanner ;
- Je demande à l'écran de m'afficher ce document = profil de cette
écran ;
- Je demande à analyser le fichier imprimer = profil de cette
imprimante.

À partir de là tu s une chaîne graphique assez blindée où, en terme de
couleurs, luminosité... l'image du document d'origine est préservée,
idem quand je l'affiche sur l'écran et pareil quand je l'imprime.

[efji]

Cher Benoit, je pense que de nouveau tu racontes un maximum de bêtises.
Désolé pour toi :)

Post by Benoît

Post by efji

Post by Benoît
J'utilise un MacBook Pro Retina fin 2013 : 10bits/couleur. Soit 4 fois
plus que les écrans « standards » sur 8 bits.

Tu es sûr de ça ?
J'en doute fort, surtout sur un macbook de 2013.
Il y a une controverse sur les 10 bits sur les macbook pro de 2017 (et
il semble in fine qu'ils ne l'aient pas mais que seule leur carte
graphique les supportent sur un écran externe) mais rien d'aussi vieux
que 2013. Ils ont introduit le 10 bits en 2017 sur l'imac mais seulement
avec l'écran 5K.

Sur le MacBook Pro Retina mi-2014 il semble que le gamut soit 88% de
l'Adobe RGB et 99% du sRGB.
Le problème est que si tu ne paramètres pas ton écran correctement, ce
que tu verras n'as rien à voir avec ce qui est supposé être affiché et
tes retouches seront fausses.

Rien à voir avec le 10 bits.

Post by Benoît

Post by efji
J'ai un macbook pro de 2018 et je n'ai noté aucune différence avec celui
de 2013 que j'avais avant. Tu connais un moyen de tester ça ?
De toute façon je ne vois pas quel soft ou format est capable de gérer ça.

Ce n'est pas un logiciel qui va pouvoir te dire s'il y a une différence,

Pour pour afficher une image en 10 bits par pixels il faut en avoir une
ainsi qu'un soft capable de l'afficher sans la traduire en 8 bits.

Quel format d'image connais-tu qui encode une image en 10 bits/pixel ?
(Si tu me réponds "raw", je sors la kalach (car ce n'est pas un format
d'image) !).

Post by Benoît
c'est du matériel qui, avec son logiciel, saura dire que si je demande
d'afficher telle couleur RGB, je « vois » cette couleur. Et je créé un
fichier de profil écran correspondant. Tu as aujourd'hui des outils pour
tout calibrer. Il te fournisse un document papier à conserver

Blablabla qui n'a rien à voir.

De toute façon entre temps je me suis renseigné et ton vieux macbook n'a
évidemment pas un écran en 10 bits, pas plus que ta carte graphique.

[Benoît]

Post by efji
Cher Benoit, je pense que de nouveau tu racontes un maximum de bêtises.
Désolé pour toi :)

Post by Benoît

Post by efji

Post by Benoît
J'utilise un MacBook Pro Retina fin 2013 : 10bits/couleur. Soit 4 fois
plus que les écrans « standards » sur 8 bits.

Tu es sûr de ça ?
J'en doute fort, surtout sur un macbook de 2013.
Il y a une controverse sur les 10 bits sur les macbook pro de 2017 (et
il semble in fine qu'ils ne l'aient pas mais que seule leur carte
graphique les supportent sur un écran externe) mais rien d'aussi vieux
que 2013. Ils ont introduit le 10 bits en 2017 sur l'imac mais seulement
avec l'écran 5K.

Sur le MacBook Pro Retina mi-2014 il semble que le gamut soit 88% de
l'Adobe RGB et 99% du sRGB.
Le problème est que si tu ne paramètres pas ton écran correctement, ce
que tu verras n'as rien à voir avec ce qui est supposé être affiché et
tes retouches seront fausses.

Rien à voir avec le 10 bits.

100% d'accord

Post by efji

Post by Benoît

Post by efji
J'ai un macbook pro de 2018 et je n'ai noté aucune différence avec celui
de 2013 que j'avais avant. Tu connais un moyen de tester ça ?
De toute façon je ne vois pas quel soft ou format est capable de gérer ça.

Ce n'est pas un logiciel qui va pouvoir te dire s'il y a une différence,

Pour pour afficher une image en 10 bits par pixels il faut en avoir une
ainsi qu'un soft capable de l'afficher sans la traduire en 8 bits.
Quel format d'image connais-tu qui encode une image en 10 bits/pixel ?
(Si tu me réponds "raw", je sors la kalach (car ce n'est pas un format
d'image) !).

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.

Post by efji

Post by Benoît
c'est du matériel qui, avec son logiciel, saura dire que si je demande
d'afficher telle couleur RGB, je « vois » cette couleur. Et je créé un
fichier de profil écran correspondant. Tu as aujourd'hui des outils pour
tout calibrer. Il te fournisse un document papier à conserver

Blablabla qui n'a rien à voir.
De toute façon entre temps je me suis renseigné et ton vieux macbook n'a
évidemment pas un écran en 10 bits, pas plus que ta carte graphique.

Merci de me donner le lien parce que mes recherches me donnaient des
informations assez « unsure ».

[efji]

Post by Benoît
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.

J'ai un peu cherché les applications de ça et, à part les discours
théoriques du style "c'est mieux car il y a plus de couleurs", on trouve
essentiellement des choses qui concernent la video car j'imagine que les
softs sont capables d'extrapoler de l'information supplémentaire à
partir d'une séquence d'images 8 bits. Rien trouvé sur la photo, bien
que PS supporte le 10 bits en sortie.

Post by Benoît

Post by efji
Blablabla qui n'a rien à voir.
De toute façon entre temps je me suis renseigné et ton vieux macbook n'a
évidemment pas un écran en 10 bits, pas plus que ta carte graphique.

Merci de me donner le lien parce que mes recherches me donnaient des
informations assez « unsure ».

Les rumeurs de 2015 disaient que ça allait être intégré au système et à
quelques mac :
https://nofilmschool.com/2015/11/apple-paving-way-10-bit-color-its-latest-operating-system-update
Ca l'est en fait sur les mac pro (pas mac book) avec l'écran 5K (pas 4K).
Ils communiquent peu là dessus car ils savent que ça n'intéresse presque
personne en pratique car ça n'a aucun intérêt pour le commun des
mortels, et même le photographe pro.

[Benoît]

Post by efji

Post by Benoît
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.

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.

Post by efji
J'ai un peu cherché les applications de ça et, à part les discours
théoriques du style "c'est mieux car il y a plus de couleurs", on trouve
essentiellement des choses qui concernent la video car j'imagine que les
softs sont capables d'extrapoler de l'information supplémentaire à
partir d'une séquence d'images 8 bits. Rien trouvé sur la photo, bien
que PS supporte le 10 bits en sortie.

Pour l'écran Ok. Pour la photo c'est simple. Si tu fais un dégradé du
noir au blanc et que tu le tires sur un mètre de long tu as des rayures
de 4mm. Comme les gris de chaque rayure sont très proche cela ne se
verra pas, mais si tu commences à faire des retouches diverses et
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.

[efji]

Post by Benoît

Post by efji

Post by Benoît
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é.

Post by Benoît
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.

Post by Benoît
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]

Post by 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]

Post by Alf92

Post by 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 ?

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]

Post by efji

Post by Benoît

Post by efji

Post by Benoît
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é.

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

Post by efji

Post by Benoît
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.

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

Post by efji

Post by Benoît
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.

Post by efji
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]

Post by efji

Post by Benoît

Post by efji

Post by Benoît
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é.

Post by Benoît
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.

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

Post by Didier
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.

[Didier]

Post by efji

Post by Didier
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.

[Benoît]

Post by Didier

Post by efji

Post by Benoît

Post by efji

Post by Benoît
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é.

Post by Benoît
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.

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

Post by Didier
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. ;)

Post by Didier
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.

Post by Didier
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.

[Didier]

Post by Benoît

Post by Didier

Post by efji

Post by Benoît

Post by efji

Post by Benoît
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é.

Post by Benoît
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.

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

Post by Didier
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.

Post by Benoît

Post by Didier
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.

Post by Didier
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

Post by Benoît
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.

[j***@hotmail.com]

Post by efji

Post by Benoît

Post by efji

Post by Benoît
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é.

Post by Benoît
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.

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

Post by Benoît
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?

René

[Benoît]

Post by j***@hotmail.com

Post by efji

Post by Benoît

Post by efji

Post by Benoît
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é.

Post by Benoît
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.

Post by Benoît
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.

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.

Post by j***@hotmail.com
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]

Post by Benoît
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é.

Post by Benoît
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]

Post by efji

Post by Benoît
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.

Post by efji
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

Post by efji
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.

Post by efji

Post by Benoît
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]

Post by efji

Post by Benoît
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é.

Post by Benoît
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 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 ;)

[jdd]

Post by Benoît
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

Post by Benoît
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

[Benoît]

Post by jdd

Post by Benoît
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.

Post by jdd

Post by Benoît
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.
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.

[Didier]

Post by Benoît

Post by jdd

Post by Benoît
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.

Post by jdd

Post by Benoît
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
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
(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

[Benoît]

Post by Didier

Post by Benoît

Post by jdd

Post by Benoît
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.

Post by jdd

Post by Benoît
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
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
(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.

[efji]

Post by Benoît

Post by Didier

Post by Benoît
(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).

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.

[Benoît]

Post by efji

Post by Benoît

Post by Didier

Post by Benoît
(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).

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 !

Post by efji
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é).

Post by efji
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.

[efji]

Mon petit Benoit, s'il te plaît, arrête de t'enfoncer..;

Post by Benoît
distributivité qui entrerait en jeu : a(b/c) = ab / ac

et retourne au cm2...

Post by Benoît
100 x 5 + 2 = 502 mais 100 x (5 + 2) = 100

ou en ce1...

Post by Benoît

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}

[Didier]

Post by Benoît

Post by efji

Post by Benoît

Post by Didier

Post by Benoît
(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).

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

La distributivité, dans un anneau (a fortior un corps), met en jeu les
deux lois de composition qui permettent de définir l'anneau (le corps).
Sur le corps des réels, on parle de l'addition et de la mutliplication.
Parler de distributivité entre la multiplication et la division n'a pas
de sens.
Didier.

Didier.

[Benoît]

Post by Didier

Post by Benoît

Post by efji

Post by Benoît

Post by Didier

Post by Benoît
(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).

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

La distributivité, dans un anneau (a fortior un corps), met en jeu les
deux lois de composition qui permettent de définir l'anneau (le corps).
Sur le corps des réels, on parle de l'addition et de la mutliplication.
Parler de distributivité entre la multiplication et la division n'a pas
de sens.

+1

Merci beaucoup.

[Didier]

Post by Benoît

Post by Didier

Post by Benoît

Post by jdd

Post by Benoît
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.

Post by jdd

Post by Benoît
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
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
(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).
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
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.

Sur le plan mathématique, je ne vois rien d'anormal.
Didier.

[Benoît]

Post by Didier

Post by Benoît

Post by Didier

Post by Benoît

Post by jdd

Post by Benoît
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.

Post by jdd

Post by Benoît
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
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
(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).
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
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.

Sur le plan mathématique, je ne vois rien d'anormal.

Absolument, mais le fait que 6 ≠ 6,6666 fait que tu as une sorte de trou
noir : 0. Si jamais tu arrives à 0 tu ne pourras pas en sortir :
10/10,1 x 100 = 0 si tu oublies les chiffres après la virgule

sinon tu as comme résultat 99,00990099...

Tu comprends donc que les retouches avec des entiers...

Sinon, j'ai un peu creusé le sujet et il apparaît que les fichiers RAW
contiennent plus d'information que leur export direct et c'est pourquoi
on a tout intérêt de faire des retouches « de bases » avec l'appli du
fabriquant puisqu'elle a accès à plus d'information qu'une tiff
exportée.

[jdd]

Post by Benoît
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

Post by Benoît
La multiplication et la division ne sont plus commutative.

elles ne le sont jamais...

Post by Benoît
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

[Benoît]

Post by jdd

Post by Benoît
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

Post by Benoît
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

Post by jdd

Post by Benoît
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.

Post by jdd
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.

Post by jdd
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.

[jdd]

Post by Benoît

Post by jdd
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

[Benoît]

Post by jdd

Post by Benoît

Post by jdd
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

Pas même si tu as 8, 16 ou 32... bits. Pour info, aujourd'hui on est
avec 3,14 suivi de dix milliards de chiffres. Alors tes 8 bits...

Voilà le matériel utilisé en 2010 pour arriver à 2,7 milliars de
chiffres :
Fabrice Bellard (France)
• Temps de calcul : 131 jours.
• Core i7 CPU at 2.93 GHz6 GiB (1) of RAM
• 7.5 TB of disk storage using five 1.5 TB hard disks (Seagate
Barracuda 7200.11 model)
• 64 bit Red Hat Fedora 10 distribution
• Computation of the binary digits: 103 days
• Verification of the binary digits: 13 days
• Conversion to base 10: 12 days
• Verification of the conversion: 3 days.

Et lis bien <https://fr.wikipedia.org/wiki/Effet_papillon> si tu ne le
connais :

L'origine viendrait du fait que Lorenz faisait des prévisions météo.
Cela prenait beaucoup de temps machine. Un jour il relança les mêmes
données initiales, mais dû arrêter les calculs (son temps machine était
épuisé). Un sortie de la situation sur papier et resaisie des données le
lendemain : pas les mêmes résultats malgré je ne sais combien de
chiffres après la virgule, mais moins que ce que savait calculer
l'ordinateur. D'où : une différence de vitesse du vent (entre autre)
équivalente à une aile de papillon implique des différences énormes
après des jours.

[efji]

Post by Benoît

Post by jdd

Post by Benoît

Post by jdd
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

Pas même si tu as 8, 16 ou 32... bits. Pour info, aujourd'hui on est
avec 3,14 suivi de dix milliards de chiffres. Alors tes 8 bits...
Voilà le matériel utilisé en 2010 pour arriver à 2,7 milliars de

Au risque de me répéter : arrête de t'enfoncer !!!
Tu confonds "calculer x décimales de pi" et "faire un calcul avec x
décimales".

Additionner deux nombres à x décimales demande grosso-modo x opérations.
Le processeur de l'ordi bas de gamme de Mme Michu acheté à Carrefour
fait couramment 10Gflops, c'est-à-dire qu'il fait 10 milliards
d'opérations flottantes par seconde sur des mots de 32 bits. Ton nombre
à 2.7 milliards de décimales peut se représenter avec environ 400
millions de mots de 32 bits, donc l'addition de 2 de ces individus
prendra environ 1/20e de seconde chez Michu, 1/100e de seconde chez moi
qui suis plus riche, et moins de 2x10^{-8} secondes sur l'ordinateur le
plus puissant du monde (200 PetaFlops).

[Benoît]

Post by efji

Post by Benoît

Post by jdd

Post by Benoît

Post by jdd
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

Pas même si tu as 8, 16 ou 32... bits. Pour info, aujourd'hui on est
avec 3,14 suivi de dix milliards de chiffres. Alors tes 8 bits...
Voilà le matériel utilisé en 2010 pour arriver à 2,7 milliars de

Au risque de me répéter : arrête de t'enfoncer !!!
Tu confonds "calculer x décimales de pi" et "faire un calcul avec x
décimales".
Additionner deux nombres à x décimales demande grosso-modo x opérations.

Non, une seule :
1 000 000 000 000
+
2 000 000 000 000

Ne prend vraiment pas plus de temps que :

1
+
2

[jdd]

Post by Benoît

Post by efji
Additionner deux nombres à x décimales demande grosso-modo x opérations.

1 000 000 000 000
+
2 000 000 000 000
1
+
2

j'abandonne...

jdd

[efji]

Post by jdd

Post by Benoît

Post by efji
Additionner deux nombres à x décimales demande grosso-modo x opérations.

1 000 000 000 000
+
2 000 000 000 000
1
+
2

j'abandonne...

Moi aussi. Les fonctionnaires ont dans leur statut un "droit de retrait"
en cas de force majeure. Je me l'applique !

[jdd]

Post by efji

Post by jdd

Post by Benoît

Post by efji
Additionner deux nombres à x décimales demande grosso-modo x opérations.

1 000 000 000 000
+
2 000 000 000 000
1
+
2

j'abandonne...

Moi aussi. Les fonctionnaires ont dans leur statut un "droit de retrait"
en cas de force majeure. Je me l'applique !

:-) à noter qu'en virgule flottante les deux calculs ne donnent pas le
même résultat, si tant est qu'on arrive à saisir les valeurs d'entrée :-)

jdd

[j***@hotmail.com]

Post by jdd

Post by Benoît
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

Post by Benoît
La multiplication et la division ne sont plus commutative.

elles ne le sont jamais...

Post by Benoît
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

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écimales flottantes.
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.
https://forums.tomshardware.com/threads/true-10bit-vs-8bit-frc.2937222/
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 de moins?
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 une science
exacte.

René

[Didier]

Post by jdd

Post by Benoît
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

Post by Benoît
La multiplication et la division ne sont plus commutative.

elles ne le sont jamais...

Il semble parler de commutativité entre deux opérations,ce qui n'a pas
de sens. On peut dire "la multiplication est commutative", ce qui est
vrai, ou "l'addition est commutative" ce qui est vrai aussi.
Didier.

[Pierre Maurette]

jdd :

[...]

Post by Benoît
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).

[Markorki]

Post by Benoît
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

[Markorki]

Post by Markorki

Post by Benoît
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
https://www.generation-nt.com/reponses/pb-degrade-escalier-entraide-4284712.html
... fil déjà initié par un certain Benoît !!;-((
https://www.flickr.com/photos/orchimous/albums/72157681185085536

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]

Post by Markorki
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
ajout de bruit

oui

Post by Markorki
**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]

Post by jdd

Post by Markorki
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
ajout de bruit

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

Post by jdd
oui

Post by Markorki
**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.

[Alf92]

Post by j***@hotmail.com
En bref en 2015 j'ai acheté un écran LG31MU97-B 4096x2160 pixels, 1700$ payé
1400 $ chez mon fournisseur habituel.
Des l'installation un des fils a eu un problème de contacts.
Au service technique autorisé Capri ils me l'ont brisé d'avantage, l'écran
avait un demi cercle non rétroéclairé. Sous garantie, après 2 mois j'en ai
enfin obtenu un nouveau. J'étais bien heureux.
Il y a 15 jours un bris d'aqueduc sur ma rue a forcé l'arrêt et la remise du
service électrique... mon écran a eu un choc, est devenu tout noir, et n'en
est pas revenu. Hors garantie et discontinué LG me dit de retourner chez
Capri. Disons que je n'ai pas vraiment confiance... dois-je tenter (et
débourser) pour une réparation ou dois-je en acheter un autre.

probalement l'étage d'alimentation qui est en cause.
as tu essayé de démonter ? peut-être juste un fusible...
à creuser avant d'acheter.

[j***@hotmail.com]

Post by Alf92

Post by j***@hotmail.com
En bref en 2015 j'ai acheté un écran LG31MU97-B 4096x2160 pixels, 1700$ payé
1400 $ chez mon fournisseur habituel.
Des l'installation un des fils a eu un problème de contacts.
Au service technique autorisé Capri ils me l'ont brisé d'avantage, l'écran
avait un demi cercle non rétroéclairé. Sous garantie, après 2 mois j'en ai
enfin obtenu un nouveau. J'étais bien heureux.
Il y a 15 jours un bris d'aqueduc sur ma rue a forcé l'arrêt et la remise du
service électrique... mon écran a eu un choc, est devenu tout noir, et n'en
est pas revenu. Hors garantie et discontinué LG me dit de retourner chez
Capri. Disons que je n'ai pas vraiment confiance... dois-je tenter (et
débourser) pour une réparation ou dois-je en acheter un autre.

probalement l'étage d'alimentation qui est en cause.
as tu essayé de démonter ? peut-être juste un fusible...
à creuser avant d'acheter.

Je sais que tu es le bricoleur de FRP. Mon bricolage se limite surtout à la
fabrication de maquettes pour des amis artistes...
Vérifier l’existence d'un simple fusible... oui, plus?, je ne suis pas outillé
et surtout je ne saurais pas.

René