Vu la longueur du fil précédent, je préfère en ouvrir un
autre, d'autant que je ne parle pas d'usage mais de nature.
je voudrais résumer les particularités _objectives_ (sans
rire) du raw. corrigez-moi si je me trompe.
* dans le fichier raw, chaque pixel du capteur est
enregistré séparément, les informations de _couleur_ sont
donc individualisées par pixel,
* la _profondeur_ de couleur (le nombre de nuances) est plus
grande que les minables 8 bits des fichiers jpg standard.
à priori, c'est tout, et ce n'est pas rien.
commentaire:
où trouver les infos autrement que par pifométrie?
les apn sont renommés pour faire une différence de poids
entre les couleurs selon la couleur (moins de pixels
verts??? moins de bits sur le vert ou sur une autre couleur???
quand on dit "8 mégapixels", c'est en faisant la somme
bleu+vert+rouge, donc avec en gros moins de 3Mpix par couleur?
un fichier raw devrait avoir une taille de plus de 8Mo (8Mo
x nombre de bits / 8), je viens d'en faire une, pour voir,
qui fait 6.7?
jdd
--
pour m'écrire, aller sur:
http://www.dodin.net
http://valerie.dodin.net
http://arvamip.free.fr
Quand les gens s'inquiètent des divers formats existants de RAW/NEF/etc. et craignent de ne pouvoir y accéder dans quelques anné es, je me demande pourquoi ils ne conserveraient pas la plus récente version du logiciel qui fait leur affaire pour traiter ces fichiers-là, avec leurs archives RAW.
A condition de pouvoir *toujours* le faire marcher dans le futur. Et c'est de cela dont parle Jean-Daniel. Ce que je préconise, c'est pour pallier à ce problème.
Et le paragraphe ci-haut peut en rassurer plus d'un, également. Mais personnellement j'aime mieux stocker un logiciel RAW qui marche + des RAW que de remplir des DVD avec des TIFF... Enfin, ça dépend des besoins!
Je fais comme toi, sauf que ufraw et dcraw étant en open-source, je ne me fais pas de souci.
-- Stephan Peccini PhotoNature : <URL:http://www.photonature.fr>
Le Sun, 9 Oct 2005 14:39:30 -0400
Quand les gens s'inquiètent des divers formats existants de
RAW/NEF/etc. et craignent de ne pouvoir y accéder dans quelques anné
es, je me demande pourquoi ils ne conserveraient pas la plus récente
version du logiciel qui fait leur affaire pour traiter ces
fichiers-là, avec leurs archives RAW.
A condition de pouvoir *toujours* le faire marcher dans le futur. Et
c'est de cela dont parle Jean-Daniel. Ce que je préconise, c'est pour
pallier à ce problème.
Et le paragraphe ci-haut peut en rassurer plus d'un, également.
Mais personnellement j'aime mieux stocker un logiciel RAW qui marche +
des RAW que de remplir des DVD avec des TIFF... Enfin, ça dépend des
besoins!
Je fais comme toi, sauf que ufraw et dcraw étant en open-source, je ne
me fais pas de souci.
--
Stephan Peccini
PhotoNature : <URL:http://www.photonature.fr>
Quand les gens s'inquiètent des divers formats existants de RAW/NEF/etc. et craignent de ne pouvoir y accéder dans quelques anné es, je me demande pourquoi ils ne conserveraient pas la plus récente version du logiciel qui fait leur affaire pour traiter ces fichiers-là, avec leurs archives RAW.
A condition de pouvoir *toujours* le faire marcher dans le futur. Et c'est de cela dont parle Jean-Daniel. Ce que je préconise, c'est pour pallier à ce problème.
Et le paragraphe ci-haut peut en rassurer plus d'un, également. Mais personnellement j'aime mieux stocker un logiciel RAW qui marche + des RAW que de remplir des DVD avec des TIFF... Enfin, ça dépend des besoins!
Je fais comme toi, sauf que ufraw et dcraw étant en open-source, je ne me fais pas de souci.
-- Stephan Peccini PhotoNature : <URL:http://www.photonature.fr>
Pierre Pallier
Hello, Stéphan Peccini a écrit dans <news:
Ce que je préconise, c'est pour pallier à ce problème.
pallier CE problème, grrrmmmmbllll. -- Pierre. Mes photographies : <URL:http://perso.wanadoo.fr/pierre.pallier> La FAQ de frp : <URL:http://frp.parisv.com> Les news avec 40tude Dialog : http://perso.wanadoo.fr/pierre.pallier/Dialog
Hello, Stéphan Peccini a écrit dans
<news:20051009205614.5ed0aa30.stephan@photonature.fr>
Ce que je préconise, c'est pour pallier à ce problème.
pallier CE problème, grrrmmmmbllll.
--
Pierre.
Mes photographies : <URL:http://perso.wanadoo.fr/pierre.pallier>
La FAQ de frp : <URL:http://frp.parisv.com>
Les news avec 40tude Dialog : http://perso.wanadoo.fr/pierre.pallier/Dialog
Ce que je préconise, c'est pour pallier à ce problème.
pallier CE problème, grrrmmmmbllll. -- Pierre. Mes photographies : <URL:http://perso.wanadoo.fr/pierre.pallier> La FAQ de frp : <URL:http://frp.parisv.com> Les news avec 40tude Dialog : http://perso.wanadoo.fr/pierre.pallier/Dialog
Stéphan Peccini
Le Sun, 9 Oct 2005 20:59:19 +0200
Hello, Stéphan Peccini a écrit dans <news:
Ce que je préconise, c'est pour pallier à ce problème.
pallier CE problème, grrrmmmmbllll.
Merci d'apporter ta pierre à l'édifice :-)
-- Stephan Peccini PhotoNature : <URL:http://www.photonature.fr>
Le Sun, 9 Oct 2005 20:59:19 +0200
Hello, Stéphan Peccini a écrit dans
<news:20051009205614.5ed0aa30.stephan@photonature.fr>
Ce que je préconise, c'est pour pallier à ce problème.
pallier CE problème, grrrmmmmbllll.
Merci d'apporter ta pierre à l'édifice :-)
--
Stephan Peccini
PhotoNature : <URL:http://www.photonature.fr>
Ce que je préconise, c'est pour pallier à ce problème.
pallier CE problème, grrrmmmmbllll.
Merci d'apporter ta pierre à l'édifice :-)
Il aura éclairé ce point d'orthographe !
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Stéphan Peccini <stephan@photonature.fr> wrote:
Le Sun, 9 Oct 2005 20:59:19 +0200
Hello, Stéphan Peccini a écrit dans
<news:20051009205614.5ed0aa30.stephan@photonature.fr>
Ce que je préconise, c'est pour pallier à ce problème.
pallier CE problème, grrrmmmmbllll.
Merci d'apporter ta pierre à l'édifice :-)
Il aura éclairé ce point d'orthographe !
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Ce que je préconise, c'est pour pallier à ce problème.
pallier CE problème, grrrmmmmbllll.
Merci d'apporter ta pierre à l'édifice :-)
Il aura éclairé ce point d'orthographe !
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Hi hi... Ma vengeance sera terrible. -- Pierre. Mes photographies : <URL:http://perso.wanadoo.fr/pierre.pallier> La FAQ de frp : <URL:http://frp.parisv.com> Les news avec 40tude Dialog : http://perso.wanadoo.fr/pierre.pallier/Dialog
Hello, Denis Vanneste a écrit dans
<news:Xns96EADA16EDB0Achienflou@chien.net>
Hi hi... Ma vengeance sera terrible.
--
Pierre.
Mes photographies : <URL:http://perso.wanadoo.fr/pierre.pallier>
La FAQ de frp : <URL:http://frp.parisv.com>
Les news avec 40tude Dialog : http://perso.wanadoo.fr/pierre.pallier/Dialog
Hi hi... Ma vengeance sera terrible. -- Pierre. Mes photographies : <URL:http://perso.wanadoo.fr/pierre.pallier> La FAQ de frp : <URL:http://frp.parisv.com> Les news avec 40tude Dialog : http://perso.wanadoo.fr/pierre.pallier/Dialog
M'enfin, Pierre, c'était il y a trois ans ! Aujourd'hui, je me suis retenu, hein... ;-)
-- Denis Vanneste
Pierre Pallier
Hello, Denis Vanneste a écrit dans <news:
M'enfin, Pierre, c'était il y a trois ans ! Aujourd'hui, je me suis retenu, hein... ;-)
Bon, d'accord. Je retiens mon bras vengeur. Faisons gaffe tout de même, sinon on va se faire traiter de conviviaux et la destruction de frpn va être proposée. -- Pierre. Mes photographies : <URL:http://perso.wanadoo.fr/pierre.pallier> La FAQ de frp : <URL:http://frp.parisv.com> Les news avec 40tude Dialog : http://perso.wanadoo.fr/pierre.pallier/Dialog
Hello, Denis Vanneste a écrit dans
<news:Xns96EADE0132362chienflou@chien.net>
M'enfin, Pierre, c'était il y a trois ans ! Aujourd'hui, je me suis
retenu, hein... ;-)
Bon, d'accord. Je retiens mon bras vengeur.
Faisons gaffe tout de même, sinon on va se faire traiter de conviviaux et la
destruction de frpn va être proposée.
--
Pierre.
Mes photographies : <URL:http://perso.wanadoo.fr/pierre.pallier>
La FAQ de frp : <URL:http://frp.parisv.com>
Les news avec 40tude Dialog : http://perso.wanadoo.fr/pierre.pallier/Dialog
M'enfin, Pierre, c'était il y a trois ans ! Aujourd'hui, je me suis retenu, hein... ;-)
Bon, d'accord. Je retiens mon bras vengeur. Faisons gaffe tout de même, sinon on va se faire traiter de conviviaux et la destruction de frpn va être proposée. -- Pierre. Mes photographies : <URL:http://perso.wanadoo.fr/pierre.pallier> La FAQ de frp : <URL:http://frp.parisv.com> Les news avec 40tude Dialog : http://perso.wanadoo.fr/pierre.pallier/Dialog
Laurent Martin
Ci-dessous, chaque ligne indique le nombre de niveaux codables pour chaque IL, en commençant par les hautes lumières. La deuxième colonne indique le nombre de niveaux en 12 bits gamma=1 (les RAW habituels), la troisième le nombre de niveau en 8 bits gamma=2.2 (le JPG).
C'est totalement théorique et en réalité parfaitement inexact...
Un gamma plus élevé entraine un contraste moyen inférieur et donc effectivement une dynamique plus large... Un peu comme en négatif couleur le surcroit de dynamique par rapport à la diapositive provient du fait que le négatif est un support intermédiaire qui se satisfait d'un faible contraste. Je ne suis pas d'accord pour donner un gamma à un Raw, puisque celui-ci n'est pas encore une image à proprement parler et qu'il nécessite l'application d'une interprétation logiciel, en particulier une "courbe" de restitution dont la pente moyenne constitue justement le gamma... Je compare le fichier Raw à une image latente sur le film, en modulant le developpement on peut intervenir sur l'image à produire et sa dynamique.
Lorsqu'un jpg est produit par le boitier, tous les traitements (qui seraient effectués par le derawtiseur en aval) sont effectués immédiatement. Le Jpg ne peut donc pas avoir plus de dynamique que l'image qui serait produit en aval depuis le fichier Raw : sauf cas particuliers il n'y a aucune raison non plus pour qu'il y en ait moins.
Là où je suis d'accord avec toi, c'est sur la confusion qu'il ne fait pas faire entre dynamique et profondeur en bits des couleurs. Par contre quand on a une grande profondeur dans les couleurs, on peut plus facilement travailler sur la courbe de restitution, en particulier pour diminuer le contraste local aux hautes lumières (point faible des capteurs) et ainsi gagner (un peu) en dynamique : c'est exactement ce que fait le Fuji S3.
Ci-dessous, chaque ligne indique le nombre de niveaux codables pour chaque
IL, en commençant par les hautes lumières. La deuxième colonne indique le
nombre de niveaux en 12 bits gamma=1 (les RAW habituels), la troisième le
nombre de niveau en 8 bits gamma=2.2 (le JPG).
C'est totalement théorique et en réalité parfaitement inexact...
Un gamma plus élevé entraine un contraste moyen inférieur et donc
effectivement une dynamique plus large...
Un peu comme en négatif couleur le surcroit de dynamique par rapport à la
diapositive provient du fait que le négatif est un support intermédiaire qui
se satisfait d'un faible contraste.
Je ne suis pas d'accord pour donner un gamma à un Raw, puisque celui-ci
n'est pas encore une image à proprement parler et qu'il nécessite
l'application d'une interprétation logiciel, en particulier une "courbe" de
restitution dont la pente moyenne constitue justement le gamma... Je compare
le fichier Raw à une image latente sur le film, en modulant le developpement
on peut intervenir sur l'image à produire et sa dynamique.
Lorsqu'un jpg est produit par le boitier, tous les traitements (qui seraient
effectués par le derawtiseur en aval) sont effectués immédiatement. Le Jpg
ne peut donc pas avoir plus de dynamique que l'image qui serait produit en
aval depuis le fichier Raw : sauf cas particuliers il n'y a aucune raison
non plus pour qu'il y en ait moins.
Là où je suis d'accord avec toi, c'est sur la confusion qu'il ne fait pas
faire entre dynamique et profondeur en bits des couleurs. Par contre quand
on a une grande profondeur dans les couleurs, on peut plus facilement
travailler sur la courbe de restitution, en particulier pour diminuer le
contraste local aux hautes lumières (point faible des capteurs) et ainsi
gagner (un peu) en dynamique : c'est exactement ce que fait le Fuji S3.
Ci-dessous, chaque ligne indique le nombre de niveaux codables pour chaque IL, en commençant par les hautes lumières. La deuxième colonne indique le nombre de niveaux en 12 bits gamma=1 (les RAW habituels), la troisième le nombre de niveau en 8 bits gamma=2.2 (le JPG).
C'est totalement théorique et en réalité parfaitement inexact...
Un gamma plus élevé entraine un contraste moyen inférieur et donc effectivement une dynamique plus large... Un peu comme en négatif couleur le surcroit de dynamique par rapport à la diapositive provient du fait que le négatif est un support intermédiaire qui se satisfait d'un faible contraste. Je ne suis pas d'accord pour donner un gamma à un Raw, puisque celui-ci n'est pas encore une image à proprement parler et qu'il nécessite l'application d'une interprétation logiciel, en particulier une "courbe" de restitution dont la pente moyenne constitue justement le gamma... Je compare le fichier Raw à une image latente sur le film, en modulant le developpement on peut intervenir sur l'image à produire et sa dynamique.
Lorsqu'un jpg est produit par le boitier, tous les traitements (qui seraient effectués par le derawtiseur en aval) sont effectués immédiatement. Le Jpg ne peut donc pas avoir plus de dynamique que l'image qui serait produit en aval depuis le fichier Raw : sauf cas particuliers il n'y a aucune raison non plus pour qu'il y en ait moins.
Là où je suis d'accord avec toi, c'est sur la confusion qu'il ne fait pas faire entre dynamique et profondeur en bits des couleurs. Par contre quand on a une grande profondeur dans les couleurs, on peut plus facilement travailler sur la courbe de restitution, en particulier pour diminuer le contraste local aux hautes lumières (point faible des capteurs) et ainsi gagner (un peu) en dynamique : c'est exactement ce que fait le Fuji S3.
K7lap
bonjour,
Je voudrais apporter qqs précisions car il y a qqs imprécisions dans le thread...
Le gamma=2.2 n'a pas été choisi par hasard. Il correspond à des critères de perception psycho-visuels.
Le gamma 2.2 correspond à l'afficheur. Au départ on utilisait les tubes CRT et leur courbe de transfert tension-luminosité correspond à un gamma de 2.2 (environ) Les caméras télévisions ont été obligées d'avoir un circuit de compression avec un gamma 0.6 ou 0.7 (l'inverse de 2.2... mais je n'ai pas de calculette sous la main...) Vous savez, ampli OP en fonctinnement LOG-EXP... Et tout cela tombait bien, car l'oeil n'est pas capable de juger une différence de luminosité de moins de 4 %... cela qui rend inefficace une linéarité avec gamma de 1. Il est donc logique de faire une compression lors du trasfert d'information (sur les ondes ou sur les disques durs) et comme la loi des 4% rend la réponse de l'oeil logarithmique (comme pour le son) un gamma de 0.7 est donc légitime ou judicieux.
Je pense que nos LCD doivent traiter ce gamma 2.2 pour offrir à l'oeil une transmission finale équivalente à 1 (G0.7 x G2.2 =1) Mais cela est tellement facile en numérique. (ou leurs drivers)
D'autres parts, il n'existe pas de transformation gamma dans la norme jpeg. le 0.7 doit se faire avant, et le 2.2 dans l'afficheur (ou son pilote)
La dynamique faite avec du G0.7 est agrandie. On peut par exemple avoir une dynamique de 4000 avec du 8 bits G0.7 (soit l'équivalent 12 bits) (chiffres estimatifs) mais la précision ne sera plus de 1/4000 mais de 4% quelquesoit la valeur... (chiffres donnés à titre d'exemple, il faudrait faire le calcul exact)
Concernant la précision des pixels en mode raw, 12 bits résultat de la conversion A/D. Il reste très intéressant de travailler en 16 bits, car quand on fait un calcul, il y a toujours des arrondis qui surviennent... Le 16 bits permet de travailler avec 12 bits et 4 bits après la virgule (fictivement, suite à padding et masking) Il y aura donc beaucoup moins d'erreur d'arrondis (et donc une précision amméliorée de 4 bits = 6% après la virgule)
Les algorithmes Hard jpeg (8 bits) utilisent pour cela des multiplieurs 10 (les vieux) , 12 ou 16 bits et troncquent à la fin (L'utilisation d'IP permettait de ne pas rester en 16 bits, mais maintenant le silicium ne limite plus le jpeg)
Pour rester honnète, j'ai toujours un doute concernant la mémorisation des intensités lumineuses dans les fichiers images. Y-a-t il vraiment une compression (dynamique) correspondant au G0.7 ou est-ce vraiment une loi linéaire (// à celle de l'oeil)
Les CCD/CMOS ont un gamma de 1 (ou 0.95)
Oups! déjà midi!
MilaP
bonjour,
Je voudrais apporter qqs précisions car il y a qqs imprécisions dans le
thread...
Le gamma=2.2 n'a pas été choisi par hasard. Il correspond à des
critères de perception psycho-visuels.
Le gamma 2.2 correspond à l'afficheur. Au départ on utilisait les tubes CRT
et leur courbe de transfert tension-luminosité correspond à un gamma de 2.2
(environ)
Les caméras télévisions ont été obligées d'avoir un circuit de compression
avec un gamma 0.6 ou 0.7 (l'inverse de 2.2... mais je n'ai pas de
calculette sous la main...) Vous savez, ampli OP en fonctinnement
LOG-EXP...
Et tout cela tombait bien, car l'oeil n'est pas capable de juger une
différence de luminosité de moins de 4 %... cela qui rend inefficace une
linéarité avec gamma de 1.
Il est donc logique de faire une compression lors du trasfert d'information
(sur les ondes ou sur les disques durs) et comme la loi des 4% rend la
réponse de l'oeil logarithmique (comme pour le son) un gamma de 0.7 est donc
légitime ou judicieux.
Je pense que nos LCD doivent traiter ce gamma 2.2 pour offrir à l'oeil une
transmission finale équivalente à 1 (G0.7 x G2.2 =1) Mais cela est
tellement facile en numérique. (ou leurs drivers)
D'autres parts, il n'existe pas de transformation gamma dans la norme jpeg.
le 0.7 doit se faire avant, et le 2.2 dans l'afficheur (ou son pilote)
La dynamique faite avec du G0.7 est agrandie. On peut par exemple avoir une
dynamique de 4000 avec du 8 bits G0.7 (soit l'équivalent 12 bits)
(chiffres estimatifs) mais la précision ne sera plus de 1/4000 mais de 4%
quelquesoit la valeur... (chiffres donnés à titre d'exemple, il faudrait
faire le calcul exact)
Concernant la précision des pixels en mode raw, 12 bits résultat de la
conversion A/D. Il reste très intéressant de travailler en 16 bits, car
quand on fait un calcul, il y a toujours des arrondis qui surviennent... Le
16 bits permet de travailler avec 12 bits et 4 bits après la virgule
(fictivement, suite à padding et masking) Il y aura donc beaucoup moins
d'erreur d'arrondis (et donc une précision amméliorée de 4 bits = 6% après
la virgule)
Les algorithmes Hard jpeg (8 bits) utilisent pour cela des multiplieurs 10
(les vieux) , 12 ou 16 bits et troncquent à la fin (L'utilisation d'IP
permettait de ne pas rester en 16 bits, mais maintenant le silicium ne
limite plus le jpeg)
Pour rester honnète, j'ai toujours un doute concernant la mémorisation des
intensités lumineuses dans les fichiers images. Y-a-t il vraiment une
compression (dynamique) correspondant au G0.7 ou est-ce vraiment une loi
linéaire (// à celle de l'oeil)
Je voudrais apporter qqs précisions car il y a qqs imprécisions dans le thread...
Le gamma=2.2 n'a pas été choisi par hasard. Il correspond à des critères de perception psycho-visuels.
Le gamma 2.2 correspond à l'afficheur. Au départ on utilisait les tubes CRT et leur courbe de transfert tension-luminosité correspond à un gamma de 2.2 (environ) Les caméras télévisions ont été obligées d'avoir un circuit de compression avec un gamma 0.6 ou 0.7 (l'inverse de 2.2... mais je n'ai pas de calculette sous la main...) Vous savez, ampli OP en fonctinnement LOG-EXP... Et tout cela tombait bien, car l'oeil n'est pas capable de juger une différence de luminosité de moins de 4 %... cela qui rend inefficace une linéarité avec gamma de 1. Il est donc logique de faire une compression lors du trasfert d'information (sur les ondes ou sur les disques durs) et comme la loi des 4% rend la réponse de l'oeil logarithmique (comme pour le son) un gamma de 0.7 est donc légitime ou judicieux.
Je pense que nos LCD doivent traiter ce gamma 2.2 pour offrir à l'oeil une transmission finale équivalente à 1 (G0.7 x G2.2 =1) Mais cela est tellement facile en numérique. (ou leurs drivers)
D'autres parts, il n'existe pas de transformation gamma dans la norme jpeg. le 0.7 doit se faire avant, et le 2.2 dans l'afficheur (ou son pilote)
La dynamique faite avec du G0.7 est agrandie. On peut par exemple avoir une dynamique de 4000 avec du 8 bits G0.7 (soit l'équivalent 12 bits) (chiffres estimatifs) mais la précision ne sera plus de 1/4000 mais de 4% quelquesoit la valeur... (chiffres donnés à titre d'exemple, il faudrait faire le calcul exact)
Concernant la précision des pixels en mode raw, 12 bits résultat de la conversion A/D. Il reste très intéressant de travailler en 16 bits, car quand on fait un calcul, il y a toujours des arrondis qui surviennent... Le 16 bits permet de travailler avec 12 bits et 4 bits après la virgule (fictivement, suite à padding et masking) Il y aura donc beaucoup moins d'erreur d'arrondis (et donc une précision amméliorée de 4 bits = 6% après la virgule)
Les algorithmes Hard jpeg (8 bits) utilisent pour cela des multiplieurs 10 (les vieux) , 12 ou 16 bits et troncquent à la fin (L'utilisation d'IP permettait de ne pas rester en 16 bits, mais maintenant le silicium ne limite plus le jpeg)
Pour rester honnète, j'ai toujours un doute concernant la mémorisation des intensités lumineuses dans les fichiers images. Y-a-t il vraiment une compression (dynamique) correspondant au G0.7 ou est-ce vraiment une loi linéaire (// à celle de l'oeil)
