Le 7/4, j'ai publié la photo d'un xylocope pris à la va-vite en JPG et
malheureusement sur la photo cet insecte apparait quasiment tout noir
sur fond de fleurs blanches, sans aucun détail. Triste !
Une Dame qui fréquente le forum m'a houspillé : pris en RAW ce xylocope
aurait montré les subtiles gradations de sa carapace. Pourquoi, mais
POURQUOI, m'obstiné-je donc à photographier en JPG ? Ce n'est plus de la
bêtise, c'est du vice !
Alors, éperonné par ces reproches, j'ai pris toute une palanquée de
photos de fourmis en RAW+JPG. On allait bien voir si en RAW elle
montreraient quelque chose de plus qu'en JPG, ces fourmis toutes noires !
Et bien oui, les différences sont sensibles, même sur des fourmis.
Voici la comparaison à 100 % de la même photo en JPG à gauche et en RAW
à droite, sans aucune retouche. Les couleurs de l'abdomen en particulier
et les contrastes sur les pattes ne laissent aucun doute sur la
supériorité du RAW.
http://cjoint.com/12av/BDmua0ClBUi.htm
Dont acte.
en principe un jpeg doit utiliser un multiple de 16, c'est le cas de 4288, pas de 4310
Euh, je crois bien que la taille des blocs du Jpeg est 8x8...
qui n'est toujours pas un multiple de 4310 :-)
jdd
-- Pour nous montrer vos photos, créez votre album sur le compte frpm (demandez-nous login et mot de passe, on vous le donnera!) http://www.flickr.com/photos//
Le 25/04/2012 10:49, Tonton Th a écrit :
en principe un jpeg doit utiliser un multiple de 16, c'est le cas de
4288, pas de 4310
Euh, je crois bien que la taille des blocs du Jpeg est 8x8...
qui n'est toujours pas un multiple de 4310 :-)
jdd
--
Pour nous montrer vos photos, créez votre album sur le compte frpm
(demandez-nous login et mot de passe, on vous le donnera!)
http://www.flickr.com/photos/76105150@N07/
en principe un jpeg doit utiliser un multiple de 16, c'est le cas de 4288, pas de 4310
Euh, je crois bien que la taille des blocs du Jpeg est 8x8...
qui n'est toujours pas un multiple de 4310 :-)
jdd
-- Pour nous montrer vos photos, créez votre album sur le compte frpm (demandez-nous login et mot de passe, on vous le donnera!) http://www.flickr.com/photos//
Ghost-Rider
Le 25/04/2012 10:39, jdd a écrit :
Le 25/04/2012 09:47, Ghost-Rider a écrit :
Bizarre. Tous les Nef de mon D90 font 4310 x 2868, le jpg jumeau fait toujours 4288 x 2848 (comme les jpg "natifs") et la sauvegarde du Nef en Jpg par Picasa (enregistrer une copie) donne toujours 4310 x 2868 soit identique au Nef d'origine. Ceci sur des fichiers originaux, non retraités.
en principe un jpeg doit utiliser un multiple de 16, c'est le cas de 4288, pas de 4310
je ne sais pas comment c'est géré
Le jpg est tronqué par rapport au nef, c'est visible ici, jpg à gauche, nef à droite : http://cjoint.com/12av/BDzmnz0xgXl.htm Au passage, on voit que le traitement des aberrations chromatiques est des plus nécessaires.
-- Ghost Rider
Le 25/04/2012 10:39, jdd a écrit :
Le 25/04/2012 09:47, Ghost-Rider a écrit :
Bizarre.
Tous les Nef de mon D90 font 4310 x 2868, le jpg jumeau fait toujours
4288 x 2848 (comme les jpg "natifs") et la sauvegarde du Nef en Jpg
par Picasa (enregistrer une copie) donne toujours 4310 x 2868 soit
identique au Nef d'origine.
Ceci sur des fichiers originaux, non retraités.
en principe un jpeg doit utiliser un multiple de 16, c'est le cas de
4288, pas de 4310
je ne sais pas comment c'est géré
Le jpg est tronqué par rapport au nef, c'est visible ici, jpg à gauche,
nef à droite :
http://cjoint.com/12av/BDzmnz0xgXl.htm
Au passage, on voit que le traitement des aberrations chromatiques est
des plus nécessaires.
Bizarre. Tous les Nef de mon D90 font 4310 x 2868, le jpg jumeau fait toujours 4288 x 2848 (comme les jpg "natifs") et la sauvegarde du Nef en Jpg par Picasa (enregistrer une copie) donne toujours 4310 x 2868 soit identique au Nef d'origine. Ceci sur des fichiers originaux, non retraités.
en principe un jpeg doit utiliser un multiple de 16, c'est le cas de 4288, pas de 4310
je ne sais pas comment c'est géré
Le jpg est tronqué par rapport au nef, c'est visible ici, jpg à gauche, nef à droite : http://cjoint.com/12av/BDzmnz0xgXl.htm Au passage, on voit que le traitement des aberrations chromatiques est des plus nécessaires.
-- Ghost Rider
jdd
Le 25/04/2012 12:17, Ghost-Rider a écrit :
Le jpg est tronqué par rapport au nef, c'est visible ici, jpg à gauche, nef à droite :
redressement des perspectives (ou correction d'objectif)? ca réduit forcément l'image, pas forcément le nombre de pixel du fichier?
jdd
-- Pour nous montrer vos photos, créez votre album sur le compte frpm (demandez-nous login et mot de passe, on vous le donnera!) http://www.flickr.com/photos//
Le 25/04/2012 12:17, Ghost-Rider a écrit :
Le jpg est tronqué par rapport au nef, c'est visible ici, jpg à
gauche, nef à droite :
redressement des perspectives (ou correction d'objectif)? ca réduit
forcément l'image, pas forcément le nombre de pixel du fichier?
jdd
--
Pour nous montrer vos photos, créez votre album sur le compte frpm
(demandez-nous login et mot de passe, on vous le donnera!)
http://www.flickr.com/photos/76105150@N07/
Le jpg est tronqué par rapport au nef, c'est visible ici, jpg à gauche, nef à droite :
redressement des perspectives (ou correction d'objectif)? ca réduit forcément l'image, pas forcément le nombre de pixel du fichier?
jdd
-- Pour nous montrer vos photos, créez votre album sur le compte frpm (demandez-nous login et mot de passe, on vous le donnera!) http://www.flickr.com/photos//
Bour-Brown
René a écrit ( )
Corel et Picasa dérawtisent en créant plus de pixels que les autres logiciels.
Oui, c'est un effet connu.
En général il y a sur les capteurs plus de photosites que les pixels, parce que pour créer les pixels, on sert de photosites plus ou moins éloignés, donc faut de la marge.
Les dérawtiseurs sérieux conservent les spéc. du constructeur, les autres sont tout contents d'aller gratter quelques pixels comme si c'était important.
René a écrit
( 7Jydne6li_3evwrSnZ2dnUVZ_tadnZ2d@b2b2c.ca )
Corel et Picasa dérawtisent en créant plus de pixels que les autres
logiciels.
Oui, c'est un effet connu.
En général il y a sur les capteurs plus de photosites que les pixels, parce
que pour créer les pixels, on sert de photosites plus ou moins éloignés,
donc faut de la marge.
Les dérawtiseurs sérieux conservent les spéc. du constructeur, les autres
sont tout contents d'aller gratter quelques pixels comme si c'était
important.
Corel et Picasa dérawtisent en créant plus de pixels que les autres logiciels.
Oui, c'est un effet connu.
En général il y a sur les capteurs plus de photosites que les pixels, parce que pour créer les pixels, on sert de photosites plus ou moins éloignés, donc faut de la marge.
Les dérawtiseurs sérieux conservent les spéc. du constructeur, les autres sont tout contents d'aller gratter quelques pixels comme si c'était important.
markorki
René a écrit :
Pour mon JPG j'ai ré-enregistré successivement 4 fois en JPG qualité 0 avec Corel PhotoPaint, c'était le maximum ou minimum possible. Puis j'ai repris cette dernière image une fois avec Photoshop CS5 qui a encore réduit le poids d'environ la moitié. Rien de plus. Surprise. Je ne sais pas si PS en premier suivi de Corel aurait donné le même résultat. Avec Nikon Capture la réduction s'est arrêté à environ 260Ko.
Ta méthode est très discutable. Prends une photo en 10Mpix, un jpeg en qualité maxi en sortie de boitier te fera (sujet moyen, pas de sous-bois) un fichier entre 3 et 4 MO, mettons 3,5.
Prends ce jpg plus que correct, enregistre le en qualité 50 (je prends XnView qui va croissant de 0 à 100 du pire au meilleur, avec PSP ce serait le contraire, on fournit un taux de compression visé correspondant à un sujet moyen, en fait une valeur de seuil de différence colorimétrique). Tu ouvres cette nouvelle image et tu l'enregistres à > 50, par exemple 90, tu obtiendras un fichier beaucoup plus gros que le fichier enregistré à 50, mais ne contenant pas plus de détails, c'est ainsi. Enregistrer en haute qualité un fichier créé en plus basse qualité revient à stocker avec précision ce qui est des erreurs d'arrondi, autreement dit une "marge d'erreur". En multipliant de telles manips, on doit pouvoire en quelques dizaines de passe, obtenir des images très peu détaillées mais restant d'un volume important.
J'ai constaté cela un jour où j'ai réduit pour archivage tout un répertoire (il me restait l'original) avc un taux de compression énorme (mais en mode explorateur, on ne voit que les vignettes, on ne voit rien des dégats et les ai redimensionnes ensuiteavec une haute qualité: les réduites étaient du même ordre de taille, et évidemment pas terribles...
D4où l'importance de l'ergonomie: ça serait pas mal que le taux de compression soit toujours affiché en clair dès qu'on invoque un enregistrement (sous XnView, dans le dialogue d'enregistrement, il faut appeler le sous-dialogue "options", sinon on ne voit rien et on enregistre avec la dernière qualité utilisée ).
René a écrit :
Pour mon JPG j'ai ré-enregistré successivement 4 fois en JPG qualité 0
avec Corel PhotoPaint, c'était le maximum ou minimum possible. Puis j'ai
repris cette dernière image une fois avec Photoshop CS5 qui a encore
réduit le poids d'environ la moitié. Rien de plus. Surprise. Je ne sais
pas si PS en premier suivi de Corel aurait donné le même résultat. Avec
Nikon Capture la réduction s'est arrêté à environ 260Ko.
Ta méthode est très discutable.
Prends une photo en 10Mpix, un jpeg en qualité maxi en sortie de boitier
te fera (sujet moyen, pas de sous-bois) un fichier entre 3 et 4 MO,
mettons 3,5.
Prends ce jpg plus que correct, enregistre le en qualité 50 (je prends
XnView qui va croissant de 0 à 100 du pire au meilleur, avec PSP ce
serait le contraire, on fournit un taux de compression visé
correspondant à un sujet moyen, en fait une valeur de seuil de
différence colorimétrique).
Tu ouvres cette nouvelle image et tu l'enregistres à > 50, par exemple
90, tu obtiendras un fichier beaucoup plus gros que le fichier
enregistré à 50, mais ne contenant pas plus de détails, c'est ainsi.
Enregistrer en haute qualité un fichier créé en plus basse qualité
revient à stocker avec précision ce qui est des erreurs d'arrondi,
autreement dit une "marge d'erreur". En multipliant de telles manips, on
doit pouvoire en quelques dizaines de passe, obtenir des images très peu
détaillées mais restant d'un volume important.
J'ai constaté cela un jour où j'ai réduit pour archivage tout un
répertoire (il me restait l'original) avc un taux de compression énorme
(mais en mode explorateur, on ne voit que les vignettes, on ne voit rien
des dégats et les ai redimensionnes ensuiteavec une haute qualité: les
réduites étaient du même ordre de taille, et évidemment pas terribles...
D4où l'importance de l'ergonomie: ça serait pas mal que le taux de
compression soit toujours affiché en clair dès qu'on invoque un
enregistrement (sous XnView, dans le dialogue d'enregistrement, il faut
appeler le sous-dialogue "options", sinon on ne voit rien et on
enregistre avec la dernière qualité utilisée ).
Pour mon JPG j'ai ré-enregistré successivement 4 fois en JPG qualité 0 avec Corel PhotoPaint, c'était le maximum ou minimum possible. Puis j'ai repris cette dernière image une fois avec Photoshop CS5 qui a encore réduit le poids d'environ la moitié. Rien de plus. Surprise. Je ne sais pas si PS en premier suivi de Corel aurait donné le même résultat. Avec Nikon Capture la réduction s'est arrêté à environ 260Ko.
Ta méthode est très discutable. Prends une photo en 10Mpix, un jpeg en qualité maxi en sortie de boitier te fera (sujet moyen, pas de sous-bois) un fichier entre 3 et 4 MO, mettons 3,5.
Prends ce jpg plus que correct, enregistre le en qualité 50 (je prends XnView qui va croissant de 0 à 100 du pire au meilleur, avec PSP ce serait le contraire, on fournit un taux de compression visé correspondant à un sujet moyen, en fait une valeur de seuil de différence colorimétrique). Tu ouvres cette nouvelle image et tu l'enregistres à > 50, par exemple 90, tu obtiendras un fichier beaucoup plus gros que le fichier enregistré à 50, mais ne contenant pas plus de détails, c'est ainsi. Enregistrer en haute qualité un fichier créé en plus basse qualité revient à stocker avec précision ce qui est des erreurs d'arrondi, autreement dit une "marge d'erreur". En multipliant de telles manips, on doit pouvoire en quelques dizaines de passe, obtenir des images très peu détaillées mais restant d'un volume important.
J'ai constaté cela un jour où j'ai réduit pour archivage tout un répertoire (il me restait l'original) avc un taux de compression énorme (mais en mode explorateur, on ne voit que les vignettes, on ne voit rien des dégats et les ai redimensionnes ensuiteavec une haute qualité: les réduites étaient du même ordre de taille, et évidemment pas terribles...
D4où l'importance de l'ergonomie: ça serait pas mal que le taux de compression soit toujours affiché en clair dès qu'on invoque un enregistrement (sous XnView, dans le dialogue d'enregistrement, il faut appeler le sous-dialogue "options", sinon on ne voit rien et on enregistre avec la dernière qualité utilisée ).
jean-daniel dodin
Le 25/04/2012 17:09, markorki a écrit :
D'où l'importance de l'ergonomie: ça serait pas mal que le taux de compression soit toujours affiché en clair dès qu'on invoque un enregistrement
c'est le cas dans GIMP
jdd
Le 25/04/2012 17:09, markorki a écrit :
D'où l'importance de l'ergonomie: ça serait pas mal que le taux de
compression soit toujours affiché en clair dès qu'on invoque un
enregistrement
D'où l'importance de l'ergonomie: ça serait pas mal que le taux de compression soit toujours affiché en clair dès qu'on invoque un enregistrement
c'est le cas dans GIMP
jdd
markorki
Jacques L'helgoualc'h a écrit :
Le 25-04-2012, Tonton Th a écrit :
On 04/25/2012 10:39 AM, jdd wrote:
Tous les Nef de mon D90 font 4310 x 2868, le jpg jumeau fait toujours 4288 x 2848 (comme les jpg "natifs") et la sauvegarde du Nef en Jpg par Picasa (enregistrer une copie) donne toujours 4310 x 2868 soit identique au Nef d'origine. Ceci sur des fichiers originaux, non retraités.
en principe un jpeg doit utiliser un multiple de 16, c'est le cas de 4288, pas de 4310
Euh, je crois bien que la taille des blocs du Jpeg est 8x8...
4310 = 2 * 2155 ...
Non, la raison est quele RAW est toujours plus grand que le jpg, car un point dématricé à besoin de calcul sur les voisins, et il faut éviter l' "effet de bord" : soit on crée des points juste pour calculer, soit on "invente" des voisins identiques à ceux qui existent vraiment (symétriques/bord, plutôt, mais alors les coins subissent une erreur double).
Jacques L'helgoualc'h a écrit :
Le 25-04-2012, Tonton Th<tth@la.bas.invalid> a écrit :
On 04/25/2012 10:39 AM, jdd wrote:
Tous les Nef de mon D90 font 4310 x 2868, le jpg jumeau fait toujours
4288 x 2848 (comme les jpg "natifs") et la sauvegarde du Nef en Jpg
par Picasa (enregistrer une copie) donne toujours 4310 x 2868 soit
identique au Nef d'origine.
Ceci sur des fichiers originaux, non retraités.
en principe un jpeg doit utiliser un multiple de 16, c'est le cas de
4288, pas de 4310
Euh, je crois bien que la taille des blocs du Jpeg est 8x8...
4310 = 2 * 2155 ...
Non, la raison est quele RAW est toujours plus grand que le jpg, car un
point dématricé à besoin de calcul sur les voisins, et il faut éviter l'
"effet de bord" : soit on crée des points juste pour calculer, soit on
"invente" des voisins identiques à ceux qui existent vraiment
(symétriques/bord, plutôt, mais alors les coins subissent une erreur
double).
Tous les Nef de mon D90 font 4310 x 2868, le jpg jumeau fait toujours 4288 x 2848 (comme les jpg "natifs") et la sauvegarde du Nef en Jpg par Picasa (enregistrer une copie) donne toujours 4310 x 2868 soit identique au Nef d'origine. Ceci sur des fichiers originaux, non retraités.
en principe un jpeg doit utiliser un multiple de 16, c'est le cas de 4288, pas de 4310
Euh, je crois bien que la taille des blocs du Jpeg est 8x8...
4310 = 2 * 2155 ...
Non, la raison est quele RAW est toujours plus grand que le jpg, car un point dématricé à besoin de calcul sur les voisins, et il faut éviter l' "effet de bord" : soit on crée des points juste pour calculer, soit on "invente" des voisins identiques à ceux qui existent vraiment (symétriques/bord, plutôt, mais alors les coins subissent une erreur double).
Alf92
"Jean-Claude Ghislain" a écrit
je n'ai jamais constaté de différence entre les images construites à partir de mes RAW ou des DNG correspondants.
Même chose.
Pas même chose pour moi, mais ce sont des raw de Fuji et donc, comme d'habitude, une technologie un peu différente des autres.
c'est bien ce qui me semblait avec les tests faits sur les RAW du S100fs.
"Jean-Claude Ghislain" <jcg@invalid.com> a écrit
je n'ai jamais constaté de différence entre les images construites à
partir de mes RAW ou des DNG correspondants.
Même chose.
Pas même chose pour moi, mais ce sont des raw de Fuji et donc, comme
d'habitude, une technologie un peu différente des autres.
c'est bien ce qui me semblait avec les tests faits sur les RAW du S100fs.
