Réduction d'un RAW ... en RAW

[olivier1010]

Pour revenir au format Raw, c'est un format qui pose des problèmes de pérennité et de dépendance.

Demandez aux utilisateurs de Photoshop CS6 s'ils sont heureux de ne pas pouvoir importer les raw des derniers boitiers (ils ne sont plus supportés par Camera Raw, le module d'importation raw utilisé par Photoshop).

Bien sur, la solution est de mettre à jour vers Photoshop CC

C'est un avantage supplémentaire de l'utilisation d'un format de fichier standard, comme le tiff 16 bits, dans lequel le dématriçage serait déjà réalisé, mais conservant l'espace couleur du boitier. Pas besoin de mise à jour des logiciels lorsqu'un nouveau boitier arrive sur le marché.

Le raw pose aussi des problèmes avec les capteurs exotiques, (fuji par exemple) pour lesquels le dématriçage n'est pas toujours réalisé avec une qualité optimale selon les logiciels utilisés.

On peut donc se demander pourquoi en 2016 on est toujours limité au JPEG sur les boitiers, pourquoi on a pas au moins un JPEG2000 ou PNG 16 bits avec support d'autres espaces couleurs que les préhistoriques sRGB et Adobe RGB, et pourquoi on a pas un format de fichier intermédiaire entre le raw et le JPEG, un tiff 16 bits en compression non destructive, dématricé, mais sans altération de l'espace couleur du boitier.

Avec les hautes résolutions actuelles des capteurs (30 Mpixels et plus) conserver la matrice dans les fichiers de prise de vue devient il me semble moins indispensable qu'auparavant lorsque les boitiers étaient limités à 12 Mpixels. D'où l'intérêt questionnable du fichier raw aujoud'hui si ce n'est pour un usage très haut de gamme.

[Samoreen]

Bien sur, la solution est de mettre à jour vers Photoshop CC

Et celle de la transformation en DNG que l'on oublie trop souvent ?

On peut donc se demander pourquoi en 2016 on est toujours limité au JPEG sur les boitiers, pourquoi on a pas au moins un JPEG2000 ou PNG 16 bits avec support d'autres espaces couleurs que les préhistoriques sRGB et Adobe RGB, et pourquoi on a pas un format de fichier intermédiaire entre le raw et le JPEG, un tiff 16 bits en compression non destructive, dématricé, mais sans altération de l'espace couleur du boitier.

Et le jour où on fera ça, on entendra gémir les utilisateurs qui ne comprendront pas pourquoi ça prend tant de temps pour transférer un fichier de 200 Mo ou plus de la mémoire tampon vers la carte mémoire et pourquoi les rafales sont si lentes et pourquoi ça chauffe au bout de 10 ou 15 images prises en continu. Il faudra des processeurs plus rapides, qui tireront plus sur la batterie, des cartes plus performantes et encore plus capacitives, etc.

D'où l'intérêt questionnable du fichier raw aujoud'hui si ce n'est pour un usage très haut de gamme.

C'est oublier les avantages essentiels du RAW et qui n'ont rien à voir avec une pratique haut de gamme :

- Possibilité de contrôler a posteriori le développement et de reprendre les réglages si nécessaire.
- Possibilité de développer plusieurs versions de la même image à partir du même "négatif".
- Possibilité de bénéficier après coup d'un meilleur algorithme de traitement au fur et à mesure des améliorations du logiciel.

Tout cela s'opposant au caractère définitif d'un développement "in-camera".

http://ppphoto.fr/docs/ | La Justification du Format RAW
http://ppphoto.fr/docs/ | Compléments sur le Format RAW

[olivier1010]

Et celle de la transformation en DNG que l'on oublie trop souvent ?

Et le jour où on fera ça, on entendra gémir les utilisateurs qui ne comprendront pas pourquoi ça prend tant de temps pour transférer un fichier de 200 Mo ou plus de la mémoire tampon vers la carte mémoire et pourquoi les rafales sont si lentes et pourquoi ça chauffe au bout de 10 ou 15 images prises en continu. Il faudra des processeurs plus rapides, qui tireront plus sur la batterie, des cartes plus performantes et encore plus capacitives, etc.

C'est oublier les avantages essentiels du RAW et qui n'ont rien à voir avec une pratique haut de gamme :

- Possibilité de contrôler a posteriori le développement et de reprendre les réglages si nécessaire.
- Possibilité de développer plusieurs versions de la même image à partir du même "négatif".
- Possibilité de bénéficier après coup d'un meilleur algorithme de traitement au fur et à mesure des améliorations du logiciel.

Tout cela s'opposant au caractère définitif d'un développement "in-camera".

http://ppphoto.fr/docs/ | La Justification du Format RAW
http://ppphoto.fr/docs/ | Compléments sur le Format RAW

- Oui la transformation en DNG... Encore plus de dépendance vis à vis du fournisseur et une opération en plus, avec une taille de fichier 2 fois plus importante pour incorporer le raw original...

- Un tiff 16 bits n'est pas tellement plus gros qu'un raw. Aujourd'hui on peut traiter et écrire de la vidéo 4k sur une compact flash. Donc le tiff 16 bits ne poserait pas de soucis.

- à part la matrice d'origine, un raw n'importe rien d'autre il me semble, par rapport à un tiff 16 bits dans l'espace couleur du boitier. La seule différence est la présence des 4 couches RGGB
Je maintiens que plus la résolution des capteurs sera importante, plus le raw deviendra inutile par rapport à un tiff 16 bits. Sauf usage très pointu.

[P!erre]

- Un tiff 16 bits n'est pas tellement plus gros qu'un raw. Aujourd'hui on peut traiter et écrire de la vidéo 4k sur une compact flash. Donc le tiff 16 bits ne poserait pas de soucis.

Je te laisse comparer la taille d'une minute de vidéo 4k en pleine qualité, et la taille en 16 bit de 300 tif (60 secondes * 5 i/sec, je suis gentil) d'un capteur de 40 Mpix. 

[Verso92]

- Un tiff 16 bits n'est pas tellement plus gros qu'un raw.

J'imagine que c'est une boutade ?

Pour un RAW en qualité max, c'est aujourd'hui 14 bits par pixel (en 24x36). Pour un TIFF 16 bits, c'est 16 x 3 = 48 bits par pixel...

On peut donc se demander pourquoi en 2016 on est toujours limité au JPEG sur les boitiers, pourquoi on a pas au moins un JPEG2000 ou PNG 16 bits avec support d'autres espaces couleurs que les préhistoriques sRGB et Adobe RGB [...]

J'imagine bien un Jpeg boitier en ProPhoto... on aurait pas fini d'avoir des questions des utilisateurs sur les couleurs bizarres sur leurs photos !!!

[P!erre]

J'imagine que c'est une boutade ?

Je me demande aussi si Olivier1010 sait de quoi il parle...

[gerarto]

...
- à part la matrice d'origine, un raw n'importe rien d'autre il me semble, par rapport à un tiff 16 bits dans l'espace couleur du boitier. La seule différence est la présence des 4 couches RGGB
Je maintiens que plus la résolution des capteurs sera importante, plus le raw deviendra inutile par rapport à un tiff 16 bits. Sauf usage très pointu.

Faut-il en rajouter une couche ?

La seule différence ? (enfin, presque la seule)

Oui, mais alors de taille ! 
C'est quand même étonnant qu'on arrive à lire des choses comme ça aujourd'hui !

[olivier1010]

Je me demande aussi si Olivier1010 sait de quoi il parle...

Puisque certains doutent, voici les tailles de fichier, obtenues à partir de la résolution du moment 6720 x 4480, soit celle d'un 5d markIV :

raw : 35 Mo

tiff non compressé, 16 bits : 172 Mo

tiff compression zip, 16bits : 155 Mo

JPEG2000 compression non destructive, 16 bits : 78 Mo

JPEG2000 compression destructive, qualité max 100, 16 bits :  65 Mo

JPEG2000 compression destructive, qualité 99, 16 bits :  4.6 Mo

JPEG2000 compression destructive, qualité 90, 16 bits :  3.5 Mo

JPEG2000 compression destructive, qualité 75, 16 bits : 1.9 Mo

On voit bien qu'en utilisant une compression de fichier moderne non destructive, ou bien une compression très faible, on arrive à une taille de fichier qui est loin d'être délirante par rapport à celle d'un raw, voir même largement plus petite pour la compression destructive.

Avec l'avantage d'un format standard qui ne nécessite pas de nouveaux logiciels a chaque fois qu'un nouveau boitier sort sur le marché. A noter que le JPEG2000 peut être encapsulé dans un conteneur tiff.
Maintenant si vous préférez à tout prix le raw et le marketing qui va avec, pourquoi pas...

Pour finir la résolution des capteurs risque fort d'augmenter encore un peu puis de se stabiliser, pour cause de limite physique en terme de bruit. Par contre les cartes mémoire et les processeurs vont continuer de progresser.

Je ne dis pas qu'il faut abandonner le raw, je dis simplement que pour la plupart des utilisations c'est un format qui est devenu élitiste. Un fichier 16 bits compressé avec une méthode de compression moderne, dans l'espace couleur du boitier, est tout aussi efficace, et plus petit.

Maintenant libre à vous de soutenir coute que coute des technologies qui vous lient intimement avec des fournisseurs, mais pour ma part je pense que les boitiers modernes devraient évoluer à ce niveau et proposer aussi le support d'un format de fichier dématricé, en 16 bits par canal, dans l'espace couleur du capteur, et compression non destructive ou légère.

Je dis aussi que le jpeg limité à 8 bits et sRGB ou AdobeRGB a fait son temps vous ne trouvez pas ?

[alafaille]

J'ai un peu de mal à comprendre ta démonstration chiffrée sur l'inutilité du raw car finalement la compression non destructive la plus performante revient quand même à doubler la taille du fichier  (et avec probablement moins de souplesse pour des corrections de type balance des blancs ?).

Si on part sur une option "compression destructive" que donnerait un png 16 bits en taille et qualité par rapport au jpg2000, sachant que le png est aujourd'hui bien plus répandu que le jpg2000 ( qui, pour x raisons, n'a jamais vraiment pris son envol).

Après, effectivement, on peut militer pour un "raw standard open source" pour limiter la prolifération des formats propriétaires mais là c'est un peu l'idée du dng d'Adobe non ? (non, pas taper et pas troller sur le dng).

[olivier1010]

J'ai un peu de mal à comprendre ta démonstration chiffrée sur l'inutilité du raw car finalement la compression non destructive la plus performante revient quand même à doubler la taille du fichier  (et avec probablement moins de souplesse pour des corrections de type balance des blancs ?).

Si on part sur une option "compression destructive" que donnerait un png 16 bits en taille et qualité par rapport au jpg2000, sachant que le png est aujourd'hui bien plus répandu que le jpg2000 ( qui, pour x raisons, n'a jamais vraiment pris son envol).

Après, effectivement, on peut militer pour un "raw standard open source" pour limiter la prolifération des formats propriétaires mais là c'est un peu l'idée du dng d'Adobe non ? (non, pas taper et pas troller sur le dng).

Le PNG est moins interessant en terme de compression. 172 Mo non compressé, 115 Mo compressé, contre 78 Mo pour le JPG2000. Cela dépend aussi des images.

Je ne vois pas pourquoi la balance des blancs serait moins performante dans un fichier 16 bits dématricé. A condition bien sur que les canaux ne soient pas écrêtés lors de l'enregistrement.

Le DNG n'est pas supporté non plus dans les boitiers des leaders.

Le raw est surtout utile pour obtenir la matrice du capteur afin d'optimiser le débruitage ou l'accentuation. Avec les résolutions actuelles, cela a de moins en moins de sens. A partir d'une décimation 1/2 je pense que le raw n'a plus guère d'utilité. Cela correspond quand même à 95 % des usages.

En tout cas je pense qu'un tel format de fichier RGB 16 bits en espace couleur natif, proposé pourquoi pas avec une option de décimation 1/2 et 1/4, satisferait beaucoup l'initiateur de ce fil.

[Samoreen]

Le raw est surtout utile pour obtenir la matrice du capteur afin d'optimiser le débruitage ou l'accentuation.

Désolé mais c'est une affirmation très réductrice. C'est comme comparer le monde de la photographie au temps des positifs directs avec l'époque des négatifs qui a suivi.

Personne ne va nier que l'on peut obtenir aujourd'hui des JPEGs de très bonne qualité. Là n'est pas la question : nous parlons photographie. Si l'objectif est de produire rapidement des images "qui vont bien", pourquoi pas. Un smartphone va souvent suffire. À partir du moment où on désire travailler ses images, tester plusieurs versions possibles, bénéficier de traitements améliorés sur le long terme (je récupère aujourd'hui des RAWs que j'aurais pu jeter il y a 6 ou 7 ans car jugés inexploitables), etc., rien ne remplace aujourd'hui le format RAW.

Affirmer que c'est un format superflu à réserver à je ne sais quelle élite est juste hors de propos. Dans les cours que nous donnons dans mon club, nous encourageons très fortement les stagiaires à utiliser le RAW. Ça n'implique aucune contrainte particulière et ça présente tellement d'avantages que je n'ai jamais vu un seul de nos adhérents revenir en arrière (même s'il reste quelques isolés à convaincre).

[P!erre]

- Un tiff 16 bits n'est pas tellement plus gros qu'un raw.

Puisque certains doutent, voici les tailles de fichier, obtenues à partir de la résolution du moment 6720 x 4480, soit celle d'un 5d markIV :

raw : 35 Mo

tiff non compressé, 16 bits : 172 Mo

tiff compression zip, 16bits : 155 Mo

Ah, ok ! Pas tellement plus gros, c'est tout de même 4.6 fois plus gros. Je comprends mieux ton point de vue.

Celui qui dépense par exemple CHF 750.- par an en stockage de photos (stockage et deux archives de sécurité, 30'000 images, 6 To) peut donc dépenser CHF 3'500.-, c'est pas tellement plus. Mmmm.... pas d'accord. 

[P!erre]

Je dis aussi que le jpeg limité à 8 bits et sRGB ou AdobeRGB a fait son temps vous ne trouvez pas ?

As-tu beaucoup de possibilités d'imprimer, d'afficher plus que 8 bits ?

[Verso92]

- Un tiff 16 bits n'est pas tellement plus gros qu'un raw.

Puisque certains doutent, voici les tailles de fichier, obtenues à partir de la résolution du moment 6720 x 4480, soit celle d'un 5d markIV :

raw : 35 Mo

tiff non compressé, 16 bits : 172 Mo

tiff compression zip, 16bits : 155 Mo

Honnêtement, Olivier, je ne comprends pas où tu veux en venir...

Edit : oups, doublon avec P!errre...

Je ne vois pas pourquoi la balance des blancs serait moins performante dans un fichier 16 bits dématricé.

?!!!

[olivier1010]

Honnêtement, Olivier, je ne comprends pas où tu veux en venir...

Edit : oups, doublon avec P!errre...

?!!!

Tout simplement que le format raw est une complication pas forcément nécessaire aujourd'hui pour la plupart des usages avec des résolutions de capteur si importante. Et que le format jpeg n'est pas non plus un format idéal pour sa limitation en terme de profondeur de quantification et son espace couleur figé sRGB ou Adobe RGB qui fait perdre la largeur de l'espace couleur original du boitier.

Pour rappel la résolution réelle d'un capteur avec matrice de bayer en filtrage passif, comme celui celui d'un 5d mk4 par exemple, n'est pas de 30 Mpixels mais un chiffre bien inférieur, lié à la matrice de Bayer.

On ne peut obtenir en filtrage passif (sans micro déplacement du capteur derrière le filtre pendant l'exposition) qu'environ la moitié du nombre de pixels annoncé (plus exactement la résolution réelle est environ 0.58 fois le nombre de pixels annoncés). C'est le nombre de photosites nécessaires par pixel qui dicte cette limitation physique. Sur une matrice de bayer classique il faut 4 photosites pour un pixel.

Voir ici par exemple :

http://lagemaat.blogspot.fr/2007/09/actual-resolution-of-bayer-sensors-you.html

.

Pour cette raison on peut certainement utiliser un fichier avec une décimation 1/2 pendant le dématriçage (opération simple mathématiquement), sans perdre grand chose en terme de résolution réelle. Ce qui ramène les poids de fichier à :

- tiff 16 bits non compressé : 43 Mo

- jpeg2000 16 bits en compression non destructive : 27 Mo

.

On est maintenant à une taille de fichier plus petite que le raw, sans perdre grand chose en terme de souplesse de traitement (balance des blancs, post traitement sur les valeurs de luminance, modification de l'espace couleur).
Cela implique d'appliquer deux traitements pendant le dématriçage (réduction de bruit, accentuation), ce que certains fabricants de boitiers ne se privent pas de faire, et ce qui il me semble ne pose pas de problèmes particulier, sachant qu'il est préférable d'appliquer ces traitements en trois étapes (prise de vue, traitement artistique, visualisation).

L'inconvénient évidemment est que le traitement du bruit et l'accentuation à la prise de vue sont figés dans le fichier de prise de vue. Mais est ce un gros problème pour la plupart des images, sachant qu'on pourrait aussi agir sur un réglage à ce niveau pour ces traitements internes au boitier (comme on peut le faire d'ailleurs avec les styles d'images en jpeg).

.
Pour les cas où la gestion du bruit ou de l'accentuation doit satisfaire des exigences et une souplesse particulières, il est certes préférable d'utiliser un raw, mais pour la plupart des situations, il me semble qu'un fichier 16 bits en compression non destructive, dans l'espace couleur du capteur, avec éventuellement une décimation, est pratiquement aussi performant et aussi souple qu'un raw, avec la complication et la dépendance vis à vis d'un fournisseur en moins, et sans grande différence en terme de poids de fichier, si ce n'est un fichier possiblement plus petit que le raw.

Un autre avantage est la simplicité pour réduire la taille de ce fichier. Réduire un raw n'est pas possible, sauf dans le boitier comme un choix avant la prise de vue, si l'on choisit un raw réduit. Au prix d'un support encore moins large que le raw dans les logiciels de traitement. Combien de temps a t'il fallu attendre pour avoir le support du mRaw et du sRaw dans la plupart des logiciels, sauf ceux du fabricant du boitier ??

Je comprends que le raw soit un outil intéressant, mais sa complication et sa non standardisation font qu'il n'est pas du tout recommandé voir banni dans certains domaines, comme le journalisme ou l'archivage.

Pour ceux qui ne veulent pas trop se compliquer la vie et qui sont sensibles à la pérennité et au potentiel de leurs fichiers, un format standard plus performant que le jpeg 8 bits serait le bienvenu il me semble dans les boitiers actuels....

Peut être par une mise à jour firmware bientôt ?

[gerarto]

J'hallucine un peu quand même !

Laisser croire qu'il faille 4 photosites pour faire un pixel est de la désinformation !
Un photosite = un pixel, définitivement !

Après qu'on admette que les valeurs RVB d'un pixel soient obtenues par "déduction" à partir des photosites voisins de la matrice RVVB est parfaitement exact
Sauf que pour chaque pixel une des trois valeurs est juste (celle correspondant au filtre), et les deux autres déduites avec une marge d'erreur qui doit être quand même plus que réduite vu la qualité de ce que l'on obtient...
Et encore plus maintenant qu'il commence à ne plus y avoir de filtre passe bas sur nombre de capteurs.

Je ne comprends toujours pas cet acharnement contre les raw, qui ne date pas d'hier et qui n'a aucun sens, surtout quand on voit les solutions de contournement proposées et leurs impasses.

Il n'y a rien de plus simple qu'un raw en terme de poids de fichier comparé à la somme de ses possibilités !

[Verso92]

Tout simplement que le format raw est une complication pas forcément nécessaire aujourd'hui pour la plupart des usages avec des résolutions de capteur si importante. Et que le format jpeg n'est pas non plus un format idéal pour sa limitation en terme de profondeur de quantification et son espace couleur figé sRGB ou Adobe RGB qui fait perdre la largeur de l'espace couleur original du boitier.

Pour rappel la résolution réelle d'un capteur avec matrice de bayer en filtrage passif, comme celui celui d'un 5d mk4 par exemple, n'est pas de 30 Mpixels mais un chiffre bien inférieur, lié à la matrice de Bayer.

On ne peut obtenir en filtrage passif (sans micro déplacement du capteur derrière le filtre pendant l'exposition) qu'environ la moitié du nombre de pixels annoncé (plus exactement la résolution réelle est environ 0.58 fois le nombre de pixels annoncés). C'est le nombre de photosites nécessaires par pixel qui dicte cette limitation physique.

?

Quel mélange dans ta tête...

Sur une matrice de bayer classique il faut 4 photosites pour un pixel.

Définitivement, non !

En terme de luminance, 1 photosite = 1 pixel.

En terme de chrominance, les couleurs sont reconstruites à partir des pixels avoisinants, c'est vrai. Mais ça ne se limite pas aux quatre photosites RVVB du motif élémentaire de la matrice, fort heureusement (les résultats seraient bien trop pauvres) !

Pour cette raison on peut certainement utiliser un fichier avec une décimation 1/2 pendant le dématriçage (opération simple mathématiquement), sans perdre grand chose en terme de résolution réelle. Ce qui ramène les poids de fichier à :

- tiff 16 bits non compressé : 43 Mo

- jpeg2000 16 bits en compression non destructive : 27 Mo

En partant d'hypothèses fausses, on obtient des conclusions fausses, sans surprise...

Un autre avantage est la simplicité pour réduire la taille de ce fichier. Réduire un raw n'est pas possible, sauf dans le boitier comme un choix avant la prise de vue, si l'on choisit un raw réduit. Au prix d'un support encore moins large que le raw dans les logiciels de traitement. Combien de temps a t'il fallu attendre pour avoir le support du mRaw et du sRaw dans la plupart des logiciels, sauf ceux du fabricant du boitier ??

Hors sujet : les mRAW et sRAW ne sont pas des RAW (il faudra bien un jour que certains fabricants n'emploient pas des termes techniques entretenant la confusion...).

[olivier1010]

?

Quel mélange dans ta tête...

Définitivement, non !

En terme de luminance, 1 photosite = 1 pixel.

En terme de chrominance, les couleurs sont reconstruites à partir des pixels avoisinants, c'est vrai. Mais ça ne se limite pas aux quatre photosites RVVB du motif élémentaire de la matrice, fort heureusement (les résultats seraient bien trop pauvres) !

En partant d'hypothèses fausses, on obtient des conclusions fausses, sans surprise...

Hors sujet : les mRAW et sRAW ne sont pas des RAW (il faudra bien un jour que certains fabricants n'emploient pas des termes techniques entretenant la confusion...).

Si le Bayer est si performant, pourquoi a t'on conservé le tri CCD sur les caméras pro, jusqu'au jour où les capteurs bayer ont pu se doter d'un très grand nombre de photosites pour compenser la perte du filtre ?

Un photosite filtré n'est pas égal à un pixel en terme de luminance. Le rapport signal / bruit n'est pas le même, il est impacté par le filtrage. Sinon a quoi bon utiliser des capteurs monochromes pour faire du N&B ou de l'astronomie si un Bayer était équivalent ?

Vous avez des détails sur la structure du mRaw et du sRaw ? Comment sont ils réalisés exactement ?

[Verso92]

Si le Bayer est si performant, pourquoi a t'on conservé le tri CCD sur les caméras pro, jusqu'au jour où les capteurs bayer ont pu se doter d'un très grand nombre de photosites pour compenser la perte du filtre ?

Mais, Olivier, il n'est pas question ici de "défendre" le Bayer... c'est une solution astucieuse qui permet au bout du compte de sortir d'excellents résultats, avec les défauts qu'on connait.

Sur le papier, la solution du Foveon est plus performante, par exemple... mais avec les défauts que, là aussi, on connait.

Un photosite filtré n'est pas égal à un pixel en terme de luminance. Le rapport signal / bruit n'est pas le même, il est impacté par le filtrage. Sinon a quoi bon utiliser des capteurs monochromes pour faire du N&B ou de l'astronomie si un Bayer était équivalent ?

Oui, toutafé. D'ailleurs, en photographie générale, on peut même comparer les deux technos (avec et sans filtre). Leica propose son appareil fétiche (le M) en deux versions : une filtrée (type 240) et une défiltrée (le Monochrom, type 246)...

Vous avez des détails sur la structure du mRaw et du sRaw ? Comment sont ils réalisés exactement ?

Il y avait eu un article à l'époque (en anglais, et on s'était accroché sur le forum sur certains aspects de la traduction, d'ailleurs), à l'occasion de la sortie du boitier Canon les embarquant. Il faudrait le retrouver...

[P!erre]

Tout simplement que le format raw est une complication pas forcément nécessaire aujourd'hui pour la plupart des usages avec des résolutions de capteur si importante. Et que le format jpeg n'est pas non plus un format idéal pour sa limitation en terme de profondeur de quantification et son espace couleur figé sRGB ou Adobe RGB qui fait perdre la largeur de l'espace couleur original du boitier.

Pourquoi le raw serait-il une complication ? C'est avant tout un fichier plein de potentialités, spécialement en cas de lumière difficile. Le raw n'a aucune raison de disparaître ou d'être délaissé par les développeurs, sachant qu'il y a des milliards et des milliards de fichiers en circulation qui n'attendent que de meilleurs algorithmes au fil des ans pour en délivrer à chaque fois un ultime plus ultime.

Quand je développe mes raw et que j'en fait des tif 16 bit pleins de calques, je peux bosser dessus à loisir et pour finir, j'en fais des jpg faciles à transmettre ou à archiver, lorsque ce sont des versions finales. Et là, le 8 bit suffit tout à fait, puisque de toute manière pas grand-monde pourrait trouver utile d'extraire plus de 8 bits de mes fichiers finalisés.

Ces comparaisons me font toujours penser aux approches du son, où certains ne jurent que par une dynamique énorme. Ils se plaignaient de la dynamique du CD, trouvaient génial le son en 24 bits. Sauf que sur un CD, la dynamique théorique atteint 90 dB et il faut des conditions exceptionnelles pour arriver à obtenir un enregistrement audio dont la dynamique réelle dépasse 60 - 64 dB. Aller bien au delà de 90 dB n'a aucun intérêt réel en matière de son.

Dépasser 3 x 8 bits pour une image post traitée n'a aucun intérêt pratique actuellement, et pour longtemps encore pour le commun des mortels.

Le couple raw dans le boîtier --> jpg pour la transmission des fichiers traités est le plus efficace.

[P!erre]

L'inconvénient évidemment est que le traitement du bruit et l'accentuation à la prise de vue sont figés dans le fichier de prise de vue. Mais est ce un gros problème pour la plupart des images, sachant qu'on pourrait aussi agir sur un réglage à ce niveau pour ces traitements internes au boitier (comme on peut le faire d'ailleurs avec les styles d'images en jpeg).

Heu, pour moi, le traitement du bruit et de l'accentuation ne peuvent se faire dans l'APN.

Le bruit est finement traité avec DXO. Pour les plus belles images, l'accentuation est gérée par calques avec différents réglages de DXO dans PS, au besoin avec des sélection pour éviter des effets de bord.

Que le raw est bien pour tout cela ! 

[Samoreen]

Sur une matrice de bayer classique il faut 4 photosites pour un pixel.

Légende urbaine que l'on peut également lire dans certains ouvrages comme le bouquin de Sascha Erni sur C1 :

Sensors with microfilter arrays are by far the most widely used in today's cameras, offering average pixel sharpness as a trade-off for greater light sensitivity. This approach requires two or three sensor pixels to produce a single pixel of color image data— in other words, image resolution is one half or a third of the nominal resolution of the sensor.

Lui, il ne dit pas 4 il dit juste 2 ou 3. Ce genre d'affirmation démontre simplement une certaine incompréhension de ce qu'est le processus de dématriçage. Une matrice de Bayer n'enregistre pour un photosite qu'une seule composante par couleur (R, V ou B) et il faut donc calculer (interpoler) les 2 autres. De là à en conclure qu'il faut 4 photosites pour produire un pixel, il y a quand même une grosse exagération. On peut à la limite constater que chaque photosite sert plusieurs fois dans le calcul des 2 composantes manquantes de (4 ?) sites voisins.

On peut aussi admettre qu'une interpolation est toujours une source d'erreur possible et que son résultat peut s'éloigner de la réalité mais la marge d'erreur doit être du même ordre de grandeur que les défauts induits par l'optique.

[Oooops! Doublon avec gerarto]

[Samoreen]

On peut à la limite constater que chaque photosite sert plusieurs fois dans le calcul des 2 composantes manquantes de (4 ?) sites voisins.

On peut d'ailleurs considérer qu'une exploration plus profonde des photosites voisins permettraient d'améliorer la précision. Pourquoi se contenter de 4 photosites voisins ? C'est peut-être même déjà fait. Le tout est d'arriver à un équilibre entre précision de l'interpolation et temps de calcul qui croît exponentiellement avec le nombre de photosites voisins pris en compte. Quand nous franchirons une nouvelle étape en matière de performances, peut-être verrons-nous apparaître des algorithmes encore plus précis ?

[restoc]

+1
Il est clair que 4 photosites en entrée de dématriçage = 4 pixels en sortie de dématriçage dans le fichier raw ... chez tous les constructeurs d'APN .
La définition du capteur est conservée entre l'entrée et la sortie du dématriceur. Par ex 20 Mphotosites = 20 Mpix. ( NB les constructeurs pourraient tout aussi bien privilégier le Rapport S/ B notamment sur le canal rouge et bleu et décider de  fusionner 2 photosites ou 4,  en 1 seul pixel. Mais là ce ne serait pas terrible côté marketing !).

L'erreur de ceux qui disent le contraire est de ne pas connaître ce que fait le dématriçage, à savoir affecter à chaque photosite 3 valeurs séparées R, V et B et non plus une seule.

Ils font confusion avec le fait que la "résolution couleur vraie" ( et non plus la définition) ne peut être éffectivement qu'inférieure à la résolution théorique correspondant à la définition.   

Rien n'interdit en effet de dématricer sur une matrice plus grande que 4 pixels et c'est probablement déjà utilisé en haut isos chez certains.
Mais le temps de calcul  vs le gain en profondeur ( nb de bits significatifs)  n'a peut être que peu d'intérêt si le capteur est très propre en S/B. ...déjà que certains avec 12 ou 14 bits par voie rvb ne savent pas trop qu'en faire ...

[Verso92]

On peut d'ailleurs considérer qu'une exploration plus profonde des photosites voisins permettraient d'améliorer la précision. Pourquoi se contenter de 4 photosites voisins ? C'est peut-être même déjà fait. Le tout est d'arriver à un équilibre entre précision de l'interpolation et temps de calcul qui croît exponentiellement avec le nombre de photosites voisins pris en compte. Quand nous franchirons une nouvelle étape en matière de performances, peut-être verrons-nous apparaître des algorithmes encore plus précis ?

Il y a bien longtemps que les algos de dématriçage se servent des pixels débordant du triplet au voisinage direct du photosite en question...

Mes lectures en diagonales parlaient plutôt d'algorithme du gradient mis en œuvre sur neuf pixels au moins (d'ailleurs, il suffit de jeter un œil à la tronche d'un pixel mort pour avoir une petite idée).