dès que tu quittes les données brutes pour le RGB tu as figé quelque chose.
et bien non justement. tu n'a rien figé.
tu apliques les formules inverse et tu retrouve ton raw.
Ah non ! Il n'y a pas toujours de "formules inverses". Souvenez-vous de vos cours de math (bijection, injection, surjection). Et ici c'est le cas. Le passage du raw au RGB fait perdre de l'information.
(pour info, j'ai un DEA de traitement du signal, spécialité visionnique, alors je connais un peu...)
raison de plus pour réviser. :)
-- F.J.
Stephane Legras-Decussy wrote:
"Jean-Pierre Roche" <jpierreroche@sanspub.invalid> a écrit dans le message
dès que tu quittes les données brutes pour le RGB tu as figé quelque chose.
et bien non justement. tu n'a rien figé.
tu apliques les formules inverse et tu retrouve ton raw.
Ah non !
Il n'y a pas toujours de "formules inverses". Souvenez-vous
de vos cours de math (bijection, injection, surjection).
Et ici c'est le cas. Le passage du raw au RGB fait perdre
de l'information.
(pour info, j'ai un DEA de traitement du signal, spécialité
visionnique, alors je connais un peu...)
dès que tu quittes les données brutes pour le RGB tu as figé quelque chose.
et bien non justement. tu n'a rien figé.
tu apliques les formules inverse et tu retrouve ton raw.
Ah non ! Il n'y a pas toujours de "formules inverses". Souvenez-vous de vos cours de math (bijection, injection, surjection). Et ici c'est le cas. Le passage du raw au RGB fait perdre de l'information.
(pour info, j'ai un DEA de traitement du signal, spécialité visionnique, alors je connais un peu...)
raison de plus pour réviser. :)
-- F.J.
DoLooP
=?ISO-8859-15?Q?Stéphan?= Peccini wrote in news::
Mais je suis d'accord avec ce que tu dis et je comprends très bien l'intérêt d'avoir plus de barreaux pour avoir une meilleure image (moins d'aplats) mais pas pour le min/max de lumière :-(
Depuis le début, personnellement je résonne en terme de différence: (max)- (min) en pensant "longueur" dynamique, donc distance (ce qui n'est PAS la définition de la dynamique). Dans ce cas, l'echantillonage ne change pas la distance des points max et min du signal d'origine, donc ne change pas la longueur de la plage encodable.
La dynamique étant en réalité un rapport (max)/(min), le nombre de "barreaux" perdu du coté min par sous échantillonage influent énormément le résultat de la division. Donc la dynamique d'un echantillonage 8 bits est bien 256 fois plus faible qu'un echantillonage 16 bits.
Si cette fois, j'ai bien compris :°)
-- Grand Vé ! DoLooP
=?ISO-8859-15?Q?Stéphan?= Peccini <stephan@photonature.fr> wrote in
news:1s6ai3-g0h.ln1@photonature.fr:
Mais je suis d'accord avec ce que tu dis et je comprends très bien
l'intérêt d'avoir plus de barreaux pour avoir une meilleure image
(moins d'aplats) mais pas pour le min/max de lumière :-(
Depuis le début, personnellement je résonne en terme de différence: (max)-
(min) en pensant "longueur" dynamique, donc distance (ce qui n'est PAS la
définition de la dynamique). Dans ce cas, l'echantillonage ne change pas la
distance des points max et min du signal d'origine, donc ne change pas la
longueur de la plage encodable.
La dynamique étant en réalité un rapport (max)/(min), le nombre de
"barreaux" perdu du coté min par sous échantillonage influent énormément le
résultat de la division. Donc la dynamique d'un echantillonage 8 bits est
bien 256 fois plus faible qu'un echantillonage 16 bits.
Mais je suis d'accord avec ce que tu dis et je comprends très bien l'intérêt d'avoir plus de barreaux pour avoir une meilleure image (moins d'aplats) mais pas pour le min/max de lumière :-(
Depuis le début, personnellement je résonne en terme de différence: (max)- (min) en pensant "longueur" dynamique, donc distance (ce qui n'est PAS la définition de la dynamique). Dans ce cas, l'echantillonage ne change pas la distance des points max et min du signal d'origine, donc ne change pas la longueur de la plage encodable.
La dynamique étant en réalité un rapport (max)/(min), le nombre de "barreaux" perdu du coté min par sous échantillonage influent énormément le résultat de la division. Donc la dynamique d'un echantillonage 8 bits est bien 256 fois plus faible qu'un echantillonage 16 bits.
Si cette fois, j'ai bien compris :°)
-- Grand Vé ! DoLooP
Pierre Pallier
Hello, Stéphan Peccini a écrit dans <news:
Mais je suis d'accord avec ce que tu dis et je comprends très bien l'intérêt d'avoir plus de barreaux pour avoir une meilleure image (moins d'aplats) mais pas pour le min/max de lumière :-(
En effet, pour moi ça ce sont deux notions séparées et relativement indépendantes.
De toutes façons, pour moi un CAN convertit une plage de tension donnée, et généralement fixe, genre 0-10V. Donc, toujours dans mon idée, si un capteur CCD a un mauvais rendement quantique, il va falloir "booster" le signal via un amplificateur, avant de l'appliquer au CAN. Avec tous les désagréments possibles que ça implique.
Avec un capteur possédant un bon rendement quantique, et une bonne surface utile de pixels, la qualité avant conversion sera meilleure.
J'ai trouvé un article qui semble parler plutôt bien de CCD : <URL:http://www.jautomatise.com/articles/j27p6675.pdf> (<300 Ko) -- 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:1s6ai3-g0h.ln1@photonature.fr>
Mais je suis d'accord avec ce que tu dis et je comprends très bien l'intérêt
d'avoir plus de barreaux pour avoir une meilleure image (moins d'aplats)
mais pas pour le min/max de lumière :-(
En effet, pour moi ça ce sont deux notions séparées et relativement
indépendantes.
De toutes façons, pour moi un CAN convertit une plage de tension donnée, et
généralement fixe, genre 0-10V. Donc, toujours dans mon idée, si un capteur
CCD a un mauvais rendement quantique, il va falloir "booster" le signal via
un amplificateur, avant de l'appliquer au CAN. Avec tous les désagréments
possibles que ça implique.
Avec un capteur possédant un bon rendement quantique, et une bonne surface
utile de pixels, la qualité avant conversion sera meilleure.
J'ai trouvé un article qui semble parler plutôt bien de CCD :
<URL:http://www.jautomatise.com/articles/j27p6675.pdf> (<300 Ko)
--
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
Mais je suis d'accord avec ce que tu dis et je comprends très bien l'intérêt d'avoir plus de barreaux pour avoir une meilleure image (moins d'aplats) mais pas pour le min/max de lumière :-(
En effet, pour moi ça ce sont deux notions séparées et relativement indépendantes.
De toutes façons, pour moi un CAN convertit une plage de tension donnée, et généralement fixe, genre 0-10V. Donc, toujours dans mon idée, si un capteur CCD a un mauvais rendement quantique, il va falloir "booster" le signal via un amplificateur, avant de l'appliquer au CAN. Avec tous les désagréments possibles que ça implique.
Avec un capteur possédant un bon rendement quantique, et une bonne surface utile de pixels, la qualité avant conversion sera meilleure.
J'ai trouvé un article qui semble parler plutôt bien de CCD : <URL:http://www.jautomatise.com/articles/j27p6675.pdf> (<300 Ko) -- 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
Jean-Pierre Gallou wrote:
mais ça ne change strictement de faire un passage raw -> RGB sans la moindre correction et *après* de corriger ce RGB.
Mais ça n'a aucun intérêt pour cause de taille de fichier. Le simple dématriçage multiplie par 3 la quantité de données sans ajouter aucune information.
Si, l'intérêt est l'indépendance du format tiff, alors que les raw ...
-- Stephan Peccini PhotoNature : <URL:http://www.photonature.fr>
Jean-Pierre Gallou wrote:
mais ça ne change strictement de faire un passage
raw -> RGB sans la moindre correction et *après*
de corriger ce RGB.
Mais ça n'a aucun intérêt pour cause de taille de fichier. Le simple
dématriçage multiplie par 3 la quantité de données sans ajouter aucune
information.
Si, l'intérêt est l'indépendance du format tiff, alors que les raw ...
--
Stephan Peccini
PhotoNature : <URL:http://www.photonature.fr>
mais ça ne change strictement de faire un passage raw -> RGB sans la moindre correction et *après* de corriger ce RGB.
Mais ça n'a aucun intérêt pour cause de taille de fichier. Le simple dématriçage multiplie par 3 la quantité de données sans ajouter aucune information.
Si, l'intérêt est l'indépendance du format tiff, alors que les raw ...
-- Stephan Peccini PhotoNature : <URL:http://www.photonature.fr>
Stephane Legras-Decussy
"Francois Jouve" a écrit dans le message de news: 44527811$0$12959$
Il n'y a pas toujours de "formules inverses". Souvenez-vous de vos cours de math (bijection, injection, surjection).
oui bien sur mais je serais bien etonné que pour ce cas précis, il y n'y ai pas d'inversion possible...
ça ne change pas le fond du problème qu'un tiff 12 bit (hypothetique) est bien mieux qu'un raw 12 bit, mais si je me gourre sur l'inversion, je reconnaitrai mon erreur sur ce point...
j'enquête...
raison de plus pour réviser. :)
ça fait 10 ans, hein... ;-)
"Francois Jouve" <francois.jouve_HALTEAUSPAM@polytechnique.fr> a écrit dans
le message de news: 44527811$0$12959$79c14f64@nan-newsreader-05.noos.net...
Il n'y a pas toujours de "formules inverses". Souvenez-vous
de vos cours de math (bijection, injection, surjection).
oui bien sur mais je serais bien etonné
que pour ce cas précis, il y n'y ai pas d'inversion possible...
ça ne change pas le fond du problème
qu'un tiff 12 bit (hypothetique) est bien mieux
qu'un raw 12 bit,
mais si je me gourre sur l'inversion, je reconnaitrai
mon erreur sur ce point...
"Francois Jouve" a écrit dans le message de news: 44527811$0$12959$
Il n'y a pas toujours de "formules inverses". Souvenez-vous de vos cours de math (bijection, injection, surjection).
oui bien sur mais je serais bien etonné que pour ce cas précis, il y n'y ai pas d'inversion possible...
ça ne change pas le fond du problème qu'un tiff 12 bit (hypothetique) est bien mieux qu'un raw 12 bit, mais si je me gourre sur l'inversion, je reconnaitrai mon erreur sur ce point...
j'enquête...
raison de plus pour réviser. :)
ça fait 10 ans, hein... ;-)
Stephane Legras-Decussy
"Jean-Pierre Gallou" a écrit dans le message de news:
Mais ça n'a aucun intérêt pour cause de taille de fichier. Le simple dématriçage multiplie par 3 la quantité de données sans ajouter aucune information.
OUI ! pour cause de taille de fichier uniquement.
JPR semble bien convaincu qu'il y a autre chose de plus fort que ça dans le raw...
"Jean-Pierre Gallou" <gallou@reply.to.invalid> a écrit dans le message de
news: mn.e5377d648f7f38bf.23168@reply.to.invalid...
Mais ça n'a aucun intérêt pour cause de taille de fichier. Le simple
dématriçage multiplie par 3 la quantité de données sans ajouter aucune
information.
OUI ! pour cause de taille de fichier uniquement.
JPR semble bien convaincu qu'il y a autre chose de
plus fort que ça dans le raw...
"Jean-Pierre Gallou" a écrit dans le message de news:
Mais ça n'a aucun intérêt pour cause de taille de fichier. Le simple dématriçage multiplie par 3 la quantité de données sans ajouter aucune information.
OUI ! pour cause de taille de fichier uniquement.
JPR semble bien convaincu qu'il y a autre chose de plus fort que ça dans le raw...
Jean-Pierre Gallou
Il n'y a pas toujours de "formules inverses". Souvenez-vous de vos cours de math (bijection, injection, surjection). Et ici c'est le cas. Le passage du raw au RGB fait perdre de l'information.
A mon avis, ça dépend quel RGB. Sur 8 bits, c'est sûr, du 16 bits dans un espace de couleur linéaire, j'en doute.
-- Ceci est une signature automatique de MesNews. Site : http://www.mesnews.net
Il n'y a pas toujours de "formules inverses". Souvenez-vous
de vos cours de math (bijection, injection, surjection).
Et ici c'est le cas. Le passage du raw au RGB fait perdre
de l'information.
A mon avis, ça dépend quel RGB. Sur 8 bits, c'est sûr, du 16 bits dans
un espace de couleur linéaire, j'en doute.
--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net
Il n'y a pas toujours de "formules inverses". Souvenez-vous de vos cours de math (bijection, injection, surjection). Et ici c'est le cas. Le passage du raw au RGB fait perdre de l'information.
A mon avis, ça dépend quel RGB. Sur 8 bits, c'est sûr, du 16 bits dans un espace de couleur linéaire, j'en doute.
-- Ceci est une signature automatique de MesNews. Site : http://www.mesnews.net
Jean-Pierre Gallou
Si, l'intérêt est l'indépendance du format tiff, alors que les raw ...
Pour l'indépendance des raw, il y a openraw. Quand à tiff, il existe tellement de possibilités qu'aucun programme ne sait les lire tous. D'ailleurs savez-vous que les raw sont en fait des tiff un peu particuliers ? Le format tiff permet toutes sortes de fantaisies, et les formats raw Canon et Nikon dérivent de tiff. Le problème est qu'ils utilisent des tags spécifiques, des formats binaires pour le codage, etc. Ce sont donc des tiffs illisibles par des programmes tiff standard. Voici ce que dit la commande "file" qui sur Unix/Linux donne le type d'un fichier:
-- Ceci est une signature automatique de MesNews. Site : http://www.mesnews.net
Si, l'intérêt est l'indépendance du format tiff, alors que les raw ...
Pour l'indépendance des raw, il y a openraw. Quand à tiff, il existe
tellement de possibilités qu'aucun programme ne sait les lire tous.
D'ailleurs savez-vous que les raw sont en fait des tiff un peu
particuliers ? Le format tiff permet toutes sortes de fantaisies, et
les formats raw Canon et Nikon dérivent de tiff. Le problème est qu'ils
utilisent des tags spécifiques, des formats binaires pour le codage,
etc. Ce sont donc des tiffs illisibles par des programmes tiff
standard.
Voici ce que dit la commande "file" qui sur Unix/Linux donne le type
d'un fichier:
Si, l'intérêt est l'indépendance du format tiff, alors que les raw ...
Pour l'indépendance des raw, il y a openraw. Quand à tiff, il existe tellement de possibilités qu'aucun programme ne sait les lire tous. D'ailleurs savez-vous que les raw sont en fait des tiff un peu particuliers ? Le format tiff permet toutes sortes de fantaisies, et les formats raw Canon et Nikon dérivent de tiff. Le problème est qu'ils utilisent des tags spécifiques, des formats binaires pour le codage, etc. Ce sont donc des tiffs illisibles par des programmes tiff standard. Voici ce que dit la commande "file" qui sur Unix/Linux donne le type d'un fichier:
-- Ceci est une signature automatique de MesNews. Site : http://www.mesnews.net
Jean-Claude Ghislain
dès que tu quittes les données brutes pour le RGB tu as figé quelque chose.
et bien non justement. tu n'a rien figé. tu apliques les formules inverse et tu retrouve ton raw.
Avec un JPEG bien compressé ça va être dur...
tu dis "en mieux " alors que justement le raw n'existe que parce que les capteurs sont pas foutus pour des raisons de coût de sortir un RGB par pixel !!!
Le Foveon, mais ce n'est pas une entière réussite.
Alors fait moi passer un tiff de 2500 K à 9000 K d'un clic de souris qu'on rigole...
rien de plus facile, c'est qu'un *preset* de coef RVB à appliquer...
Pas si facile qu'il n'y paraît. On s'était amusé à faire l'expérience sur frpln et si pour de petites dérives cela fonctionne aussi bien avec le fichier RGB, pour de grosses dérives pas vraiment moyen d'avoir aussi bien avec un RGB 8/bits couche. Tu me diras qu'en 16/bits couche ça irait mieux, mais les APN courants ne sortent pas du RGB 16 bits/couche, la Raw garde pour l'instant toute sa supériorité en vue d'un post-traitement.
eclairage tungstene, tu baisses le rouge,
Il faut plutôt aller vers le rouge orangé, si tu ne t'occupes que du rouge tu ne vas pas vraiment corriger une dominante tungstène. Il va nous falloir baisser le rouge et monter le bleu ou si tu préfères, retirer du jaune et ajouter du cyan.
-- Jean-Claude Ghislain www.grimart.com
dès que tu quittes les données brutes pour le RGB tu as figé quelque
chose.
et bien non justement. tu n'a rien figé.
tu apliques les formules inverse et tu retrouve ton raw.
Avec un JPEG bien compressé ça va être dur...
tu dis "en mieux " alors que justement le raw n'existe que parce
que les capteurs sont pas foutus pour des raisons de coût
de sortir un RGB par pixel !!!
Le Foveon, mais ce n'est pas une entière réussite.
Alors fait moi passer un tiff de 2500 K à 9000 K d'un clic de souris
qu'on rigole...
rien de plus facile,
c'est qu'un *preset* de coef RVB à appliquer...
Pas si facile qu'il n'y paraît. On s'était amusé à faire l'expérience
sur frpln et si pour de petites dérives cela fonctionne aussi bien avec
le fichier RGB, pour de grosses dérives pas vraiment moyen d'avoir aussi
bien avec un RGB 8/bits couche. Tu me diras qu'en 16/bits couche ça
irait mieux, mais les APN courants ne sortent pas du RGB 16 bits/couche,
la Raw garde pour l'instant toute sa supériorité en vue d'un
post-traitement.
eclairage tungstene, tu baisses le rouge,
Il faut plutôt aller vers le rouge orangé, si tu ne t'occupes que du
rouge tu ne vas pas vraiment corriger une dominante tungstène. Il va
nous falloir baisser le rouge et monter le bleu ou si tu préfères,
retirer du jaune et ajouter du cyan.
dès que tu quittes les données brutes pour le RGB tu as figé quelque chose.
et bien non justement. tu n'a rien figé. tu apliques les formules inverse et tu retrouve ton raw.
Avec un JPEG bien compressé ça va être dur...
tu dis "en mieux " alors que justement le raw n'existe que parce que les capteurs sont pas foutus pour des raisons de coût de sortir un RGB par pixel !!!
Le Foveon, mais ce n'est pas une entière réussite.
Alors fait moi passer un tiff de 2500 K à 9000 K d'un clic de souris qu'on rigole...
rien de plus facile, c'est qu'un *preset* de coef RVB à appliquer...
Pas si facile qu'il n'y paraît. On s'était amusé à faire l'expérience sur frpln et si pour de petites dérives cela fonctionne aussi bien avec le fichier RGB, pour de grosses dérives pas vraiment moyen d'avoir aussi bien avec un RGB 8/bits couche. Tu me diras qu'en 16/bits couche ça irait mieux, mais les APN courants ne sortent pas du RGB 16 bits/couche, la Raw garde pour l'instant toute sa supériorité en vue d'un post-traitement.
eclairage tungstene, tu baisses le rouge,
Il faut plutôt aller vers le rouge orangé, si tu ne t'occupes que du rouge tu ne vas pas vraiment corriger une dominante tungstène. Il va nous falloir baisser le rouge et monter le bleu ou si tu préfères, retirer du jaune et ajouter du cyan.
-- Jean-Claude Ghislain www.grimart.com
Francois Jouve
Stephane Legras-Decussy wrote:
"Francois Jouve" a écrit dans le message de news: 44527811$0$12959$
Il n'y a pas toujours de "formules inverses". Souvenez-vous de vos cours de math (bijection, injection, surjection).
oui bien sur mais je serais bien etonné que pour ce cas précis, il y n'y ai pas d'inversion possible...
ça ne change pas le fond du problème qu'un tiff 12 bit (hypothetique) est bien mieux qu'un raw 12 bit, mais si je me gourre sur l'inversion, je reconnaitrai mon erreur sur ce point...
Le dématricage n'est pas une opération bijective car il y a interpolation pour inventer les valeurs manquantes. Il n'y a donc pas de formules inverses. En d'autres termes, il existe plusieurs fichiers raw donnant le même rgb. Ceci est indépendant de l'échantillonnage des couleurs (j'ai conscience d'embrouiller encore un peu plus les choses en disant cela, mais les valeureux qui sont encore ici peuvent l'entendre).
j'enquête...
raison de plus pour réviser. :)
ça fait 10 ans, hein... ;-)
c'est rien 10 ans. La bijection j'ai du l'apprendre il y a 35 ans, en CE1. Vivent les "maths modernes" :)
-- F.J.
Stephane Legras-Decussy wrote:
"Francois Jouve" <francois.jouve_HALTEAUSPAM@polytechnique.fr> a écrit dans
le message de news: 44527811$0$12959$79c14f64@nan-newsreader-05.noos.net...
Il n'y a pas toujours de "formules inverses". Souvenez-vous
de vos cours de math (bijection, injection, surjection).
oui bien sur mais je serais bien etonné
que pour ce cas précis, il y n'y ai pas d'inversion possible...
ça ne change pas le fond du problème
qu'un tiff 12 bit (hypothetique) est bien mieux
qu'un raw 12 bit,
mais si je me gourre sur l'inversion, je reconnaitrai
mon erreur sur ce point...
Le dématricage n'est pas une opération bijective
car il y a interpolation pour inventer les valeurs
manquantes. Il n'y a donc pas de formules inverses.
En d'autres termes, il existe plusieurs fichiers
raw donnant le même rgb. Ceci est indépendant de
l'échantillonnage des couleurs (j'ai conscience
d'embrouiller encore un peu plus les choses
en disant cela, mais les valeureux qui sont encore
ici peuvent l'entendre).
j'enquête...
raison de plus pour réviser.
:)
ça fait 10 ans, hein... ;-)
c'est rien 10 ans. La bijection j'ai du l'apprendre il y a 35 ans,
en CE1. Vivent les "maths modernes" :)
"Francois Jouve" a écrit dans le message de news: 44527811$0$12959$
Il n'y a pas toujours de "formules inverses". Souvenez-vous de vos cours de math (bijection, injection, surjection).
oui bien sur mais je serais bien etonné que pour ce cas précis, il y n'y ai pas d'inversion possible...
ça ne change pas le fond du problème qu'un tiff 12 bit (hypothetique) est bien mieux qu'un raw 12 bit, mais si je me gourre sur l'inversion, je reconnaitrai mon erreur sur ce point...
Le dématricage n'est pas une opération bijective car il y a interpolation pour inventer les valeurs manquantes. Il n'y a donc pas de formules inverses. En d'autres termes, il existe plusieurs fichiers raw donnant le même rgb. Ceci est indépendant de l'échantillonnage des couleurs (j'ai conscience d'embrouiller encore un peu plus les choses en disant cela, mais les valeureux qui sont encore ici peuvent l'entendre).
j'enquête...
raison de plus pour réviser. :)
ça fait 10 ans, hein... ;-)
c'est rien 10 ans. La bijection j'ai du l'apprendre il y a 35 ans, en CE1. Vivent les "maths modernes" :)
