Je viens de planter une série de photos, mais alors planter. Tout ça
parce que j'avais oublié de revenir en Raw. Et le JPEG, même en haute
définition, c'est mauvais dès lors qu'on a de large aplats de couleur.
Là c'était du gris puisqu'il y avait une bruine comme il faut
aujourd'hui en Bretagne.
Vous voulez voir ce qu'est un ciel gris revu et corrigé par jpeg ?
Déjà des couleurs qui apparaîssent, un vrai arc-en-ciel : du rouge/rose
n'importe où.
<https://www.cjoint.com/doc/18_04/HDjryvoW7RQ_Capture-d'écran-2018-04-09-à-19.22.32.JPG>
Et maintenant le bruit, à partir d'un dégradé gris dû aux nuages dans le
ciel, on obtient ça :
On a des aplats, des dégradés de pixels, des tâches vertes, des roses,
des bleues. Bref on a tout sauf ce qu'on a photographié.
Pour ceux qui vont râler qu'on ne fait jamais d'agradissements
permettants de voir ces défauts :
<https://www.cjoint.com/doc/18_04/HDjrImGP1kQ_Capture-d'écran-2018-04-09-à-19.33.31.JPG>
Ou, côté arcs-en ciel pour un jour sans soleil :
https://www.cjoint.com/doc/18_04/HDjrNnH4orQ_Capture-d'écran-2018-04-09-à-19.38.47.JPG
Bref, le jpeg, je le jette, je fais du RAW. Point barre ! _erde !
Pour info, Sony A7 II, ISO 800. 1/750e f16 sur un 35-70 pour le second.
--
Pense à l'étiquette qu'une fois les vendanges faites.
Absolument, il ouvre le fichier de façon assez brutale : il ne touche
à
rien.
il utilise une T° de couleur... on ne peut pas developer un raw sans fixer une T° de couleur.
Quand j'ouvre dans LR il met tout au centre, température neutre. C'est un choix de sa part. GraphicConverter, lui, prend les pixels tels qu'ils sont, avec un double capteur vert, un rouge et un bleu.
Il fait quand même une tambouille, même si elle est basique. Les pixels n'existent pas en tant que tels sur un capteur à matrice de Bayer, donc GC doit bien faire un choix pour reconstituer des pixels.
> Absolument, il ouvre le fichier de façon assez brutale : il ne touche
à
> rien.
il utilise une T° de couleur... on ne peut pas developer un raw sans
fixer une T° de couleur.
Quand j'ouvre dans LR il met tout au centre, température neutre. C'est
un choix de sa part.
GraphicConverter, lui, prend les pixels tels qu'ils sont, avec un double
capteur vert, un rouge et un bleu.
Il fait quand même une tambouille, même si elle est basique. Les pixels
n'existent pas en tant que tels sur un capteur à matrice de Bayer, donc GC
doit bien faire un choix pour reconstituer des pixels.
Absolument, il ouvre le fichier de façon assez brutale : il ne touche
à
rien.
il utilise une T° de couleur... on ne peut pas developer un raw sans fixer une T° de couleur.
Quand j'ouvre dans LR il met tout au centre, température neutre. C'est un choix de sa part. GraphicConverter, lui, prend les pixels tels qu'ils sont, avec un double capteur vert, un rouge et un bleu.
Il fait quand même une tambouille, même si elle est basique. Les pixels n'existent pas en tant que tels sur un capteur à matrice de Bayer, donc GC doit bien faire un choix pour reconstituer des pixels.
benoit
Stephane Legras-Decussy wrote:
Le 12/04/2018 14:19, Benoit a écrit :
Quand j'ouvre dans LR il met tout au centre, température neutre. C'est un choix de sa part.
il faut que tu comprennes qu'il n'y a pas de T° e couleur neutre.
Ce que j'entends par là c'est qu'il n'y a aucune correction de « température » j'ai tant de bleu, tant de vert, tant de rouge et bien j'affiche ce que j'ai. Je ne corrige pas parce que c'est de la lumière chaude, froide... je suis RAW donc voilà ce que j'ai reçu comme lumière ! La correction c'est pour plus tard. J'ai peut-être MA température de couleur en tant que type de capteur qui a une dominante (pour vous les humains), mais pour moi je vous donne l'info que j'ai reçue. C'est tout -- Pense à l'étiquette qu'une fois les vendanges faites.
> Quand j'ouvre dans LR il met tout au centre, température neutre. C'est
> un choix de sa part.
il faut que tu comprennes qu'il n'y a pas de T° e couleur neutre.
Ce que j'entends par là c'est qu'il n'y a aucune correction de
« température » j'ai tant de bleu, tant de vert, tant de rouge et bien
j'affiche ce que j'ai. Je ne corrige pas parce que c'est de la lumière
chaude, froide... je suis RAW donc voilà ce que j'ai reçu comme
lumière ! La correction c'est pour plus tard.
J'ai peut-être MA température de couleur en tant que type de capteur qui
a une dominante (pour vous les humains), mais pour moi je vous donne
l'info que j'ai reçue. C'est tout
--
Pense à l'étiquette qu'une fois les vendanges faites.
Quand j'ouvre dans LR il met tout au centre, température neutre. C'est un choix de sa part.
il faut que tu comprennes qu'il n'y a pas de T° e couleur neutre.
Ce que j'entends par là c'est qu'il n'y a aucune correction de « température » j'ai tant de bleu, tant de vert, tant de rouge et bien j'affiche ce que j'ai. Je ne corrige pas parce que c'est de la lumière chaude, froide... je suis RAW donc voilà ce que j'ai reçu comme lumière ! La correction c'est pour plus tard. J'ai peut-être MA température de couleur en tant que type de capteur qui a une dominante (pour vous les humains), mais pour moi je vous donne l'info que j'ai reçue. C'est tout -- Pense à l'étiquette qu'une fois les vendanges faites.
Markorki
Benoit a écrit :
Markorki wrote:
La création d'artefacts jpg ne dépend pas de la couleur. Elle ne vient que de la nature de l'algo de compression jpg, et de la trop faible variation de valeur des composantes de points voisins dans des aplats presque unis.
D'où l'intérêt de travailler avec du RAW pour faire des retouches sur l'original et pas sur du déjà retouché.
De toute façon, sauf si tu archives en RAW sans jamais traduire tes photos en jpg, le passage en jpg provoquera des artefacts en marches d'escalier (posterisation) si tu as des plages à très faible variation. Le **seul** remède à ce pb est l(ajout de bruit **juste-avant** le passage en jpg. Voir dans wikipedia l'algo de compression en jpg : Un point est inchangé de ses voisins si la différence entre eux dans l'original à comprimer est inférieure à un certain seuil => grandes zones unies (points codés comme le point référence du carré de 8 tant que la différence ne justifie pas de détailler plus (ajouter des données) le fichier résultat de compression). -- Tous citoyens-politiciens-touristes : vous aussi faites un passage éclair dans un ministère de la "France en marche-arrière".
Benoit a écrit :
Markorki <markorkispamepas@orange.fromage> wrote:
La création d'artefacts jpg ne dépend pas de la couleur. Elle ne vient que
de la nature de l'algo de compression jpg, et de la trop faible variation
de valeur des composantes de points voisins dans des aplats presque unis.
D'où l'intérêt de travailler avec du RAW pour faire des retouches sur
l'original et pas sur du déjà retouché.
De toute façon, sauf si tu archives en RAW sans jamais traduire tes photos en
jpg, le passage en jpg provoquera des artefacts en marches d'escalier
(posterisation) si tu as des plages à très faible variation.
Le **seul** remède à ce pb est l(ajout de bruit **juste-avant** le passage en jpg.
Voir dans wikipedia l'algo de compression en jpg :
Un point est inchangé de ses voisins si la différence entre eux dans l'original
à comprimer est inférieure à un certain seuil => grandes zones unies (points
codés comme le point référence du carré de 8 tant que la différence ne justifie
pas de détailler plus (ajouter des données) le fichier résultat de compression).
--
Tous citoyens-politiciens-touristes : vous aussi faites un passage éclair dans
un ministère de la "France en marche-arrière".
La création d'artefacts jpg ne dépend pas de la couleur. Elle ne vient que de la nature de l'algo de compression jpg, et de la trop faible variation de valeur des composantes de points voisins dans des aplats presque unis.
D'où l'intérêt de travailler avec du RAW pour faire des retouches sur l'original et pas sur du déjà retouché.
De toute façon, sauf si tu archives en RAW sans jamais traduire tes photos en jpg, le passage en jpg provoquera des artefacts en marches d'escalier (posterisation) si tu as des plages à très faible variation. Le **seul** remède à ce pb est l(ajout de bruit **juste-avant** le passage en jpg. Voir dans wikipedia l'algo de compression en jpg : Un point est inchangé de ses voisins si la différence entre eux dans l'original à comprimer est inférieure à un certain seuil => grandes zones unies (points codés comme le point référence du carré de 8 tant que la différence ne justifie pas de détailler plus (ajouter des données) le fichier résultat de compression). -- Tous citoyens-politiciens-touristes : vous aussi faites un passage éclair dans un ministère de la "France en marche-arrière".
pehache
Le 12/04/2018 à 14:43, Markorki a écrit :
Benoit a écrit :
Markorki wrote:
La création d'artefacts jpg ne dépend pas de la couleur. Elle ne vient que de la nature de l'algo de compression jpg, et de la trop faible variation de valeur des composantes de points voisins dans des aplats presque unis.
D'où l'intérêt de travailler avec du RAW pour faire des retouches sur l'original et pas sur du déjà retouché.
De toute façon, sauf si tu archives en RAW sans jamais traduire tes photos en jpg,
Donc sans jamais les voir :-)
le passage en jpg provoquera des artefacts en marches d'escalier (posterisation) si tu as des plages à très faible variation. Le **seul** remède à ce pb est l(ajout de bruit **juste-avant** le passage en jpg.
Ce n'est pas le passage en jpg qui fait ça, mais la réduction de 12/14/16 bits (suivant les RAW) par canal RGB à 8 bits par canal RGB. Un tiff 8 bits pourra aussi faire apparaitre de la postérisation.
Voir dans wikipedia l'algo de compression en jpg : Un point est inchangé de ses voisins si la différence entre eux dans l'original à comprimer est inférieure à un certain seuil => grandes zones unies (points codés comme le point référence du carré de 8 tant que la différence ne justifie pas de détailler plus (ajouter des données) le fichier résultat de compression).
Le 12/04/2018 à 14:43, Markorki a écrit :
Benoit a écrit :
Markorki <markorkispamepas@orange.fromage> wrote:
La création d'artefacts jpg ne dépend pas de la couleur. Elle ne vient
que
de la nature de l'algo de compression jpg, et de la trop faible
variation
de valeur des composantes de points voisins dans des aplats presque
unis.
D'où l'intérêt de travailler avec du RAW pour faire des retouches sur
l'original et pas sur du déjà retouché.
De toute façon, sauf si tu archives en RAW sans jamais traduire tes photos
en
jpg,
Donc sans jamais les voir :-)
le passage en jpg provoquera des artefacts en marches d'escalier
(posterisation) si tu as des plages à très faible variation.
Le **seul** remède à ce pb est l(ajout de bruit **juste-avant** le passage
en jpg.
Ce n'est pas le passage en jpg qui fait ça, mais la réduction de 12/14/16
bits (suivant les RAW) par canal RGB à 8 bits par canal RGB. Un tiff 8
bits pourra aussi faire apparaitre de la postérisation.
Voir dans wikipedia l'algo de compression en jpg :
Un point est inchangé de ses voisins si la différence entre eux dans
l'original
à comprimer est inférieure à un certain seuil => grandes zones unies
(points
codés comme le point référence du carré de 8 tant que la différence ne
justifie
pas de détailler plus (ajouter des données) le fichier résultat de
compression).
La création d'artefacts jpg ne dépend pas de la couleur. Elle ne vient que de la nature de l'algo de compression jpg, et de la trop faible variation de valeur des composantes de points voisins dans des aplats presque unis.
D'où l'intérêt de travailler avec du RAW pour faire des retouches sur l'original et pas sur du déjà retouché.
De toute façon, sauf si tu archives en RAW sans jamais traduire tes photos en jpg,
Donc sans jamais les voir :-)
le passage en jpg provoquera des artefacts en marches d'escalier (posterisation) si tu as des plages à très faible variation. Le **seul** remède à ce pb est l(ajout de bruit **juste-avant** le passage en jpg.
Ce n'est pas le passage en jpg qui fait ça, mais la réduction de 12/14/16 bits (suivant les RAW) par canal RGB à 8 bits par canal RGB. Un tiff 8 bits pourra aussi faire apparaitre de la postérisation.
Voir dans wikipedia l'algo de compression en jpg : Un point est inchangé de ses voisins si la différence entre eux dans l'original à comprimer est inférieure à un certain seuil => grandes zones unies (points codés comme le point référence du carré de 8 tant que la différence ne justifie pas de détailler plus (ajouter des données) le fichier résultat de compression).
Markorki
pehache a écrit :
le passage en jpg provoquera des artefacts en marches d'escalier (posterisation) si tu as des plages à très faible variation. Le **seul** remède à ce pb est l(ajout de bruit **juste-avant** le passage en jpg.
Ce n'est pas le passage en jpg qui fait ça, mais la réduction de 12/14/16 bits (suivant les RAW) par canal RGB à 8 bits par canal RGB. Un tiff 8 bits pourra aussi faire apparaitre de la postérisation.
C'est faux sauf si la compression jpg **destructive** est l'un des modes de compression utilisés en TIFF (il y a plusieurs algo de compression en autorisés en tiff, dont un proche du zip et un LZH ). Non, c'est l'algo de compression jpg qui fait des vagues. Pour preuve : tant que tu affiches le résultat jpg de la derawtisation, pas de posterisation; dès que compression **et_réaffichage** , oui. Ce n'est pas un effet de chnagement de nombre de bits, qui aurait *aussi* des effets sur des zones détaillées, ce qui n'est pas le cas. En plus, si tu connais l'algo de compression jpg, ça ne peut pas ne pas se produire. Si tu connais un outil qui comprime en jpg avec plus de 8 bits ( JPEG 2000 ?) , comprime des ciels uniformes, ils seront rayés tout pareil. -- Tous citoyens-politiciens-touristes : vous aussi faites un passage éclair dans un ministère de la "France en marche-arrière".
pehache a écrit :
le passage en jpg provoquera des artefacts en marches d'escalier
(posterisation) si tu as des plages à très faible variation.
Le **seul** remède à ce pb est l(ajout de bruit **juste-avant** le passage
en jpg.
Ce n'est pas le passage en jpg qui fait ça, mais la réduction de 12/14/16
bits (suivant les RAW) par canal RGB à 8 bits par canal RGB. Un tiff 8
bits pourra aussi faire apparaitre de la postérisation.
C'est faux sauf si la compression jpg **destructive** est l'un des modes de
compression utilisés en TIFF (il y a plusieurs algo de compression en autorisés
en tiff, dont un proche du zip et un LZH ).
Non, c'est l'algo de compression jpg qui fait des vagues.
Pour preuve : tant que tu affiches le résultat jpg de la derawtisation, pas de
posterisation; dès que compression **et_réaffichage** , oui.
Ce n'est pas un effet de chnagement de nombre de bits, qui aurait *aussi* des
effets sur des zones détaillées, ce qui n'est pas le cas.
En plus, si tu connais l'algo de compression jpg, ça ne peut pas ne pas se
produire. Si tu connais un outil qui comprime en jpg avec plus de 8 bits ( JPEG
2000 ?) , comprime des ciels uniformes, ils seront rayés tout pareil.
--
Tous citoyens-politiciens-touristes : vous aussi faites un passage éclair dans
un ministère de la "France en marche-arrière".
le passage en jpg provoquera des artefacts en marches d'escalier (posterisation) si tu as des plages à très faible variation. Le **seul** remède à ce pb est l(ajout de bruit **juste-avant** le passage en jpg.
Ce n'est pas le passage en jpg qui fait ça, mais la réduction de 12/14/16 bits (suivant les RAW) par canal RGB à 8 bits par canal RGB. Un tiff 8 bits pourra aussi faire apparaitre de la postérisation.
C'est faux sauf si la compression jpg **destructive** est l'un des modes de compression utilisés en TIFF (il y a plusieurs algo de compression en autorisés en tiff, dont un proche du zip et un LZH ). Non, c'est l'algo de compression jpg qui fait des vagues. Pour preuve : tant que tu affiches le résultat jpg de la derawtisation, pas de posterisation; dès que compression **et_réaffichage** , oui. Ce n'est pas un effet de chnagement de nombre de bits, qui aurait *aussi* des effets sur des zones détaillées, ce qui n'est pas le cas. En plus, si tu connais l'algo de compression jpg, ça ne peut pas ne pas se produire. Si tu connais un outil qui comprime en jpg avec plus de 8 bits ( JPEG 2000 ?) , comprime des ciels uniformes, ils seront rayés tout pareil. -- Tous citoyens-politiciens-touristes : vous aussi faites un passage éclair dans un ministère de la "France en marche-arrière".
Stephane Legras-Decussy
Le 12/04/2018 14:42, Benoit a écrit :
Ce que j'entends par là c'est qu'il n'y a aucune correction de « température » j'ai tant de bleu, tant de vert, tant de rouge et bien j'affiche ce que j'ai.
le strict minimum faisable c'est recopier dans un tiff16 les valeurs electriques des photosites. ça ne donne rien de regardable car chaque pixel aura 2 composantes sur les 3, non renseignée. la méthode la plus basique pour renseigner les composantes manquantes, c'est pour chaque pixel, recopier la valeur de son 8-voisinage. exemple : https://fr.wikipedia.org/wiki/D%C3%A9matri%C3%A7age#/media/File:Algorithme_de_d%C3%A9matricage.svg il manque le coin haut gauche de l'image rouge... on va stupidement recopier la valeur du voisin de droite. finalement, tu obtiens un tiff16 sans trou et sans aucun traitement. tu l'affiches ou tu l'imprimes : c'est déguellasse.
Le 12/04/2018 14:42, Benoit a écrit :
Ce que j'entends par là c'est qu'il n'y a aucune correction de
« température » j'ai tant de bleu, tant de vert, tant de rouge et bien
j'affiche ce que j'ai.
le strict minimum faisable c'est recopier dans un tiff16 les valeurs
electriques des photosites.
ça ne donne rien de regardable car chaque pixel aura 2 composantes sur
les 3, non renseignée.
la méthode la plus basique pour renseigner les composantes manquantes,
c'est pour chaque pixel, recopier la valeur de son 8-voisinage.
Ce que j'entends par là c'est qu'il n'y a aucune correction de « température » j'ai tant de bleu, tant de vert, tant de rouge et bien j'affiche ce que j'ai.
le strict minimum faisable c'est recopier dans un tiff16 les valeurs electriques des photosites. ça ne donne rien de regardable car chaque pixel aura 2 composantes sur les 3, non renseignée. la méthode la plus basique pour renseigner les composantes manquantes, c'est pour chaque pixel, recopier la valeur de son 8-voisinage. exemple : https://fr.wikipedia.org/wiki/D%C3%A9matri%C3%A7age#/media/File:Algorithme_de_d%C3%A9matricage.svg il manque le coin haut gauche de l'image rouge... on va stupidement recopier la valeur du voisin de droite. finalement, tu obtiens un tiff16 sans trou et sans aucun traitement. tu l'affiches ou tu l'imprimes : c'est déguellasse.
Stephane Legras-Decussy
Le 12/04/2018 14:43, Markorki a écrit :
De toute façon, sauf si tu archives en RAW sans jamais traduire tes photos en jpg, le passage en jpg provoquera des artefacts en marches d'escalier (posterisation) si tu as des plages à très faible variation.
on peut aussi faire du jpeg lossless. aucun interet... autant faire du tiff ou du PNG...
Le 12/04/2018 14:43, Markorki a écrit :
De toute façon, sauf si tu archives en RAW sans jamais traduire tes
photos en jpg, le passage en jpg provoquera des artefacts en marches
d'escalier (posterisation) si tu as des plages à très faible variation.
on peut aussi faire du jpeg lossless.
aucun interet... autant faire du tiff ou du PNG...
De toute façon, sauf si tu archives en RAW sans jamais traduire tes photos en jpg, le passage en jpg provoquera des artefacts en marches d'escalier (posterisation) si tu as des plages à très faible variation.
on peut aussi faire du jpeg lossless. aucun interet... autant faire du tiff ou du PNG...
Stephane Legras-Decussy
Le 12/04/2018 15:06, pehache a écrit :
Ce n'est pas le passage en jpg qui fait ça, mais la réduction de 12/14/16 bits (suivant les RAW) par canal RGB à 8 bits par canal RGB. Un tiff 8 bits pourra aussi faire apparaitre de la postérisation.
oui et même en envoyant un tiff16 à l'imprimante, elle va le faire elle même cette réduction de bit
Le 12/04/2018 15:06, pehache a écrit :
Ce n'est pas le passage en jpg qui fait ça, mais la réduction de 12/14/16
bits (suivant les RAW) par canal RGB à 8 bits par canal RGB. Un tiff 8
bits pourra aussi faire apparaitre de la postérisation.
oui et même en envoyant un tiff16 à l'imprimante, elle va le faire elle
même cette réduction de bit
Ce n'est pas le passage en jpg qui fait ça, mais la réduction de 12/14/16 bits (suivant les RAW) par canal RGB à 8 bits par canal RGB. Un tiff 8 bits pourra aussi faire apparaitre de la postérisation.
oui et même en envoyant un tiff16 à l'imprimante, elle va le faire elle même cette réduction de bit
Stephane Legras-Decussy
Le 12/04/2018 15:50, Stephane Legras-Decussy a écrit :
tu l'affiches ou tu l'imprimes : c'est déguellasse.
et pour ce qui est du rendu de couleur, tout ce que tu auras c'est le rendu des sensibilités des photodiodes. par exemple, la photodiode bleue est plus sensible que la verte, donc valeur electrique plus elevée donc dominante bleu dans l'image brute de deraw... dominante bleu qui ne correspond à rien dans la scène photographiée, qui correspond juste à un défaut de capteur. je suis pas sur que la réalité des défauts de capteurs soit celle qui t'interesse :-)
Le 12/04/2018 15:50, Stephane Legras-Decussy a écrit :
tu l'affiches ou tu l'imprimes : c'est déguellasse.
et pour ce qui est du rendu de couleur, tout ce que tu auras
c'est le rendu des sensibilités des photodiodes.
par exemple, la photodiode bleue est plus sensible que la verte, donc
valeur electrique plus elevée donc dominante bleu
dans l'image brute de deraw...
dominante bleu qui ne correspond à rien dans la scène photographiée, qui
correspond juste à un défaut de capteur.
je suis pas sur que la réalité des défauts de capteurs soit celle
qui t'interesse :-)
Le 12/04/2018 15:50, Stephane Legras-Decussy a écrit :
tu l'affiches ou tu l'imprimes : c'est déguellasse.
et pour ce qui est du rendu de couleur, tout ce que tu auras c'est le rendu des sensibilités des photodiodes. par exemple, la photodiode bleue est plus sensible que la verte, donc valeur electrique plus elevée donc dominante bleu dans l'image brute de deraw... dominante bleu qui ne correspond à rien dans la scène photographiée, qui correspond juste à un défaut de capteur. je suis pas sur que la réalité des défauts de capteurs soit celle qui t'interesse :-)
René
Le jeudi 12 avril 2018 03:07:55 UTC-4, Yves Tabouret a écrit :
Le Thu, 12 Apr 2018 08:57:09 +0200, René a écrit:
Le jeudi 12 avril 2018 00:59:26 UTC-4, GhostRaider a écrit :
Le 11/04/2018 à 17:01, Benoit a écrit : > Sinon, on me demande de tout faire en automatique j'ai donc un gris > moyen un peu sombre (j'avais peut-être laissé le correcteu r sur -1). > Quand j'ouvre le premier RAW dans GraphicConverter, j'ai ça : > <https://www.cjoint.com/doc/18_04/HDlo5Bk5ziQ_Capture2018-04-11-15.11. 38.JPG> > > C'est du brut de de fonderie. Rien, pas un ajustement, une correctio n de > l'optique... et surtout le fait qu'un capteur à deux verts par pixel. Voilà ce que j'obtiens avec PICASA : avant/après. https://www.cjoint.com/doc/18_04/HDme3qbg3r1_Benoit.jpg Je ne suis pas entièrement satisfait. Le fond surtout est assez v ilain.
Voyons voyons. Il suffit de définir le point blanc. https://www.cjoint.com/c/HDmg3QqwnTM René
Tu utilises NX2, un convertisseur pour Nikon dont rien ne garanti qu'il développe correctement les ARW. Il te faut le convertisseur de Sony.
Le problème n'est ps le mien. Je n'ai pas ouvert le RAW mais le JPG da ns Nikon Capture qui travaille aussi le JPG et les TIFF. J'ai seulement tenté cela face aux photos désastreuses de Benoit. Je croyait que lui avait le bon convertisseur, il semble que ce ne soit pa s le cas... Pour lui la question serait: par un jour ensoleillé normal, avec une s cène normalement colorée, un réglage d'usine de son APN et u ne prise de vue automatiquement normale son APN fait-il un jpg normal? Si non son APN est défectueux. Si oui je ne comprends pas pourquoi ses photos de la mire sont aussi fausse sauf grosse erreur de réglage lors de ces prises de vues. René
Le jeudi 12 avril 2018 03:07:55 UTC-4, Yves Tabouret a écrit :
Le Thu, 12 Apr 2018 08:57:09 +0200, René <jeanpasse@hotmail.com> a écrit:
> Le jeudi 12 avril 2018 00:59:26 UTC-4, GhostRaider a écrit :
>> Le 11/04/2018 à 17:01, Benoit a écrit :
>>
>> > Sinon, on me demande de tout faire en automatique j'ai donc un gris
>> > moyen un peu sombre (j'avais peut-être laissé le correcteu r sur -1).
>> > Quand j'ouvre le premier RAW dans GraphicConverter, j'ai ça :
>> >
>> <https://www.cjoint.com/doc/18_04/HDlo5Bk5ziQ_Capture2018-04-11-15.11. 38.JPG>
>> >
>> > C'est du brut de de fonderie. Rien, pas un ajustement, une correctio n
>> de
>> > l'optique... et surtout le fait qu'un capteur à deux verts par pixel.
>> Voilà ce que j'obtiens avec PICASA : avant/après.
>> https://www.cjoint.com/doc/18_04/HDme3qbg3r1_Benoit.jpg
>> Je ne suis pas entièrement satisfait. Le fond surtout est assez v ilain.
>
> Voyons voyons. Il suffit de définir le point blanc.
> https://www.cjoint.com/c/HDmg3QqwnTM
>
> René
Tu utilises NX2, un convertisseur pour Nikon dont rien ne garanti qu'il
développe correctement les ARW.
Il te faut le convertisseur de Sony.
Le problème n'est ps le mien. Je n'ai pas ouvert le RAW mais le JPG da ns Nikon Capture qui travaille aussi le JPG et les TIFF.
J'ai seulement tenté cela face aux photos désastreuses de Benoit. Je croyait que lui avait le bon convertisseur, il semble que ce ne soit pa s le cas...
Pour lui la question serait: par un jour ensoleillé normal, avec une s cène normalement colorée, un réglage d'usine de son APN et u ne prise de vue automatiquement normale son APN fait-il un jpg normal?
Si non son APN est défectueux.
Si oui je ne comprends pas pourquoi ses photos de la mire sont aussi fausse sauf grosse erreur de réglage lors de ces prises de vues.
Le jeudi 12 avril 2018 03:07:55 UTC-4, Yves Tabouret a écrit :
Le Thu, 12 Apr 2018 08:57:09 +0200, René a écrit:
Le jeudi 12 avril 2018 00:59:26 UTC-4, GhostRaider a écrit :
Le 11/04/2018 à 17:01, Benoit a écrit : > Sinon, on me demande de tout faire en automatique j'ai donc un gris > moyen un peu sombre (j'avais peut-être laissé le correcteu r sur -1). > Quand j'ouvre le premier RAW dans GraphicConverter, j'ai ça : > <https://www.cjoint.com/doc/18_04/HDlo5Bk5ziQ_Capture2018-04-11-15.11. 38.JPG> > > C'est du brut de de fonderie. Rien, pas un ajustement, une correctio n de > l'optique... et surtout le fait qu'un capteur à deux verts par pixel. Voilà ce que j'obtiens avec PICASA : avant/après. https://www.cjoint.com/doc/18_04/HDme3qbg3r1_Benoit.jpg Je ne suis pas entièrement satisfait. Le fond surtout est assez v ilain.
Voyons voyons. Il suffit de définir le point blanc. https://www.cjoint.com/c/HDmg3QqwnTM René
Tu utilises NX2, un convertisseur pour Nikon dont rien ne garanti qu'il développe correctement les ARW. Il te faut le convertisseur de Sony.
Le problème n'est ps le mien. Je n'ai pas ouvert le RAW mais le JPG da ns Nikon Capture qui travaille aussi le JPG et les TIFF. J'ai seulement tenté cela face aux photos désastreuses de Benoit. Je croyait que lui avait le bon convertisseur, il semble que ce ne soit pa s le cas... Pour lui la question serait: par un jour ensoleillé normal, avec une s cène normalement colorée, un réglage d'usine de son APN et u ne prise de vue automatiquement normale son APN fait-il un jpg normal? Si non son APN est défectueux. Si oui je ne comprends pas pourquoi ses photos de la mire sont aussi fausse sauf grosse erreur de réglage lors de ces prises de vues. René
