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

[Verso92]

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.

De toute façon, il semblerait qu'il ne soit pas possible d'imprimer avec une profondeur supérieure à 8 bits sous Windows (sauf manips complexes)...

[olivier1010]

De toute façon, il semblerait qu'il ne soit pas possible d'imprimer avec une profondeur supérieure à 8 bits sous Windows (sauf manips complexes)...

C'est possible principalement avec un RIP disposant d'une vraie trame 16 bits. Adobe propose cette option nommée "StudioRip" dans leur librairie PDF Print Engine.

A ma connaissance c'est le seul RIP qui spécifie clairement une trame 16 bits en sortie. D'autres RIP supportent le 16 bits en entrée, mais sans donner de détails sur ce qu'il se passe au niveau de la trame de sortie.

http://www.datalogics.com/products/studiorip/

Évidemment pour avoir un vrai 16 bits il ne suffit pas de supporter du 16 bits en entrée, il faut aussi une trame capable de représenter ces valeurs en sortie.

Les avis divergent en ce qui concerne l'apport du 16 bits sur un RIP. Cela dit je ne suis pas certain qu'il soit implémenté de bout en bout sur les RIP ou drivers d'impression disponible actuellement dans les produits commerciaux courants. Il faudra donc attendre un peu avant d'avoir un jugement valable de l'apport du 16 bits à l'impression.

Il faut aussi une imprimante qui supporte l'adressage des buses en mode direct (mode 1 bit). Ce qui limite en pratique aux imprimantes pro grand format.

Quand aux applications sous Windows, elles ne supportent pas pour la plupart l'impression 16 bits (driver XPS en mode 16 bits). Il faut donc passer par un fichier tiff ou psd 16 bits et l'envoyer vers un RIP.

Canon a bien un driver XPS 16 bits sous Windows, mais son utilisation est rendu aléatoire par la nécessité soit d'une application compatible 16 bits XPS, soit l'existence d'un plugin pour imprimer en 16 bits depuis une application non compatible XPS, avec les problèmes de compatibilité et de disponibilité que cela pose. De plus la trame qu'il produit n'est à ma connaissance absolument pas documentée.

[olivier1010]

Pour revenir au mRaw et sRaw, selon l'auteur de DCRaw qui a effectué sur ces formats un gros travail de reverse engineering,  ils utilisent un sous échantillonnage chroma semblable au 4:2:2 pour le sRaw et 4:2:0 pour le mRaw.

A cause de ce sous échantillonnage et du codage sous une forme similaire à YCbCr, l'espace couleur résultant n'est pas clairement défini, en fait ce n'est même pas un vrai espace couleur au sens mathématique car les valeurs de codage ne définissent pas rigoureusement une couleur.

En pratique, ces deux formats ont moins de précision colorimétrique dans les très bas niveaux. Cela se manifeste très visiblement lorsque les ombres sont fortement remontées lors du développement.

Donc même s'ils permettent de réduire la taille de fichier et de conserver une résolution raisonnable, on ne peut pas les comparer à un vrai raw, ils sont moins performants sur le plan de la colorimétrie et posent certainement plus de problème à ce niveau qu'un fichier moins trafiqué comme un tiff 16 bits dématricé (éventuellement décimé) dans l'espace couleur du capteur.

Selon, Douglas A. Kerr, ces formats de fichier ne sont pas d'un niveau technique suffisant pour gagner un prix dans une école scientifique de niveau intermédiaire

Cela montre qu'ils ont été conçus certainement sans grande attention, pour fournir (en 2007) une alternative plus petites aux Raw qui à l'époque représentaient encore une taille non négligeable par rapport aux capacités des cartes mémoire (de mémoire 4 à 16 Gb en Compact Flash).

En clair, même si leur usage peut s'avérer pratique dans certains cas lorsque la taille de fichier est primordiale et qu'une souplesse de traitement est requise, il ne faut pas en attendre une performance similaire à un raw en terme de précision colorimétrique et certainement de capacité de traitement du bruit.

Infos principalement en provenance de Douglas A. Kerr, un ingénieur télécom passionné de photo numérique.

dougkerr.net/Pumpkin/articles/sRaw.pdf

Des tests comparitifs Raw, mRaw, sRaw qui montrent les problèmes de colorimétrie du mRaw et sRaw :
https://www.slrlounge.com/canon-raw-image-size-and-dynamic-range-comparison/
Et des infos techniques sur le Raw :

http://lclevy.free.fr/cr2/

[Verso92]

Pour revenir au mRaw et sRaw, selon l'auteur de DCRaw qui a effectué sur ces formats un gros travail de reverse engineering,  ils utilisent un sous échantillonnage chroma semblable au 4:2:2 pour le sRaw et 4:2:0 pour le mRaw.

A cause de ce sous échantillonnage et du codage sous une forme similaire à YCbCr, l'espace couleur résultant n'est pas clairement défini, en fait ce n'est même pas un vrai espace couleur au sens mathématique car les valeurs de codage ne définissent pas rigoureusement une couleur.

En pratique, ces deux formats ont moins de précision colorimétrique dans les très bas niveaux. Cela se manifeste très visiblement lorsque les ombres sont fortement remontées lors du développement.

Donc même s'ils permettent de réduire la taille de fichier et de conserver une résolution raisonnable, on ne peut pas les comparer à un vrai raw, ils sont moins performants sur le plan de la colorimétrie et posent certainement plus de problème à ce niveau qu'un fichier moins trafiqué comme un tiff 16 bits dématricé (éventuellement décimé) dans l'espace couleur du capteur.

Selon, Douglas A. Kerr, ces formats de fichier ne sont pas d'un niveau technique suffisant pour gagner un prix dans une école scientifique de niveau intermédiaire

Cela montre qu'ils ont été conçus certainement sans grande attention, pour fournir (en 2007) une alternative plus petites aux Raw qui à l'époque représentaient encore une taille non négligeable par rapport aux capacités des cartes mémoire (de mémoire 4 à 16 Gb en Compact Flash).

En clair, même si leur usage peut s'avérer pratique dans certains cas lorsque la taille de fichier est primordiale et qu'une souplesse de traitement est requise, il ne faut pas en attendre une performance similaire à un raw en terme de précision colorimétrique et certainement de capacité de traitement du bruit.

Infos principalement en provenance de Douglas A. Kerr, un ingénieur télécom passionné de photo numérique.

dougkerr.net/Pumpkin/articles/sRaw.pdf

Des tests comparitifs Raw, mRaw, sRaw qui montrent les problèmes de colorimétrie du mRaw et sRaw :
https://www.slrlounge.com/canon-raw-image-size-and-dynamic-range-comparison/
Et des infos techniques sur le Raw :

http://lclevy.free.fr/cr2/

Oui, c'est bien le souvenir que j'en avais, à la louche...

[olivier1010]

Oui, c'est bien le souvenir que j'en avais, à la louche...

On peut en conclusion dire que le mRaw et sRaw peuvent être utiles dans certains cas, mais pas spécialement très performant sur le plan de la colorimétrie et vraisemblablement du traitement du bruit lorsqu'on a besoin de tirer sur les curseurs ou de réaliser des opérations complexes sur l'image.
En clair il doit y avoir moyen de produire des raw réduits nettement plus performants, à la fois en taille de fichier et en performance colorimétrique, que ce que Canon a proposé en 2007 et qui est toujours disponible aujourd'hui.

Peut être en utilisant une technique de combinaison des pixels et un format de compression moderne (wavelet par exemple) permettant de conserver l'espace couleur et une définition proche du raw original.
Cela dit je suis persuadé aussi qu'un format de fichier plus simple (16 bits RGB, compressé ou non, dans un espace couleur proche du capteur)  a sa place au sein des boitiers. Il aurait l'avantage d'être facilement décimable (abaissement de la résolution) et directement supporté dans la plupart des logiciels et des RIP.

La possibilité de décimation dans le boitier reste importante à mon sens, car tout le monde n'a pas besoin de conserver 30 ou 50 millions de photosites dans ses fichiers, en journalisme courant par exemple. Mais il peut être souhaitable de conserver presque toute la performance du raw original lorsqu'il est nécessaire de fortement corriger une image.

Le tout sans aller jusqu'à un raw réduit haute performance qui nécessiterait un travail de développement important (et des retards d'implémentations dans les logiciels de développement).

[gerarto]

C'est manifestement ce que fait Sony avec ses raw "compressés" des Boîtiers A7x, mais qui restent de vrais raw avec perte minime. Et aucun problème avec les logiciels tiers puisqu'ils les prennent en charge (C1, DxO, LR...)

Un scandale absolu vu le prix des boîtiers, qui a secoué le web : quoi, Sony n'offre pas la possibilité d'avoir des "vrais" raw ?   

Moyennant quoi Sony a rajouté le raw brut par nouveau firmware.
Et probablement 99,9 % des râleurs - et des autres - continuent à faire avec avec les raw "compressés" parce qu'ils ont le plus grand mal à voir une différence entre les deux raw, sauf cas très pointus (astro, très hauts iso ?). Et tout ça avec un poids de fichier pratiquement divisé par deux... 

[P!erre]

Je me suis posé la question des arw de l'A7RII. Les fichiers originaux sont lourds... que risque-t-on et dans quelles conditions en compressant ?

Je n'ai pas trouvé une véritable réponse.

[gerarto]

Je me suis posé la question des arw de l'A7RII. Les fichiers originaux sont lourds... que risque-t-on et dans quelles conditions en compressant ?

Je n'ai pas trouvé une véritable réponse.

J'ai fait quelques essais au début, pas réellement trouvé de différence entre non compressés et compressés, donc je suis resté en compressé. Comme ça diminue en gros par 2 le poids du raw...

Après quelqu'un qui est au limites : photos de nuit en hauts iso ou astro par exemple a probablement intérêt à être en non compressé.
Un de ces jours, j'essayerai de faire un test dans ces conditions pour voir...

[Verso92]

J'ai fait quelques essais au début, pas réellement trouvé de différence entre non compressés et compressés, donc je suis resté en compressé. Comme ça diminue en gros par 2 le poids du raw...

Après quelqu'un qui est au limites : photos de nuit en hauts iso ou astro par exemple a probablement intérêt à être en non compressé.
Un de ces jours, j'essayerai de faire un test dans ces conditions pour voir...

Curieux que Sony n'ait pas adopté la solution Nikon, à savoir "RAW compressé sans perte" : le beurre et l'argent du beurre !

[olivier1010]

C'est manifestement ce que fait Sony avec ses raw "compressés" des Boîtiers A7x, mais qui restent de vrais raw avec perte minime. Et aucun problème avec les logiciels tiers puisqu'ils les prennent en charge (C1, DxO, LR...)

Un scandale absolu vu le prix des boîtiers, qui a secoué le web : quoi, Sony n'offre pas la possibilité d'avoir des "vrais" raw ?   

Moyennant quoi Sony a rajouté le raw brut par nouveau firmware.
Et probablement 99,9 % des râleurs - et des autres - continuent à faire avec avec les raw "compressés" parce qu'ils ont le plus grand mal à voir une différence entre les deux raw, sauf cas très pointus (astro, très hauts iso ?). Et tout ça avec un poids de fichier pratiquement divisé par deux... 

Le raw compressé Sony utilise peut être une compression non destructive ? Avec une technique moderne il doit être possible de descendre à environ la moitié de la taille du fichier original en non destructif. C'est ce que permet en gros le format JPEG2000 en compression non destructive.

[Verso92]

Avec une technique moderne il doit être possible de descendre à environ la moitié de la taille du fichier original en non destructif.

Sur le Nikon D810 (14 bits) :
- RAW non compressé : 73,2 Mo.
- RAW compressé sans perte : 40,7 Mo (moyenne).
- RAW compressé avec pertes : 36,3 Mo (moyenne).

(source Nikon)

[gerarto]

Je me suis posé la question des arw de l'A7RII. Les fichiers originaux sont lourds... que risque-t-on et dans quelles conditions en compressant ?

Je n'ai pas trouvé une véritable réponse.

J'ai trouvé un début de réponse ici, et ça correspond bien à mes impressions de l'époque sur des "tests" qui étaient loin d'être aussi poussés :

http://sebimagery.com/blog/2016/2/21/sony-raw-compressed-versus-uncompressed

Curieux que Sony n'ait pas adopté la solution Nikon, à savoir "RAW compressé sans perte" : le beurre et l'argent du beurre !

Une avis/analyse sur la compression Sony en deuxième partie de cette page.
C'est un peu trop pointu pour mes connaissances en la matière...
http://www.rawdigger.com/howtouse/sony-craw-arw2-posterization-detection

[olivier1010]

Curieux que Sony n'ait pas adopté la solution Nikon, à savoir "RAW compressé sans perte" : le beurre et l'argent du beurre !

Il est très probable que la compression sans perte d'un raw en temps réel (ou à un rythme compatible avec la taille du buffer) nécessite une puissance de calcul qui impose soit un algorithme optimisé, soit un processeur optimisé, ce que Sony n'a peut être pas, ou qu'ils ne souhaitent pas investir à ce niveau.

On voit bien le niveau de puissance nécessaire lorsqu'on sauve un fichier en JPEG2000 avec compression sans perte, sur un PC. C'est long.... Malgré une horloge à 2 Ghz ou plus. Il faut donc un processeur capable de traiter cela dans le boitier, mais en dix fois plus rapide, avec une fréquence d'horloge vraisemblablement plus faible... Ce qui possiblement demande une architecture parallèle assez massive, avec la programmation qui va avec.

[Verso92]

Une avis/analyse sur la compression Sony en deuxième partie de cette page.
C'est un peu trop pointu pour mes connaissances en la matière...
http://www.rawdigger.com/howtouse/sony-craw-arw2-posterization-detection

Justement : en choisissant "compressé sans perte", on s'affranchit des pertes éventuelles (tranquillité d'esprit) tout en bénéficiant de fichiers beaucoup moins lourds...

Il est très probable que la compression sans perte d'un raw en temps réel (ou à un rythme compatible avec la taille du buffer) nécessite une puissance de calcul qui impose soit un algorithme optimisé, soit un processeur optimisé, ce que Sony n'a peut être pas, ou qu'ils ne souhaitent pas investir à ce niveau.

Faut pas charrier : cette possibilité existe depuis pas mal de temps sur les reflex Nikon, ce qui en dit long sur la "puissance de calcul" nécessaire...

[olivier1010]

Justement : en choisissant "compressé sans perte", on s'affranchit des pertes éventuelles (tranquillité d'esprit) tout en bénéficiant de fichiers beaucoup moins lourds...

Faut pas charrier : cette possibilité existe depuis pas mal de temps sur les reflex Nikon, ce qui en dit long sur la "puissance de calcul" nécessaire...

Sony préfère également peut être utiliser la puissance disponible pour d'autres fonctions, notamment trafiquer le raw, historiquement c'est ce que fait Sony non ?

[gerarto]

Sony préfère également peut être utiliser la puissance disponible pour d'autres fonctions, notamment trafiquer le raw, historiquement c'est ce que fait Sony non ?

Heu... trafiquer le raw, ça veut dire quoi ?

Jamais entendu parler de "trafiquage" de raw par Sony !
Tout au plus d'une réduction du bruit au plus près de la source (avant conversion A/N) de par la conception de ses capteurs (ce qui n'était pas possible avec les capteurs Canon).

Maintenant, historiquement aucun raw Sony n'était trafiqué dans le sens de "compressé" ! Depuis les premiers reflex Sony (A100/ A700 /A900) jusqu'à récemment, les raw étaient tout ce qu'il y a de plus normaux, sans compression.

[gerarto]

Il est très probable que la compression sans perte d'un raw en temps réel (ou à un rythme compatible avec la taille du buffer) nécessite une puissance de calcul qui impose soit un algorithme optimisé, soit un processeur optimisé, ce que Sony n'a peut être pas, ou qu'ils ne souhaitent pas investir à ce niveau.
...

Qu'elle soit sans perte ou avec perte, le "temps perdu" à la compression est compensé par "temps gagné" à l'enregistrement, non ?

Et concernant Sony, je ne vois pas en quoi la compression "avec pertes à la Sony" serait plus économe en puissance de calcul qu'un compression sans perte.
Sachant que si Sony a choisi cette méthode, ils devaient probablement avoir leur petite idée sur la chose, il ne faut quand même pas les prendre pour des perdreaux de l'année...

Sur le Nikon D810 (14 bits) :
- RAW non compressé : 73,2 Mo.
- RAW compressé sans perte : 40,7 Mo (moyenne).
- RAW compressé avec pertes : 36,3 Mo (moyenne).

(source Nikon)

Là où l'on voit que la compression Sony est quand même assez efficace, c'est qu'elle amène pour un A7RII à une valeur de 41.0 Mo en moyenne, quasiment identique à celle du raw non compressé sans perte de Nikon... mais pour un raw de 42 Mpix vs un de 36 Mpix. Soit un gain supplémentaire de 16% si mes calculs sont bons.

D'après ce que j'ai compris de la compression Sony - dont la dénomination exacte est "11+7 bits" - c'est qu'elle ne crée des pertes que là où c'est quasiment invisible.  

[Edit] Il semble d'ailleurs d'après ce que j'ai pu lire que la compression "lossy" de Sony ne soit pas du tout du même type que les compressions à perte de Canon / Nikon. D'ailleurs DxO prend en charge sans sourciller le format compressé de Sony alors qu'il refuse de prendre en charge les sRaw et mRaw de Canon et les sRaw de Nikon.   

[olivier1010]

Heu... trafiquer le raw, ça veut dire quoi ?

Jamais entendu parler de "trafiquage" de raw par Sony !
Tout au plus d'une réduction du bruit au plus près de la source (avant conversion A/N) de par la conception de ses capteurs (ce qui n'était pas possible avec les capteurs Canon).

Maintenant, historiquement aucun raw Sony n'était trafiqué dans le sens de "compressé" ! Depuis les premiers reflex Sony (A100/ A700 /A900) jusqu'à récemment, les raw étaient tout ce qu'il y a de plus normaux, sans compression.

Pour les très hautes sensibilités, le raw Sony serait modifié numériquement :

Voir ici par exemple :

http://blog.kasson.com/?p=6762

[gerarto]

Pour les très hautes sensibilités, le raw Sony serait modifié numériquement :

Voir ici par exemple :

http://blog.kasson.com/?p=6762

Bon, ce genre de "découverte" me laisse un peu sceptique quand c'est un cas unitaire...
Et quand ce n'est pas corroboré par des pointures comme DxO Mark.
Par ailleurs, mon anglais technique est insuffisant pour me permettre de juger de la pertinence ou pas de la chose dans un domaine extrêmement pointu...

Après personne n'a dit que le bruit ne faisait pas l'objet de traitement particulier au niveau du raw, surtout avec un boîtier champion des hauts iso et "étudié pour" !
Il y a une nuance de taille entre "modifier numériquement le raw" qui laisse entendre qu'on triche avec les données capteurs et "traiter le bruit" au plus près de la source, bruit qui évidemment vient perturber le signal capté et n'en fait pas partie
Et que ce traitement du bruit se fasse éventuellement par paliers n'aurait vraiment rien d'étonnant ni de scandaleux.