pb: une image de 30 Mpixels peut elle faire également 30 Moctets ?

[rsp]

Et pourquoi donc le raw non compressé n'existerait généralement pas ?

Il se trouve que les raw des dernières version des Sony A7 peuvent être au choix :
- soit compressés à la mode Sony ARV 2.3.x, compression avec perte de type 11bits + 7.
- soit NON COMPRESSES, donc absolument "intacts". J'insiste sur le non-compressé parce que justement il a été reproché à Sony de ne pas le proposer "compressé sans perte".

Il y a une dizaine de formats RAW dont 2 apparemment, un NIKON et un SONY, ne sont pas compressés, ce qui est considéré comme une aberration par tout le monde.
D'où le "généralement".
SI le terme ne te va pas je ferai une recherche demain dans le dictionnaire des synonymes, désolé.

[gerarto]

Il y a une dizaine de formats RAW dont 2 apparemment, un NIKON et un SONY, ne sont pas compressés, ce qui est considéré comme une aberration par tout le monde.
D'où le "généralement".
SI le terme ne te va pas je ferai une recherche demain dans le dictionnaire des synonymes, désolé.

J'aurais peut-être dû partir de ce post :

J'ai écrit que le RAW NON COMPRESSÉ n'existe généralement pas ce qui interdit les comparaisons simples. si tu vas sur le lien que j'ai indiqué, tu verras que tu peux analyser le détail pour les RAW Canon si l'analyse avec un éditeur en héxadécimal fait partie de tes passe-temps.

[ieu00027]

Illustration du changement d'algo pour la compression Jpeg sous Photoshop (CS6) :

(quand on passe de "7" à "6")

Dans l'exemple des jpeg, on peut avoir un changement d'algorithmes afin de modifier le taux de compression. De plus, c'est une coimpression lossy. Mais le cas de raws compressés, on ne peut choisir le taux de compression qui de plus est losseless. C'est très différent. A mon sens, il n'y a qu'un algorithme par modèle/série de boitiers pour les raws compressés. Et c'est la répartition statistiques des valeurs qui est la cause de la modification de poids. Cette répartition doit d'ailleurs varier grandement dès que l'exposition d'une même prise de vue varie de 1 IL en plus ou en moins.

[Verso92]

A mon sens, il n'y a qu'un algorithme par modèle/série de boitiers pour les raws compressés

Sur le D810, il y en a au moins deux :
- compression sans perte,
- compression avec pertes.

[rsp]

J'ai fait un comparatif de 5 fichiers raw d'A7RII, 42 Mpix, avec les deux cas (compressés / non compressés), et pour chaque une vue sombre et une vue claire (6 IL de différence entre les deux) vu qu'il a été question précédemment de poids différents dans ce cas, + 1 supplémentaire avec un diaph différent.

A vous de juger, mais en tout cas ça colle de très près - et je m'y attendais - au calcul de Verso dans le deuxième post de ce fil (avec 16 bits).

Ce qui est très surprenant c'est que les différences sont minimes sur la ligne RAW+EXIF entre les colonnes comparables (1/2 d'un côté et 3/4/5 quand il n'y a pas compression).
Pour les "non compressés" (3/4/5) c'est normal, il n'y a pas de compression donc la taille est toujours la même (nombre de photo-sites x dimension en bits) mais c'est surprenant pour les deux premières colonnes. Je suppose que c'est parce que la compression SONY porte essentiellement sur la réduction du nombre de bits et n'utilise pas les méthodes des autres fabricants (qui doivent s'apparenter à un ZIP ; si j'ai bien lu le lien que j'ai indiqué, Canon utilise pour comprimer un JPEG sans perte).

[chelmimage]

Comment vérifiez-vous qu'il n'y a pas de pertes?

[Verso92]

Comment vérifiez-vous qu'il n'y a pas de pertes?

Par définition, la compression sans perte est... sans perte (ce sont des algorithmes réversibles qui sont mis en œuvre) !


Sinon, pour convaincre les plus butés lors d'une discussion sur ce sujet, il y a quelques années, j'avais fait la manip suivante :

1 - PdV en RAW non compressé,

2 - Enregistrement en TIFF 16 bits,

3 - Compression "sans perte" dans Nikon Capture du RAW non compressé,

4 - Enregistrement en TIFF 16 bits du RAW compressé "sans perte",

5 - Comparaison avec un éditeur hexadécimal des deux fichiers TIFF... champs "données" rigoureusement identiques, au bit près.

[remico]

Sur le D810, il y en a au moins deux :
- compression sans perte,
- compression avec pertes.

En Sony c'est :

- soit compression avec perte 11 + 7-bit  http://www.rawdigger.com/howtouse/sony-craw-arw2-posterization-detection

- soit pour les appareils qui le peuvent pas de compression mais en plus les données de ces raw non compressés sont enregistrés en 16 bits.
http://www.sonyalpharumors.com/understanding-compression-of-the-sony-a7r-ii-uncompressed-arw-raw-format-diglloyd/

Extrait :

And here are two key insights he shares about the new A7rII uncompressed RAW format:

   1) The Sony A7R II captures 14 bits per photosite. The Sony uncompressed raw format then stores these 14 bits in 16 bits, bloating the file by 14%. In other words, Sony wastes about 9MB per image for no value or purpose at all. So Sony users lose triply: wasted storage, degraded camera responsiveness, fewer shots before the camera buffer fills.

   2) A lossless-compressed format can save far more than even the bit packing mentioned above. Nikon and Canon use Huffman encoding. But it might be that the CPU in the Sony cameras is not fast enough for Huffman encoding?

[chelmimage]

Par définition, la compression sans perte est... sans perte (ce sont des algorithmes réversibles qui sont mis en œuvre) !
Sinon, pour convaincre les plus butés lors d'une discussion sur ce sujet, il y a quelques années, j'avais fait la manip suivante :
1 - PdV en RAW non compressé,
2 - Enregistrement en TIFF 16 bits,
3 - Compression "sans perte" dans Nikon Capture du RAW non compressé,
4 - Enregistrement en TIFF 16 bits du RAW compressé "sans perte",
5 - Comparaison avec un éditeur hexadécimal des deux fichiers TIFF... champs "données" rigoureusement identiques, au bit près.

Vérification indiscutable, en effet..

[ieu00027]

Sur le D810, il y en a au moins deux :
- compression sans perte,
- compression avec pertes.

Je parlais de l'algorithme de compression sans perte. il est évident que si l'on change le mode de compression, on doit changer d'algorithme.

[Verso92]

Je parlais de l'algorithme de compression sans perte. il est évident que si l'on change le mode de compression, on doit changer d'algorithme.

Là, n'ayant pas désassemblé le micro-code des Nikon, je ne saurais pas dire...

[gerarto]

Ce qui est très surprenant c'est que les différences sont minimes sur la ligne RAW+EXIF entre les colonnes comparables (1/2 d'un côté et 3/4/5 quand il n'y a pas compression).
Pour les "non compressés" (3/4/5) c'est normal, il n'y a pas de compression donc la taille est toujours la même (nombre de photo-sites x dimension en bits) mais c'est surprenant pour les deux premières colonnes. Je suppose que c'est parce que la compression SONY porte essentiellement sur la réduction du nombre de bits et n'utilise pas les méthodes des autres fabricants (qui doivent s'apparenter à un ZIP ; si j'ai bien lu le lien que j'ai indiqué, Canon utilise pour comprimer un JPEG sans perte).

Dans le cas des raw "ARW 2.3" Sony qui sont comprimés à perte, la taille des fichiers raw pour un A7RII est relativement constante : environ 41 Mo quelque soit le type d'image.
La "compression" n'en est pas vraiment une, par rapport à la méthode des autres fabricants qui utilisent la méthode sans perte type Huffmann.
Je n'ai pas réussi à trouver une explication technique vraiment convaincante de la méthode qui revient si j'ai bien compris a "perdre" des bits d'information... sauf que les infos perdues sont choisies là où ça ne "mange pas de pain" !
Donc effectivement si ce sont toujours les mêmes bits qui sont tronqués, la taille constante des raw est normale.

[gerarto]

En Sony c'est :

- soit compression avec perte 11 + 7-bit  http://www.rawdigger.com/howtouse/sony-craw-arw2-posterization-detection

- soit pour les appareils qui le peuvent pas de compression mais en plus les données de ces raw non compressés sont enregistrés en 16 bits.
http://www.sonyalpharumors.com/understanding-compression-of-the-sony-a7r-ii-uncompressed-arw-raw-format-diglloyd/

Extrait :

And here are two key insights he shares about the new A7rII uncompressed RAW format:

   1) The Sony A7R II captures 14 bits per photosite. The Sony uncompressed raw format then stores these 14 bits in 16 bits, bloating the file by 14%. In other words, Sony wastes about 9MB per image for no value or purpose at all. So Sony users lose triply: wasted storage, degraded camera responsiveness, fewer shots before the camera buffer fills.

   2) A lossless-compressed format can save far more than even the bit packing mentioned above. Nikon and Canon use Huffman encoding. But it might be that the CPU in the Sony cameras is not fast enough for Huffman encoding?

Eternel problème qui n'exclut pas complètement un certain degré de "Sony bashing" quand on va creuser un peu plus loin les interventions sur ces blogs/pages.

Cette affaire a fait grand bruit il y a plus d'un an quand quelqu'un en triturant des raw Sony a réussi à obtenir quelques artefacts dans des cas plus que limite (du style : je sous-expose de 6/8 IL et je remets + 6/8 IL au dématriçage...) .

A la suite de quoi Sony a rajouté des raw non compressés par firmware sur les derniers boîtiers.

Et maintenant un an plus tard que se passe-t-il ?

Et bien probablement 99.9% des utilisateurs restent en raw compressé parce qu'ils sont absolument incapables de voir la moindre différence en terme de qualité image entre les deux possibilités !
Après pour ceux (0.01% ? ) qui font de la photo "aux limites" (astro, etc...), ou pour les anxieux (c'est leur droit )  il leur reste le non compressé.

[rsp]

Ce n'est pas que du dé-zingage de Sony : à quoi fournir les capteurs ayant le bruit le plus faible et la plus grande dynamique si on ne propose qu'un résultat tronqué ?
D'accord avec toi, les spécialistes du genre "chieurs" de chez dpreview, par ailleurs assez adorateurs de Sony et très critiques de Canon, ont réussi à montrer que sur une photo de clair de lune on peut mettre en évidence des artefacts.
La raison pour laquelle Sony ne passe pas au RAW compressé reste mystérieuse ce qui n'empêche qu'elle est peut-être excellente ! Il semble que Sony ait réalisé des prouesses en terme d'E/S sur les mémoires, il n'y a qu'à voir la dernière version du RX100 par exemple. Dans ce cas pourquoi perdre du temps à comprimer ? même si ça fait qu'après l'utilisateur traîne de plus gros fichiers dans les transferts (WIFI, de care à PC etc.).

[remico]

Eternel problème qui n'exclut pas complètement un certain degré de "Sony bashing" quand on va creuser un peu plus loin les interventions sur ces blogs/pages.

Cette affaire a fait grand bruit il y a plus d'un an quand quelqu'un en triturant des raw Sony a réussi à obtenir quelques artefacts dans des cas plus que limite (du style : je sous-expose de 6/8 IL et je remets + 6/8 IL au dématriçage...) .

A la suite de quoi Sony a rajouté des raw non compressés par firmware sur les derniers boîtiers.

Et maintenant un an plus tard que se passe-t-il ?

Et bien probablement 99.9% des utilisateurs restent en raw compressé parce qu'ils sont absolument incapables de voir la moindre différence en terme de qualité image entre les deux possibilités !
Après pour ceux (0.01% ? ) qui font de la photo "aux limites" (astro, etc...), ou pour les anxieux (c'est leur droit )  il leur reste le non compressé.

Non ce n'est pas du Sony bashing et tant mieux si ce format de compression avec pertes convient pour 99,9999% des utilisations.

(...)
Je n'ai pas réussi à trouver une explication technique vraiment convaincante de la méthode qui revient si j'ai bien compris a "perdre" des bits d'information... sauf que les infos perdues sont choisies là où ça ne "mange pas de pain" !

Les informations perdues sont dans les hautes lumières et dans les forts contrastes, c'est expliqué dans le lien sur rawdigger au chapitre Inside SONY cRAW format
http://www.rawdigger.com/howtouse/sony-craw-arw2-posterization-detection

1/ les données brutes du capteur en 14bits (16384 valeurs) sont compressées en 11bits (2048 valeurs possibles) mais pas de façon linéaire, division par 8, en accordant plus d'importance au faibles valeurs donc au détriment des hautes lumières.

2/ chaque rangée est divisée par bloc de 16, le maximum et le minimum sont calculés et enregistrés en 11 bits, leur position dans le bloc est codé en 4 bits et suivent les deltas (écarts) pour les 14 autres pixels encodés en 7bits. Cet encodage est très précis pour les valeurs faibles de contraste, inférieures à 128 en 11bits soit 16 pour un jpg 8bits mais de plus en plus approximatif quand le contraste augmente, je cite :

For a data span of less than or equal to 128, the factor is 1, and no rounding error is introduced while reversing the delta encoding. For a larger span, the scheme does introduce the rounding error, which may lead to posterization. In other words, if the chunk of 32 pixels spans across an area that contains a large variation in brightness, the data in the block is not exact, but is only an approximation.

[gerarto]

Non ce n'est pas du Sony bashing et tant mieux si ce format de compression avec pertes convient pour 99,9999% des utilisations.
...

C'est bien pourtant ce que certains commentateurs de la page en question laissent entendre (page de sonyalpharumors.com ).
Plus tout le tapage orchestré sur le web à l'époque.

Je ne parle évidemment pas de ce qui a pu se dire ici.

...
Les informations perdues sont dans les hautes lumières et dans les forts contrastes, c'est expliqué dans le lien sur rawdigger au chapitre Inside SONY cRAW format
http://www.rawdigger.com/howtouse/sony-craw-arw2-posterization-detection

1/ les données brutes du capteur en 14bits (16384 valeurs) sont compressées en 11bits (2048 valeurs possibles) mais pas de façon linéaire, division par 8, en accordant plus d'importance au faibles valeurs donc au détriment des hautes lumières.

2/ chaque rangée est divisée par bloc de 16, le maximum et le minimum sont calculés et enregistrés en 11 bits, leur position dans le bloc est codé en 4 bits et suivent les deltas (écarts) pour les 14 autres pixels encodés en 7bits. Cet encodage est très précis pour les valeurs faibles de contraste, inférieures à 128 en 11bits soit 16 pour un jpg 8bits mais de plus en plus approximatif quand le contraste augmente, je cite :

For a data span of less than or equal to 128, the factor is 1, and no rounding error is introduced while reversing the delta encoding. For a larger span, the scheme does introduce the rounding error, which may lead to posterization. In other words, if the chunk of 32 pixels spans across an area that contains a large variation in brightness, the data in the block is not exact, but is only an approximation.

Evidemment aussi que j'ai cette page en archives depuis longtemps (c'est probablement les premiers à avoir soulevé le lièvre)...

Après le problème est que si cette postérisation est bien réelle, on est quand même dans des cas un peu particuliers pour les exemples.
Personne ne nie que la compression en question ne crée pas d'artefacts. Reste simplement à voir dans quels cas pratiques... et si c'est visible seulement à 100% écran.
Comme beaucoup, quand la mise à disposition des raw non compressés a été effective, j'ai fait quelques tests en prenant "en double" quelques photos "normales" (celles que je fais habituellement), et j'ai cherché des différences... sans réellement en trouver.
Donc je reste en raw compressés sans trop me poser de questions. Mais si je devais faire la photo du siècle, je basculerais évidemment en non compressé.

[remico]

Ce n'est pas tout à fait des artefacts, en astro là où il n'y a rien, il n'y aura toujours rien après encodage, c'est plutôt une imprécision, une valeur trop faible sera gommée, et les autres valeurs seront arrondies.

J'ai fait une feuille de calcul, j'espère sans erreur, avec une série progressive de 16 pixel partant de zéro en ajoutant 8 et avec un maximum variable. Un écart 8 en 11 bits cela correspondrait grosso modo à une différence de 1 en 8bits jpg.

Pour les quatre séries dont le maximum est inférieur ou égal à 1023, tout se passe bien, la progressivité est respectée.
Par contre pour la dernière, cela fait un escalier, le pixel à 8 se retrouve à zéro, les deux suivants à 16 etc, c'est pour les cas où l'écart mini-maxi est supérieur à 1024, on aura seulement 1/16 ème des nuances possibles des données 11bits, elles-mêmes moins précises que les données 14bits brutes du capteur.