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

Démarré par detrez, Décembre 22, 2016, 19:31:37

« précédent - suivant »

remico

Citation de: remico le Décembre 23, 2016, 17:09:07
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


Citation de: Verso92 le Décembre 23, 2016, 17:46:15
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

Citation de: Verso92 le Décembre 23, 2016, 19:02:01
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

Citation de: remico le Décembre 24, 2016, 15:47:59
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

Citation de: remico le Décembre 23, 2016, 15:58:01
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

Citation de: Verso92 le Décembre 23, 2016, 16:50:55
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

Citation de: remico le Décembre 23, 2016, 17:09:07
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

Citation de: Laure-Anh le Décembre 27, 2016, 18:36:53
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

Citation de: Verso92 le Décembre 27, 2016, 19:06:27
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

Citation de: Laure-Anh le Décembre 27, 2016, 20:38:28
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

Citation de: Verso92 le Décembre 27, 2016, 21:02:22
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

Citation de: rsp le Décembre 27, 2016, 22:05:29
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

Citation de: rsp le Décembre 27, 2016, 22:05:29
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.

Citation de: ChatOuille le Décembre 28, 2016, 01:18:18
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

Citation de: patsgt le Décembre 28, 2016, 09:06:29
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

Citation de: Verso92 le Décembre 28, 2016, 09:48:05
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

Citation de: dioptre le Décembre 23, 2016, 16:03:13
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

Citation de: dioptre le Décembre 28, 2016, 10:32:23
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

Citation de: rsp le Décembre 27, 2016, 19:46:04
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

Citation de: ChatOuille le Décembre 28, 2016, 01:18:18
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

Citation de: rsp le Décembre 28, 2016, 15:23:05
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

Citation de: houlala le Décembre 28, 2016, 10:01:20
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.
Amicalement, Paul

Verso92

Citation de: Verso92 le Décembre 28, 2016, 17:17:10
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

Citation de: Verso92 le Décembre 28, 2016, 01:34:37
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

Citation de: rsp le Décembre 28, 2016, 15:23:05
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).