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

[detrez]

Au risque de passer pour un ignare, je me pose la question.
Un de mes amis qui possède un Canon 750 (24Mpx) sort des images marquées 30M° (clic droit propriétés du RAW). Sur mon Nex7 (24Mpx), mes images sont indiquées 24 M°. 6 M° de moins peuvent s'expliquer comment ?

[Verso92]

Un de mes amis qui possède un Canon 750 (24Mpx) sort des images marquées 30M° (clic droit propriétés du RAW).

Mes images de D810 (36 MPixels) font environ 45 Mo (RAW 14 bits, compression sans perte).

Mais sans compression, les images font 73,2 Mo.

Dans un RAW de D810, chaque pixel est codé sur 14 bits (si ce choix est fait dans le menu).

En informatique, les données sont souvent stockées sur 8 ou 16 bits. Si on prend un codage sur 16 bits (2 bits inutilisés par pixel, donc), cela fait 36 MPixels x 16 bits = 576 millions de bits.

Un octet = 8 bits.

576 / 8 = 72 Mo... en comptant les octets d'en-tête du fichier (nom de fichier, EXIF, etc), on retombe sur ses pieds !

6 M° de moins peuvent s'expliquer comment ?

Le taux de compression du RAW est plus élevé, tout simplement...

[Franciscus Corvinus]

Tu peux faire tenir tes 30 MPix dans 1 MO si tu veux. C'est juste un question de savoir combien de pertes tu es pret a accepter.

[Franciscus Corvinus]

Ca dépend si on veut une liste exhaustive de tous les facteurs affectant le poids du ficher, ou le facteur le plus important/probable (qui est celui que j'ai cité).

[seba]

Ce n'est ce genre de réponses qui va faire comprendre à notre ami cette différence (explications généralistes)
Pour vous troubler un peu plus, prenez deux images avec votre apn avec un angle différent et du même sujet et vous constaterez que le poids de l'image est différente (quelques fois de plus Mo) alors maintenant cherchez et donnez des explications convaincantes,

En RAW ?

[B_M]

Chaque constructeur d'APN a son format raw propriétaire. Nef, cr2, raf ... Il n'est donc pas étonnant d'obtenir des différences. Chaque marque a sa sauce.
B_M

[Verso92]

Oui autrement on ne peut rien expliquer, faire un essai et tu verras (sur un sujet au même endroit mais sous un angle différent, j'ai des différences de 4 Mo)

Ce n'est valable que si le RAW est compressé.

Sinon, le poids des fichiers sera identique quelle que soit la situation, pour une profondeur de couleur donnée (12 ou 14 bits, par exemple).

[astrophoto]

je viens de regarder une série de raw de 6D (compression sans perte), ça va de 28691 ko à 19237 ko. Ca dépend du contenu de l'image, du niveau de bruit etc.
On aura le même phénomène en compressant en zip des fichiers de nature différente (photo, texte, données...)

[gerarto]

Je viens de donner un exemple avec des raw non compressés et tu affirmes le contraire , je le répète faire un essai et constater

Et bien, il n'y a aucune raison majeure pour que le raw en lui même soit sensiblement différent...

Sauf que dans le fichier raw sont encapsulées pas mal de données supplémentaires, dont en particulier une imagette jpg (qui peut être de taille conséquente suivant les marques), et que tout jpeg est par définition de taille variable !

[remico]

Au risque de passer pour un ignare, je me pose la question.
Un de mes amis qui possède un Canon 750 (24Mpx) sort des images marquées 30M° (clic droit propriétés du RAW). Sur mon Nex7 (24Mpx), mes images sont indiquées 24 M°. 6 M° de moins peuvent s'expliquer comment ?

Peut-être parce que le Nex 7 utilise un format compressé pour ses raw, le ARW 2.3.0/2.3.1 (lossy delta-compression) selon wikipedia, il y a aussi des Sony qui utilisent un format lossless :
https://en.wikipedia.org/wiki/List_of_cameras_supporting_a_raw_format#Sony

[dioptre]

J'ai fait une vérification sur les RAWS d'un 5DsR.
Une série prise lors d'une expo, vernissage et oeuvres.
le poids des RAWS c'est entre 79,1 et 49,7 Mo.
La moyenne est dans les 60 Mo
Je pensais que c'était du à la complexité des détails de la vue.
Il semble que non en partie.
Les fichiers les plus lourds sont les plus clairs et les plus légers sont les plus sombres.
Par exemple des pièces prises dans la pénombre pour avoir une vue correcte d'écrans : ce sont les plus légers autour de 50 - 55 Mo

[jipT]

Attention les RAW canon ne sont pas compressés pour la partie RAW mais ils incluent une image de prévisualisation en pleine résolution qui est codée en jpg et qui elle peut être de taille variable. Comme elle est en plein format et pas trop compressée, c'est elle qui fait grossir les RAW en taille (Mo) par rapport à la taille théorique.

jip

[Verso92]

Et bien, il n'y a aucune raison majeure pour que le raw en lui même soit sensiblement différent...

Sauf que dans le fichier raw sont encapsulées pas mal de données supplémentaires, dont en particulier une imagette jpg (qui peut être de taille conséquente suivant les marques), et que tout jpeg est par définition de taille variable !

Oui, c'est la seule explication valable, naturellement : les données RAW, si elles ne sont pas compressées, occuperont forcément une taille fixe, par définition.

Par contre, j'avais en effet oublié que le RAW embarquait aussi (NEF) deux images Jpeg (la vignette et l'aperçu), dont le poids peut varier, effectivement.

Ci-dessous, trois NEF effectués à l'instant avec le D700, en RAW non compressé : on note effectivement des petites différences dans les poids respectifs des fichiers...

[Verso92]

Pour illustrer, voici la photo "9752" :

[Verso92]

Et la "9754" :

(d'ailleurs, curieusement, le fichier "9754" est un peu plus lourd que le "9752"... va comprendre, Charles ?  ;-)

[ChatOuille]

La différence en poids n'est pas énorme, mais je remarque quand-même que sur la 2ème, bien que la composante chromatique est homogène, la composante luminance est très variable dans ce dégradé. Peut-être que la première contient plus de plages identiques que la 2ème. Ce n'est qu'une supposition un peu gratuite. Il faudrait tester avec l'objectif bouché (100% noir).

[Verso92]

La différence en poids n'est pas énorme, mais je remarque quand-même que sur la 2ème, bien que la composante chromatique est homogène, la composante luminance est très variable dans ce dégradé. Peut-être que la première contient plus de plages identiques que la 2ème. Ce n'est qu'une supposition un peu gratuite. Il faudrait tester avec l'objectif bouché (100% noir).

Avec une vue "au noir" (bouchon sur l'objectif + mode M), j'obtiens un fichier de 24 394 ko.

[remico]

J'ai fait une vérification sur les RAWS d'un 5DsR.
Une série prise lors d'une expo, vernissage et oeuvres.
le poids des RAWS c'est entre 79,1 et 49,7 Mo.
La moyenne est dans les 60 Mo
Je pensais que c'était du à la complexité des détails de la vue.
Il semble que non en partie.
Les fichiers les plus lourds sont les plus clairs et les plus légers sont les plus sombres.
Par exemple des pièces prises dans la pénombre pour avoir une vue correcte d'écrans : ce sont les plus légers autour de 50 - 55 Mo

Il y a un mythe comme quoi la moitié des valeurs seraient pour le stop le plus clair, la moitié de la moitié pour un stop en dessous etc etc :
http://www.ayton.id.au/wiki/doku.php?id=omd:ettr

Pour le poids des fichiers sombres ou clairs c'est confirmé dans cet article qui revient sur ce mythe :
https://photomorrobay.wordpress.com/2012/01/08/histogram-myth-explicated-youll-lose-half-your-tonal-values-for-each-one-full-stop-of-under-exposure/

Extrait :

I think an experiment I did proves the linear nature of the histogram. I photographed a gray stucco wall with these constants.ISO 100
f 11 Focal length 50 mm (which would be 80 mm full frame) Distance from wall 1.1 m (3'10") TripodI varied the exposure in 1 stop increments for a total of 8 exposures.

Here are the shutter speeds and the sizes of the files for each exposure.
These exposures were chosen to produce data on my histogram from the far left to the far right.

1/500 sec    18.55 MB
1/250 sec    19.18 MB
1/125 sec    20.18 MB
1/60  sec     21.85 MB
1/30  sec     24.58 MB
1/15  sec     27.17 MB
1/8    sec     30.51 MB
1/4    sec     33.72 MB

So the size of the files I'm assuming is more or less a linear progression (I have not plotted it). If the myth were true, based on a far right value of 33.72 MB, the file size on the far left at 1/500 sec should be 2.11 MB, not 18.55 MB.

[Verso92]

Il y a un mythe comme quoi la moitié des valeurs seraient pour le stop le plus clair, la moitié de la moitié pour un stop en dessous etc etc :
http://www.ayton.id.au/wiki/doku.php?id=omd:ettr

Il fait un peu peur, ton lien, quand même...  ;-)

[Verso92]

Bon, aller, tant qu'à faire... un petit essai avec le D810 :

- 6526 : 64 ISO, photo nette.
- 6527 : 6 400 ISO, photo nette.
- 6528 : 64 ISO, photo floue.
- 6529 : 64 ISO, photo nette, +1 IL.

;-)

[Verso92]

6526 :

[Verso92]

6527 :

[Verso92]

6528 :

[Verso92]

6529 :

[Verso92]

Enfin, bref, pas de surprise... on constate que le fichier est plus lourd quand l'image (enfin, le Jpeg intégré au RAW) est :

- plus claire (6529 vs 6526),
- plus nette (6526 vs 6528),
- à ISO plus élevé, à cause du bruit (6527 vs 6526).

[remico]

Il y a un mythe comme quoi la moitié des valeurs seraient pour le stop le plus clair, la moitié de la moitié pour un stop en dessous etc etc :
http://www.ayton.id.au/wiki/doku.php?id=omd:ettr

Il fait un peu peur, ton lien, quand même...  ;-)

Je n'ai pas tout compris surtout du deuxième lien.
https://photomorrobay.wordpress.com/2012/01/08/histogram-myth-explicated-youll-lose-half-your-tonal-values-for-each-one-full-stop-of-under-exposure/

L'avantage d'exposer à droite n'est pas (ne serait pas ?) parce qu'il y a plus de nuances possibles dans les hautes lumières mais bien parce qu'en remontant une image ou partie d'image trop sombre on remonte aussi du bruit, alors qu'en assombrissant une photo trop claire on l'atténue.

Ce n'est pas simple c'est toute la "cuisine" qui est faite sur le raw pendant la derawtisation rien que sur la luminosité, de façon transparente pour l'utilisateur (ouf!), avec les options de dcraw on en a un aperçu :

-k et -S réglage du point noir et du point blanc (normalement préréglé pour chaque appareil)
- W n'ajuste pas automatiquement la luminosité (normalement c'est ajusté, comment ? mystère)
- b ajuste la clarté (défaut = 1.0)
-g fixe la courbe de gamma (défaut 2.222 4.5)  pour le srgb standard c'est 2.4 12.9

Enfin, bref, pas de surprise... on constate que le fichier est plus lourd quand l'image (enfin, le Jpeg intégré au RAW) est :

- plus claire (6529 vs 6526),
- plus nette (6526 vs 6528),
- à ISO plus élevé, à cause du bruit (6527 vs 6526).

Peut-être que pour le poids plus important des fichiers clairs c'est juste une histoire de codage autrement dit il n'y aurait pas plus d'informations mais le codage de celles-ci prendrait plus de place, j'ai créé deux fichiers png 16bits de couleur unie 800x600, le blanc 4,3 ko est aussi plus lourd que le noir 2,9 ko.

[Verso92]

Je n'ai pas tout compris surtout du deuxième lien.
https://photomorrobay.wordpress.com/2012/01/08/histogram-myth-explicated-youll-lose-half-your-tonal-values-for-each-one-full-stop-of-under-exposure/

L'avantage d'exposer à droite n'est pas (ne serait pas ?) parce qu'il y a plus de nuances possibles dans les hautes lumières mais bien parce qu'en remontant une image ou partie d'image trop sombre on remonte aussi du bruit, alors qu'en assombrissant une photo trop claire on l'atténue.

Heu... il me semble que c'est admis depuis bien longtemps déjà, non ?

(je voulais dire par là que l'auteur du lien en question racontait tellement d'âneries qu'il valait mieux ne pas trop s'y attarder...)

[remico]

Peut-être parce que le Nex 7 utilise un format compressé pour ses raw, le ARW 2.3.0/2.3.1 (lossy delta-compression) selon wikipedia, il y a aussi des Sony qui utilisent un format lossless :
https://en.wikipedia.org/wiki/List_of_cameras_supporting_a_raw_format#Sony

Je complète mon précédent message, le Nex 7 utilise un format de raw compressé avec pertes et de plus en 12 bits seulement (4096 valeurs possibles) au lieu de 14 bits pour le Canon 750D (16384 valeurs possibles) ce qui doit jouer aussi sur le poids des raws

https://www.dxomark.com/Cameras/Sony/NEX-7---Specifications
https://www.dxomark.com/Cameras/Canon/EOS-750D---Specifications

[ChatOuille]

Avec une vue "au noir" (bouchon sur l'objectif + mode M), j'obtiens un fichier de 24 394 ko.

Merci Verso pour le test. Cela va dans le sens que je pensais. 

[Laure-Anh]

Il y a un mythe comme quoi la moitié des valeurs seraient pour le stop le plus clair, la moitié de la moitié pour un stop en dessous etc etc :

Outre la netteté des détails plus ou moins nombreux enregistrés, la variation de poids du fichier RAW non compressé dépend de la dynamique du capteur résultant de la sensibilité ISO mise en oeuvre et de la tonalité de la scène photographiée.

Après avoir calé l'exposition théoriquement correcte liée à la lumière ambiante existante qui me sert à photographier, l'ajout de + 1 IL par augmentation du temps de pose à sensibilité constante afin d'optimiser l'acquisition du fichier numérique RAW en prévision d'une post-production elle-même optimale permet d'acquérir effectivement plus de nuances et plus d'infos codées parce que le poids du fichier RAW optimal est objectivement plus élevé que le poids du fichier RAW exposé normalement selon la pratique argentique.
L'augmentation de poids constatée est plus ou moins élevée. Elle dépend de la tonalité de la scène photographiée. Plus il y a des tons clairs, plus l'augmentation sera sensible.

Dans l'exemple posté ci-après, l'augmentation de poids est minime et s'explique par la présence minime de tons clairs au sein de la scène photographiée...

[Verso92]

Outre la netteté des détails plus ou moins nombreux enregistrés, la variation de poids du fichier RAW non compressé dépend de la dynamique du capteur résultant de la sensibilité ISO mise en oeuvre et de la tonalité de la scène photographiée.

On est bien d'accord que ça joue sur le poids des Jpeg embarqués dans le fichier RAW, n'est-ce pas ?

Par définition, le poids des données RAW, si non compressées, sera fixe et déterminé.

[rsp]

Une analyse assez détaillée du contenu d'un CR2 (désolé pour les autres marques) : http://lclevy.free.fr/cr2/
Il me semble que tous les RAW Canon sont compressés sans perte, ce qui explique que leur taille varie autant, en plus de la présence d'un JPG de bonne qualité encapsulé dedans.
Pour Sony il y a un format RAW sans perte (14 bits me semble-t-il) qui doit être en usage sur le A7RII et un format RAW compressé avec pertes (passage de 14 à 12 bits avec compression) sur tous les autres.
Les tons les plus sombres étant plus proches de 0000 que de 3FFF (sur 14 bits, même si les valeurs des RAW Canon sont décalées de 1024), il me semble me souvenir de mes cours sur la compression de données que cela donne naturellement des quantités de données pus faibles (mais ça remonte à très loin).

[Laure-Anh]

On est bien d'accord que ça joue sur le poids des Jpeg embarqués dans le fichier RAW, n'est-ce pas ?

Par définition, le poids des données RAW, si non compressées, sera fixe et déterminé.

Ben, je me pose pour tout dire la question parce que dans le cas de mon exemple, le premier jpeg embarqué comporte moins de pixels sombres à gauche et des HL calées à droite sans cramage tandis que le jpeg du RAW optimisé comporte davantage de pixels à gauche mais une bonne partie des HL existantes auparavant sont cramées : dans ces conditions, leurs poids respectifs ne doivent pas être très éloignés l'un de l'autre.  Par curiosité, j'ai vérifié en regardant les propriétés des deux prises de vues en pleine résolution 4352x2904, le premier jpeg pèse 5,40Mo (= 5 664 243 octets) contre 5,62Mo (= 5 901 873 octets) pour le second embarqué dans le RAW oprimisé quand on les développe dans DPP 4 avec les mêmes paramètres, plus précisément avec les mêmes paramètres boîtier. Cette variation de poids de 0,22Mo n'explique pas la variation entre les deux RAW qui est, je le rappelle, de 0,5Mo. D'autant que les jpegs embarqués dans un RAW non compressé ne sont pas des jpeg en pleine résolution mais des jpeg basse résolution.

Si cela avait été une prise de vue d'une feuille blanche très blanche cadrée plein pot, le jpeg embarqué dans le RAW optimisé aurait été cramé en totalité et aurait pesé moins lourd que le fichier embarqué dans le RAW exposé normalement avec ses HL calées à droite. La prise de poids du fichier RAW optimisé ne s'explique pas dans un tel cas par l'augmentation du poids des jpegs embarqués. Amha.

[Verso92]

Ben, je me pose pour tout dire la question parce que dans le cas de mon exemple, le premier jpeg embarqué comporte moins de pixels sombres à gauche et des HL calées à droite sans cramage tandis que le jpeg du RAW optimisé comporte davantage de pixels à gauche mais une bonne partie des HL existantes auparavant sont cramées : dans ces conditions, leurs poids respectifs ne doivent pas être très éloignés l'un de l'autre.  Par curiosité, j'ai vérifié en regardant les propriétés des deux prises de vues en pleine résolution 4352x2904, le premier jpeg pèse 5,40Mo (= 5 664 243 octets) contre 5,62Mo (= 5 901 873 octets) pour le second embarqué dans le RAW oprimisé quand on les développe dans DPP 4 avec les mêmes paramètres, plus précisément avec les mêmes paramètres boîtier. Cette variation de poids de 0,22Mo n'explique pas la variation entre les deux RAW qui est, je le rappelle, de 0,5Mo. D'autant que les jpegs embarqués dans un RAW non compressé ne sont pas des jpeg en pleine résolution mais des jpeg basse résolution.

Si cela avait été une prise de vue d'une feuille blanche très blanche cadrée plein pot, le jpeg embarqué dans le RAW optimisé aurait été cramé en totalité et aurait pesé moins lourd que le fichier embarqué dans le RAW exposé normalement avec ses HL calées à droite. La prise de poids du fichier RAW optimisé ne s'explique pas dans un tel cas par l'augmentation du poids des jpegs embarqués. Amha.

Pourtant, ce n'est pas compliqué... le poids des données RAW (en version non compressée), c'est le nombre de pixels multiplié par le nombre de bit de quantification (au "cadrage" près)...

[Laure-Anh]

Pourtant, ce n'est pas compliqué... le poids des données RAW (en version non compressée), c'est le nombre de pixels multiplié par le nombre de bit de quantification (au "cadrage" près)...

Le poids théorique maximal d'un RAW comportant un nombre déterminé de pixels est déterminé et fixe.

[rsp]

J'ai du mal à comprendre comment on peut parler avec certitude de la dimension d'un objet (RAW non compressé) qui n'existe pas (ils sont compressés sans pertes, comme les ZIP par exemple) et qui, en plus, embarque plein d'autres choses dont un JPEG dont la dimension est assez difficile à prédire.
Question à Verso92 : il existe un RAW non compressé chez Nikon ?

[ChatOuille]

J'ai du mal à comprendre comment on peut parler avec certitude de la dimension d'un objet (RAW non compressé) qui n'existe pas (ils sont compressés sans pertes, comme les ZIP par exemple) et qui, en plus, embarque plein d'autres choses dont un JPEG dont la dimension est assez difficile à prédire.
Question à Verso92 : il existe un RAW non compressé chez Nikon ?

Je ne suis pas Verso, mais chez Nikon existe bien un Raw non compressé. Je ne sais pas s'il existe encore sur les nouveaux boîtiers car beaucoup disent que ce format n'a plus d'utilité. Effectivement les nouveaux capteurs ont pas mal de pixels et de dynamique, ce qui augmente le poids du fichier. C'est l'avantage du raw compressé sans perte. Le seul inconvénient (mineur) est le temps de décompression.

Je ne comprends pas quand tu dis que l'objet raw n'existe pas... c'est pourtant bel et bien un fichier binaire avec ces caractéristiques comme le poids.

[Verso92]

Question à Verso92 : il existe un RAW non compressé chez Nikon ?

Oui : c'est un archaïsme débile qui subsiste sur les boitiers haut de gamme de la marque...

Sur le reste de la gamme, ils ont fort logiquement supprimé cette erreur.

C'est l'avantage du raw compressé sans perte. Le seul inconvénient (mineur) est le temps de décompression.

Même pas...

Un boitier en mode compressé (sans perte/avec pertes) sera plus rapide qu'en mode non-compressé. Les temps de compression/décompression sont moins pénalisants que les temps d'écriture/lecture sur la carte.

[Verso92]

Je me réinvite dans la discussion (je suis à l'origine de la question en ce qui concerne les différences de poids sur un même boitier et prise dans les mêmes conditions) je dois avouer, que aucune de vos réponses ne sont satisfaisantes.
Un fichier a un poids, le nombres de pixels et... la formule classique mais mais , je le répète de là a avoir des différences de plusieurs Mo sur deux images d'un même sujet (portrait) je veux bien accepter le coup du Jpeg embarqué mais  6 M c'est beaucoup et cela sur un 5D III
Il dois y avoir une alchimie qui dépasse les simples utilisateurs que nous sommes (la politique et la religion ne sont pas autorisées sur ce forum aussi je ne parlerai point d'intervention divine). Bon j'ai une automobile et je dois avouer que je ne cherche pas à savoir comment fonctionne mon carburateur électronique;  

De toute façon, s'il s'agit d'un mode "non compressé", les variations de poids des fichiers RAW ne peuvent être dus qu'au(x) Jpeg embarqué(s). Mais les RAW de ton 5D MkIII sont-ils "non compressés" ?

En cas de compression, les variations peuvent être importantes... en cas de changement d'algo pour la compression.

Sous Photoshop, par exemple, il y a un changement d'algo dans la compression Jpeg : le poids diminue au fur et à mesure que tu compresses d'avantage... sauf à une frontière (5 ou 6, je ne sais plus très bien), où curieusement le poids remonte avant de redescendre.

[houlala]

En cas de compression, les variations peuvent être importantes... en cas de changement d'algo pour la compression.

Sous Photoshop, par exemple, il y a un changement d'algo dans la compression Jpeg : le poids diminue au fur et à mesure que tu compresses d'avantage... sauf à une frontière (5 ou 6, je ne sais plus très bien), où curieusement le poids remonte avant de redescendre.

Je me demandais d'où provenait cette hausse apparemment illogique. Un changement d'algorythme ? Ok.

[dioptre]

J'ai fait une vérification sur les RAWS d'un 5DsR.
Une série prise lors d'une expo, vernissage et oeuvres.
le poids des RAWS c'est entre 79,1 et 49,7 Mo.
La moyenne est dans les 60 Mo
Je pensais que c'était du à la complexité des détails de la vue.
Il semble que non en partie.
Les fichiers les plus lourds sont les plus clairs et les plus légers sont les plus sombres.
Par exemple des pièces prises dans la pénombre pour avoir une vue correcte d'écrans : ce sont les plus légers autour de 50 - 55 Mo

Comme je disais il y a des différences importantes.
Toutes photos à 100 iso.
Entre 50 et 80 Mo on ne peut dire que c'est dû uniquement aux JPEG embarqués

[Verso92]

Comme je disais il y a des différences importantes.
Toutes photos à 100 iso.
Entre 50 et 80 Mo on ne peut dire que c'est dû uniquement aux JPEG embarqués

On parlait de RAW non compressés, dioptre...

[remico]

Une analyse assez détaillée du contenu d'un CR2 (désolé pour les autres marques) : http://lclevy.free.fr/cr2/
Il me semble que tous les RAW Canon sont compressés sans perte, ce qui explique que leur taille varie autant, en plus de la présence d'un JPG de bonne qualité encapsulé dedans.
Pour Sony il y a un format RAW sans perte (14 bits me semble-t-il) qui doit être en usage sur le A7RII et un format RAW compressé avec pertes (passage de 14 à 12 bits avec compression) sur tous les autres.
Les tons les plus sombres étant plus proches de 0000 que de 3FFF (sur 14 bits, même si les valeurs des RAW Canon sont décalées de 1024), il me semble me souvenir de mes cours sur la compression de données que cela donne naturellement des quantités de données pus faibles (mais ça remonte à très loin).

Même écart que l'initiateur du fil sur imaging ressource, 25,16 Mo pour le Nex7 et 31 Mo pour le Canon 750D - T6i pour la mire :
http://www.imaging-resource.com/PRODS/NEX7/NEX7hSLI00100NR1.ARW.HTM
http://www.imaging-resource.com/PRODS/canon-t6i/T6IhSLI00100NR2D.CR2.HTM

Avec une mire plus sombre le raw est plus léger, très peu pour le Sony 25Mo un peu plus pour le Canon 27Mo :
http://www.imaging-resource.com/PRODS/NEX7/NEX7LL001003.ARW.HTM
http://www.imaging-resource.com/PRODS/canon-t6i/T6ILL001007XNR.CR2.HTM

[rsp]

Je ne comprends pas quand tu dis que l'objet raw n'existe pas... c'est pourtant bel et bien un fichier binaire avec ces caractéristiques comme le poids.

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.

[Verso92]

J'ai écrit que le RAW NON COMPRESSÉ n'existe généralement pas ce qui interdit les comparaisons simples.

Prends un Nikon, dans ce cas...

[Verso92]

Je me demandais d'où provenait cette hausse apparemment illogique. Un changement d'algorythme ? Ok.

C'est, du moins, l'explication que j'avais lu... et qui me semble la plus plausible.

[ieu00027]

Je doute que Nikon utilise plusieurs algorithmes de compression. Généralement, s'il est bien choisi, et la différence de taille entre NEF compressé et non compressé semble l'indiquer, un seul algorithme suffit. On change d'algorithme pour optimiser la compression quand on change de type de données. Mais ici, ce sont toujours les mêmes données. Seule leur répartition statistique change. Dans ce cas, il me semble inutile de se compliquer la vie en utilisant plusieurs algorithmes.

[Verso92]

C'est, du moins, l'explication que j'avais lu... et qui me semble la plus plausible.

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

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

[ChatOuille]

Oui : c'est un archaïsme débile qui subsiste sur les boitiers haut de gamme de la marque...

Sur le reste de la gamme, ils ont fort logiquement supprimé cette erreur.

Même pas...

Un boitier en mode compressé (sans perte/avec pertes) sera plus rapide qu'en mode non-compressé. Les temps de compression/décompression sont moins pénalisants que les temps d'écriture/lecture sur la carte.

Je parlais uniquement du temps théorique de décompression. Je ne connais pas la différence réelle en tant qu'utilisateur (cela dépend de l'algorithme) mais je suis absolument sûr qu'elle est négligeable. Je suis bien d'accord que le Raw non compressé est un archaïsme.

[gerarto]

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.

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".

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).

[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.