On parle photo. Et dans la photo si j'envoie une image jpeg faite sur mon pc à moi au mac du maquettiste d'une publication pour qui je travaille elle va s'afficher exactement de la même manière sur son écran que sur le mien (qu'on supposera évidemment calibrés tous les deux).
non ! tu crois que oui mais non.
Ah oui bon sang mais c'est bien sûr. Toute la presse travaille en aveugle et le fait que le magazine que je trouve en kiosque soit un reflet raisonnablement exact de l'image originale sur mon écran n'est que l'effet d'un heureux hasard. Faut arrêter la moquette je crois.
elle est que, comme je l'ai déja dit, la norme jpeg impose la semantique du flux de donnée du jpeg (en-tete, marqueur de début de matrice, fin de matrice, fin de fichier, etc) mais *pas* la manière de reconstruire le RGB.
donc suivant les bibliotheques jpeg utilisée, tu vas trouver des variantes dans les calculs de FFT ou d'interpolation de couleur. (oui le jpeg est sous-echantilloné en couleur).
Faudrait peut-être retomber sur terre. Des millions d'images sont échangées tous les jours (à des fins professionnelles) entre des gens qui ne se sont jamais vus et *jamais* je n'ai entendu parler de variantes dues à des différences de calculs FFT ou d'interpolation de couleur. Si elles existent, elles sont négligeables par rapport aux autres facteurs bien connus de dérive. Donc si tu as des exemples précis et documentés je veux bien mais jusqu'ici tu ne proposes que des affirmations qui vont à l'encontre de la pratique de milliers ou de millions de gens.
-- Jean-Pierre Roche
enlever sanspub pour m'écrire...
http://jpierreroche.free.fr/
On parle photo. Et dans la photo si j'envoie une image jpeg faite sur mon
pc à moi au mac du maquettiste d'une publication pour qui je travaille
elle va s'afficher exactement de la même manière sur son écran que sur le
mien (qu'on supposera évidemment calibrés tous les deux).
non ! tu crois que oui mais non.
Ah oui bon sang mais c'est bien sûr. Toute la presse
travaille en aveugle et le fait que le magazine que je
trouve en kiosque soit un reflet raisonnablement exact de
l'image originale sur mon écran n'est que l'effet d'un
heureux hasard. Faut arrêter la moquette je crois.
elle est que, comme je l'ai déja dit, la norme
jpeg impose la semantique du flux de donnée du jpeg
(en-tete, marqueur de début de matrice, fin de matrice, fin de fichier, etc)
mais *pas* la manière de reconstruire le RGB.
donc suivant les bibliotheques jpeg utilisée, tu vas trouver des
variantes dans les calculs de FFT ou d'interpolation de couleur.
(oui le jpeg est sous-echantilloné en couleur).
Faudrait peut-être retomber sur terre. Des millions d'images
sont échangées tous les jours (à des fins professionnelles)
entre des gens qui ne se sont jamais vus et *jamais* je n'ai
entendu parler de variantes dues à des différences de
calculs FFT ou d'interpolation de couleur. Si elles
existent, elles sont négligeables par rapport aux autres
facteurs bien connus de dérive. Donc si tu as des exemples
précis et documentés je veux bien mais jusqu'ici tu ne
proposes que des affirmations qui vont à l'encontre de la
pratique de milliers ou de millions de gens.
--
Jean-Pierre Roche
jproche@sanspubchello.fr
enlever sanspub pour m'écrire...
On parle photo. Et dans la photo si j'envoie une image jpeg faite sur mon pc à moi au mac du maquettiste d'une publication pour qui je travaille elle va s'afficher exactement de la même manière sur son écran que sur le mien (qu'on supposera évidemment calibrés tous les deux).
non ! tu crois que oui mais non.
Ah oui bon sang mais c'est bien sûr. Toute la presse travaille en aveugle et le fait que le magazine que je trouve en kiosque soit un reflet raisonnablement exact de l'image originale sur mon écran n'est que l'effet d'un heureux hasard. Faut arrêter la moquette je crois.
elle est que, comme je l'ai déja dit, la norme jpeg impose la semantique du flux de donnée du jpeg (en-tete, marqueur de début de matrice, fin de matrice, fin de fichier, etc) mais *pas* la manière de reconstruire le RGB.
donc suivant les bibliotheques jpeg utilisée, tu vas trouver des variantes dans les calculs de FFT ou d'interpolation de couleur. (oui le jpeg est sous-echantilloné en couleur).
Faudrait peut-être retomber sur terre. Des millions d'images sont échangées tous les jours (à des fins professionnelles) entre des gens qui ne se sont jamais vus et *jamais* je n'ai entendu parler de variantes dues à des différences de calculs FFT ou d'interpolation de couleur. Si elles existent, elles sont négligeables par rapport aux autres facteurs bien connus de dérive. Donc si tu as des exemples précis et documentés je veux bien mais jusqu'ici tu ne proposes que des affirmations qui vont à l'encontre de la pratique de milliers ou de millions de gens.
-- Jean-Pierre Roche
enlever sanspub pour m'écrire...
http://jpierreroche.free.fr/
Charles VASSALLO
Bour-Brown wrote:
Plus le temps passe et plus cette histoire d'espace couleur me sort par les yeux.
Les scientifiques qui font autorité sur la chose ne pourraient-ils pas définir précisément un espace qui engloberait une fois pour toute toutes les lumières et couleurs perçues par l'être humain, mutants compris, appeler ça espace couleur final on va dire, puis demander à tous les fabricants de s'y référer et proposer les méthodes qui permettent de mapper des autres espaces vers celui-ci ?
Non, parce que si chacun propose plusieurs espaces, autant choisir le plus large et on n'en parle plus...
Y'a ka bien sûr. En fait ça existe déjà, mais c'est inutilisable, ce bas-monde étant plein de contraintes contradictoires et de compromis, qui de surcroit évoluent dans le temps au fil des avancées techniques... et de ce que le pékin lambda peut accepter de débourser. Restez en ligne ! Mais gérez la couleur d'ici là.
Charles
Bour-Brown wrote:
Plus le temps passe et plus cette histoire d'espace couleur me sort par les
yeux.
Les scientifiques qui font autorité sur la chose ne pourraient-ils pas
définir précisément un espace qui engloberait une fois pour toute toutes les
lumières et couleurs perçues par l'être humain, mutants compris, appeler ça
espace couleur final on va dire, puis demander à tous les fabricants de s'y
référer et proposer les méthodes qui permettent de mapper des autres espaces
vers celui-ci ?
Non, parce que si chacun propose plusieurs espaces, autant choisir le plus
large et on n'en parle plus...
Y'a ka bien sûr. En fait ça existe déjà, mais c'est inutilisable, ce
bas-monde étant plein de contraintes contradictoires et de compromis,
qui de surcroit évoluent dans le temps au fil des avancées techniques...
et de ce que le pékin lambda peut accepter de débourser.
Restez en ligne ! Mais gérez la couleur d'ici là.
Plus le temps passe et plus cette histoire d'espace couleur me sort par les yeux.
Les scientifiques qui font autorité sur la chose ne pourraient-ils pas définir précisément un espace qui engloberait une fois pour toute toutes les lumières et couleurs perçues par l'être humain, mutants compris, appeler ça espace couleur final on va dire, puis demander à tous les fabricants de s'y référer et proposer les méthodes qui permettent de mapper des autres espaces vers celui-ci ?
Non, parce que si chacun propose plusieurs espaces, autant choisir le plus large et on n'en parle plus...
Y'a ka bien sûr. En fait ça existe déjà, mais c'est inutilisable, ce bas-monde étant plein de contraintes contradictoires et de compromis, qui de surcroit évoluent dans le temps au fil des avancées techniques... et de ce que le pékin lambda peut accepter de débourser. Restez en ligne ! Mais gérez la couleur d'ici là.
Charles
François FORNIER
je suis d'accord qu'un tiff 8 bit n'est pas superieur à un jpeg fine et c'est ce qui est implementé actuellement.
Moi pas. A ce que je sache, le jpeg est un format forcément compressé avec perte, alors que le tiff est soit non compressé, soit compressé sans perte (type LZW...). Et comme le jpeg en en 8 bits lui aussi...
je dis juste depuis le début, que le format raw permet juste de garde r les 12bits / pixel, ce que ferait tout aussi bien un tiff16.
Le raw, c'est du tiff. Un peu spécial peut-être, mais du tiff quand même. Ensuite, 8 bits, 12 bits ou 16 bits, ce n'est que fonction des capacités du capteur (pour ne pas gaspiller la mémoire). Le jour ou l 'on aura des capteurs capable d'une dynamique suffisante, et des circuits de traitement suffisemment rapides, le raw passera à 14 ou 16 bits naturellement.
et qu'on est obligé de se taper du raw juste pour un détail technique de gain de place sur la carte.
Donc on met du raw 16 bits et tu seras heureux? Juste pour ne pas gagner de place?
Ce qui sort du capteur (à part le Foveon, qui n'a pas eu beaucoup de succés) est monochrome et filtré par la matrice de Bayer. On enregist re les donnés après un minimum de traitement, dans le domaine analogique (amplification du signal par exemple), et conversion analogique/numériq ue.
Et c'est pour ça, à mon sens, qu'on a le raw. Pas pour gagner de la place, pas pour emmerder les cochons d'utilisateurs, mais pour sauvegarder les données les moins altérées possibles d'une manièr e efficace.
la preuve c'est que le foveon sort un quasi tiff16, le "quasi" venant aussi d'une histoire de gain de place.
Comme je doute que ce capteur ait une dynamique suffisemment étendue pour justifier 48 bits par pixels, je pense qu'il doit y avoir d'autres raisons.
Et si on laissait les mouches tranquilles? Enfin pour ce que j'en dis...
-- A+ François
je suis d'accord qu'un tiff 8 bit n'est pas superieur
à un jpeg fine et c'est ce qui est implementé actuellement.
Moi pas. A ce que je sache, le jpeg est un format forcément compressé
avec perte, alors que le tiff est soit non compressé, soit compressé
sans perte (type LZW...). Et comme le jpeg en en 8 bits lui aussi...
je dis juste depuis le début, que le format raw permet juste de garde r
les 12bits / pixel, ce que ferait tout aussi bien un tiff16.
Le raw, c'est du tiff. Un peu spécial peut-être, mais du tiff quand
même. Ensuite, 8 bits, 12 bits ou 16 bits, ce n'est que fonction des
capacités du capteur (pour ne pas gaspiller la mémoire). Le jour ou l 'on
aura des capteurs capable d'une dynamique suffisante, et des circuits de
traitement suffisemment rapides, le raw passera à 14 ou 16 bits
naturellement.
et qu'on est obligé de se taper du raw juste pour un
détail technique de gain de place sur la carte.
Donc on met du raw 16 bits et tu seras heureux? Juste pour ne pas gagner
de place?
Ce qui sort du capteur (à part le Foveon, qui n'a pas eu beaucoup de
succés) est monochrome et filtré par la matrice de Bayer. On enregist re
les donnés après un minimum de traitement, dans le domaine analogique
(amplification du signal par exemple), et conversion analogique/numériq ue.
Et c'est pour ça, à mon sens, qu'on a le raw. Pas pour gagner de la
place, pas pour emmerder les cochons d'utilisateurs, mais pour
sauvegarder les données les moins altérées possibles d'une manièr e
efficace.
la preuve c'est que le foveon sort un quasi tiff16,
le "quasi" venant aussi d'une histoire de gain de place.
Comme je doute que ce capteur ait une dynamique suffisemment étendue
pour justifier 48 bits par pixels, je pense qu'il doit y avoir d'autres
raisons.
Et si on laissait les mouches tranquilles?
Enfin pour ce que j'en dis...
je suis d'accord qu'un tiff 8 bit n'est pas superieur à un jpeg fine et c'est ce qui est implementé actuellement.
Moi pas. A ce que je sache, le jpeg est un format forcément compressé avec perte, alors que le tiff est soit non compressé, soit compressé sans perte (type LZW...). Et comme le jpeg en en 8 bits lui aussi...
je dis juste depuis le début, que le format raw permet juste de garde r les 12bits / pixel, ce que ferait tout aussi bien un tiff16.
Le raw, c'est du tiff. Un peu spécial peut-être, mais du tiff quand même. Ensuite, 8 bits, 12 bits ou 16 bits, ce n'est que fonction des capacités du capteur (pour ne pas gaspiller la mémoire). Le jour ou l 'on aura des capteurs capable d'une dynamique suffisante, et des circuits de traitement suffisemment rapides, le raw passera à 14 ou 16 bits naturellement.
et qu'on est obligé de se taper du raw juste pour un détail technique de gain de place sur la carte.
Donc on met du raw 16 bits et tu seras heureux? Juste pour ne pas gagner de place?
Ce qui sort du capteur (à part le Foveon, qui n'a pas eu beaucoup de succés) est monochrome et filtré par la matrice de Bayer. On enregist re les donnés après un minimum de traitement, dans le domaine analogique (amplification du signal par exemple), et conversion analogique/numériq ue.
Et c'est pour ça, à mon sens, qu'on a le raw. Pas pour gagner de la place, pas pour emmerder les cochons d'utilisateurs, mais pour sauvegarder les données les moins altérées possibles d'une manièr e efficace.
la preuve c'est que le foveon sort un quasi tiff16, le "quasi" venant aussi d'une histoire de gain de place.
Comme je doute que ce capteur ait une dynamique suffisemment étendue pour justifier 48 bits par pixels, je pense qu'il doit y avoir d'autres raisons.
Et si on laissait les mouches tranquilles? Enfin pour ce que j'en dis...
-- A+ François
JPW
"François FORNIER" a écrit
Le raw, c'est du tiff. Un peu spécial peut-être, mais du tiff quand même.
décidément
c'est la foire aux gogols ou quoi ???
Ce qui sort du capteur (à part le Foveon, qui n'a pas eu beaucoup de succés) est monochrome et filtré par la matrice de Bayer. On enregistre les donnés après un minimum de traitement, dans le domaine analogique (amplification du signal par exemple), et conversion analogique/numérique.
Et c'est pour ça, à mon sens, qu'on a le raw.
bon pas complètement quand même...
jpw
"François FORNIER" <nospam@nospam.com> a écrit
Le raw, c'est du tiff. Un peu spécial peut-être, mais du tiff quand
même.
décidément
c'est la foire aux gogols ou quoi ???
Ce qui sort du capteur (à part le Foveon, qui n'a pas eu beaucoup de
succés) est monochrome et filtré par la matrice de Bayer. On enregistre
les donnés après un minimum de traitement, dans le domaine analogique
(amplification du signal par exemple), et conversion analogique/numérique.
Le raw, c'est du tiff. Un peu spécial peut-être, mais du tiff quand même.
décidément
c'est la foire aux gogols ou quoi ???
Ce qui sort du capteur (à part le Foveon, qui n'a pas eu beaucoup de succés) est monochrome et filtré par la matrice de Bayer. On enregistre les donnés après un minimum de traitement, dans le domaine analogique (amplification du signal par exemple), et conversion analogique/numérique.
Et c'est pour ça, à mon sens, qu'on a le raw.
bon pas complètement quand même...
jpw
François FORNIER
"François FORNIER" a écrit
Le raw, c'est du tiff. Un peu spécial peut-être, mais du tiff quan d même.
décidément
c'est la foire aux gogols ou quoi ???
Bien tenté!
Des fois, suivre le fil permet de se raccrocher aux branches. Le tiff, c'est comme l'avi, un format de fichier. Ca décrit la manière de stoc ker les données dedans. Après, ce qu'on y met...
Donc, je répète, le raw, au moins à la sauce Nikon (NEF) et Canon ( CR2), soit 90% du marché des reflexs, ce sont des fichiers dont le format est la la norme tiff version 6.0.
C'est mieux comme ça?
-- A+ François
"François FORNIER" <nospam@nospam.com> a écrit
Le raw, c'est du tiff. Un peu spécial peut-être, mais du tiff quan d
même.
décidément
c'est la foire aux gogols ou quoi ???
Bien tenté!
Des fois, suivre le fil permet de se raccrocher aux branches. Le tiff,
c'est comme l'avi, un format de fichier. Ca décrit la manière de stoc ker
les données dedans. Après, ce qu'on y met...
Donc, je répète, le raw, au moins à la sauce Nikon (NEF) et Canon ( CR2),
soit 90% du marché des reflexs, ce sont des fichiers dont le format est
la la norme tiff version 6.0.
Le raw, c'est du tiff. Un peu spécial peut-être, mais du tiff quan d même.
décidément
c'est la foire aux gogols ou quoi ???
Bien tenté!
Des fois, suivre le fil permet de se raccrocher aux branches. Le tiff, c'est comme l'avi, un format de fichier. Ca décrit la manière de stoc ker les données dedans. Après, ce qu'on y met...
Donc, je répète, le raw, au moins à la sauce Nikon (NEF) et Canon ( CR2), soit 90% du marché des reflexs, ce sont des fichiers dont le format est la la norme tiff version 6.0.
C'est mieux comme ça?
-- A+ François
Stephane Legras-Decussy
"François FORNIER" a écrit dans le message de news: e2vuo0$qr1$
oi pas. A ce que je sache, le jpeg est un format forcément compressé ec perte, alors que le tiff est soit non compressé, soit compressé ans perte (type LZW...). Et comme le jpeg en en 8 bits lui aussi...
oui, je disais ça pour pas chipoter, en pratique à vue d'oeil, c'est pas flagrant...
Le raw, c'est du tiff. Un peu spécial peut-être, mais du tiff quand même.
OUF, c'est ce que ne veulent pas comprendre un certain nombre içi... parle en à JPR...
et qu'on est obligé de se taper du raw juste pour un détail technique de gain de place sur la carte.
Donc on met du raw 16 bits et tu seras heureux? Juste pour ne pas gagner de place?
non je veux dire que si la place n'est pas compté, l'apn dematrice trivialement le Bayer (recopie du voisin), on obtient un RGB 12 bit.
ensuite l'apn le colle dans un tiff 16 en laissant à zero les 4 bit de poids faible. il compresse en LZW (efficace car le tiff sera bourré de redondance) et hop on obtient un fichier sans le moindre postraitement, brut de capteur, et dans un format standard...
youpi.... fini les raw machin truc...
Comme je doute que ce capteur ait une dynamique suffisemment étendue pour justifier 48 bits par pixels, je pense qu'il doit y avoir d'autres raisons.
le foveon sort 36 bit pixel, il suffirai de laisser a zero les poids faibles et compresser en LZW.
cependant, c'est toujours trop gros donc, Sigma ne fait pas ça et prefère utiliser une compression ration 2:1 destructrice...
Et si on laissait les mouches tranquilles? Enfin pour ce que j'en dis...
ben j'aime bien comprendre les trucs...
"François FORNIER" <nospam@nospam.com> a écrit dans le message de news:
e2vuo0$qr1$1@news.tiscali.fr...
oi pas. A ce que je sache, le jpeg est un format forcément compressé
ec perte, alors que le tiff est soit non compressé, soit compressé
ans perte (type LZW...). Et comme le jpeg en en 8 bits lui aussi...
oui, je disais ça pour pas chipoter, en pratique à vue
d'oeil, c'est pas flagrant...
Le raw, c'est du tiff. Un peu spécial peut-être, mais du tiff quand
même.
OUF, c'est ce que ne veulent pas comprendre un certain nombre
içi... parle en à JPR...
et qu'on est obligé de se taper du raw juste pour un
détail technique de gain de place sur la carte.
Donc on met du raw 16 bits et tu seras heureux? Juste pour ne pas gagner
de place?
non je veux dire que si la place n'est pas compté,
l'apn dematrice trivialement le Bayer (recopie du voisin),
on obtient un RGB 12 bit.
ensuite l'apn le colle dans un tiff 16 en laissant à zero les 4 bit de poids
faible. il compresse en LZW (efficace car le tiff sera bourré de redondance)
et hop on obtient un fichier sans le moindre postraitement, brut de capteur,
et dans un format standard...
youpi.... fini les raw machin truc...
Comme je doute que ce capteur ait une dynamique suffisemment étendue
pour justifier 48 bits par pixels, je pense qu'il doit y avoir d'autres
raisons.
le foveon sort 36 bit pixel, il suffirai de laisser a zero
les poids faibles et compresser en LZW.
cependant, c'est toujours trop gros donc, Sigma
ne fait pas ça et prefère utiliser une compression ration 2:1
destructrice...
Et si on laissait les mouches tranquilles?
Enfin pour ce que j'en dis...
"François FORNIER" a écrit dans le message de news: e2vuo0$qr1$
oi pas. A ce que je sache, le jpeg est un format forcément compressé ec perte, alors que le tiff est soit non compressé, soit compressé ans perte (type LZW...). Et comme le jpeg en en 8 bits lui aussi...
oui, je disais ça pour pas chipoter, en pratique à vue d'oeil, c'est pas flagrant...
Le raw, c'est du tiff. Un peu spécial peut-être, mais du tiff quand même.
OUF, c'est ce que ne veulent pas comprendre un certain nombre içi... parle en à JPR...
et qu'on est obligé de se taper du raw juste pour un détail technique de gain de place sur la carte.
Donc on met du raw 16 bits et tu seras heureux? Juste pour ne pas gagner de place?
non je veux dire que si la place n'est pas compté, l'apn dematrice trivialement le Bayer (recopie du voisin), on obtient un RGB 12 bit.
ensuite l'apn le colle dans un tiff 16 en laissant à zero les 4 bit de poids faible. il compresse en LZW (efficace car le tiff sera bourré de redondance) et hop on obtient un fichier sans le moindre postraitement, brut de capteur, et dans un format standard...
youpi.... fini les raw machin truc...
Comme je doute que ce capteur ait une dynamique suffisemment étendue pour justifier 48 bits par pixels, je pense qu'il doit y avoir d'autres raisons.
le foveon sort 36 bit pixel, il suffirai de laisser a zero les poids faibles et compresser en LZW.
cependant, c'est toujours trop gros donc, Sigma ne fait pas ça et prefère utiliser une compression ration 2:1 destructrice...
Et si on laissait les mouches tranquilles? Enfin pour ce que j'en dis...
ben j'aime bien comprendre les trucs...
Stephane Legras-Decussy
"JPW" a écrit dans le message de news:
c'est la foire aux gogols ou quoi ???
faut arrêter de lire uniquement la presse photo bas de gamme...
on t'a dit depuis toujours que le raw etait un truc special, mais non... désolé...
"JPW" <jpw@libertysurf.invalid> a écrit dans le message de news:
4bhdj0F10ji3cU1@individual.net...
c'est la foire aux gogols ou quoi ???
faut arrêter de lire uniquement
la presse photo bas de gamme...
on t'a dit depuis toujours que le raw etait
un truc special, mais non... désolé...
pas besoin de me taper tout le fil pour constater que vous proférez des âneries
MDR...
je suis quand même assez effaré que des contributeurs réguliers soient aussi à coté de la plaque dès qu'on gratte un peu du coté du bureau d'étude...
François FORNIER
"François FORNIER" a écrit dans le message de n ews: e2vuo0$qr1$
Moi pas. A ce que je sache, le jpeg est un format forcément compress é ec perte, alors que le tiff est soit non compressé, soit compressé ans perte (type LZW...). Et comme le jpeg en en 8 bits lui aussi...
oui, je disais ça pour pas chipoter, en pratique à vue d'oeil, c'est pas flagrant...
On est d'accord.
non je veux dire que si la place n'est pas compté, l'apn dematrice trivialement le Bayer (recopie du voisin), on obtient un RGB 12 bit.
C'est un peu dommage de dématricer sommairement, non? Moi je préfèr e garder des raw, et les convertir plus tard sur un appareil plus puissant que mon reflex (mon PC) et avec un soft qui pourra avoir évolué depui s l'achat du reflex (capture NX?)donc un traitement amélioré par rappor t à celui de l'appareil.
Pour l'info, Nikon Capture peut te générer du TIFF 16 bits en RGB ou en CMJN. C'est surement mieux que ce que peut te sortir le boitier...
ensuite l'apn le colle dans un tiff 16 en laissant à zero les 4 bit d e poids faible. il compresse en LZW (efficace car le tiff sera bourré de redo ndance) et hop on obtient un fichier sans le moindre postraitement, brut de cap teur, et dans un format standard...
Pas d'accord. S'il y a eu dématriçage, ce n'est plus du brut de capte ur, et comme l'opération ne semble pas réversible on perd de l'info en ne se donnant pas la possibilité d'utiliser des algos plus performants plus t ard.
youpi.... fini les raw machin truc...
Comme tu le vois, ce n'est pas si simple.
En résumé, tant qu'on a une matrice, de bayer ou autre, je préfèr e du raw vrai de vrai (pour les données niveau pixel, le format du fichier j e m'en tape un peu), pour du RGB c'est plus simple puisque le raw peut être stocké directement sous une forme lisible sans autre opération que l'amplification et la conversion numérique.
Mais j'ai lu quelque part que des mode de stockage analogiques étaient en cours de développement. Ca ne simplifiera pas les choses.
le foveon sort 36 bit pixel, il suffirai de laisser a zero les poids faibles et compresser en LZW.
Et même là, je pense que sa dynamique n'est pas suffisemment étendu e pour 36 bits, mais je peu me tromper.
cependant, c'est toujours trop gros donc, Sigma ne fait pas ça et prefère utiliser une compression ration 2:1 destructrice...
Et ça, c'est vraiment con.
Et si on laissait les mouches tranquilles? Enfin pour ce que j'en dis...
ben j'aime bien comprendre les trucs...
Moi aussi, mais comme là on dirais qu'on retombé sur nos pattes, diso ns que je n'ai rien dit. En tous cas, ça décrasse les neurones, ça fai t du bien!
-- A+ François
"François FORNIER" <nospam@nospam.com> a écrit dans le message de n ews:
e2vuo0$qr1$1@news.tiscali.fr...
Moi pas. A ce que je sache, le jpeg est un format forcément compress é
ec perte, alors que le tiff est soit non compressé, soit compressé
ans perte (type LZW...). Et comme le jpeg en en 8 bits lui aussi...
oui, je disais ça pour pas chipoter, en pratique à vue
d'oeil, c'est pas flagrant...
On est d'accord.
non je veux dire que si la place n'est pas compté,
l'apn dematrice trivialement le Bayer (recopie du voisin),
on obtient un RGB 12 bit.
C'est un peu dommage de dématricer sommairement, non? Moi je préfèr e
garder des raw, et les convertir plus tard sur un appareil plus puissant
que mon reflex (mon PC) et avec un soft qui pourra avoir évolué depui s
l'achat du reflex (capture NX?)donc un traitement amélioré par rappor t à
celui de l'appareil.
Pour l'info, Nikon Capture peut te générer du TIFF 16 bits en RGB ou en
CMJN. C'est surement mieux que ce que peut te sortir le boitier...
ensuite l'apn le colle dans un tiff 16 en laissant à zero les 4 bit d e poids
faible. il compresse en LZW (efficace car le tiff sera bourré de redo ndance)
et hop on obtient un fichier sans le moindre postraitement, brut de cap teur,
et dans un format standard...
Pas d'accord. S'il y a eu dématriçage, ce n'est plus du brut de capte ur,
et comme l'opération ne semble pas réversible on perd de l'info en ne se
donnant pas la possibilité d'utiliser des algos plus performants plus t ard.
youpi.... fini les raw machin truc...
Comme tu le vois, ce n'est pas si simple.
En résumé, tant qu'on a une matrice, de bayer ou autre, je préfèr e du
raw vrai de vrai (pour les données niveau pixel, le format du fichier j e
m'en tape un peu), pour du RGB c'est plus simple puisque le raw peut
être stocké directement sous une forme lisible sans autre opération que
l'amplification et la conversion numérique.
Mais j'ai lu quelque part que des mode de stockage analogiques étaient
en cours de développement. Ca ne simplifiera pas les choses.
le foveon sort 36 bit pixel, il suffirai de laisser a zero
les poids faibles et compresser en LZW.
Et même là, je pense que sa dynamique n'est pas suffisemment étendu e
pour 36 bits, mais je peu me tromper.
cependant, c'est toujours trop gros donc, Sigma
ne fait pas ça et prefère utiliser une compression ration 2:1
destructrice...
Et ça, c'est vraiment con.
Et si on laissait les mouches tranquilles?
Enfin pour ce que j'en dis...
ben j'aime bien comprendre les trucs...
Moi aussi, mais comme là on dirais qu'on retombé sur nos pattes, diso ns
que je n'ai rien dit. En tous cas, ça décrasse les neurones, ça fai t du
bien!
"François FORNIER" a écrit dans le message de n ews: e2vuo0$qr1$
Moi pas. A ce que je sache, le jpeg est un format forcément compress é ec perte, alors que le tiff est soit non compressé, soit compressé ans perte (type LZW...). Et comme le jpeg en en 8 bits lui aussi...
oui, je disais ça pour pas chipoter, en pratique à vue d'oeil, c'est pas flagrant...
On est d'accord.
non je veux dire que si la place n'est pas compté, l'apn dematrice trivialement le Bayer (recopie du voisin), on obtient un RGB 12 bit.
C'est un peu dommage de dématricer sommairement, non? Moi je préfèr e garder des raw, et les convertir plus tard sur un appareil plus puissant que mon reflex (mon PC) et avec un soft qui pourra avoir évolué depui s l'achat du reflex (capture NX?)donc un traitement amélioré par rappor t à celui de l'appareil.
Pour l'info, Nikon Capture peut te générer du TIFF 16 bits en RGB ou en CMJN. C'est surement mieux que ce que peut te sortir le boitier...
ensuite l'apn le colle dans un tiff 16 en laissant à zero les 4 bit d e poids faible. il compresse en LZW (efficace car le tiff sera bourré de redo ndance) et hop on obtient un fichier sans le moindre postraitement, brut de cap teur, et dans un format standard...
Pas d'accord. S'il y a eu dématriçage, ce n'est plus du brut de capte ur, et comme l'opération ne semble pas réversible on perd de l'info en ne se donnant pas la possibilité d'utiliser des algos plus performants plus t ard.
youpi.... fini les raw machin truc...
Comme tu le vois, ce n'est pas si simple.
En résumé, tant qu'on a une matrice, de bayer ou autre, je préfèr e du raw vrai de vrai (pour les données niveau pixel, le format du fichier j e m'en tape un peu), pour du RGB c'est plus simple puisque le raw peut être stocké directement sous une forme lisible sans autre opération que l'amplification et la conversion numérique.
Mais j'ai lu quelque part que des mode de stockage analogiques étaient en cours de développement. Ca ne simplifiera pas les choses.
le foveon sort 36 bit pixel, il suffirai de laisser a zero les poids faibles et compresser en LZW.
Et même là, je pense que sa dynamique n'est pas suffisemment étendu e pour 36 bits, mais je peu me tromper.
cependant, c'est toujours trop gros donc, Sigma ne fait pas ça et prefère utiliser une compression ration 2:1 destructrice...
Et ça, c'est vraiment con.
Et si on laissait les mouches tranquilles? Enfin pour ce que j'en dis...
ben j'aime bien comprendre les trucs...
Moi aussi, mais comme là on dirais qu'on retombé sur nos pattes, diso ns que je n'ai rien dit. En tous cas, ça décrasse les neurones, ça fai t du bien!
-- A+ François
Stephane Legras-Decussy
"Jean-Pierre Roche" a écrit dans le message de news: 4453506a$0$12876$
Tu fais bien puisque tu es incapable de différencier de l'information native de l'information traitée donc dégradée...
on dé-matrice trivialement (copie des voisins) un raw et on le colle dans un tiff16 standard sans *la moindre* transformation de donnée.
le moindre bit de ton raw reste intact et preservé.
c'est evident, je vois pas ce qui te dépasse là-dedans...
"Jean-Pierre Roche" <jpierreroche@sanspub.invalid> a écrit dans le message
de news: 4453506a$0$12876$626a54ce@news.free.fr...
Tu fais bien puisque tu es incapable de différencier de l'information
native de l'information traitée donc dégradée...
on dé-matrice trivialement
(copie des voisins) un raw et on le colle
dans un tiff16 standard sans *la moindre*
transformation de donnée.
le moindre bit de ton raw reste intact et preservé.
c'est evident, je vois pas ce qui
te dépasse là-dedans...
