Morceaux choisis des commentaires de Nasim Mansurov
http://mansurovs.com/nikon-d800-high-iso-image-samples
181
(...) "I consider the D800 to be a revolutionary product. We have not
seen anything like this for many years from Nikon"
51
(...) Here is my take on the D800: I consider it to be a revolutionary
product, similar to how the D3 was when it came out. In fact, I consider
it more revolutionary than the D3, given that it costs only $3K. We have
not seen anything like this for a very long time.
35
(...)excellent AF module + metering + video from the D4
16
(...)its video output is pretty much the same as on the $6K Nikon D4
(except for very high ISO capabilities)
142
(...) The Nikon D800 is better than the D700 in every way, except for
the fps speed. So yes, the images from the D800 do make a difference in
image quality for portraiture…
52
(...)you are talking about JPEG image sizes ? In that case, yes, we
should see less noise on the smaller version of the JPEG. But why would
you let the camera do it? You can get much better results if you convert
RAW to a smaller JPEG. You do not even have to use Photoshop for that –
Lightroom’s export tool will do it for you automatically.
134
(...) by using a DX mode on an FX camera, you are cutting off more than
half of the resolution with no chance to get it back. Why not shoot in
FX and crop as much as you want later? Your field of view could then be
changed to whatever you want.
By using a DX mode, you are also eliminating good chances of removing
noise by down-sampling an image
182
(...) you would be trading one type of camera (sports and wildlife) for
another (landscapes, macro, portraits, etc). If you shoot in high ISOs,
then you will be disappointed with the D800 performance.
22
(...)
Why forget down-sampling ? That’s the only proper way to compare the
image output of the D800 to the D700. As I have already written many
times before, the Nikon D700 will surely beat the Nikon D800 at 100%
view. It is expected, again, because of the twice bigger pixel size. But
down-sampled to the same 12 MP resolution, we should be getting clean
images with lots of details and I believe we are, judging from the above
image samples.
77
(...)
I do a mix of landscapes and portraiture (weddings mostly) and I rarely
ever have to shoot above ISO 1600 (all landscapes are shot at ISO
100-200, unless I do not have a tripod with me). It is a different story
when I go shooting birds occasionally, where my Nikon D3s is
irreplaceable, but for everything else, I try to stay at low ISOs. So
the Nikon D800 would fit my needs perfectly, just like it does with many
others. As for your statement “just doesn’t seem right to buy a 36mp
sensor and then being somewhat forced to down-sample to get better image
quality” – you do not get better image quality by down-sampling, you
simply reduce noise when you have to, if the noise levels are
unacceptable to you. I do not expect to do much down-sampling with the
D800, since I will keep on shooting at lower ISOs. However, if I am
inside a church and I cannot use a flash, it is nice to know that I can
crank up ISO to higher values and still get decent results when the
image is down-sampled
Le 09/04/2012 12:25, YouDontNeedToKnowButItsNoëlle a écrit :
Capture NX n'a pas le bon goût de fonctionner sous Linux et c'est un goinfre en mémoire, ce qui risque de se sentir sur de grosses images de 36 MP.
hum... 36Mpix c'est quasi seulement le double de calcul que des images de compacts actuel.
pour des calculs courts (<0,5s), ce qui est le cas de 99% des effets de retouche, x2 ça n'affecte pas le boulot quotidien.
Ça suppose que les algorithmes soit liénaire en nombre de pixels. Et là je ne m'avancerait surtout pas à l'affirmer...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
YouDontNeedToKnowButItsNoëlle
Le 10/04/12 13:09, Stephane Legras-Decussy a écrit :
je retouche mes pano de 50MPix avec un vieux dualcore 1,6Ghz/ 1Go sous gimp... ça roule...
(certe capture gargantua NX n'est pas passé par chez moi)
Il ne s'agit pas de retoucher en certains points, mais surtout de faire le deraw à partir des données brutes de l'image. Beaucoup des modifications et traitements que permet capture NX à la base, et pour lesquelles il est irremplaçable si on est équipé Nikon, sont globales : on peut revenir sur les réglages de rendu, de WB bien sur mais aussi d'accentuation, de récupération du détail (d-lightning). Et là c'est fatal, si tu as une image 4 x plus grosse, tu mobilises 4 x fois plus de mémoire et de puissance de calcul (mais NX sait faire usage du parallélisme, pas comme mon CS3 ). Mais je crois volontiers que les programmeurs de Gimp, qui font ça parce qu'ils aiment ça, sont moins des tâches que ceux qui travaillent pour Nikon ou pire, les sbires de chez Adobe. Capture fait un usage considérable de la mémoire et du temps de calcul, mais au moins il se répartit sur les processeurs disponibles, et rend la mémoire. C'est un cochon savant par rapport à CS3 qui fait des erreurs d'allocation tout le temps, a des fuites, n'utilise qu'un processeur et pédale dans la semoule si il y a plusieurs grosses images ouvertes en même temps.
Noëlle Adam
Le 10/04/12 13:09, Stephane Legras-Decussy a écrit :
je retouche mes pano de 50MPix avec
un vieux dualcore 1,6Ghz/ 1Go sous gimp... ça roule...
(certe capture gargantua NX n'est pas passé par chez moi)
Il ne s'agit pas de retoucher en certains points, mais surtout de faire
le deraw à partir des données brutes de l'image.
Beaucoup des modifications et traitements que permet capture NX à la
base, et pour lesquelles il est irremplaçable si on est équipé Nikon,
sont globales : on peut revenir sur les réglages de rendu, de WB bien
sur mais aussi d'accentuation, de récupération du détail (d-lightning).
Et là c'est fatal, si tu as une image 4 x plus grosse, tu mobilises 4 x
fois plus de mémoire et de puissance de calcul (mais NX sait faire
usage du parallélisme, pas comme mon CS3 ). Mais je crois volontiers que
les programmeurs de Gimp, qui font ça parce qu'ils aiment ça, sont moins
des tâches que ceux qui travaillent pour Nikon ou pire, les sbires de
chez Adobe.
Capture fait un usage considérable de la mémoire et du temps de calcul,
mais au moins il se répartit sur les processeurs disponibles, et rend la
mémoire. C'est un cochon savant par rapport à CS3 qui fait des erreurs
d'allocation tout le temps, a des fuites, n'utilise qu'un processeur et
pédale dans la semoule si il y a plusieurs grosses images ouvertes en
même temps.
Le 10/04/12 13:09, Stephane Legras-Decussy a écrit :
je retouche mes pano de 50MPix avec un vieux dualcore 1,6Ghz/ 1Go sous gimp... ça roule...
(certe capture gargantua NX n'est pas passé par chez moi)
Il ne s'agit pas de retoucher en certains points, mais surtout de faire le deraw à partir des données brutes de l'image. Beaucoup des modifications et traitements que permet capture NX à la base, et pour lesquelles il est irremplaçable si on est équipé Nikon, sont globales : on peut revenir sur les réglages de rendu, de WB bien sur mais aussi d'accentuation, de récupération du détail (d-lightning). Et là c'est fatal, si tu as une image 4 x plus grosse, tu mobilises 4 x fois plus de mémoire et de puissance de calcul (mais NX sait faire usage du parallélisme, pas comme mon CS3 ). Mais je crois volontiers que les programmeurs de Gimp, qui font ça parce qu'ils aiment ça, sont moins des tâches que ceux qui travaillent pour Nikon ou pire, les sbires de chez Adobe. Capture fait un usage considérable de la mémoire et du temps de calcul, mais au moins il se répartit sur les processeurs disponibles, et rend la mémoire. C'est un cochon savant par rapport à CS3 qui fait des erreurs d'allocation tout le temps, a des fuites, n'utilise qu'un processeur et pédale dans la semoule si il y a plusieurs grosses images ouvertes en même temps.
Noëlle Adam
Stephane Legras-Decussy
Le 10/04/2012 16:01, Erwan David a écrit :
Ça suppose que les algorithmes soit liénaire en nombre de pixels. Et là je ne m'avancerait surtout pas à l'affirmer...
bien sur qu'ils le sont.
déja la plupart des algo sont 1 pixel dépendant.
quelque uns utilisent les 8-voisins
le flou utilisent n voisins en fonction de son rayon, mais reste linéairement proportionnel au nombre de pixel total ...
je ne vois aucun algo non-linéaire au nombre de pixel, une idée ?
Le 10/04/2012 16:01, Erwan David a écrit :
Ça suppose que les algorithmes soit liénaire en nombre de pixels. Et là
je ne m'avancerait surtout pas à l'affirmer...
bien sur qu'ils le sont.
déja la plupart des algo sont 1 pixel dépendant.
quelque uns utilisent les 8-voisins
le flou utilisent n voisins en fonction de son rayon,
mais reste linéairement proportionnel au nombre de pixel total ...
je ne vois aucun algo non-linéaire au nombre de pixel, une idée ?
Ça suppose que les algorithmes soit liénaire en nombre de pixels. Et là je ne m'avancerait surtout pas à l'affirmer...
bien sur qu'ils le sont.
déja la plupart des algo sont 1 pixel dépendant.
quelque uns utilisent les 8-voisins
le flou utilisent n voisins en fonction de son rayon, mais reste linéairement proportionnel au nombre de pixel total ...
je ne vois aucun algo non-linéaire au nombre de pixel, une idée ?
Stephane Legras-Decussy
Le 10/04/2012 16:06, YouDontNeedToKnowButItsNoëlle a écrit :
Il ne s'agit pas de retoucher en certains points, mais surtout de faire le deraw à partir des données brutes de l'image.
yep, mais le deraw c'est du local répété partout... il prend une petite zone du bayer, fait ça petit cuisine et sort un pixel RVB.
Beaucoup des modifications et traitements que permet capture NX à la base, et pour lesquelles il est irremplaçable si on est équipé Nikon, sont globales : on peut revenir sur les réglages de rendu, de WB bien sur mais aussi d'accentuation, de récupération du détail (d-lightning).
je vois pas bien comment il pourrait y avoir des trucs infaisables ailleurs, on peut convertir un raw nikon en DNG, on perd des possibilités ?
par exemple le D_lighting c'est rien que faire une petite bosse en bas de l'outil courbe ...
Et là c'est fatal, si tu as une image 4 x plus grosse, tu mobilises 4 x fois plus de mémoire et de puissance de calcul
yep, mais là on n'est qu'en 2x ...
en vidéo, la HD met à genou un ordi moyen car on passe directement à 4x le format précédent ... beuh ça rame en débit ... et en plus pour achever la bête, l'algo de décompression est beaucoup plus cpu-phage.
là on a bien morflé en video ... c'est pépère en photo :-)
Le 10/04/2012 16:06, YouDontNeedToKnowButItsNoëlle a écrit :
Il ne s'agit pas de retoucher en certains points, mais surtout de faire
le deraw à partir des données brutes de l'image.
yep, mais le deraw c'est du local répété partout... il prend une petite
zone du bayer, fait ça petit cuisine et sort un pixel RVB.
Beaucoup des modifications et traitements que permet capture NX à la
base, et pour lesquelles il est irremplaçable si on est équipé Nikon,
sont globales : on peut revenir sur les réglages de rendu, de WB bien
sur mais aussi d'accentuation, de récupération du détail (d-lightning).
je vois pas bien comment il pourrait y avoir des trucs infaisables
ailleurs, on peut convertir un raw nikon en DNG, on perd des possibilités ?
par exemple le D_lighting c'est rien que faire une petite bosse en bas
de l'outil courbe ...
Et là c'est fatal, si tu as une image 4 x plus grosse, tu mobilises 4 x
fois plus de mémoire et de puissance de calcul
yep, mais là on n'est qu'en 2x ...
en vidéo, la HD met à genou un ordi moyen car on passe directement à 4x
le format précédent ... beuh ça rame en débit ... et en plus pour
achever la bête, l'algo de décompression est beaucoup plus cpu-phage.
là on a bien morflé en video ... c'est pépère en photo :-)
Le 10/04/2012 16:06, YouDontNeedToKnowButItsNoëlle a écrit :
Il ne s'agit pas de retoucher en certains points, mais surtout de faire le deraw à partir des données brutes de l'image.
yep, mais le deraw c'est du local répété partout... il prend une petite zone du bayer, fait ça petit cuisine et sort un pixel RVB.
Beaucoup des modifications et traitements que permet capture NX à la base, et pour lesquelles il est irremplaçable si on est équipé Nikon, sont globales : on peut revenir sur les réglages de rendu, de WB bien sur mais aussi d'accentuation, de récupération du détail (d-lightning).
je vois pas bien comment il pourrait y avoir des trucs infaisables ailleurs, on peut convertir un raw nikon en DNG, on perd des possibilités ?
par exemple le D_lighting c'est rien que faire une petite bosse en bas de l'outil courbe ...
Et là c'est fatal, si tu as une image 4 x plus grosse, tu mobilises 4 x fois plus de mémoire et de puissance de calcul
yep, mais là on n'est qu'en 2x ...
en vidéo, la HD met à genou un ordi moyen car on passe directement à 4x le format précédent ... beuh ça rame en débit ... et en plus pour achever la bête, l'algo de décompression est beaucoup plus cpu-phage.
là on a bien morflé en video ... c'est pépère en photo :-)
Stephane Legras-Decussy
Le 08/04/2012 20:17, Elohan a écrit :
On viendra peut-être à des traitements automatiques poussés en Jpeg boîtier, mais ce n'est pas encore ça, même avec un haut de gamme comme le D800.
hum tu n'as pas vu les jpeg corrigés en interne dans le GF3 de BB. ?
c'est du délire... tu peux reposter ta cafetière BB stp ?
Le 08/04/2012 20:17, Elohan a écrit :
On viendra peut-être à des traitements automatiques poussés en Jpeg
boîtier, mais ce n'est pas encore ça, même avec un haut de gamme comme
le D800.
hum tu n'as pas vu les jpeg corrigés en interne dans le
GF3 de BB. ?
c'est du délire... tu peux reposter ta cafetière BB stp ?
On viendra peut-être à des traitements automatiques poussés en Jpeg boîtier, mais ce n'est pas encore ça, même avec un haut de gamme comme le D800.
hum tu n'as pas vu les jpeg corrigés en interne dans le GF3 de BB. ?
c'est du délire... tu peux reposter ta cafetière BB stp ?
Stephane Legras-Decussy
Le 09/04/2012 09:51, Yannick Patois a écrit :
J'y crois pas. Je veux bien imaginer qu'il dispose de circuits spécialisés plus optimisés DSP qu'un processeur généraliste, mais de là à équivaloir à un PC, y'a une marge. D'autant que le problème du boiter est double ici: il doit faire vite (temps réel) et il doit faire avec très peu de puissance (un ou deux watt au plus là ou un PC peut en mettre 100). Et on peut en ajouter qu'il n'y a pas quelques giga de RAM dispo pour les traitements (un GMIC chez moi bouffe rapidement 1Go de RAM), ne serait-ce que pour des raisons de conso électrique (ça consomme la RAM dynamique, et la statique est chère et moins dense).
Tu as des arguments pour ton affirmation?
pourtant un circuit spécialisé explose un PC et en consommant peanuts...
par exemple mon compact nikon décompresse du full HD et le sort en HDMI... chose impossible avec mon dual-core de 2009...
mieux encore, puisqu'il filme en fullHD, il est donc capable d'encoder en temps reel en H264 !
si on compare en terme de megaflop, mon compact enterre mon PC...
un PC c'est du calcul centralisé CPU, c'est très inefficace, on fait bien mieux avec un GPU (moteur graphique multicoeur).
pour l'anecdote, l'armée US vient de construire un des plus puissant ordi du monde en assemblant des... playstation 3.
J'y crois pas. Je veux bien imaginer qu'il dispose de circuits
spécialisés plus optimisés DSP qu'un processeur généraliste, mais de là
à équivaloir à un PC, y'a une marge. D'autant que le problème du boiter
est double ici: il doit faire vite (temps réel) et il doit faire avec
très peu de puissance (un ou deux watt au plus là ou un PC peut en
mettre 100). Et on peut en ajouter qu'il n'y a pas quelques giga de RAM
dispo pour les traitements (un GMIC chez moi bouffe rapidement 1Go de
RAM), ne serait-ce que pour des raisons de conso électrique (ça consomme
la RAM dynamique, et la statique est chère et moins dense).
Tu as des arguments pour ton affirmation?
pourtant un circuit spécialisé explose un PC et en consommant
peanuts...
par exemple mon compact nikon décompresse du full HD
et le sort en HDMI... chose impossible avec mon dual-core
de 2009...
mieux encore, puisqu'il filme en fullHD, il est donc capable
d'encoder en temps reel en H264 !
si on compare en terme de megaflop, mon compact enterre mon PC...
un PC c'est du calcul centralisé CPU, c'est très inefficace, on fait
bien mieux avec un GPU (moteur graphique multicoeur).
pour l'anecdote, l'armée US vient de construire un des plus puissant
ordi du monde en assemblant des... playstation 3.
J'y crois pas. Je veux bien imaginer qu'il dispose de circuits spécialisés plus optimisés DSP qu'un processeur généraliste, mais de là à équivaloir à un PC, y'a une marge. D'autant que le problème du boiter est double ici: il doit faire vite (temps réel) et il doit faire avec très peu de puissance (un ou deux watt au plus là ou un PC peut en mettre 100). Et on peut en ajouter qu'il n'y a pas quelques giga de RAM dispo pour les traitements (un GMIC chez moi bouffe rapidement 1Go de RAM), ne serait-ce que pour des raisons de conso électrique (ça consomme la RAM dynamique, et la statique est chère et moins dense).
Tu as des arguments pour ton affirmation?
pourtant un circuit spécialisé explose un PC et en consommant peanuts...
par exemple mon compact nikon décompresse du full HD et le sort en HDMI... chose impossible avec mon dual-core de 2009...
mieux encore, puisqu'il filme en fullHD, il est donc capable d'encoder en temps reel en H264 !
si on compare en terme de megaflop, mon compact enterre mon PC...
un PC c'est du calcul centralisé CPU, c'est très inefficace, on fait bien mieux avec un GPU (moteur graphique multicoeur).
pour l'anecdote, l'armée US vient de construire un des plus puissant ordi du monde en assemblant des... playstation 3.
Ici dans sa taille d'origine, ni recadrage ni correction de la géométrie ou des aberrations, simplement débruitage et accentuation : http://cjoint.com/data3/3DljtKqYrgB_ga_sld_g.jpg
Les corrections faites sont transparentes aussi bien avec les jpg qu'avec les raw (SilkyPix et Adobe Camera Raw).
Stephane Legras-Decussy a écrit
( jm2dhu$q2b$4@speranza.aioe.org )
c'est du délire... tu peux reposter ta cafetière BB stp ?
Ici dans sa taille d'origine, ni recadrage ni correction de la géométrie ou
des aberrations, simplement débruitage et accentuation :
http://cjoint.com/data3/3DljtKqYrgB_ga_sld_g.jpg
Les corrections faites sont transparentes aussi bien avec les jpg qu'avec
les raw (SilkyPix et Adobe Camera Raw).
Ici dans sa taille d'origine, ni recadrage ni correction de la géométrie ou des aberrations, simplement débruitage et accentuation : http://cjoint.com/data3/3DljtKqYrgB_ga_sld_g.jpg
Les corrections faites sont transparentes aussi bien avec les jpg qu'avec les raw (SilkyPix et Adobe Camera Raw).
pour du graphique, rapport qualité prix imbattable
J'en connais qui le font (des clusters de carte-mère de play-station) pas que pour du graphique, comme station expérimentale. Juste pour une question de prix.
pour du graphique, rapport qualité prix imbattable
J'en connais qui le font (des clusters de carte-mère de play-station)
pas que pour du graphique, comme station expérimentale. Juste pour une
question de prix.
pour du graphique, rapport qualité prix imbattable
J'en connais qui le font (des clusters de carte-mère de play-station) pas que pour du graphique, comme station expérimentale. Juste pour une question de prix.
Noëlle Adam
Charles Vassallo
Stephane Legras-Decussy a écrit :
Le 10/04/2012 16:01, Erwan David a écrit :
Ça suppose que les algorithmes soit liénaire en nombre de pixels. Et là je ne m'avancerait surtout pas à l'affirmer...
bien sur qu'ils le sont.
déja la plupart des algo sont 1 pixel dépendant.
quelque uns utilisent les 8-voisins
le flou utilisent n voisins en fonction de son rayon, mais reste linéairement proportionnel au nombre de pixel total ...
je ne vois aucun algo non-linéaire au nombre de pixel, une idée ?
Chaque fois qu'on introduit un seuil dans l'application du résultat, on introduit du non-linéaire, non ? Exemple dans Photoshop : accentuation, flou de surface. Dans le deuxième cas, le ralentissement des calculs est spectaculaire.
Charles
Stephane Legras-Decussy a écrit :
Le 10/04/2012 16:01, Erwan David a écrit :
Ça suppose que les algorithmes soit liénaire en nombre de pixels. Et là
je ne m'avancerait surtout pas à l'affirmer...
bien sur qu'ils le sont.
déja la plupart des algo sont 1 pixel dépendant.
quelque uns utilisent les 8-voisins
le flou utilisent n voisins en fonction de son rayon,
mais reste linéairement proportionnel au nombre de pixel total ...
je ne vois aucun algo non-linéaire au nombre de pixel, une idée ?
Chaque fois qu'on introduit un seuil dans l'application du résultat, on
introduit du non-linéaire, non ? Exemple dans Photoshop : accentuation,
flou de surface. Dans le deuxième cas, le ralentissement des calculs est
spectaculaire.
Ça suppose que les algorithmes soit liénaire en nombre de pixels. Et là je ne m'avancerait surtout pas à l'affirmer...
bien sur qu'ils le sont.
déja la plupart des algo sont 1 pixel dépendant.
quelque uns utilisent les 8-voisins
le flou utilisent n voisins en fonction de son rayon, mais reste linéairement proportionnel au nombre de pixel total ...
je ne vois aucun algo non-linéaire au nombre de pixel, une idée ?
Chaque fois qu'on introduit un seuil dans l'application du résultat, on introduit du non-linéaire, non ? Exemple dans Photoshop : accentuation, flou de surface. Dans le deuxième cas, le ralentissement des calculs est spectaculaire.
