NEF 12 ou 14 bits ?

[bignoz]

Salut,

Je repasse vite fait pour dire que je suis dans la chaloupe, j'ai déjà quitté le bateau de cette discussion d'ingénieurs dont je ne pige plus rien 

[kochka]

Quelle importance l'algo utilisé ?
Si Nikon te dit que la compression est sans pertes, elle est sans pertes... il n'y a pas besoin de chercher midi à quatorze heure, qu'ils aient utilisé Huffman ou n'importe quoi d'autre c'est leur salade, mais en tant qu'utilisateur tout ce qui nous importe c'est qu'aucun bit n'a été altéré à la décompression par rapport à l'original (contrairement à un JPEG, donc).

Faire confiance à Nikon lorsqu'il nous affirme à coté, que le D600 est sans poussière, peut paraitre un peu osé. 

[Ronan]

Aujourd'hui Nikon indique "sans perte", ce qui a un sens bien précis en français et l'essai de Verso montre bien que "réversible" veut dire... "réversible": on récupère à la sortie le fichier original sans aucune différence et j'aimerais que l'on m'explique en quoi le tableau de chiffres "décompressé", dès lors qu'il est identique à celui à celui obtenu en parallèle sans compression, pourrait faire perdre une quelconque "valeur intermédiaire". Là, c'est vraiment le grand nawak!

La question initiale portait sur 12/14 bits. Avec un D300 ou un D90, c'est complètement inutile. Avec un D3X, je travaillais toujours en 14 bits (il offrait une dynamique record pour l'époque, rappelons-le). Avec un D3/D3s, par précaution et comme ça ne coûte rien en performances, en 14 bits. Avec les boitiers récents qui offrent 14 IL de dynamique (soit en pratique 12 IL utiles, à la louche), en 14 bits sans discussion possible.

Reste la Q du Mimile quant on a besoin de rafale... 14 bits quand c'est possible, sinon 12 bits en Raw, sinon Jpeg, par ordre décroissant...

Concernant l'algo, ce n'est pas un Lempel-Ziv-Welch, mais un Welch-Lempel-Ziv!

[Verso92]

La zone de quantification est simplement plus large et les infos données pas le capteur sont plus nombreuses et donc plus précises (après à voir comment les exploiter et avec quel derawtiseur).

Plus précisément, la zone à quantifier a bien sûr la même "largeur". Les infos sont donc en théorie plus précises, à condition que les bits de poids faibles ne soient pas noyés dans le bruit, ce qui n'est pas gagné à priori, loin s'en faut...

Concernant l'algo, ce n'est pas un Lempel-Ziv-Welch, mais un Welch-Lempel-Ziv!

Blagounette mise de côté, le LZW est l'algo utilisé, à priori, pour les formats "image" comme le TIFF ou le GIF... pourquoi pas le NEF, qui a une structure de TIFF, comme chacun sait ?

;-)

[restoc]

Dans toute la littérature que j'ai pu trouver, il y a toujours équivalence entre algorithme résersible et compression "sans perte". Quand un algo est réversible, il est possible de retrouver le message original, au bit près, en appliquant la transformation inverse.

Après, il faut quand même avoir l'esprit tordu pour imaginer qu'il puisse y avoir des pertes avec une compression "sans perte" (là, on est au niveau du français "basique", n'est-ce pas ?).
Sinon, je m'étais amusé, il y a quelques temps déjà, à compresser "sans perte" dans Capture Nx2 un NEF pris avec l'option "sans compression" (il fallait bien convaincre les derniers sceptiques...). J'avais ensuite converti en TIFF 16 Bits les deux fichiers, et j'avais vérifié à l'aide d'un éditeur hexa-décimal qu'ils contenaient rigoureusement les mêmes données, au bit près.
Sinon, pour l'algo utilisé dans les NEF, je pencherais pour ma part pour un Lempel-Ziv-Welch (à confirmer)...

[Ronan]

Parce que la mesure se fait avec une limite à ZERO dB de rapport S/B, ce qui est quand même... peu!
Si tu prends 20 dB comme limite visuelle acceptable, tu enlèves à la louche 2 IL.
Mais les mesures DxO sont pour autant comparatives, donc permettent la comparaison entre boîtiers. C'est juste que de la mesure à la preatique, là où tu lis 14, tu gardes 12, et là où tu lis 12, tu gardes 10. Voilà...
Amitiés
Ronan

[Botticelli]

La question initiale portait sur 12/14 bits. Avec un D300 ou un D90, c'est complètement inutile.

Sur un D90 c'est tellement inutile que l'option 12/14 bits n'est pas disponible...

D'apres le mode d'emploi :NEF images are compressed, reducing file size by about 40–50%
per cent with almost no effect on image quality.

Personne n'a relevé cette citation du mode d'emploi, qui ne semble pas s'appliquer au mode de compressions sans pertes.
Après un rapide coup d'oeil au mode d'emploi du D3s (au hasard), je vois que cette phrase s'applique à la compression "à l'aide d'un algorithme irréversible". Il y a deux modes de compression, un sans perte / réversible et un avec perte / irréversible.
Tous les intervenants ne parlent pas du même mode de compression sur ce fil...

[Verso92]

?

[Ronan]

Quel mode d'emploi? Celui du D2X ou celui du D3/D4/D800/D600 etc. ?

[Botticelli]

Quel mode d'emploi? Celui du D2X ou celui du D3/D4/D800/D600 etc. ?

Je ne sais pas de quel MDE bolek a tiré sa phrase initialement, mais comme je l'ai dit c'est la même dans le mode d'emploi du D3s.
D4, D800, D600 : même combat (edit : tous proposent compression avec ou sans perte ; tous sauf le D600 proposent "pas de compression") .

[Verso92]

Personne n'a relevé cette citation du mode d'emploi, qui ne semble pas s'appliquer au mode de compressions sans pertes.
Après un rapide coup d'oeil au mode d'emploi du D3s (au hasard), je vois que cette phrase s'applique à la compression "à l'aide d'un algorithme irréversible". Il y a deux modes de compression, un sans perte / réversible et un avec perte / irréversible.
Tous les intervenants ne parlent pas du même mode de compression sur ce fil...

- sans compression : pas besoin de commentaires,

- compression "sans perte" : pas de perte (algo réversible),

- compression "avec pertes" : légère dégradation (algo non réversible).

[Ronan]

Reala? On va dire 10 mais c'est bien payé en raison du grain...
Diapo? 7/8... Comme un Jpeg, quoi, et pour cause !!! Mais avec un scanner Laser d'enfer (on n'en fait plus: Siemens à 150.000 E) et, là encore, c'est bien payé en raison du grain !

[eengel]

Le 14 bit lui est un choix personnel qui peut avec certains calculateurs un peu justes et avec certains logiciels ne pas être judicieux car allongeant  le process pour un résultat très hypothétique notamment pour des fichiers D800 et pour une config courte en pattes çà se ressent très vite.

A la fin du mode d'emploi du D800 (page 439), il est noté que l'enregistrement des photo en RAW (ou tiff) est un des facteurs qui diminue l'autonomie de l'accumulateur (comme le moniteur, le VR, les vitesses lentes, ...). A priori, enregistrer en JPEG nécessite plus de calculs mais il y a moins de données à écrire sur la carte. Or, à ma connaissance, écrire sur une flash coûte en énergie. Visiblement plus que de calculer. Donc marginalement, il est intéressant, pour l'autonomie électrique, d'enregistrer en compressé.
Quand à affirmer que le temps de calcul pour décompresser va être plus long que le temps d'accès au disque, cela me semble hasardeux. (Pour mémoire: Raw 14 bit non compressé: 74.4 Mo. Raw 14 bit compressé sans pertes: 41.3 Mo, JPEG Fine/Large: 16.3 Mo).  

[Botticelli]

Ok merci beaucoup ! Et par rapport à l'argentique ? Une reala 100 visuellement ferait combien en dynamique ? Et une Velvia 50 ?

Tu as déjà oublié la réponse de JMS ?

Je dirais 10 à 11 pour une Reala et 6 à 8 pour une Velvia...

[Ronan]

Attention, ce n'est pas que les mesures soient fausses, c'est qu'elles sont faites selon une norme qui favorise un chiffre élevé (limite à 0 dB alors qu'à 20 dB on a déjà un bruit très élevé, visuellement, et qu'on peut prendre cette valeur pour limite pratique).

Mais l'intérêt des mesures DxO Mark, c'est d'être parfaitement normalisées et comparatives.

[restoc]

Verso et Ronan faut creuser un peu : selon le type d 'applications un algo peut être réversible et avec pertes :  par ex  un RLE est un algo réversible qui pour faire trés simple va trés bien aller sur des fax ou des images simples tout ce qui est différent d'un seuil est  raméné à 0 ou 255 pour un fax par ex . Donc dans les demi teintes il y pertes définitives. Et pourtant il est parfaitement réversible puisqu'on retrouve bien le texte sans perte !!. Selon les auteurs Le terme "sans perte"  n'est donc à ne pas prendre au pied de la lettre en terme de nb de pixels et de bits mais en terme d'information et donc à mettre en face de l'application pour laquelle il est destiné.

C'est basique en traitement du signal et sûrement pas tordu!

Pour la compression sans perte de MM Canon Nikon Sony et autres, à l'heure actuelle vu les puissances de calcul des processeurs des boitiers on peut obtenir du sans perte stricte ( peu compréssé) et du avec pertes acceptables.. je crois que du temps du D100, d70,  D200 que la question se posait bien en terme de pertes à cette époque.
On trouve aussi du LZ avec pertes, applicable à de l'image et même paramétrable en Db (de perte, pas de S/b évidemment).

Les LZ version Welch faits à l'origine pour des données codées sur 4 ou 8 bits ont été recuisinnées de façon proriétaire par Nikon, Canon etc  pour améliorer les perfs sur du 12 ou 14 bits car la connaissance des occurences de valeurs  ( dont le bruit cette fois !) est primoriale pour la perf,  puisque ce sont des algos probabilistes et statistiques. Donc c'est du LZ Nikon, LZ CAnon etc.
Bon je vais continuer à chercher le 0db en 14 bits. Parait qu'il y en a qui l'ont vu  .. à Lourdes !

[sylvatica]

Restoc, arrête de dire des aneries. L'algorithme RLE est l'algorithme le plus simple de compression sans perte. Au lieu de dire AAAABBBBBB on dit 4A6B. Cela prend moins de place et cela contient exactement les mêmes imformations. C'est le genre d'idée qui est utilisé dans la compression des images en .gif ou .png. Il y a bien sur d'autres types d'algorithmes de compression sans perte avec des idées très sophistiquées. Ils réduisent (sauf cas exceptionnel) la taille des fichiers, mais l'information d'origine reste intacte.

Les algorithmes de compression avec perte font disparaitre l'information "la moins importante". Le plus souvent, on fait une transformée de Fourier et on coupe les hautes fréquences. C'est grosso-modo ce que font les formats de compression .jpeg et .mp3. Une partie de l'information est définitivement perdue. À noter qu'en interne ces algorithmes utilisent aussi des algorithmes de compression sans perte (le jpeg utilise un codage de Huffman après avoir coupé les hautes fréquences).

Ton truc, d'algo réversible avec perte, je ne vois pas du tout ce que c'est. Et ton exemple du fax est folklorique. En écoutant ma musique sur des fichiers mp3, je comprends toujours ce que le chanteur dit. Pourtant, le fichiers a été compressé avec un algorithme avec perte.

Concernant, la compression "sans perte" des NEFs, ce n'est pas simple de savoir si c'est vraiment un algorithme de compression sans perte ou avec perte (mais très faible). Face à cette interrogation, il y a plusieures attitudes :
- Faire confiance à Nikon et esperer que ce qu'ils appelent "compression sans perte" est bien ce qu'un informaticien appelle compression sans perte. (C'est pas mon genre de faire confiance  )
- Demander à Nikon le code source de leur algo. Oublions...
- Lire le code de DCRAW, l'utilitaire libre pour lire les fichiers RAW. L'auteur a fait du reverse engineering pour écrire son code. Tu peux lire une partie du code ici : http://lclevy.free.fr/nef/nikon_compression.c. En regardant rapidement, il semble que ce soit une compression de type Huffman qui est bien une compression sans perte.

Donc selon le code source de DCRAW, la compression NEF sans perte est un codage de Huffman qui est bien garanti sans aucune perte.

Le seul truc que je ne comprends pas, c'est pourquoi ils laissent la possibilité d'enregistrer le NEF sans compression. Je ne vois vraiment pas l'intérêt.

[Glouglou]

J'ouvre un sujet sur 12 ou 14 bits et 3 pages plus loin pas plus de 3 participations se rapportant à la question mais tout un tas de trucs sans aucun rapport mais se rapportant à l'ego des participants.

Merci à ceux qui ont respecté "mon" fil .... et à la réponse de Ronan L ....

[sylvatica]

Si il faut répondre aux questions des propriétaires de fils...

Des tests avec des images faites avec un D300
- Are 14-bit Raw Images Really Any Better Than 12-bit Raw?
http://www.earthboundlight.com/phototips/nikon-d300-d3-14-bit-versus-12-bit.html
- 14-bit Raw Versus 12-bit Raw: Further Analysis and Comparison
http://www.earthboundlight.com/phototips/14-bit-raw-12-bit-part-two.html

Un fil avec des photos faites au D800
http://www.fredmiranda.com/forum/topic/1099741/0

Et le meilleur pour la fin : un test de Bernard Rome fait au D800
http://b-rome.com/RAW_12_ou_14_bits.html

[Verso92]

Quand à affirmer que le temps de calcul pour décompresser va être plus long que le temps d'accès au disque, cela me semble hasardeux. (Pour mémoire: Raw 14 bit non compressé: 74.4 Mo. Raw 14 bit compressé sans pertes: 41.3 Mo, JPEG Fine/Large: 16.3 Mo).  

Une chose est sûre : le ratio temps de calcul supplémentaire pour la compression vs temps de gagné en écriture sur la carte est sensiblement favorable aux versions "compressées". Il suffit de faire l'essai sur des rafales chronomètre à la main...

[Verso92]

Verso et Ronan faut creuser un peu : selon le type d 'applications un algo peut être réversible et avec pertes :  par ex  un RLE est un algo réversible qui pour faire trés simple va trés bien aller sur des fax ou des images simples tout ce qui est différent d'un seuil est  raméné à 0 ou 255 pour un fax par ex . Donc dans les demi teintes il y pertes définitives. Et pourtant il est parfaitement réversible puisqu'on retrouve bien le texte sans perte !!. Selon les auteurs Le terme "sans perte"  n'est donc à ne pas prendre au pied de la lettre en terme de nb de pixels et de bits mais en terme d'information et donc à mettre en face de l'application pour laquelle il est destiné.

C'est basique en traitement du signal et sûrement pas tordu!

Tu iras raconter ça aux spécialistes en cryptologie (par exemple) : ça leur fera un bon moment de rigolade... s'il y a pertes définitives, la transformée inverse ne permettra pas de retrouver les données originales, donc la réversibilité est perdue, par définition.
Encore un petit effort, restoc, et tu vas finir par nous expliquer que "sans perte", ça veut dire "avec pertes"...

Pour la compression sans perte de MM Canon Nikon Sony et autres, à l'heure actuelle vu les puissances de calcul des processeurs des boitiers on peut obtenir du sans perte stricte ( peu compréssé) et du avec pertes acceptables.. je crois que du temps du D100, d70,  D200 que la question se posait bien en terme de pertes à cette époque.

Pour donner un ordre d'idée, sur le D700 (14 bits) :

- non compressé : 25 249 ko,
- compressé "sans perte" : 15 932 ko,
- compressé "avec pertes" : 14 583 ko.
Du temps du D200, la compression "sans perte" n'était pas disponible (à confirmer)...

[Jinx]

Restoc, le RLE avec perte fallait oser
Évites de parler de sujets dont tu ignores tout, car là tu passes vraiment pour un clown !

[algraf]

Le seul truc que je ne comprends pas, c'est pourquoi ils laissent la possibilité d'enregistrer le NEF sans compression. Je ne vois vraiment pas l'intérêt.

C'est, de toute évidence, pour rassurer les incrédules irréductibles et leur laisser penser qu'ils ont raison, à tord, de ne pas croire à la compression sans pertes.

[bolek]

Si il faut répondre aux questions des propriétaires de fils...

Des tests avec des images faites avec un D300
- Are 14-bit Raw Images Really Any Better Than 12-bit Raw?
http://www.earthboundlight.com/phototips/nikon-d300-d3-14-bit-versus-12-bit.html
- 14-bit Raw Versus 12-bit Raw: Further Analysis and Comparison
http://www.earthboundlight.com/phototips/14-bit-raw-12-bit-part-two.html

Un fil avec des photos faites au D800
http://www.fredmiranda.com/forum/topic/1099741/0

Et le meilleur pour la fin : un test de Bernard Rome fait au D800
http://b-rome.com/RAW_12_ou_14_bits.html

Au vue des testes cités par Sylvatica il m'apparait que les 2 bits supplémentaires di 14 bits sont rajoutés pour les bas niveaux d'éclairement, la précision supplémentaire n'est pas redistribuée uniformément sur toute la plage utile et encore moins « à droite » où elle serait plus utile pour distinguer entre la saturation du capteur (que l'on ne peut pas récupérer  quelque soit la résolution en niveau d'éclairement) et les niveaux proche de la saturation.   De toute façon l'intérêt du 14 bits dépend plus de la résolution  en niveau d'éclairement du CAN que de la dynamique.  Certains semble confondre  12 bits de  résolution  en niveau d'éclairement avec 12 Il de dynamique.
Glouglou, je ne voulais pas polluer ton fils, mais généraliser à l'affectation pertinente des valeurs numériques aux niveaux du signal analogique  du capteur.

[kochka]

Un algo réversible qui serait "presque" réversible, il faut le faire.