Le nombre de photos que je shoote et stock ne fait que grandir bien sur.
Et en raw, ça prend même beaucoup de place! Même avec un "petit" 6MP.
Outre la sélection et passage à la poubelle des choses inintéressantes,
un autre moyen consiste à les sauvegarder dans un autre format. Ce
d'autant que je ne sais pas combien de temps je pourrai ouvrir un RAW!
La question est donc, quel est le meilleur format pour garder tout ça?
Sous-entendu, ce bon vieux jpeg n'est-il pas trop destructif? A l'oeil
comme ça, j'ai pas trop l'impression... Mais c'est mon oeil.
Justement non. Encore une fois un RAW n'est *pas* une image. Et c'est ce qui fait son intérêt : pouvoir créer des images différentes à partir de ses données....
Allons, je peux pas résister à l'envie de mettre un peu d'huile sur le feu...
Je suis désolé pour JPR, mais un raw est bel et bien une façon particulière de coder une image, certes liée à la physique d'un capteur concret, mais tout aussi honorable en tant que codage d'image que du JPEG, TIFF, BNP, PNG etc. Un codage n'est rien d'autre qu'une manière de mettre dans un fichier les données numériques résultant d'une numérisation. Il peut inclure un traitement plus ou moins sophistiqué de ces données (JPEG, PNG) ou être un simple rangement de ces données côte à côte (grosso modo, BNP, TIFF sans compression, et certainement certains raw)
Un informaticien qui n'aurait rien de mieux à faire pourrait très facilement créer un raw à partir d'un jpeg : il suffirait pour ça de simuler une matrice de Bayer de son cru par dessus l'image reconstituée, d'en extraire les rvb lus à travers les «cellules» de la matrice et de les coller dans un fichier dans l'ordre qui lui plaira. Si on pouvait ensuite transmettre à un derawtiseur les paramètres de cette matrice de Bayer virtuelle et la façon de ranger les données, on pourrait alors jouer avec ce raw particulier comme on le fait avec les nef, orf ou cr2 du moment -- et en déduire une infinité de variantes.
Evidemment, si on passait aux actes à partir d'un JPEG 8-bit, les images obtenues à partir de ce raw de 2ème génération ne seraient pas aussi bonnes que celles obtenues à partir du vrai raw de départ, parce que la construction du jpeg a fait perdre beaucoup d'informations. Mais il n'y aurait pratiquement pas de différences si on faisait cette tambouille à partir d'un TIFF 16-bit.
Amha, les différences qu'on peut voir entre un derawtiseur et un autre sont dues essentiellement à la plus ou moins grande habileté des algorithmes de dématriçage. Peu ou prou, ce dématriçage est un rééchantillonage des rvb bruts (en gros, on double la résolution), et on sait bien qu'on n'a pas tout à fait les mêmes résultats en interpolant au plus proche voisin, en bicubique, ou avec des algorithmes fractaux.
Une fois que le dématriceur a fait son boulot, qu'on puisse sortir une infinité d'images d'un raw particulier ne relève que de la liberté d'interprétation du photographe face à son ordinateur. Tout comme ce photographe a la même liberté pour reprendre une image jpeg qui ne lui plairait pas.
Cette liberté n'est bridée que par les possibilités limitées des moyens à disposition. Par exemple, on n'a pas actuellement la possibilité de modifier **proprement** la température de couleur d'un JPEG, alors qu'on le peut dans un derawtiseur. C'est juste une limitation du moment. Si le besoin s'en faisait sentir assez fort, quelqu'un saurait très bien faire un filtre ad hoc.
Charles
Jean-Pierre Roche wrote:
Justement non. Encore une fois un RAW n'est *pas* une image. Et c'est ce
qui fait son intérêt : pouvoir créer des images différentes à partir de
ses données....
Allons, je peux pas résister à l'envie de mettre un peu d'huile sur le
feu...
Je suis désolé pour JPR, mais un raw est bel et bien une façon
particulière de coder une image, certes liée à la physique d'un capteur
concret, mais tout aussi honorable en tant que codage d'image que du
JPEG, TIFF, BNP, PNG etc. Un codage n'est rien d'autre qu'une manière de
mettre dans un fichier les données numériques résultant d'une
numérisation. Il peut inclure un traitement plus ou moins sophistiqué de
ces données (JPEG, PNG) ou être un simple rangement de ces données côte
à côte (grosso modo, BNP, TIFF sans compression, et certainement
certains raw)
Un informaticien qui n'aurait rien de mieux à faire pourrait très
facilement créer un raw à partir d'un jpeg : il suffirait pour ça de
simuler une matrice de Bayer de son cru par dessus l'image reconstituée,
d'en extraire les rvb lus à travers les «cellules» de la matrice et de
les coller dans un fichier dans l'ordre qui lui plaira. Si on pouvait
ensuite transmettre à un derawtiseur les paramètres de cette matrice de
Bayer virtuelle et la façon de ranger les données, on pourrait alors
jouer avec ce raw particulier comme on le fait avec les nef, orf ou cr2
du moment -- et en déduire une infinité de variantes.
Evidemment, si on passait aux actes à partir d'un JPEG 8-bit, les images
obtenues à partir de ce raw de 2ème génération ne seraient pas aussi
bonnes que celles obtenues à partir du vrai raw de départ, parce que la
construction du jpeg a fait perdre beaucoup d'informations. Mais il n'y
aurait pratiquement pas de différences si on faisait cette tambouille à
partir d'un TIFF 16-bit.
Amha, les différences qu'on peut voir entre un derawtiseur et un autre
sont dues essentiellement à la plus ou moins grande habileté des
algorithmes de dématriçage. Peu ou prou, ce dématriçage est un
rééchantillonage des rvb bruts (en gros, on double la résolution), et on
sait bien qu'on n'a pas tout à fait les mêmes résultats en interpolant
au plus proche voisin, en bicubique, ou avec des algorithmes fractaux.
Une fois que le dématriceur a fait son boulot, qu'on puisse sortir une
infinité d'images d'un raw particulier ne relève que de la liberté
d'interprétation du photographe face à son ordinateur. Tout comme ce
photographe a la même liberté pour reprendre une image jpeg qui ne lui
plairait pas.
Cette liberté n'est bridée que par les possibilités limitées des moyens
à disposition. Par exemple, on n'a pas actuellement la possibilité de
modifier **proprement** la température de couleur d'un JPEG, alors qu'on
le peut dans un derawtiseur. C'est juste une limitation du moment. Si le
besoin s'en faisait sentir assez fort, quelqu'un saurait très bien faire
un filtre ad hoc.
Justement non. Encore une fois un RAW n'est *pas* une image. Et c'est ce qui fait son intérêt : pouvoir créer des images différentes à partir de ses données....
Allons, je peux pas résister à l'envie de mettre un peu d'huile sur le feu...
Je suis désolé pour JPR, mais un raw est bel et bien une façon particulière de coder une image, certes liée à la physique d'un capteur concret, mais tout aussi honorable en tant que codage d'image que du JPEG, TIFF, BNP, PNG etc. Un codage n'est rien d'autre qu'une manière de mettre dans un fichier les données numériques résultant d'une numérisation. Il peut inclure un traitement plus ou moins sophistiqué de ces données (JPEG, PNG) ou être un simple rangement de ces données côte à côte (grosso modo, BNP, TIFF sans compression, et certainement certains raw)
Un informaticien qui n'aurait rien de mieux à faire pourrait très facilement créer un raw à partir d'un jpeg : il suffirait pour ça de simuler une matrice de Bayer de son cru par dessus l'image reconstituée, d'en extraire les rvb lus à travers les «cellules» de la matrice et de les coller dans un fichier dans l'ordre qui lui plaira. Si on pouvait ensuite transmettre à un derawtiseur les paramètres de cette matrice de Bayer virtuelle et la façon de ranger les données, on pourrait alors jouer avec ce raw particulier comme on le fait avec les nef, orf ou cr2 du moment -- et en déduire une infinité de variantes.
Evidemment, si on passait aux actes à partir d'un JPEG 8-bit, les images obtenues à partir de ce raw de 2ème génération ne seraient pas aussi bonnes que celles obtenues à partir du vrai raw de départ, parce que la construction du jpeg a fait perdre beaucoup d'informations. Mais il n'y aurait pratiquement pas de différences si on faisait cette tambouille à partir d'un TIFF 16-bit.
Amha, les différences qu'on peut voir entre un derawtiseur et un autre sont dues essentiellement à la plus ou moins grande habileté des algorithmes de dématriçage. Peu ou prou, ce dématriçage est un rééchantillonage des rvb bruts (en gros, on double la résolution), et on sait bien qu'on n'a pas tout à fait les mêmes résultats en interpolant au plus proche voisin, en bicubique, ou avec des algorithmes fractaux.
Une fois que le dématriceur a fait son boulot, qu'on puisse sortir une infinité d'images d'un raw particulier ne relève que de la liberté d'interprétation du photographe face à son ordinateur. Tout comme ce photographe a la même liberté pour reprendre une image jpeg qui ne lui plairait pas.
Cette liberté n'est bridée que par les possibilités limitées des moyens à disposition. Par exemple, on n'a pas actuellement la possibilité de modifier **proprement** la température de couleur d'un JPEG, alors qu'on le peut dans un derawtiseur. C'est juste une limitation du moment. Si le besoin s'en faisait sentir assez fort, quelqu'un saurait très bien faire un filtre ad hoc.
Charles
Didier Dalbera
"Jean-Pierre Roche" a écrit
[...] Oui, tu as raison, l'image, c'est ce qu'on voit. Avant, c'est de l'information qui permet de produire une image. Selon le forlat, RAW ou TIFF ou JPEG, l'algorithme est plus ou moins complexe, requiert éventuellement une intervention humaine pour faire des choix, mais ça ne change rien.
Ah ? Vous avez des choix à faire pour afficher une image JEPG ou TIFF ? C'est nouveau ça !
Mais il existe des visualisateurs qui ne demandent aucune intervention de l'utilisateur pour afficher un RAW, comme FastStone par exemple (il y a quand même la possibilité de définir les réglages dans les préférences)... Le RAW a donc le même statut de "fichier contenant une image" que le Jpeg ou le Tiff. L'intervention qui est possible sur les logiciels de dématriçage n'ont qu'une utilité : permettre de faire des réglages _avant_ le dématriçage pour èviter la dégradation lors de ces réglage a posteriori. Mais on peut trés bien imaginer ouvrir l'image par un dématriçage standard, et la travailler en 16Bits par couches, et on a les mêmes possibilités sur le travail de la couleur et de l'exposition...
-- Didier
"Jean-Pierre Roche" a écrit
[...]
Oui, tu as raison, l'image, c'est ce qu'on voit. Avant, c'est de
l'information qui permet de produire une image. Selon le forlat, RAW ou
TIFF ou JPEG, l'algorithme est plus ou moins complexe, requiert
éventuellement une intervention humaine pour faire des choix, mais ça ne
change rien.
Ah ? Vous avez des choix à faire pour afficher une image JEPG ou TIFF ?
C'est nouveau ça !
Mais il existe des visualisateurs qui ne demandent aucune intervention de
l'utilisateur pour afficher un RAW, comme FastStone par exemple (il y a
quand même la possibilité de définir les réglages dans les préférences)...
Le RAW a donc le même statut de "fichier contenant une image" que le Jpeg ou
le Tiff.
L'intervention qui est possible sur les logiciels de dématriçage n'ont
qu'une utilité : permettre de faire des réglages _avant_ le dématriçage pour
èviter la dégradation lors de ces réglage a posteriori. Mais on peut trés
bien imaginer ouvrir l'image par un dématriçage standard, et la travailler
en 16Bits par couches, et on a les mêmes possibilités sur le travail de la
couleur et de l'exposition...
[...] Oui, tu as raison, l'image, c'est ce qu'on voit. Avant, c'est de l'information qui permet de produire une image. Selon le forlat, RAW ou TIFF ou JPEG, l'algorithme est plus ou moins complexe, requiert éventuellement une intervention humaine pour faire des choix, mais ça ne change rien.
Ah ? Vous avez des choix à faire pour afficher une image JEPG ou TIFF ? C'est nouveau ça !
Mais il existe des visualisateurs qui ne demandent aucune intervention de l'utilisateur pour afficher un RAW, comme FastStone par exemple (il y a quand même la possibilité de définir les réglages dans les préférences)... Le RAW a donc le même statut de "fichier contenant une image" que le Jpeg ou le Tiff. L'intervention qui est possible sur les logiciels de dématriçage n'ont qu'une utilité : permettre de faire des réglages _avant_ le dématriçage pour èviter la dégradation lors de ces réglage a posteriori. Mais on peut trés bien imaginer ouvrir l'image par un dématriçage standard, et la travailler en 16Bits par couches, et on a les mêmes possibilités sur le travail de la couleur et de l'exposition...
-- Didier
Jean-Pierre Gallou
aucune source d'image ne vous donnera du 48 bits... Mais bien du jpeg ou du tiff 8bits/couleur.
Jusqu'à présent, quand j'ai traité des images Raw, j'ai produit des tiff 48 bit (16b/couleur), que je retravaille sous PS. Je sais bien que sur les 16 bits, 4 sont sans information, l'information du capteur étant sur 12, mais cela permet des traitements comme des éclaircissements ou autres avec moins de perte... Donc une fois de plus, je ne comprends pas votre point.
-- Ceci est une signature automatique de MesNews. Site : http://www.mesnews.net
aucune source d'image ne vous donnera du 48
bits... Mais bien du jpeg ou du tiff 8bits/couleur.
Jusqu'à présent, quand j'ai traité des images Raw, j'ai produit des
tiff 48 bit (16b/couleur), que je retravaille sous PS. Je sais bien que
sur les 16 bits, 4 sont sans information, l'information du capteur
étant sur 12, mais cela permet des traitements comme des
éclaircissements ou autres avec moins de perte...
Donc une fois de plus, je ne comprends pas votre point.
--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net
aucune source d'image ne vous donnera du 48 bits... Mais bien du jpeg ou du tiff 8bits/couleur.
Jusqu'à présent, quand j'ai traité des images Raw, j'ai produit des tiff 48 bit (16b/couleur), que je retravaille sous PS. Je sais bien que sur les 16 bits, 4 sont sans information, l'information du capteur étant sur 12, mais cela permet des traitements comme des éclaircissements ou autres avec moins de perte... Donc une fois de plus, je ne comprends pas votre point.
-- Ceci est une signature automatique de MesNews. Site : http://www.mesnews.net
jean-daniel dodin
Bernard Perrot wrote:
Dit autrement, si vous aviez raison, cela voudrait dire qu'un problème n'aurait toujours qu'une seule solution, ce qui est inexact.
Vous avez par exemple plusieurs algorithmes numériques pour extraire une racine carrée, et c'est bien pour la fiabilité de notre technologie actuelle que les résultats soient identiques...
sauf que deux calculatrices de marque différente donnent des résultats différents et qu'il faut tricher pour les faire correspondre. voir "erreurs d'arrondi" et "chiffres de garde"
Dit autrement, si vous aviez raison, cela voudrait dire qu'un problème
n'aurait toujours qu'une seule solution, ce qui est inexact.
Vous avez par exemple plusieurs algorithmes numériques pour extraire une
racine carrée, et c'est bien pour la fiabilité de notre technologie
actuelle que les résultats soient identiques...
sauf que deux calculatrices de marque différente donnent des
résultats différents et qu'il faut tricher pour les faire
correspondre. voir "erreurs d'arrondi" et "chiffres de garde"
Dit autrement, si vous aviez raison, cela voudrait dire qu'un problème n'aurait toujours qu'une seule solution, ce qui est inexact.
Vous avez par exemple plusieurs algorithmes numériques pour extraire une racine carrée, et c'est bien pour la fiabilité de notre technologie actuelle que les résultats soient identiques...
sauf que deux calculatrices de marque différente donnent des résultats différents et qu'il faut tricher pour les faire correspondre. voir "erreurs d'arrondi" et "chiffres de garde"
si configuration il y a, elle est _nécessairement_ toujours imparfaite et donc variable d'un écran à l'autre (d'ailleurs les yeux aussi sont imparfaits)
Les violons sont imparfaits, il est nécessaire de les accorder, sans parler des pianos, (pff dur les pianos) et d'ailleurs nos oreilles aussi sont imparfaites.
Mais un orchestre symphonique ça fonctionne bien et des musiciens du monde entier arrivent à jouer ensemble en accordant leurs violons.
Accordons nos écrans...
-- Jean-Claude Ghislain www.grimart.com
si configuration il y a, elle est _nécessairement_ toujours
imparfaite et donc variable d'un écran à l'autre (d'ailleurs
les yeux aussi sont imparfaits)
Les violons sont imparfaits, il est nécessaire de les accorder, sans
parler des pianos, (pff dur les pianos) et d'ailleurs nos oreilles aussi
sont imparfaites.
Mais un orchestre symphonique ça fonctionne bien et des musiciens du
monde entier arrivent à jouer ensemble en accordant leurs violons.
si configuration il y a, elle est _nécessairement_ toujours imparfaite et donc variable d'un écran à l'autre (d'ailleurs les yeux aussi sont imparfaits)
Les violons sont imparfaits, il est nécessaire de les accorder, sans parler des pianos, (pff dur les pianos) et d'ailleurs nos oreilles aussi sont imparfaites.
Mais un orchestre symphonique ça fonctionne bien et des musiciens du monde entier arrivent à jouer ensemble en accordant leurs violons.
Accordons nos écrans...
-- Jean-Claude Ghislain www.grimart.com
jean-daniel dodin
Jean-Pierre Roche wrote:
Oui et ? Où faire tirer des images 16 bits ? Toutes les utilisations connues (au moins de moi...) sont en 8 bits.
donc un tiff 16 bits n'est pas une image, si je suis votre raisonnement?
Allons, je peux pas résister à l'envie de mettre un peu d'huile sur le feu...
Faisons flamber. C'est rigolo.
Je suis désolé pour JPR, mais un raw est bel et bien une façon particulière de coder une image, certes liée à la physique d'un capteur concret, mais tout aussi honorable en tant que codage d'image que du JPEG, TIFF, BNP, PNG etc. Un codage n'est rien d'autre qu'une manière de mettre dans un fichier les données numériques résultant d'une numérisation. Il peut inclure un traitement plus ou moins sophistiqué de ces données (JPEG, PNG) ou être un simple rangement de ces données côte à côte (grosso modo, BNP, TIFF sans compression, et certainement certains raw)
Oui un RAW est un fichier, un JPEG ou un TIFF aussi. Et la conclusion c'est quoi ?
Un informaticien qui n'aurait rien de mieux à faire pourrait très facilement créer un raw à partir d'un jpeg : il suffirait pour ça de simuler une matrice de Bayer de son cru par dessus l'image reconstituée, d'en extraire les rvb lus à travers les «cellules» de la matrice et de les coller dans un fichier dans l'ordre qui lui plaira. Si on pouvait ensuite transmettre à un derawtiseur les paramètres de cette matrice de Bayer virtuelle et la façon de ranger les données, on pourrait alors jouer avec ce raw particulier comme on le fait avec les nef, orf ou cr2 du moment -- et en déduire une infinité de variantes.
Ca au moins c'est à mourir de rire. Ca me rappelle les gens qui veulent un logiciel qui reconstitue la partition à partir d'un MP3. Va falloir expliquer comme on crée de l'information à partir de rien...
Evidemment, si on passait aux actes à partir d'un JPEG 8-bit, les images obtenues à partir de ce raw de 2ème génération ne seraient pas aussi bonnes que celles obtenues à partir du vrai raw de départ, parce que la construction du jpeg a fait perdre beaucoup d'informations. Mais il n'y aurait pratiquement pas de différences si on faisait cette tambouille à partir d'un TIFF 16-bit.
Hélas pure hypothèse : le jpeg est bien 8 bits et aucun apn grand public ne fait du tiff 16 bits.
Amha, les différences qu'on peut voir entre un derawtiseur et un autre sont dues essentiellement à la plus ou moins grande habileté des algorithmes de dématriçage. Peu ou prou, ce dématriçage est un rééchantillonage des rvb bruts (en gros, on double la résolution), et on sait bien qu'on n'a pas tout à fait les mêmes résultats en interpolant au plus proche voisin, en bicubique, ou avec des algorithmes fractaux.
Rien à voir : il n'y a pas de rvb bruts puisque le capteur n'est pas rvb. Si ma tante en avait, etc.
Une fois que le dématriceur a fait son boulot, qu'on puisse sortir une infinité d'images d'un raw particulier ne relève que de la liberté d'interprétation du photographe face à son ordinateur. Tout comme ce photographe a la même liberté pour reprendre une image jpeg qui ne lui plairait pas.
L'oeuf le blanc et le jaune : une fois qu'on a fait l'omelette comment séparer l'un de l'autre ? Donc non l'infinité d'images ne vient pas après le boulot du dématriceur mais justement du fait qu'on part des données avant dématricage.
Cette liberté n'est bridée que par les possibilités limitées des moyens à disposition. Par exemple, on n'a pas actuellement la possibilité de modifier **proprement** la température de couleur d'un JPEG, alors qu'on le peut dans un derawtiseur. C'est juste une limitation du moment. Si le besoin s'en faisait sentir assez fort, quelqu'un saurait très bien faire un filtre ad hoc.
Pas du tout. Ou alors il faut inventer des données. On en revient à l'oeuf et à la poule. Mieux vaut en rester au raw... Pourquoi faire simple si on peut faire compliqué vu que, en l'état actuel des choses, l'original est toujours un raw à partir duquel l'appareil produit éventuellement un jepg.
-- Jean-Pierre Roche
enlever sanspub pour m'écrire...
http://jpierreroche.free.fr/
Allons, je peux pas résister à l'envie de mettre un peu d'huile sur le
feu...
Faisons flamber. C'est rigolo.
Je suis désolé pour JPR, mais un raw est bel et bien une façon
particulière de coder une image, certes liée à la physique d'un capteur
concret, mais tout aussi honorable en tant que codage d'image que du
JPEG, TIFF, BNP, PNG etc. Un codage n'est rien d'autre qu'une manière de
mettre dans un fichier les données numériques résultant d'une
numérisation. Il peut inclure un traitement plus ou moins sophistiqué de
ces données (JPEG, PNG) ou être un simple rangement de ces données côte
à côte (grosso modo, BNP, TIFF sans compression, et certainement
certains raw)
Oui un RAW est un fichier, un JPEG ou un TIFF aussi. Et la
conclusion c'est quoi ?
Un informaticien qui n'aurait rien de mieux à faire pourrait très
facilement créer un raw à partir d'un jpeg : il suffirait pour ça de
simuler une matrice de Bayer de son cru par dessus l'image reconstituée,
d'en extraire les rvb lus à travers les «cellules» de la matrice et de
les coller dans un fichier dans l'ordre qui lui plaira. Si on pouvait
ensuite transmettre à un derawtiseur les paramètres de cette matrice de
Bayer virtuelle et la façon de ranger les données, on pourrait alors
jouer avec ce raw particulier comme on le fait avec les nef, orf ou cr2
du moment -- et en déduire une infinité de variantes.
Ca au moins c'est à mourir de rire. Ca me rappelle les gens
qui veulent un logiciel qui reconstitue la partition à
partir d'un MP3. Va falloir expliquer comme on crée de
l'information à partir de rien...
Evidemment, si on passait aux actes à partir d'un JPEG 8-bit, les images
obtenues à partir de ce raw de 2ème génération ne seraient pas aussi
bonnes que celles obtenues à partir du vrai raw de départ, parce que la
construction du jpeg a fait perdre beaucoup d'informations. Mais il n'y
aurait pratiquement pas de différences si on faisait cette tambouille à
partir d'un TIFF 16-bit.
Hélas pure hypothèse : le jpeg est bien 8 bits et aucun apn
grand public ne fait du tiff 16 bits.
Amha, les différences qu'on peut voir entre un derawtiseur et un autre
sont dues essentiellement à la plus ou moins grande habileté des
algorithmes de dématriçage. Peu ou prou, ce dématriçage est un
rééchantillonage des rvb bruts (en gros, on double la résolution), et on
sait bien qu'on n'a pas tout à fait les mêmes résultats en interpolant
au plus proche voisin, en bicubique, ou avec des algorithmes fractaux.
Rien à voir : il n'y a pas de rvb bruts puisque le capteur
n'est pas rvb. Si ma tante en avait, etc.
Une fois que le dématriceur a fait son boulot, qu'on puisse sortir une
infinité d'images d'un raw particulier ne relève que de la liberté
d'interprétation du photographe face à son ordinateur. Tout comme ce
photographe a la même liberté pour reprendre une image jpeg qui ne lui
plairait pas.
L'oeuf le blanc et le jaune : une fois qu'on a fait
l'omelette comment séparer l'un de l'autre ? Donc non
l'infinité d'images ne vient pas après le boulot du
dématriceur mais justement du fait qu'on part des données
avant dématricage.
Cette liberté n'est bridée que par les possibilités limitées des moyens
à disposition. Par exemple, on n'a pas actuellement la possibilité de
modifier **proprement** la température de couleur d'un JPEG, alors qu'on
le peut dans un derawtiseur. C'est juste une limitation du moment. Si le
besoin s'en faisait sentir assez fort, quelqu'un saurait très bien faire
un filtre ad hoc.
Pas du tout. Ou alors il faut inventer des données. On en
revient à l'oeuf et à la poule. Mieux vaut en rester au
raw... Pourquoi faire simple si on peut faire compliqué vu
que, en l'état actuel des choses, l'original est toujours un
raw à partir duquel l'appareil produit éventuellement un jepg.
--
Jean-Pierre Roche
jproche@sanspubchello.fr
enlever sanspub pour m'écrire...
Allons, je peux pas résister à l'envie de mettre un peu d'huile sur le feu...
Faisons flamber. C'est rigolo.
Je suis désolé pour JPR, mais un raw est bel et bien une façon particulière de coder une image, certes liée à la physique d'un capteur concret, mais tout aussi honorable en tant que codage d'image que du JPEG, TIFF, BNP, PNG etc. Un codage n'est rien d'autre qu'une manière de mettre dans un fichier les données numériques résultant d'une numérisation. Il peut inclure un traitement plus ou moins sophistiqué de ces données (JPEG, PNG) ou être un simple rangement de ces données côte à côte (grosso modo, BNP, TIFF sans compression, et certainement certains raw)
Oui un RAW est un fichier, un JPEG ou un TIFF aussi. Et la conclusion c'est quoi ?
Un informaticien qui n'aurait rien de mieux à faire pourrait très facilement créer un raw à partir d'un jpeg : il suffirait pour ça de simuler une matrice de Bayer de son cru par dessus l'image reconstituée, d'en extraire les rvb lus à travers les «cellules» de la matrice et de les coller dans un fichier dans l'ordre qui lui plaira. Si on pouvait ensuite transmettre à un derawtiseur les paramètres de cette matrice de Bayer virtuelle et la façon de ranger les données, on pourrait alors jouer avec ce raw particulier comme on le fait avec les nef, orf ou cr2 du moment -- et en déduire une infinité de variantes.
Ca au moins c'est à mourir de rire. Ca me rappelle les gens qui veulent un logiciel qui reconstitue la partition à partir d'un MP3. Va falloir expliquer comme on crée de l'information à partir de rien...
Evidemment, si on passait aux actes à partir d'un JPEG 8-bit, les images obtenues à partir de ce raw de 2ème génération ne seraient pas aussi bonnes que celles obtenues à partir du vrai raw de départ, parce que la construction du jpeg a fait perdre beaucoup d'informations. Mais il n'y aurait pratiquement pas de différences si on faisait cette tambouille à partir d'un TIFF 16-bit.
Hélas pure hypothèse : le jpeg est bien 8 bits et aucun apn grand public ne fait du tiff 16 bits.
Amha, les différences qu'on peut voir entre un derawtiseur et un autre sont dues essentiellement à la plus ou moins grande habileté des algorithmes de dématriçage. Peu ou prou, ce dématriçage est un rééchantillonage des rvb bruts (en gros, on double la résolution), et on sait bien qu'on n'a pas tout à fait les mêmes résultats en interpolant au plus proche voisin, en bicubique, ou avec des algorithmes fractaux.
Rien à voir : il n'y a pas de rvb bruts puisque le capteur n'est pas rvb. Si ma tante en avait, etc.
Une fois que le dématriceur a fait son boulot, qu'on puisse sortir une infinité d'images d'un raw particulier ne relève que de la liberté d'interprétation du photographe face à son ordinateur. Tout comme ce photographe a la même liberté pour reprendre une image jpeg qui ne lui plairait pas.
L'oeuf le blanc et le jaune : une fois qu'on a fait l'omelette comment séparer l'un de l'autre ? Donc non l'infinité d'images ne vient pas après le boulot du dématriceur mais justement du fait qu'on part des données avant dématricage.
Cette liberté n'est bridée que par les possibilités limitées des moyens à disposition. Par exemple, on n'a pas actuellement la possibilité de modifier **proprement** la température de couleur d'un JPEG, alors qu'on le peut dans un derawtiseur. C'est juste une limitation du moment. Si le besoin s'en faisait sentir assez fort, quelqu'un saurait très bien faire un filtre ad hoc.
Pas du tout. Ou alors il faut inventer des données. On en revient à l'oeuf et à la poule. Mieux vaut en rester au raw... Pourquoi faire simple si on peut faire compliqué vu que, en l'état actuel des choses, l'original est toujours un raw à partir duquel l'appareil produit éventuellement un jepg.
-- Jean-Pierre Roche
enlever sanspub pour m'écrire...
http://jpierreroche.free.fr/
Jean-Pierre Roche
Mais il existe des visualisateurs qui ne demandent aucune intervention de l'utilisateur pour afficher un RAW, comme FastStone par exemple (il y a quand même la possibilité de définir les réglages dans les préférences)... Le RAW a donc le même statut de "fichier contenant une image" que le Jpeg ou le Tiff.
Bien sûr, il y en a des tas. Ca ne change rien au principe.
L'intervention qui est possible sur les logiciels de dématriçage n'ont qu'une utilité : permettre de faire des réglages _avant_ le dématriçage pour èviter la dégradation lors de ces réglage a posteriori. Mais on peut trés bien imaginer ouvrir l'image par un dématriçage standard, et la travailler en 16Bits par couches, et on a les mêmes possibilités sur le travail de la couleur et de l'exposition...
Pas essayé vraiment mais quel intérêt ? Manipuler de très gros fichiers ? Et pas certain du tout que les possibilités soient les mêmes au niveau de la balance des blancs par exemple.
-- Jean-Pierre Roche
enlever sanspub pour m'écrire...
http://jpierreroche.free.fr/
Mais il existe des visualisateurs qui ne demandent aucune intervention de
l'utilisateur pour afficher un RAW, comme FastStone par exemple (il y a
quand même la possibilité de définir les réglages dans les préférences)...
Le RAW a donc le même statut de "fichier contenant une image" que le Jpeg ou
le Tiff.
Bien sûr, il y en a des tas. Ca ne change rien au principe.
L'intervention qui est possible sur les logiciels de dématriçage n'ont
qu'une utilité : permettre de faire des réglages _avant_ le dématriçage pour
èviter la dégradation lors de ces réglage a posteriori. Mais on peut trés
bien imaginer ouvrir l'image par un dématriçage standard, et la travailler
en 16Bits par couches, et on a les mêmes possibilités sur le travail de la
couleur et de l'exposition...
Pas essayé vraiment mais quel intérêt ? Manipuler de très
gros fichiers ? Et pas certain du tout que les possibilités
soient les mêmes au niveau de la balance des blancs par exemple.
--
Jean-Pierre Roche
jproche@sanspubchello.fr
enlever sanspub pour m'écrire...
Mais il existe des visualisateurs qui ne demandent aucune intervention de l'utilisateur pour afficher un RAW, comme FastStone par exemple (il y a quand même la possibilité de définir les réglages dans les préférences)... Le RAW a donc le même statut de "fichier contenant une image" que le Jpeg ou le Tiff.
Bien sûr, il y en a des tas. Ca ne change rien au principe.
L'intervention qui est possible sur les logiciels de dématriçage n'ont qu'une utilité : permettre de faire des réglages _avant_ le dématriçage pour èviter la dégradation lors de ces réglage a posteriori. Mais on peut trés bien imaginer ouvrir l'image par un dématriçage standard, et la travailler en 16Bits par couches, et on a les mêmes possibilités sur le travail de la couleur et de l'exposition...
Pas essayé vraiment mais quel intérêt ? Manipuler de très gros fichiers ? Et pas certain du tout que les possibilités soient les mêmes au niveau de la balance des blancs par exemple.
-- Jean-Pierre Roche
enlever sanspub pour m'écrire...
http://jpierreroche.free.fr/
Jean-Pierre Roche
Jusqu'à présent, quand j'ai traité des images Raw, j'ai produit des tiff 48 bit (16b/couleur), que je retravaille sous PS. Je sais bien que sur les 16 bits, 4 sont sans information, l'information du capteur étant sur 12, mais cela permet des traitements comme des éclaircissements ou autres avec moins de perte... Donc une fois de plus, je ne comprends pas votre point.
Mon point de vue est que passer par du tiff 48 bits (donc fort lourd) n'a aucun intérêt. Autant travailler à partir de l'original puisqu'on en dispose. C'est un principe de base en traitement de l'information. Si vous aviez une source *originale* en tiff 48 bits (comme un scanner) les choses seraient différentes.
-- Jean-Pierre Roche
enlever sanspub pour m'écrire...
http://jpierreroche.free.fr/
Jusqu'à présent, quand j'ai traité des images Raw, j'ai produit des tiff
48 bit (16b/couleur), que je retravaille sous PS. Je sais bien que sur
les 16 bits, 4 sont sans information, l'information du capteur étant sur
12, mais cela permet des traitements comme des éclaircissements ou
autres avec moins de perte...
Donc une fois de plus, je ne comprends pas votre point.
Mon point de vue est que passer par du tiff 48 bits (donc
fort lourd) n'a aucun intérêt. Autant travailler à partir de
l'original puisqu'on en dispose. C'est un principe de base
en traitement de l'information.
Si vous aviez une source *originale* en tiff 48 bits (comme
un scanner) les choses seraient différentes.
--
Jean-Pierre Roche
jproche@sanspubchello.fr
enlever sanspub pour m'écrire...
Jusqu'à présent, quand j'ai traité des images Raw, j'ai produit des tiff 48 bit (16b/couleur), que je retravaille sous PS. Je sais bien que sur les 16 bits, 4 sont sans information, l'information du capteur étant sur 12, mais cela permet des traitements comme des éclaircissements ou autres avec moins de perte... Donc une fois de plus, je ne comprends pas votre point.
Mon point de vue est que passer par du tiff 48 bits (donc fort lourd) n'a aucun intérêt. Autant travailler à partir de l'original puisqu'on en dispose. C'est un principe de base en traitement de l'information. Si vous aviez une source *originale* en tiff 48 bits (comme un scanner) les choses seraient différentes.
-- Jean-Pierre Roche
enlever sanspub pour m'écrire...
http://jpierreroche.free.fr/
Jean-Pierre Roche
donc un tiff 16 bits n'est pas une image, si je suis votre raisonnement?
? j'ai dit ça ? non j'ai dit qu'on ne pouvait rien en faire d'utile. C'est un format de traitement, pas d'utilisation.
-- Jean-Pierre Roche
enlever sanspub pour m'écrire...
http://jpierreroche.free.fr/
donc un tiff 16 bits n'est pas une image, si je suis votre
raisonnement?
? j'ai dit ça ? non j'ai dit qu'on ne pouvait rien en faire
d'utile. C'est un format de traitement, pas d'utilisation.
--
Jean-Pierre Roche
jproche@sanspubchello.fr
enlever sanspub pour m'écrire...
