dès que tu quittes les données brutes pour le RGB tu as figé que lque chose.
et bien non justement. tu n'a rien figé.
tu apliques les formules inverse et tu retrouve ton raw.
Vraiment? Est-on sûr que le dématriçage est une opération réver sible? Existe-t'il des outils de "re-matriçage"?
J'aurais tendance à penser que quand on passe de 12 bits par pixel à 24, on crée de l'information, et que donc le retout arrière n'est pas garanti. Mais je peux me tromper.
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 !!!
Différents algorithme pouvant donner différents résultats de qualit é variable, il est clair que tous les tiffs ne sont pas égaux devant le raw (je ne conteste pas l'argument sur les restrictions des capteurs, remarque).
fait un capteur haut de gamme qui sort 12 bits par pixel *et* par composante et adieu ton raw... il sortira du tiff LZW...
Pourtant, les reflex Sigma avec capteur Foveon qui sortent du RGB utilisent un format raw qui doit lui aussi être traité dans un logici el ad hoc plutôt que directement du tiff. Moi, ça m'interpelle.
-- A+ François
Bonsoir,
J'ai quelques questions...
dès que tu quittes les données brutes pour le RGB tu as figé que lque chose.
et bien non justement. tu n'a rien figé.
tu apliques les formules inverse et tu retrouve ton raw.
Vraiment? Est-on sûr que le dématriçage est une opération réver sible?
Existe-t'il des outils de "re-matriçage"?
J'aurais tendance à penser que quand on passe de 12 bits par pixel à 24,
on crée de l'information, et que donc le retout arrière n'est pas
garanti. Mais je peux me tromper.
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 !!!
Différents algorithme pouvant donner différents résultats de qualit é
variable, il est clair que tous les tiffs ne sont pas égaux devant le
raw (je ne conteste pas l'argument sur les restrictions des capteurs,
remarque).
fait un capteur haut de gamme qui sort 12 bits par pixel *et*
par composante et adieu ton raw... il sortira du tiff LZW...
Pourtant, les reflex Sigma avec capteur Foveon qui sortent du RGB
utilisent un format raw qui doit lui aussi être traité dans un logici el
ad hoc plutôt que directement du tiff. Moi, ça m'interpelle.
dès que tu quittes les données brutes pour le RGB tu as figé que lque chose.
et bien non justement. tu n'a rien figé.
tu apliques les formules inverse et tu retrouve ton raw.
Vraiment? Est-on sûr que le dématriçage est une opération réver sible? Existe-t'il des outils de "re-matriçage"?
J'aurais tendance à penser que quand on passe de 12 bits par pixel à 24, on crée de l'information, et que donc le retout arrière n'est pas garanti. Mais je peux me tromper.
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 !!!
Différents algorithme pouvant donner différents résultats de qualit é variable, il est clair que tous les tiffs ne sont pas égaux devant le raw (je ne conteste pas l'argument sur les restrictions des capteurs, remarque).
fait un capteur haut de gamme qui sort 12 bits par pixel *et* par composante et adieu ton raw... il sortira du tiff LZW...
Pourtant, les reflex Sigma avec capteur Foveon qui sortent du RGB utilisent un format raw qui doit lui aussi être traité dans un logici el ad hoc plutôt que directement du tiff. Moi, ça m'interpelle.
-- A+ François
Bour-Brown
Jean-Pierre Gallou a écrit ( )
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.
Une information spatiale, je dirais.
Le RAW, ce sont les infos du capteur. Si je distribue les valeurs des photosites sur une matrice de cette taille, j'obtiens des infos de couleur du style
RVRV VBVB RVRV VBVB
Je constate par exemple que que par rapport au centre de chaque quadruplet, les couleurs sont décalées. Je vais donc interpoler la valeur RGB du pixel en considérant les photosites comme des sommets et en prenant les valeurs sur les pentes. Je fais une interpolation linéaire parce que je ne suis pas un cador en math, mais un plus doué peut par exemple considérer les sommets par trois, y faire passer un arc de parabole et choisir la valeur du pixel sur cette pente-là, ou faire la moyenne entre deux arcs de parabole, ou continuer avec des polynômes de Lagrange, etc.
A ce moment-là, la valeur RGB du pixel ne représente plus les valeurs des photosites, mais des moyennes. Est-ce que c'est réversible ? Si j'ai uniquement des valeurs prises sur les pentes des interpolations dont je connais la formule, est-ce que je peux retrouver les sommets ? Je ne sais pas.
Jean-Pierre Gallou a écrit
( mn.e5487d640ed8a947.23168@reply.to.invalid )
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.
Une information spatiale, je dirais.
Le RAW, ce sont les infos du capteur. Si je distribue les valeurs des
photosites sur une matrice de cette taille, j'obtiens des infos de couleur
du style
RVRV
VBVB
RVRV
VBVB
Je constate par exemple que que par rapport au centre de chaque quadruplet,
les couleurs sont décalées. Je vais donc interpoler la valeur RGB du pixel
en considérant les photosites comme des sommets et en prenant les valeurs
sur les pentes. Je fais une interpolation linéaire parce que je ne suis pas
un cador en math, mais un plus doué peut par exemple considérer les sommets
par trois, y faire passer un arc de parabole et choisir la valeur du pixel
sur cette pente-là, ou faire la moyenne entre deux arcs de parabole, ou
continuer avec des polynômes de Lagrange, etc.
A ce moment-là, la valeur RGB du pixel ne représente plus les valeurs des
photosites, mais des moyennes. Est-ce que c'est réversible ? Si j'ai
uniquement des valeurs prises sur les pentes des interpolations dont je
connais la formule, est-ce que je peux retrouver les sommets ? Je ne sais
pas.
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.
Une information spatiale, je dirais.
Le RAW, ce sont les infos du capteur. Si je distribue les valeurs des photosites sur une matrice de cette taille, j'obtiens des infos de couleur du style
RVRV VBVB RVRV VBVB
Je constate par exemple que que par rapport au centre de chaque quadruplet, les couleurs sont décalées. Je vais donc interpoler la valeur RGB du pixel en considérant les photosites comme des sommets et en prenant les valeurs sur les pentes. Je fais une interpolation linéaire parce que je ne suis pas un cador en math, mais un plus doué peut par exemple considérer les sommets par trois, y faire passer un arc de parabole et choisir la valeur du pixel sur cette pente-là, ou faire la moyenne entre deux arcs de parabole, ou continuer avec des polynômes de Lagrange, etc.
A ce moment-là, la valeur RGB du pixel ne représente plus les valeurs des photosites, mais des moyennes. Est-ce que c'est réversible ? Si j'ai uniquement des valeurs prises sur les pentes des interpolations dont je connais la formule, est-ce que je peux retrouver les sommets ? Je ne sais pas.
Jean-Pierre Gallou
si je reprends le thermomètre
Ce thermomètre est un très mauvais exemple, parce que O°C n'est pas l'origine absolue (il y a des t° négatives). Le zéro des luminances est une origine absolue, le noir, l'absence de photon reçu.
Un meilleur exemple (et plus simple) est un outil de mesure de longueur. Si on veut mesurer des longueurs jusqu'à 1 cm, on peut choisir un double décimètre en plastique qui a une faible dynamique (on mesure de 1 à 10 mm, rapport 10) ou un micromètre (palmer) qui en a une plus élevée parce qu'il mesurera de 1/100 mm ou même 1/1000 mm à 10 mmm, rapport 1000 à 10000). Pour ceux qui ne connaissent pas le micromètre: <http://fr.wikipedia.org/wiki/Microm%C3%A8tre_%28appareil_de_mesure%29>
-- Ceci est une signature automatique de MesNews. Site : http://www.mesnews.net
si je reprends le thermomètre
Ce thermomètre est un très mauvais exemple, parce que O°C n'est pas
l'origine absolue (il y a des t° négatives). Le zéro des luminances est
une origine absolue, le noir, l'absence de photon reçu.
Un meilleur exemple (et plus simple) est un outil de mesure de
longueur. Si on veut mesurer des longueurs jusqu'à 1 cm, on peut
choisir un double décimètre en plastique qui a une faible dynamique (on
mesure de 1 à 10 mm, rapport 10) ou un micromètre (palmer) qui en a une
plus élevée parce qu'il mesurera de 1/100 mm ou même 1/1000 mm à 10
mmm, rapport 1000 à 10000).
Pour ceux qui ne connaissent pas le micromètre:
<http://fr.wikipedia.org/wiki/Microm%C3%A8tre_%28appareil_de_mesure%29>
--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net
Ce thermomètre est un très mauvais exemple, parce que O°C n'est pas l'origine absolue (il y a des t° négatives). Le zéro des luminances est une origine absolue, le noir, l'absence de photon reçu.
Un meilleur exemple (et plus simple) est un outil de mesure de longueur. Si on veut mesurer des longueurs jusqu'à 1 cm, on peut choisir un double décimètre en plastique qui a une faible dynamique (on mesure de 1 à 10 mm, rapport 10) ou un micromètre (palmer) qui en a une plus élevée parce qu'il mesurera de 1/100 mm ou même 1/1000 mm à 10 mmm, rapport 1000 à 10000). Pour ceux qui ne connaissent pas le micromètre: <http://fr.wikipedia.org/wiki/Microm%C3%A8tre_%28appareil_de_mesure%29>
-- Ceci est une signature automatique de MesNews. Site : http://www.mesnews.net
Stephane Legras-Decussy
"Francois Jouve" a écrit dans le message de news: 44527f82$0$12957$
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.
je tique.
l'interpolation calcule uniquement les pixels manquant *entre* les *vrais* ou bien elle recalcule tout (les manquant et les vrais) ?
dans le 1 er cas, on sait lesquels sont vrais, donc il suffit de degager les faux pour revenir en arrière...
dans le 2eme cas, euh... oui c'est pas bijectif mais ça me parait pas bien mechant comme modif...
un peu comme un resize bicubic + 10% suivi par un resize - x % (la flemme) pour revenir en arrière... c'est pas bijectif, mais bon...
"Francois Jouve" <francois.jouve_HALTEAUSPAM@polytechnique.fr> a écrit dans
le message de news: 44527f82$0$12957$79c14f64@nan-newsreader-05.noos.net...
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.
je tique.
l'interpolation calcule uniquement les pixels manquant *entre*
les *vrais* ou bien elle recalcule tout (les manquant et les vrais) ?
dans le 1 er cas, on sait lesquels sont vrais, donc il suffit de
degager les faux pour revenir en arrière...
dans le 2eme cas, euh... oui c'est pas bijectif mais ça
me parait pas bien mechant comme modif...
un peu comme un resize bicubic + 10%
suivi par un resize - x % (la flemme) pour revenir
en arrière... c'est pas bijectif, mais bon...
"Francois Jouve" a écrit dans le message de news: 44527f82$0$12957$
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.
je tique.
l'interpolation calcule uniquement les pixels manquant *entre* les *vrais* ou bien elle recalcule tout (les manquant et les vrais) ?
dans le 1 er cas, on sait lesquels sont vrais, donc il suffit de degager les faux pour revenir en arrière...
dans le 2eme cas, euh... oui c'est pas bijectif mais ça me parait pas bien mechant comme modif...
un peu comme un resize bicubic + 10% suivi par un resize - x % (la flemme) pour revenir en arrière... c'est pas bijectif, mais bon...
Stephane Legras-Decussy
"Bour-Brown" a écrit dans le message de news: 4452836a$0$18311$ [snip]
excellentes remarques...
à cette heure, chapeau... ;-)
"Bour-Brown" <Bour-Brown@wnd.fr> a écrit dans le message de news:
4452836a$0$18311$8fcfb975@news.wanadoo.fr...
[snip]
"Bour-Brown" a écrit dans le message de news: 4452836a$0$18311$ [snip]
excellentes remarques...
à cette heure, chapeau... ;-)
Stephane Legras-Decussy
"Jean-Claude Ghislain" a écrit dans le message de news: e2tuno$5dm$
Avec un JPEG bien compressé ça va être dur...
je parlais d'un bitmap RGB 12bit / composante...
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.
entierement d'accord. on retombe exactement sur ce que je disais à l'origine de ce gros fil :
l'interet qualitatif du raw est juste d'avoir plus de 8 bit pour quantifier le pixel... tout comme le ferais un tiff 16bit...
l'interet secondaire est d'economiser la memoire dans l'apn mais rien à voir avec la l'image.
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.
oui bien sur je simplifiais, c'est pas evident d'ailleurs en pratique...
d'où le preset calé pour des °K typiques.
"Jean-Claude Ghislain" <jcg@grimart.com> a écrit dans le message de news:
e2tuno$5dm$1@news.brutele.be...
Avec un JPEG bien compressé ça va être dur...
je parlais d'un bitmap RGB 12bit / composante...
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.
entierement d'accord. on retombe exactement sur
ce que je disais à l'origine de ce gros fil :
l'interet qualitatif du raw est juste d'avoir plus de 8 bit pour quantifier
le pixel... tout comme le ferais un tiff 16bit...
l'interet secondaire est d'economiser la memoire dans l'apn
mais rien à voir avec la l'image.
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.
oui bien sur je simplifiais, c'est pas evident d'ailleurs en pratique...
"Jean-Claude Ghislain" a écrit dans le message de news: e2tuno$5dm$
Avec un JPEG bien compressé ça va être dur...
je parlais d'un bitmap RGB 12bit / composante...
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.
entierement d'accord. on retombe exactement sur ce que je disais à l'origine de ce gros fil :
l'interet qualitatif du raw est juste d'avoir plus de 8 bit pour quantifier le pixel... tout comme le ferais un tiff 16bit...
l'interet secondaire est d'economiser la memoire dans l'apn mais rien à voir avec la l'image.
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.
oui bien sur je simplifiais, c'est pas evident d'ailleurs en pratique...
d'où le preset calé pour des °K typiques.
Stephane Legras-Decussy
"Jean-Pierre Gallou" a écrit dans le message de news:
D'ailleurs savez-vous que les raw sont en fait des tiff un peu particuliers ?
DANS MES BRAS !
c'est ce que je dis depuis le début et qui a cassé le mythe du "raw magique"...
"Jean-Pierre Gallou" <gallou@reply.to.invalid> a écrit dans le message de
news: mn.e5507d64c7e9c1e2.23168@reply.to.invalid...
D'ailleurs savez-vous que les raw sont en fait des tiff un peu
particuliers ?
DANS MES BRAS !
c'est ce que je dis depuis le début et qui
a cassé le mythe du "raw magique"...
"Jean-Pierre Gallou" a écrit dans le message de news:
D'ailleurs savez-vous que les raw sont en fait des tiff un peu particuliers ?
DANS MES BRAS !
c'est ce que je dis depuis le début et qui a cassé le mythe du "raw magique"...
François FORNIER
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
C'est bien ce qu'il me semblait. Merci de ces précisions.
En, corollaire, peut-on considérer que la balance des blancs sera plus précise avant dématriçage qu'après?
-- A+ François
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
C'est bien ce qu'il me semblait. Merci de ces précisions.
En, corollaire, peut-on considérer que la balance des blancs sera plus
précise avant dématriçage qu'après?
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
C'est bien ce qu'il me semblait. Merci de ces précisions.
En, corollaire, peut-on considérer que la balance des blancs sera plus précise avant dématriçage qu'après?
-- A+ François
François FORNIER
En d'autres termes, il existe plusieurs fichiers raw donnant le même rgb.
Et j'ajouterai aussi que le même raw peut donner plusieurs fichiers rgb différents, selon l'algorithme appliqué (mais c'est juste pour simplifier les choses, hein?)
;-)
-- A+ François
En d'autres termes, il existe plusieurs fichiers
raw donnant le même rgb.
Et j'ajouterai aussi que le même raw peut donner plusieurs fichiers rgb
différents, selon l'algorithme appliqué (mais c'est juste pour
simplifier les choses, hein?)
En d'autres termes, il existe plusieurs fichiers raw donnant le même rgb.
Et j'ajouterai aussi que le même raw peut donner plusieurs fichiers rgb différents, selon l'algorithme appliqué (mais c'est juste pour simplifier les choses, hein?)
;-)
-- A+ François
Bour-Brown
Stephane Legras-Decussy a écrit ( 4452882e$0$12867$ )
l'interpolation calcule uniquement les pixels manquant *entre* les *vrais* ou bien elle recalcule tout (les manquant et les vrais) ?
Y a pas de «vrais».
D'après ce que j'ai compris, les algorithmes de dématriçage les plus simples travaillent par bloc de quatre en glissant seulement d'une colonne à la fois, puis d'une ligne. Exemple avec les valeurs brutes des photosites exposés à travers la matrice de Bayer :
A B C D E F G H I J K L M N O P
Première ligne, premier pixel :
A B E F
Deuxième pixel :
B C F G
Troisième pixel :
C D G H
Deuxième ligne, premier pixel :
E F I J
etc.
La première fois que j'ai vu ça, horrifié que j'étais. La vache, le lissage que ça fait ! Et on s'étonne que les photos brutes d'apn soient molles ? Après, pour améliorer, y a bien sûr les interpolations, comme je l'ai écrit un peu plus tôt. Mais ça reste mou, tout ça. On peut ensuite appliquer des matrices de déconvolution, une sorte de moulinette qui par exemple augmente les différences por que ça reprenne de la pêche, mais si tu en mets trop ça commence à faire de méchants liserés. Et puis il y a des effets de moire aussi.
Bref, tout ça n'est vraiment qu'un début, la préhistoire du dématriçage. Si on continue dans cette direction et qu'on cherche à améliorer les choses, ça devient coton, il n'y a qu'à voir le lien proposé tout à l'heure par Jean-Claude Ghislain : http://lcavwww.epfl.ch/~alleysso/Publication/paperGretsi.pdf
Voilà pourquoi les «dérawtiseurs» ont tous des résultats différents, avec chacun du pour et du contre. Perso il m'arrive, dans les cas extrêmes, de moyenner plusieurs résultats de différents programmes, des fois ça marche.
Ceci dit effectivement, si on décide de grouper sommairement je ne vois pas de grosse différence avec du TIFF. Les bidouilles pour faire mieux, rien ne dit qu'on ne peut pas les faire aussi après. D'ailleurs Photoshop CS2 propose maintenant du Smart Sharpen avec lequel tu choisis tes objectifs et ça te ramène des pixels que c'est un vrai bonheur, et ça à partir de la bonne vieille image RGB des familles. Comme quoi y a des infos qu'on ne savait même pas qu'elles étaient là...
Stephane Legras-Decussy a écrit
( 4452882e$0$12867$626a54ce@news.free.fr )
l'interpolation calcule uniquement les pixels manquant *entre*
les *vrais* ou bien elle recalcule tout (les manquant et les vrais) ?
Y a pas de «vrais».
D'après ce que j'ai compris, les algorithmes de dématriçage les plus simples
travaillent par bloc de quatre en glissant seulement d'une colonne à la
fois, puis d'une ligne. Exemple avec les valeurs brutes des photosites
exposés à travers la matrice de Bayer :
A B C D
E F G H
I J K L
M N O P
Première ligne, premier pixel :
A B
E F
Deuxième pixel :
B C
F G
Troisième pixel :
C D
G H
Deuxième ligne, premier pixel :
E F
I J
etc.
La première fois que j'ai vu ça, horrifié que j'étais. La vache, le lissage
que ça fait ! Et on s'étonne que les photos brutes d'apn soient molles ?
Après, pour améliorer, y a bien sûr les interpolations, comme je l'ai écrit
un peu plus tôt. Mais ça reste mou, tout ça. On peut ensuite appliquer des
matrices de déconvolution, une sorte de moulinette qui par exemple augmente
les différences por que ça reprenne de la pêche, mais si tu en mets trop ça
commence à faire de méchants liserés. Et puis il y a des effets de moire
aussi.
Bref, tout ça n'est vraiment qu'un début, la préhistoire du dématriçage. Si
on continue dans cette direction et qu'on cherche à améliorer les choses, ça
devient coton, il n'y a qu'à voir le lien proposé tout à l'heure par
Jean-Claude Ghislain :
http://lcavwww.epfl.ch/~alleysso/Publication/paperGretsi.pdf
Voilà pourquoi les «dérawtiseurs» ont tous des résultats différents, avec
chacun du pour et du contre. Perso il m'arrive, dans les cas extrêmes, de
moyenner plusieurs résultats de différents programmes, des fois ça marche.
Ceci dit effectivement, si on décide de grouper sommairement je ne vois pas
de grosse différence avec du TIFF. Les bidouilles pour faire mieux, rien ne
dit qu'on ne peut pas les faire aussi après. D'ailleurs Photoshop CS2
propose maintenant du Smart Sharpen avec lequel tu choisis tes objectifs et
ça te ramène des pixels que c'est un vrai bonheur, et ça à partir de la
bonne vieille image RGB des familles. Comme quoi y a des infos qu'on ne
savait même pas qu'elles étaient là...
Stephane Legras-Decussy a écrit ( 4452882e$0$12867$ )
l'interpolation calcule uniquement les pixels manquant *entre* les *vrais* ou bien elle recalcule tout (les manquant et les vrais) ?
Y a pas de «vrais».
D'après ce que j'ai compris, les algorithmes de dématriçage les plus simples travaillent par bloc de quatre en glissant seulement d'une colonne à la fois, puis d'une ligne. Exemple avec les valeurs brutes des photosites exposés à travers la matrice de Bayer :
A B C D E F G H I J K L M N O P
Première ligne, premier pixel :
A B E F
Deuxième pixel :
B C F G
Troisième pixel :
C D G H
Deuxième ligne, premier pixel :
E F I J
etc.
La première fois que j'ai vu ça, horrifié que j'étais. La vache, le lissage que ça fait ! Et on s'étonne que les photos brutes d'apn soient molles ? Après, pour améliorer, y a bien sûr les interpolations, comme je l'ai écrit un peu plus tôt. Mais ça reste mou, tout ça. On peut ensuite appliquer des matrices de déconvolution, une sorte de moulinette qui par exemple augmente les différences por que ça reprenne de la pêche, mais si tu en mets trop ça commence à faire de méchants liserés. Et puis il y a des effets de moire aussi.
Bref, tout ça n'est vraiment qu'un début, la préhistoire du dématriçage. Si on continue dans cette direction et qu'on cherche à améliorer les choses, ça devient coton, il n'y a qu'à voir le lien proposé tout à l'heure par Jean-Claude Ghislain : http://lcavwww.epfl.ch/~alleysso/Publication/paperGretsi.pdf
Voilà pourquoi les «dérawtiseurs» ont tous des résultats différents, avec chacun du pour et du contre. Perso il m'arrive, dans les cas extrêmes, de moyenner plusieurs résultats de différents programmes, des fois ça marche.
Ceci dit effectivement, si on décide de grouper sommairement je ne vois pas de grosse différence avec du TIFF. Les bidouilles pour faire mieux, rien ne dit qu'on ne peut pas les faire aussi après. D'ailleurs Photoshop CS2 propose maintenant du Smart Sharpen avec lequel tu choisis tes objectifs et ça te ramène des pixels que c'est un vrai bonheur, et ça à partir de la bonne vieille image RGB des familles. Comme quoi y a des infos qu'on ne savait même pas qu'elles étaient là...
