Bonjour,
J'ai suivi avec intérêt la discussion sur l'encodage 12 ou 14 bits et la digression sur la compression sans perte. J'étais à priori d'accord avec le fait que le compression sans perte est sans pertes. C'est d'ailleurs une expression consacrée en informatique (lossless/lossy) qui exprime clairement le fait que l'opération de compression est exactement réversible ou pas (http://en.wikipedia.org/wiki/Lossless_compression) . Comme d'autres je me suis dit que si Nikon utilisait une expression aussi connotée, c'était à dessein.
Je tombe alors sur cet article du support Nikon https://nikoneurope-fr.custhelp.com/app/answers/detail/a_id/2272/~/qu'est-ce-qu'un-fichier-nef-%3F
L'article bien qu'ancien à été mis à jour récemment et dit:
3. Compression sans perte : certains reflex numériques disposent d'une option permettant d'enregistrer dans l'appareil photo le fichier NEF sous forme de fichier compressé sans perte. Dans des conditions normales de visionnage, il existe très peu de différences en termes de qualité entre un fichier NEF compressé sans perte et un fichier NEF compressé. Néanmoins, le format compressé sans perte offre une grande souplesse d'édition de l'image et donne la possibilité de réenregistrer le fichier sans compression.
S'il y a très peut de différences, c'est qu'il y en a. Je consulte alors le mode d'emploi du D800 et, page 86 je vois que le RAW compressé sans perte est définit par:
Les images NEF sont compressées à l'aide d'un algorithme réversible qui réduit la taille du fichier d'environ 20-40% sans incidence sur la qualité d'image.
Pour le coup je trouve la formulation ambiguë. Avez vous une opinion sur le fait que le compression sans perte est réellement sans pertes? Y-a-t-il enfumage? Encore un coup du marketing?
Je ne comprends pas le problème, pourquoi trouves-tu la formulation ambiguë ?
Il est dit que les images NEF sont compressées à l'aide d'un algorithme réversible, donc c'est bien une compression sans perte.
La compression sans perte ne fera rien perdre à la qualité de l'image. Ce n'est pas une opinion mais une affirmation qui vient de tests faits avec un D800 et une version de DCRAW que j'ai modifiée pour en extraire les données de compression.
Le site de Nikon n'est pas clair du tout. Ils disent :
Dans des conditions normales de visionnage, il existe très peu de différences en termes de qualité entre un fichier NEF compressé sans perte et un fichier NEF compressé.
C'est juste. Mais il faut bien comprendre qu'en plus, il n'existe aucune différence entre un fichier non compressé et un fichier compressé sans perte. En terme de qualité, du plus qualitatif, au moins qualitatif
-1- Fichier non compressé 14 bits = Fichier compressé sans perte 14 bits
-2- Fichier compressé avec perte 14 bits
-3- Fichier non compressé 12 bits = Fichier compressé sans perte 12 bits
-4- Fichier compressé avec perte 12 bits
L'ordre entre -2- et -3- est sujet à débat. Disons que -3- sera meilleur dans les hautes lumières et que -2- sera meilleur dans les basses lumières. J'aurai tendance à dire qu'en général -2- est mieux que -3-.
Par principe, la compression "sans perte" est sans perte (pas le moindre bit de changé).
Pareil que lorsqu'on compresse un fichier exécutable avec WinZip (par exemple) : le fichier décompressé sera identique (heureusement !) à l'original, au bit près.
Citation de: coval95 le Avril 05, 2013, 22:54:48
Je ne comprends pas le problème, pourquoi trouves-tu la formulation ambiguë ?
Il est dit que les images NEF sont compressées à l'aide d'un algorithme réversible, donc c'est bien une compression sans perte.
Citation de: Verso92 le Avril 05, 2013, 23:07:23
Par principe, la compression "sans perte" est sans perte.
Je suis d'accord avec cela. Mon trouble vient de l'article du support Nikon qui au paragraphe compression sans perte décrit une compression ou "il existe très peu de différences en termes de qualité entre un fichier NEF compressé sans perte et un fichier NEF compressé". Ils ont inventé la compression sans pertes mais avec différences! S'ils sont aussi approximatif dans le support technique pourquoi seraient-t-ils précis dans le mode d'emploi? De plus le "sans incidence" dit juste qu'il n'y à pas de différence notable. Pas qu'il n'y en pas.
Puisque la compression "sans perte" ne semble pas nuire au fichier, autant virer l'autre possibilité...J'ai 2 fichiers dont un qui pèse 1 tonne pour le même résultat et je laisse la possibilité de choisir, bizarre Mr Nikon !!
Citation de: eengel le Avril 05, 2013, 23:13:40
Je suis d'accord avec cela. Mon trouble vient de l'article du support Nikon qui au paragraphe compression sans perte décrit une compression ou "il existe très peu de différences en termes de qualité entre un fichier NEF compressé sans perte et un fichier NEF compressé". Ils ont inventé la compression sans pertes mais avec différences! S'ils sont aussi approximatif dans le support technique pourquoi seraient-t-ils précis dans le mode d'emploi? De plus le "sans incidence" dit juste qu'il n'y à pas de différence notable. Pas qu'il n'y en pas.
Il est évident que même Nikon n'a pas les idées claires la dessus. Il faut bien comprendre que dans ce que tu cites, Nikon dit :
"Compression sans perte" > "Compression avec perte"
ce qui n'est pas du tout incompatible avec le fait que "Sans compression" = "Compression sans perte".
Citation de: photo63 le Avril 05, 2013, 23:18:08
Pffff.... C est de la parano ou quoi ? Mdrr
En meme temps, si Nikon simplifiait ses menus et supprimaient les options et les informations totalement inutiles, l'utilisateur s'y retrouverait mieux.
Citation de: eengel le Avril 05, 2013, 22:41:39
Dans des conditions normales de visionnage, il existe très peu de différences en termes de qualité entre un fichier NEF compressé sans perte et un fichier NEF compressé.
Nikon aurait évité toute ambiguïté en écrivant :
Dans des conditions normales de visionnage, il existe très peu de différences en termes de qualité entre un fichier NEF compressé sans perte et un fichier NEF compressé
avec pertes.
Citation de: eengel le Avril 05, 2013, 22:41:39
Néanmoins, le format compressé sans perte offre une grande souplesse d'édition de l'image et donne la possibilité de réenregistrer le fichier sans compression.
Ici aussi Nikon aurait pu lever toute ambiguïté en écrivant :
Néanmoins, le format compressé sans perte offre une grande souplesse d'édition de l'image et donne la possibilité de réenregistrer le fichier
tel qu'il aurait été enregistré sans compression.
Citation de: sylvatica le Avril 05, 2013, 22:59:25
Dans des conditions normales de visionnage, il existe très peu de différences en termes de qualité entre un fichier NEF compressé sans perte et un fichier NEF compressé.
S'il existe une différence en terme de qualité, c'est que le donnée récupérées sont différentes. Si non, comment expliquer la différence de qualité?
Si je veux me lancer dans des théories fumantes, je pourrais rappeler que, pour la compression, il arrive que, préalablement à la compression proprement dite, on arrange les données pour qu'elles soient plus compressibles. Après on compresse de façon réversible ou pas. Qu'est-ce qui empêche d'envisager que Nikon, dans le cas compressé, arrange d'abord un peut la RAW (en introduisant "très peut de différence en termes de qualité") pour favoriser le compression puis, compresse à l'aide d'un algorithme réversible?
Dans ce schéma, les expériences faites avec DCRAW ne montrent rien, la perte à été introduite avant la compression.
Citation de: B [at] R le Avril 05, 2013, 23:18:42
Nikon aurait évité toute ambiguïté en écrivant :
Dans des conditions normales de visionnage, il existe très peu de différences en termes de qualité entre un fichier NEF compressé sans perte et un fichier NEF compressé avec pertes.
Oui, c'est exactement ça.
Citation de: B [at] R le Avril 05, 2013, 23:23:07
Ici aussi Nikon aurait pu lever toute ambiguïté en écrivant :
Néanmoins, le format compressé sans perte offre une grande souplesse d'édition de l'image et donne la possibilité de réenregistrer le fichier tel qu'il aurait été enregistré sans compression.
Là je ne suis pas tout à fait d'accord. La formulation de Nikon est valable. On peut réenregistrer le fichier sans compression, ça veut dire qu'on a bien toutes les données initiales et que le logiciel est capable de réenregistrer le fichier intact.
De la même manière qu'un fichier qui a été zippé puis dézippé peut être réenregistré sans compression (non zippé).
Citation de: eengel le Avril 05, 2013, 23:25:38
S'il existe une différence en terme de qualité, c'est que le donnée récupérées sont différentes. Si non, comment expliquer la différence de qualité?
Relis bien ce qu'a écrit B [at] R :
Dans des conditions normales de visionnage, il existe très peu de différences en termes de qualité entre un fichier NEF compressé sans perte et un fichier NEF compressé
avec pertes.
Il y a peu de différences si la compression avec pertes a été faite avec peu de pertes (c'est une lapalissade hein... :D).
Tu prends le format jpeg par exemple : plus le taux de compression est élevé et plus il y a de pertes, donc plus on s'éloigne des données d'origine et plus on dégrade l'image.
Citation de: coval95 le Avril 05, 2013, 23:33:58
Relis bien ce qu'a écrit B [at] R :
Dans des conditions normales de visionnage, il existe très peu de différences en termes de qualité entre un fichier NEF compressé sans perte et un fichier NEF compressé avec pertes.
OK j'ai été un peut vite. C'est plus clair. Merci
Citation de: eengel le Avril 05, 2013, 23:25:38
Si je veux me lancer dans des théories fumantes, je pourrais rappeler que, pour la compression, il arrive que, préalablement à la compression proprement dite, on arrange les données pour qu'elles soient plus compressibles. Après on compresse de façon réversible ou pas. Qu'est-ce qui empêche d'envisager que Nikon, dans le cas compressé, arrange d'abord un peut la RAW (en introduisant "très peut de différence en termes de qualité") pour favoriser le compression puis, compresse à l'aide d'un algorithme réversible?
Dans ce schéma, les expériences faites avec DCRAW ne montrent rien, la perte à été introduite avant la compression.
Je vais essayer d'expliquer les différentes compressions sur un fichier 14 bits. Excepté les informations non directement liées à l'image, un NEF de D800 contient des informations sur a peu près 36 000 000 pixels. Pour chaque pixel, le capteur donne une valeur entre 0 et 2^14-1=16383. Le 0 correspond au noir total, et 16383 correspond au pixel saturé.
-
NEF non compressé: Les 36 000 000 valeurs sont stockées de manière conventionnelle.
-
NEF compressé sans perte: Nikon utilise un codage de Huffman. En gros, imagine que ton image est un Roman, et que chaque pixel correspond à un mot. Un algorithme va regarder les mots les plus utilisés et va réécrire le roman dans une langue imaginée pour l'occasion où les mots les plus utilisés sont ceux qui ont le moins de lettres. Il faut bien sur stocker le dictionnaire français/langue imaginaire pour pouvoir décoder tout cela. Au final, le Roman va être plus court, mais il est possible de le décoder sans aucun problème.
-
NEF compressé avec perte: Au lieu de prendre toutes les valeurs entre 0 et 16383, seules 3000 valeurs sont autorisées : 0, 1, 2, 5, 10, ... , 16383. Si le capteur mesure 4, la valeur va être arrondie à 5. Il y a ainsi une perte d'informations. Attention, les trous ne sont pas répartis uniformément, et il y en a plus vers les hautes lumières que les basses lumières. Si on reprend notre analogie du Roman, cela revient à réécrire le Roman en utilisant un vocabulaire moins précis. Un peu comme si Ribéry réecrivait tout Kant.
En lisant le code source de DCRAW, j'ai remarqué que c'était bien un codage de Huffmann qui était utilisé pour la compression sans perte, ce qui est bien certifié sans pertes. J'ai aussi regardé les valeurs qui étaient autorisées dans la compression avec perte. Je pense vraiment que ce que j'ai fait est loin d'être une théorie fumante.
Citation de: coval95 le Avril 05, 2013, 23:27:25
Là je ne suis pas tout à fait d'accord. La formulation de Nikon est valable. On peut réenregistrer le fichier sans compression, ça veut dire qu'on a bien toutes les données initiales et que le logiciel est capable de réenregistrer le fichier intact.
De la même manière qu'un fichier qui a été zippé puis dézippé peut être réenregistré sans compression (non zippé).
Ma formulation est donc imparfaite ou pas assez claire, car je voulais exprimer EXACTEMENT la même chose que toi : la réversibilité !
Citation de: sylvatica le Avril 05, 2013, 23:44:42
Un peu comme si Ribéry réecrivait tout Kant.
Pas d'accord, dans ce cas ce serait une compression NEF vers JPG le plus dégradé possible... et encore ;D
Citation de: bitere le Avril 06, 2013, 00:03:46
Pas d'accord, dans ce cas ce serait une compression NEF vers JPG le plus dégradé possible... et encore ;D
Et à la décompression, c'est Kant qui doit récrire tout Ribéry. C'est là le plus drôle.
Citation de: sylvatica le Avril 05, 2013, 23:44:42
En lisant le code source de DCRAW, j'ai remarqué que c'était bien un codage de Huffmann qui était utilisé pour la compression sans perte, ce qui est bien certifié sans pertes. J'ai aussi regardé les valeurs qui étaient autorisées dans la compression avec perte. Je pense vraiment que ce que j'ai fait est loin d'être une théorie fumante.
Je suis d'accord, j'ai été un peut vite et la lecture du code de DCRAW est explicite. Désolé.
Note que je ne contestait pas ce point, mais le fait qu'une transformation préalable à la compression, afin de favoriser celle-ci aurait put altérer le contenu (cf https://fr.wikipedia.org/wiki/Transform%C3%A9e_de_Burrows-Wheeler, même si cette transformation est réversible mais ce n'est probablement pas la seule possible). Mais ce n'est pas le cas.
Citation de: B [at] R le Avril 05, 2013, 23:58:29
Ma formulation est donc imparfaite ou pas assez claire, car je voulais exprimer EXACTEMENT la même chose que toi : la réversibilité !
OK ;)
Citation de: eengel le Avril 06, 2013, 00:11:24
Je suis d'accord, j'ai été un peut vite et la lecture du code de DCRAW est explicite. Désolé.
Note que je ne contestait pas ce point, mais le fait qu'une transformation préalable à la compression, afin de favoriser celle-ci aurait put altérer le contenu (cf https://fr.wikipedia.org/wiki/Transform%C3%A9e_de_Burrows-Wheeler). Mais ce n'est pas le cas.
La transformation de Burrows-Wheeler est utilisée pour compresser du texte (L'utilitaire bzip2 l'utilise). L'idée est assez géniale et repose sur le fait qu'après une lettre donnée, il y a plus de chance qu'apparaisse une lettre qu'une autre. Par contre,
c'est aussi un algorithme de compression sans perte.
Citation de: sylvatica le Avril 05, 2013, 23:44:42
...
- NEF compressé avec perte: Au lieu de prendre toutes les valeurs entre 0 et 16383, seules 3000 valeurs sont autorisées : 0, 1, 2, 5, 10, ... , 16383. Si le capteur mesure 4, la valeur va être arrondie à 5. Il y a ainsi une perte d'informations. Attention, les trous ne sont pas répartis uniformément, et il y en a plus vers les hautes lumières que les basses lumières. Si on reprend notre analogie du Roman, cela revient à réécrire le Roman en utilisant un vocabulaire moins précis. Un peu comme si Ribéry réecrivait tout Kant.
...
Je ne suis pas sûre que ton explication soit complète, je veux dire qu'elle ne dit pas pourquoi on gagne de la place en diminuant le nombre de valeurs possibles : en effet tu as toujours 36 000 000 pixels à décrire.
Citation de: sylvatica le Avril 06, 2013, 00:15:32
La transformation de Burrows-Wheeler est utilisée pour compresser du texte (L'utilitaire bzip2 l'utilise). L'idée est assez géniale et repose sur le fait qu'après une lettre donnée, il y a plus de chance qu'apparaisse une lettre qu'une autre. Par contre, c'est aussi un algorithme de compression sans perte.
Cette transformation doit être très dépendante de la langue du texte à compresser, non ?
Citation de: coval95 le Avril 06, 2013, 00:17:51
Je ne suis pas sûre que ton explication soit complète, je veux dire qu'elle ne dit pas pourquoi on gagne de la place en diminuant le nombre de valeurs possibles : en effet tu as toujours 36 000 000 pixels à décrire.
Pour restituer les choses, on parle ici de la compression avec perte. Supposons pour faire simple que le capteur soit un capteur 2 bits. Il délivre donc pour chaque pixel un nombre entre 0 et 2^2-1=3. Il code cela en binaire :
00 : 0
01 : 1
10 : 2
11 : 3
chaque pixels va utiliser 2 bits. Si on décide de compresser avec la table de compression {0,3} (au lieu de {0,1,2,3}), on utilisera le code binaire :
0 : 0
1 : 3
chaque pixels va utiliser 1 bit. Dans ce cas, la taille du fichier va être divisé par 2.
OK mais ce n'était pas dit dans ton explication, cette précision (moins de valeurs autorisées => codage sur moins de bits => gain de place) me semblait utile à la compréhension (de la compression). ;)
Citation de: coval95 le Avril 06, 2013, 00:19:16
Cette transformation doit être très dépendante de la langue du texte à compresser, non ?
Non, et c'est cela qui est génial. Il suffit juste que dans la langue que l'on compresse, les successions de lettres ne soient pas aléatoires. C'est le cas de toutes les langues. Par exemple, en français, après un "b", on a plus de chance d'avoir un "a" qu'un "q". Mais si on se trouve dans une langue ou après le "b" on a plus d'avoir un "q" qu'un "a", cela marchera aussi.
Citation de: sylvatica le Avril 06, 2013, 00:25:38
Non, et c'est cela qui est génial. Il suffit juste que dans la langue que l'on compresse, les successions de lettres ne soient pas aléatoires. C'est le cas de toutes les langues. Par exemple, après un "b", on a plus de chance d'avoir un "a" qu'un "q".
Là tu me surprends beaucoup. Quand tu vois les successions de lettres dans certaines langues (langues slaves par exemple), ça nous semble imprononçable, on n'a jamais ces associations dans les langues latines (par exemple).
Ah, tu as édité ton post ! ;)
Mais je n'ai toujours pas compris ce que tu voulais dire. Si le logiciel de compression ne sait pas dans quelle langue a été écrit le texte à compresser, comment fait-il ?
Citation de: coval95 le Avril 06, 2013, 00:30:59
Là tu me surprends beaucoup. Quand tu vois les successions de lettres dans certaines langues (langues slaves par exemple), ça nous semble imprononçable, on n'a jamais ces associations dans les langues latines (par exemple).
Ah, tu as édité ton post ! ;)
Mais je n'ai toujours pas compris ce que tu voulais dire. Si le logiciel de compression ne sait pas dans quelle langue a été écrit le texte à compresser, comment fait-il ?
Quand il compresse, il écrit la table de correspondance au début, pour que la décompression puisse se faire en connaissance de cause.
Car cela fonctionne aussi avec les images, où il n'y a pas de lettres plus probables que d'autres, mais des valeurs de luminances plus probables que d'autres (un low key ne sera pas compressé de la même manière qu'un high key, mais les deux seront réduit de volume de la même manière).
Citation de: Lyr le Avril 06, 2013, 00:43:01
Quand il compresse, il écrit la table de correspondance au début, pour que la décompression puisse se faire en connaissance de cause.
Car cela fonctionne aussi avec les images, où il n'y a pas de lettres plus probables que d'autres, mais des valeurs de luminances plus probables que d'autres (un low key ne sera pas compressé de la même manière qu'un high key, mais les deux seront réduit de volume de la même manière).
Ah merci ! Voilà la clé du décodage pour moi ! ;)
A la compression le texte est analysé sous l'angle des successions de caractères et le résultat de l'analyse est stocké sous forme de table de correspondance.
Donc pour une suite de caractères retrouvée plusieurs fois dans le fichier, on aura un code (au lieu d'avoir un code par caractère, d'où le gain de place).
C'est bien ça ?
Citation de: coval95 le Avril 06, 2013, 00:30:59
Ah, tu as édité ton post ! ;)
Mais je n'ai toujours pas compris ce que tu voulais dire. Si le logiciel de compression ne sait pas dans quelle langue a été écrit le texte à compresser, comment fait-il ?
C'est très compliqué à expliquer. Pour te donner une idée, l'algo de Burrows a été posé au concours d'entrée de polyechnique il y a quelques années. Ils n'allaient même pas jusqu'à demander aux candidats de prouver que l'algo était reversible. Ça a été un massacre.
Peut-être qu'une personne qui a une compréhension profonde de l'algo pourrait te l'expliquer avec les mains. J'en suis incapable.
PS: Attention, l'algo de Burrows-W n'est pas utilisé en compression d'image. C'est uniquemen pour du texte.
Euh, l'explication de Lyr ne te convient (convainc) pas ?
Et ma reformulation n'est pas fidèle à l'esprit de la chose ?
.
Coval,
En fait, je crois qu'il y a un malentendu. La compression de Burrows-Wheeler n'a rien à voir avec les NEFs.
En ce qui concerne la compression avec perte des NEFs, où le nombre de valeurs est limité, il y a effectivement une table de correspondance qui est stockée au début du fichier. Comme le dit Lyr, c'est grâce à cette table que les logiciels peuvent décompresser l'image.
Je vais poser une question de newbie pragmatique : si un RAW compressé sans perte a la même qualité qu'un RAW non compressé, quel est l'intérêt (car il doit y en avoir un) a utiliser ce dernier ? Pourquoi ne pas utiliser systématiquement le RAW compressé sans perte ?
Citation de: RémiNOLTA le Avril 06, 2013, 02:00:48
Je vais poser une question de newbie pragmatique : si un RAW compressé sans perte a la même qualité qu'un RAW non compressé, quel est l'intérêt (car il doit y en avoir un) a utiliser ce dernier ? Pourquoi ne pas utiliser systématiquement le RAW compressé sans perte ?
Il n'y a à priori aucun intérêt à ne pas faire de compression sans perte sur ses NEFs. La raison pour laquelle Nikon propose encore le NEF non compressé est un mystère.
Citation de: RémiNOLTA le Avril 06, 2013, 02:00:48
Je vais poser une question de newbie pragmatique : si un RAW compressé sans perte a la même qualité qu'un RAW non compressé, quel est l'intérêt (car il doit y en avoir un) a utiliser ce dernier ? Pourquoi ne pas utiliser systématiquement le RAW compressé sans perte ?
Aucun intérêt à utiliser l'option "non compressé" : plus lourd et plus lent à écrire...
Citation de: sylvatica le Avril 05, 2013, 23:18:18
En meme temps, si Nikon simplifiait ses menus et supprimaient les options et les informations totalement inutiles, l'utilisateur s'y retrouverait mieux.
Citation de: sylvatica le Avril 06, 2013, 02:16:40
Il n'y a à priori aucun intérêt à ne pas faire de compression sans perte sur ses NEFs. La raison pour laquelle Nikon propose encore le NEF non compressé est un mystère.
Sur le D7100, par exemple, cette option "sans compression", totalement inutile, a disparu :
Citation de: RémiNOLTA le Avril 06, 2013, 02:00:48
Je vais poser une question de newbie pragmatique : si un RAW compressé sans perte a la même qualité qu'un RAW non compressé, quel est l'intérêt (car il doit y en avoir un) a utiliser ce dernier ? Pourquoi ne pas utiliser systématiquement le RAW compressé sans perte ?
Tiens ?? une similaire ??
Citation de: Aria le Avril 05, 2013, 23:14:58
Puisque la compression "sans perte" ne semble pas nuire au fichier, autant virer l'autre possibilité...J'ai 2 fichiers dont un qui pèse 1 tonne pour le même résultat et je laisse la possibilité de choisir, bizarre Mr Nikon !!
j'utilise du 14 Bits sans compression car c'est plus rapide à l'ouverture malgré le poids du fichier plus important (env 77 Mo pour ensuite obtenir une image de travail de 210Mo en TIFF)
[at] Verso92, l'avantage d'un boitier pro c'est justement d'avoir encore cette possibilité, d'avoir le choix de ne pas compresser ...
Citation de: d800e le Avril 06, 2013, 08:45:05
j'utilise du 14 Bits sans compression car c'est plus rapide à l'ouverture malgré le poids du fichier plus important (env 77 Mo pour ensuite obtenir une image de travail de 210Mo en TIFF)
[at] Verso92, l'avantage d'un boitier pro c'est justement d'avoir encore cette possibilité, d'avoir le choix de ne pas compresser ...
Il y a un essai tout simple que tu peux faire : tu choisis d'un côté RAW 14 bits "sans compression" et de l'autre avec compression "sans perte". Tu passes ton appareil en tout manuel et tu fais une rafale de 30 images (par exemple) à la cadence max.
Tu constateras que l'appareil mettra plus de temps à enregistrer les 30 images en mode "sans compression" et libèrera moins vite le
buffer...
Citation de: sylvatica le Avril 06, 2013, 00:25:38
Non, et c'est cela qui est génial. Il suffit juste que dans la langue que l'on compresse, les successions de lettres ne soient pas aléatoires. C'est le cas de toutes les langues. Par exemple, en français, après un "b", on a plus de chance d'avoir un "a" qu'un "q". Mais si on se trouve dans une langue ou après le "b" on a plus d'avoir un "q" qu'un "a", cela marchera aussi.
Ton explication est incomplète : l'algo BWT a pour but de reclasser les lettres des mots pour en faire des séquences de lettres répétées. Le BWT ne compresse rien, il étend même la taille du texte original.
C'est la méthode bzip2 qui utilise le BWT en 1ère passe et compresse le résultat avec Huffman en 2ème passe.
Citation de: Aria le Avril 06, 2013, 04:33:55
Tiens ?? une similaire ??
Tiens oui ! Au temps pour moi ! J'avais pourtant lu tout ce fil, très intéressant d'ailleurs.
Bon, en mêm temps il était 2h00 du mat aussi ::)
Citation de: Verso92 le Avril 06, 2013, 02:44:02
Aucun intérêt à utiliser l'option "non compressé" : plus lourd et plus lent à écrire...
Je connais ton expertise , que je ne remets pas en cause.
Mais un novice comme moi trouvera étonnant qu'un appareil soit plus lent en RAW sans compression, je devrais dire "sans le travail supplémentaire" de compression par rapport au RAW normal.
A moins que la "perte de temps" lors de la compression soit largement rattrapée par le temps d'écriture sur la carte, moins long car fichiers moins lourd ?
Si je suis dans le vrai, le gain de temps sera sensible surtout pour les rafales. Pour un cliché isolé, ce sera moins flagrant.
J'ai bon ?
[at] Verso,
Je sais très bien que 77 Mo prends plus de temps en lecture/écriture que 40 Mo
Je ne fais que du Studio, aussi la rafale de 30 images ...
L'avantage du "Sans Compression" c'est uniquement en post traitement : ça s'ouvre plus vite (même avec un temps de lecture plus important 77 contre 40)
Il y a quand même un problème. La formulation de Nikon ne garantit pas que le fichier non compressé et que le fichier "compressé et décompressé sans pertes" sont strictement identiques. Si ils ne le font pas c'est qu'il doit y avoir des différences même si elles sont peu visibles. Bien sûr ce sera difficile à vérifier car même si on fait des prises de vue du même sujet dans des conditions identiques en mode non compressé et compressé sans pertes, il y aura toujours des variantes dues aux infimes variations du temps d'exposition ou d'ouverture du diaphragme. Je serais curieux que quelqu'un fasse le test quand même et examine les tailles de fichier non compressé et compressé-décompressé, cela devrait donner une indication.
Citation de: FredEspagne le Avril 06, 2013, 09:06:20
Il y a quand même un problème. La formulation de Nikon ne garantit pas que le fichier non compressé et que le fichier "compressé et décompressé sans pertes" sont strictement identiques. Si ils ne le font pas c'est qu'il doit y avoir des différences même si elles sont peu visibles. Bien sûr ce sera difficile à vérifier car même si on fait des prises de vue du même sujet dans des conditions identiques en mode non compressé et compressé sans pertes, il y aura toujours des variantes dues aux infimes variations du temps d'exposition ou d'ouverture du diaphragme. Je serais curieux que quelqu'un fasse le test quand même et examine les tailles de fichier non compressé et compressé-décompressé, cela devrait donner une indication.
J'avais fait cet essai à l'époque.
Comme il est impossible de prendre deux photos identiques (ne serait-ce qu'à cause du bruit), j'étais parti d'un NEF non compressé. Capture Nx permettait à l'époque de compresser "sans perte" un NEF "non compressé" (il semblerait que ce ne soit plus le cas avec la version actuelle, ou, du moins, je n'ai pas retrouvé).
J'avais ensuite converti en TIFF 16 bits les deux NEF (la version "sans compression" et la version compressée "sans perte").
Pour finir, j'avais ouvert les deux TIFF générés avec un éditeur hexadécimal : données "image" strictement identiques
au bit près.
(peut-être est-il possible de retrouver ces
posts qui commencent à dater ?)
Erreur.
Citation de: RémiNOLTA le Avril 06, 2013, 09:02:16
Je connais ton expertise , que je ne remets pas en cause.
Mais un novice comme moi trouvera étonnant qu'un appareil soit plus lent en RAW sans compression, je devrais dire "sans le travail supplémentaire" de compression par rapport au RAW normal.
Tout dépend de la vitesse de compression, c'est à dire si le CPU et la RAM sont rapides ou non.
La compression d'un même fichier peut prendre 0.1s ou 15s suivant que tu fais ça sur un PC haut de gamme ou un smartphone bas de gamme...
A priori les CPU embarqués sur les boîtiers sont assez performants pour que le gain soit réel.
Citation de: FredEspagne le Avril 06, 2013, 09:06:20
Il y a quand même un problème. La formulation de Nikon ne garantit pas que le fichier non compressé et que le fichier "compressé et décompressé sans pertes" sont strictement identiques.
Dans "compressé sans pertes" il y a écrit "
sans pertes", est-ce si difficile à comprendre ?
1 seul bit altéré ou perdu rend caduque la qualification "sans pertes", tu imagines bien que Nikon ne joue pas avec ça...
Si tu achètes du soda sans sucres tu te poses la question de savoir s'il n'y aurait tout de même pas un peu de sucre dedans ?
Citation de: d800e le Avril 06, 2013, 09:02:53
[at] Verso,
Je sais très bien que 77 Mo prends plus de temps en lecture/écriture que 40 Mo
Je ne fais que du Studio, aussi la rafale de 30 images ...
L'avantage du "Sans Compression" c'est uniquement en post traitement : ça s'ouvre plus vite (même avec un temps de lecture plus important 77 contre 40)
Cela dépend certainement de l'ordinateur utilisé, de la puissance du processeur, des performances du DD (vitesse de rotation, etc).
Je viens de faire un petit essai à l'instant avec 10 x NEF de D700. Sous Capture Nx2, il me faut le même temps (17s) pour ouvrir les dix fichiers NEF, qu'ils soient "non compressés" ou compressés "sans perte" (ordinateur redémarré entre les deux essais, pour éviter les effets de "cache").
- NEF non compressés : 10 x 25 Mo,
- NEF compressés sans perte : 10 x 15 Mo.
Citation de: GilD le Avril 06, 2013, 09:38:51
Dans "compressé sans pertes" il y a écrit "sans pertes", est-ce si difficile à comprendre ?
Apparemment, oui...
Je pense qu'il y en a qui ont du temps à perdre a compliquer ce qui est simple. Mais il est vrais que c'est compliqué de faire simple. ;)
[at] Verso,
Je ne dis pas qu'il ne faut pas utiliser la "Compression Sans Pertes", je dis simplement que pour moi :
L'avantage (pour moi) du "Sans Compression" c'est uniquement en post traitement : ça s'ouvre plus vite même avec des fichiers de 77 Mo
Cela est naturellement fonction de chaque architecture matériel, et avoir un fichier plus lourd ne me pose pas de problème.
Testez tous les modes, et prenez celui qui s'adapte le mieux dans votre environnement et au résultat que l'on souhaite obtenir
Je préfère un 85 f1.4 à la place du 1.8 , car j'ai pas le même résultat (même si DXO donne la même note)
Citation de: d800e le Avril 06, 2013, 10:20:06
[at] Verso,
Je ne dis pas qu'il ne faut pas utiliser la "Compression Sans Pertes", je dis simplement que pour moi :
L'avantage (pour moi) du "Sans Compression" c'est uniquement en post traitement : ça s'ouvre plus vite avec des fichiers de 77 Mo
Par curiosité, de combien sur ta machine ?
(et puis, tant qu'à faire, avec quel type de proc' et de DD ?)
Citation de: d800e le Avril 06, 2013, 10:20:06
Je préfère un 85 f1.4 à la place du 1.8 , car j'ai pas le même résultat (même si DXO donne la même note)
Aucun rapport avec le sujet qui nous préoccupe, qui peut se chiffrer très précisément, contrairement au rendu d'un objectif.
[at] Verso, j'utilise du MAC, de 3 générations différentes, iMac, Mac Pro et MBP,
La vitesse d'ouverture dépend de chaque config, et sur le plus ancien, il vaut mieux avoir un fichier plus lourd que compressé, aussi ...
Sur les machines récentes, ya peu de diff, mais ca se ressent quand même un peu, sans doute lié au MAC, bref ... faut pas se prendre la tête, et puis toutes les licences sont en MAC, je vais pas changer de crèmerie, j'ai besoin de système UNIX et pour le peu de diff à l'ouverture ...
Allez je retourne faire la compta, ça c'est bien plus chiant que le temps d'ouverture ou le poids des fichiers ou le type de config ...
Nb:
. C'est pareil que pour un objo, le rendu, le feeling, malgré le prix bcp plus important du 1.4, dans les 2 cas c'est un objectif qui ont la meme note sur d800
. Ca fonctionne mieux sans compression dans mon cas, dans les 2 cas c'est le meme fichier, malgré le poids
. Je ne dis pas que c'est pas le meme fichier (c'est la même chose), simplement à l'usage, la réaction des machines est différente sur le temps d'ouverture
Citation de: d800e le Avril 06, 2013, 10:31:54
Sur les machines récentes, ya peu de diff, mais ca se ressent quand même un peu, sans doute lié au MAC, bref ...
Tiens, une reculade !
Si tu fais le même essai que Verso sur ta propre machine, tu arriveras au même résultat que Verso, et ton honnêteté intellectuelle t'amènera à dire qu'aujourd'hui, en effet, sur les machines récentes, le non compressé est globalement plus lent que le compressé.
(http://www.chassimages.com/forum/index.php?action=dlattach;topic=180976.0;attach=612327;image)
Merci Verso.
Je pense que cette formulation de Nikon fait disparaître toute ambiguïté.
Mais il faut savoir que pour Nikon :
COMPRESSION = COMPRESSION AVEC PERTES
[at] Tonton-Bruno, sur le dernier MBP 15 Ret et SDD, le fichier semble toujours s'ouvrir plus rapidement en version non compressé, c'est tout
dans un parc de machine, ya de la config récente et de la moins récente, faut trouver l'équilibre, c'est tout, et dans mon cas le non compressé marche mieux, c'est juste une info, ça va pas plus loin Tonton
Citation de: d800e le Avril 06, 2013, 10:42:35
[at] Tonton-Bruno, sur le dernier MBP 15 Ret et SDD, le fichier semble toujours s'ouvrir plus rapidement en version non compressé, c'est tout
dans un parc de machine, ya de la config récente et de la moins récente, faut trouver l'équilibre, c'est tout, et dans mon cas le non compressé marche mieux, c'est juste une info, ça va pas plus loin Tonton
Je ne te crois pas, car depuis 5 ans, j'ai fait les mêmes essais plusieurs fois, sur Mac et sur PC, et c'est toujours le compressé sans perte qui s'est montré le plus rapide.
Exemple: lancer un batch sous Photoshop pour convertir 15 fichiers NEF en JPG.
Pas une seule fois les fichiers non compressés ont été traités plus vite !
Citation de: d800e le Avril 06, 2013, 10:42:35
[at] Tonton-Bruno, sur le dernier MBP 15 Ret et SDD, le fichier semble toujours s'ouvrir plus rapidement en version non compressé, c'est tout
dans un parc de machine, ya de la config récente et de la moins récente, faut trouver l'équilibre, c'est tout, et dans mon cas le non compressé marche mieux, c'est juste une info, ça va pas plus loin Tonton
De toute façon, il y a les choses implicites et/ou facilement vérifiables. Par rapport au mode "non compressé" :
- le mode "compressé sans perte" est sans perte,
- le mode "compressé sans perte" produit des fichiers moins volumineux,
- le mode "compressé sans perte" permet une meilleur réactivité de l'APN.
Reste la lecture sur l'ordinateur. Suivant l'équilibre de la configuration (processeur/RAM/DD, principalement), les choses peuvent certainement varier un peu. Après, à chacun de voir...
[at] Verso,
Entièrement d'accord : le mode "compressé sans perte" permet une meilleur réactivité de l'APN.
[at] Tonton-Bruno, je ne lance jamais un batch NEF -> JPG sous photoshop, je deteste ACR
NEF -> CNX2 -> TIFF -> Photoshop
Je ne fais jamais de JPG, Tonton, je reste toujours en TIFF 16bits (donc 210 Mo) que je transmet au diffuseur (soit format TIFF soit format PSD) sur son serveur via SSH / RSYNC (Terminal Unix d'où la nécessité d'un MAC, par facilité je suis d'accord) ...
Citation de: Verso92 le Avril 06, 2013, 11:00:07
- le mode "compressé sans perte" permet une meilleur réactivité de l'APN.
Ce point reste à vérifier car l'occupation du CPU le temps de la compression peut nuire à la réactivité du boitier.
Ce qui n'est pas le cas pour l'écriture du fichier sur la carte qui est normalement géré par un contrôleur I/O indépendant.
Mais c'est juste une interrogation, je n'en sais rien en pratique.
Citation de: GilD le Avril 06, 2013, 12:33:46
Ce point reste à vérifier car l'occupation du CPU le temps de la compression peut nuire à la réactivité du boitier.
Ce qui n'est pas le cas pour l'écriture du fichier sur la carte qui est normalement géré par un contrôleur I/O indépendant.
Mais c'est juste une interrogation, je n'en sais rien en pratique.
Verso et moi l'avons vérifié plusieurs fois par le passé.
Le RAW compressé sans perte permet de faire plus d'images en rafale et vide le buffer plus vite.
Pour le post-traitement, c'est aussi meilleur.
la lecture du fichier se fait beaucoup plus vite, et comme la décompression des données par le CPU démarre dès le début de la lecture du fichier, il n'y a aucune perte de temps dû à la décompression.
L'information donnée par d800e est donc erronée.
Le meilleur moyen de s'en rendre compte et de faire un batch de 10 ou 15 fichiers, avec juste une sauvegarde en JPG.
Le temps gagné est impressionnant
quelle que soit la machine utilisée
Sur mon MacBook Air les fichiers de D800 qu'ils soient compressés sans perte ou non mettent exactement le même temps pour s'ouvrir dans NX2.
Citation de: jeanbart le Avril 06, 2013, 14:50:31
Sur mon MacBook Air les fichiers de D800 qu'ils soient compressés sans perte ou non mettent exactement le même temps pour s'ouvrir dans NX2.
C'est le signe que le temps nécessaire à la décompression du fichier ne pénalise en rien (ou, du moins, est compensé par la lecture d'un fichier moins volumineux).
Citation de: GilD le Avril 06, 2013, 09:38:51
Dans "compressé sans pertes" il y a écrit "sans pertes", est-ce si difficile à comprendre ?
1 seul bit altéré ou perdu rend caduque la qualification "sans pertes", tu imagines bien que Nikon ne joue pas avec ça...
Si tu achètes du soda sans sucres tu te poses la question de savoir s'il n'y aurait tout de même pas un peu de sucre dedans ?
Dans l'alimentaire, il est prudent de se poser la question: les boissons dites sans alcool en contiennent un peu (jusqu'à 1%, c'est considéré comme normal par les autorités de tutelle) et je ne parlerais pas des derniers scandales de la viande de cheval vendue pour de la viande de boeuf et de la nourriture cacher ou hallal contenant du porc. La comparaison avec l'alimentaire est donc TRÈS malvenue.La formulation de Nikon entretient un certain flou mais bon, j'imagine que les différences visuelles sont impossibles à voir (vu la très médiocre qualité de notre vision).
Citation de: FredEspagne le Avril 06, 2013, 18:55:46
La formulation de Nikon entretient un certain flou mais bon, j'imagine que les différences visuelles sont impossibles à voir (vu la très médiocre qualité de notre vision).
Je rappelle, pour ceux qui pourraient interpréter de travers les propos de FredEspagne, qu'
il n'y a pas de différence.
Je ne me sens pas le courage de faire un résumé de mes cours de théorie de l'information sur les notions d'entropie d'une information, sur l'impact que cela a sur son codage et sa compression, ainsi que sur les méthodes d'écritures d'algorithmes assez simples qui permettent de faire de la compression sans perte, mais pour avoir déjà une partie des arguments et démonstrations sur le sujet, je vous renvoie à ce qui a déjà été discuté et prouvé par le passé:
http://www.chassimages.com/forum/index.php/topic,72281.0.html
Une fois cela lu, s'il y a encore des questions, je serai prêt à répondre.
Mais oui, on peut compresser SANS PERTES, l'info récupérée est EXACTEMENT la même que celle à l'origine.
Il existe plusieurs méthodes, le codage de Huffman en est une, mais pas la seule. Je ne sais pas laquelle est employée par Nikon.
En photo, une qui fonctionne bien est la méthode des différences, se basant sur la similitude à courte portée des informations pour remplacer une information (voir histogramme) étalée en une information très centrée, étroite, ce qui réduit l'entropie de l'information sans en changer le contenu et permet un meilleur codage de Huffman ensuite.
Citation de: Lyr le Avril 06, 2013, 19:17:15
Il existe plusieurs méthodes, le codage de Huffman en est une, mais pas la seule. Je ne sais pas laquelle est employée par Nikon.
C'est bien le codage de Huffman qui est utilisé pour la partie compression sans perte. Tu peux regarder le code source de dcraw disponible ici : http://www.cybercom.net/~dcoffin/dcraw/dcraw.c (http://www.cybercom.net/~dcoffin/dcraw/dcraw.c)
Tout se passe dans la fonction nikon_load_raw. Le decodage de Huffman se fait grace a l'appel gethuff(huff), et la courbe de compression avec perte est dans curve.
Citation de: Lyr le Avril 06, 2013, 19:17:15
Je ne me sens pas le courage de faire un résumé de mes cours de théorie de l'information sur les notions d'entropie d'une information, sur l'impact que cela a sur son codage et sa compression, ainsi que sur les méthodes d'écritures d'algorithmes assez simples qui permettent de faire de la compression sans perte, mais pour avoir déjà une partie des arguments et démonstrations sur le sujet, je vous renvoie à ce qui a déjà été discuté et prouvé par le passé:
http://www.chassimages.com/forum/index.php/topic,72281.0.html
Une fois cela lu, s'il y a encore des questions, je serai prêt à répondre.
Mais oui, on peut compresser SANS PERTES, l'info récupérée est EXACTEMENT la même que celle à l'origine.
Il existe plusieurs méthodes, le codage de Huffman en est une, mais pas la seule. Je ne sais pas laquelle est employée par Nikon.
En photo, une qui fonctionne bien est la méthode des différences, se basant sur la similitude à courte portée des informations pour remplacer une information (voir histogramme) étalée en une information très centrée, étroite, ce qui réduit l'entropie de l'information sans en changer le contenu et permet un meilleur codage de Huffman ensuite.
Cool : tu as retrouvé le fil sur lequel j'avais fait l'essai de comparer les TIFF 16 bits générés par un NEF non compressé et son alter égo compressé "sans perte" !
;-)
Edit : en TIFF 8 bits, pour la raison évoquée ci-dessous :
Citation de: Verso92 le Décembre 31, 2009, 14:46:20
Les deux fichiers obtenus ont été sauvegardés à leur tour en TIFF (le format utilisé pour le TIFF a été "8 bits/compressé LZW", car l'éditeur hexadécimal que j'utilise n'arrivait pas à ouvrir les TIFF 16 bits, trop lourds).
Citation de: Verso92 le Avril 06, 2013, 19:58:39
Cool : tu as retrouvé le fil sur lequel j'avais fait l'essai de comparer les TIFF 16 bits générés par un NEF non compressé et son alter égo compressé "sans perte" !
Même avec cela, il y en a encore qui vont réussir à ne pas te croire. Vu les nombres de conneries dites sur les différents types de compression par certains, le rapport signal/bruit est devenu bien trop faible pour convaincre qui que ce soit.
Citation de: sylvatica le Avril 06, 2013, 20:04:40
Même avec cela, il y en a encore qui vont réussir à ne pas te croire. Vu les nombres de conneries dites sur les différents types de compression par certains, le rapport signal/bruit est devenu bien trop faible pour convaincre qui que ce soit.
Oui, mais là, on ne peut plus rien pour eux, n'est-ce pas ?
(le but de ce genre de
post n'est pas de convaincre les neuneus, mais de ne pas les laisser polluer les fils de discussions et enduire les autres lecteurs avec de l'erreur)
Citation de: Verso92 le Avril 06, 2013, 20:10:18
Oui, mais là, on ne peut plus rien pour eux, n'est-ce pas ?
C'est effectivement sans espoir.
Citation de: jeanbart le Avril 06, 2013, 14:50:31
Sur mon MacBook Air les fichiers de D800 qu'ils soient compressés sans perte ou non mettent exactement le même temps pour s'ouvrir dans NX2.
Je pense que les temps de chargements sont difficiles à calculer et que les différences sont suffisamment faibles pour que les aléas de la mesure fausse les conclusion. Le principal problème c'est le cache disque (du driver disque et de l'OS). il faut bien être sur qu'il est dans la même état au départ pour les deux test. Vide de préférence vu le sujet de la discution. Le moyen qui semble le plus simple est de charger suffisamment de fichier pour être sur que le cache n'entre plus ligne de compte. C'est à dire sensiblement plus que la mémoire vive dispo sur ta configuration et de ne commencer les mesures qu'à partir de là. Idem pour l'autre type de fichier.
De plus comme dans toute mesure de perfs, il faut faire plusieurs essais et voir la moyenne, le pire et le meilleur cas.
Citation de: eengel le Avril 06, 2013, 20:41:37
Je pense que les temps de chargements sont difficiles à calculer et que les différences sont suffisamment faibles pour que les aléas de la mesure fausse les conclusion. Le principal problème c'est le cache disque (du driver disque et de l'OS). il faut bien être sur qu'il est dans la même état au départ pour les deux test. Vide de préférence vu le sujet de la discution. Le moyen qui semble le plus simple est de charger suffisamment de fichier pour être sur que le cache n'entre plus ligne de compte. C'est à dire sensiblement plus que la mémoire vive dispo sur ta configuration et de ne commencer les mesures qu'à partir de là. Idem pour l'autre type de fichier.
De plus comme dans toute mesure de perfs, il faut faire plusieurs essais et voir la moyenne, le pire et le meilleur cas.
C'est pour cela que dans l'essai que j'ai fait, j'ai ouvert dix fichiers NEF de chaque type en partant à chaque fois d'une ouverture de session (machine redémarré dans les deux cas).
Citation de: Verso92 le Avril 06, 2013, 21:02:14
C'est pour cela que dans l'essai que j'ai fait, j'ai ouvert dix fichiers NEF de chaque type en partant à chaque fois d'une ouverture de session (machine redémarré dans les deux cas).
J'était déjà persuadé avant mesure que le compressé était plus avantageux pour le vitesse pour le boitier et pour le PC.
Pour le boitier, il est aussi possible, comme je l'ai mentionné récemment, que cela soit aussi intéressant en terme d'autonomie électrique.
Bon, et sinon, pour mettre un peu plus le bazar, ça sert à quoi de faire du Raw compressé avec perte, par rapport à un bon jpeg ?
Citation de: vjau le Avril 06, 2013, 23:36:32
Bon, et sinon, pour mettre un peu plus le bazar, ça sert à quoi de faire du Raw compressé avec perte, par rapport à un bon jpeg ?
Si je ne devais retenir que deux avantages, ce serait la reprise en post production de la balance des blancs et des basses lumière.
Pour le deuxième point, je me souviens d'une illustration ici:
http://www.olivier-chauvignat.fr/pab/wp/tutoriels/demonstration-basses-lumieres-sur-fichier-raw/ (http://www.olivier-chauvignat.fr/pab/wp/tutoriels/demonstration-basses-lumieres-sur-fichier-raw/)
Citation de: vjau le Avril 06, 2013, 23:36:32
Bon, et sinon, pour mettre un peu plus le bazar, ça sert à quoi de faire du Raw compressé avec perte, par rapport à un bon jpeg ?
Ne nous dis pas que tu n'as pas compris la différence entre le RAW et le Jpeg ?
Citation de: Verso92 le Avril 06, 2013, 23:55:29
Ne nous dis pas que tu n'as pas compris la différence entre le RAW et le Jpeg ?
Si, mais pour moi parmi la liste des avantages figure l'absence de compression avec perte.
Un raw compressé avec perte, ça me semble une drôle de tabouille.
La possibilité de choisir la bdb à postériori est une réponse intéressante, si ce n'est qu'on peut quand même se poser la question de savoir si les infos qui ont été écartées au moment de la compression n'auraient pas justement servi à avoir une plus grande étendue colorimétrique pour retoucher la bdb.
En gros à quoi ça sert d'utiliser un format orienté post-production (donc réglages à postériori) en lui faisant subir une perte d'info à priori ?
Citation de: vjau le Avril 07, 2013, 00:22:50
Si, mais pour moi parmi la liste des avantages figure l'absence de compression avec perte.
Un raw compressé avec perte, ça me semble une drôle de tabouille.
La possibilité de choisir la bdb à postériori est une réponse intéressante, si ce n'est qu'on peut quand même se poser la question de savoir si les infos qui ont été écartées au moment de la compression n'auraient pas justement servi à avoir une plus grande étendue colorimétrique pour retoucher la bdb.
En gros à quoi ça sert d'utiliser un format orienté post-production (donc réglages à postériori) en lui faisant subir une perte d'info à priori ?
Pour essayer de quantifier mon point de vue, je dirais que la possibilité de changer le
Picture Control ou la BdB à posteriori, par exemple, ont un poids de "100", et que le fait que le RAW soit sans perte a un poids de "5"...
Citation de: GilD le Avril 06, 2013, 09:38:51
Dans "compressé sans pertes" il y a écrit "sans pertes", est-ce si difficile à comprendre ?
1 seul bit altéré ou perdu rend caduque la qualification "sans pertes", tu imagines bien que Nikon ne joue pas avec ça...
Si tu achètes du soda sans sucres tu te poses la question de savoir s'il n'y aurait tout de même pas un peu de sucre dedans ?
Mauvais exemple, tout est histoire de pourcentage.
Le bio est bio à partir d'un certain %.
Les bières sans alcool ont 0.1% d'alcool ... etc ;D
Je viens de faire un petit test sur mon D700 : je regarde le nombre PdV restantes suivant la config. J'ai le même nombre si je suis en sans compression ou bien compression sans perte. Bizarre, non ?
Après, je ne suis pas allé voir la taille des NEF produits ...
Citation de: vjau le Avril 07, 2013, 00:22:50
Si, mais pour moi parmi la liste des avantages figure l'absence de compression avec perte.
Un raw compressé avec perte, ça me semble une drôle de tabouille.
En 14 bit, tu peux selectionner RAW compressé
avec perte les yeux fermés. Une étude théorique et pratique a été faite dans un fil voisin. Les conclusion sont implacables : même pour les gens qui font du post-traitement ultra violent et qui collent leur nez à un crop 400% sur un D800, il n'y a aucune différence visuelle.
Regarde le fil "NEF 12 ou 14 bit" et mon post du 8/4/2013 à 03:13:04. Si tu me dis quelle est la ligne qui est compressée avec perte, je veux bien remonter les Champs Élysées dans le plus simple appareil en faisant le canard.
Citation de: GG_ le Avril 08, 2013, 21:40:57
Je viens de faire un petit test sur mon D700 : je regarde le nombre PdV restantes suivant la config. J'ai le même nombre si je suis en sans compression ou bien compression sans perte. Bizarre, non ?
Après, je ne suis pas allé voir la taille des NEF produits ...
C'est parce qu'une compression sans pertes va donner une compression variable qui pourrait être très bonne (image purement monochrome) ou très mauvaise (beaucoup de micro-détails, aucun pixel similaire, que ce soit à courte ou à longue portée).
Donc histoire de pas donner de fausses illusions, Nikon considère en "compression sans pertes" la pire des situations, soit "ça réduira absolument pas la taille du fichier".
Concrètement, le fichier enregistré sera plus petit que prévu, et donc le décompte sera plus lent.
Pour te donner une illustration (je suis toujours en compressé sans pertes).
Sur mon D700, avec la carte qui est dedans (16Go), il m'annonce que je pourrai enregistrer 500 photos (j'arrondis les chiffres).
Le mois passé fut bien chargé, à un moment où je connecte ma carte mémoire sur l'ordi, je vois que le dossier contient 500 photos. Je me fais "wow, j'ai eu du bol, j'étais juste à la limite de la carte, encore une ou deux photos, et c'était fini :o ".
Puis je regarder en dessous dans la barre d'état, et je vois qu'il reste environ 8 Go de libre.
Bizarre, une carte vide fit que l'appareil annonce 500 photos, j'en ai fait 500 et j'ai une carte à moitié remplie.
Je remets donc la carte dans le D700 et je regarde l'affichage.
Là il met que je peux encore faire 250 photos.
Puis là, tilt! "Mais bien sûr, il ne prend pas en compte la compression dans son prévisionnel".
C'est le genre de chose à laquelle on ne fait pas attention, et c'est de temps en temps (moins d'une fois par an pour moi) qu'on se retrouve face à une situation qui nous rappelle de tels détails.
Voilà, j'espère que cela clarifie le résultat de ton expérience.
Citation de: Lyr le Avril 08, 2013, 23:06:33
C'est parce qu'une compression sans pertes va donner une compression variable qui pourrait être très bonne (image purement monochrome) ou très mauvaise (beaucoup de micro-détails, aucun pixel similaire, que ce soit à courte ou à longue portée).
Donc histoire de pas donner de fausses illusions, Nikon considère en "compression sans pertes" la pire des situations, soit "ça réduira absolument pas la taille du fichier".
Concrètement, le fichier enregistré sera plus petit que prévu, et donc le décompte sera plus lent.
Pour te donner une illustration (je suis toujours en compressé sans pertes).
Sur mon D700, avec la carte qui est dedans (16Go), il m'annonce que je pourrai enregistrer 500 photos (j'arrondis les chiffres).
Le mois passé fut bien chargé, à un moment où je connecte ma carte mémoire sur l'ordi, je vois que le dossier contient 500 photos. Je me fais "wow, j'ai eu du bol, j'étais juste à la limite de la carte, encore une ou deux photos, et c'était fini :o ".
Puis je regarder en dessous dans la barre d'état, et je vois qu'il reste environ 8 Go de libre.
Bizarre, une carte vide fit que l'appareil annonce 500 photos, j'en ai fait 500 et j'ai une carte à moitié remplie.
Je remets donc la carte dans le D700 et je regarde l'affichage.
Là il met que je peux encore faire 250 photos.
Puis là, tilt! "Mais bien sûr, il ne prend pas en compte la compression dans son prévisionnel".
C'est le genre de chose à laquelle on ne fait pas attention, et c'est de temps en temps (moins d'une fois par an pour moi) qu'on se retrouve face à une situation qui nous rappelle de tels détails.
Voilà, j'espère que cela clarifie le résultat de ton expérience.
Ok merci pour l'info.
Que le raw sans perte soit sans perte dans NX, je n'en doute pas. D'ailleurs, je n'utilise que ça.
Par contre, les autres softs que ceux de Nikon sont ils capables d'interpréter convenablement la compression ?
Citation de: elmerfudd le Avril 11, 2013, 14:22:13
Par contre, les autres softs que ceux de Nikon sont ils capables d'interpréter convenablement la compression ?
Oui (ce n'est qu'un bête LZW tout ce qu'il y a de plus classique).
Donc les différences que je peux constater dans lightroom ne sont dues qu'au fait qu'il ne sait pas interpréter les paramètres comme le contraste, picture controle, netteté, dlighting ... ?
Et il faut que je regarde ce qu'est LZW
Citation de: elmerfudd le Avril 11, 2013, 14:28:20
Donc les différences que je peux constater dans lightroom ne sont dues qu'au fait qu'il ne sait pas interpréter les paramètres comme le contraste, picture controle, netteté, dlighting ... ?
Oui.
(s'il ne savait pas décompresser l'image, LR n'affichait rien, tout bonnement)
Citation de: elmerfudd le Avril 11, 2013, 14:28:20
Donc les différences que je peux constater dans lightroom ne sont dues qu'au fait qu'il ne sait pas interpréter les paramètres comme le contraste, picture controle, netteté, dlighting ... ?
Non !
Lightroom sait interpréter les paramètres comme le contraste, picture controle, netteté, dlighting...
Mais sans doute ne les interprète-t-il pas exactement de la même manière.
Citation de: B [at] R le Avril 11, 2013, 14:41:57
Non !
Lightroom sait interpréter les paramètres comme le contraste, picture controle, netteté, dlighting...
LR récupère donc par défaut tous les paramètres de configuration du boitier Nikon ?
Citation de: Verso92 le Avril 11, 2013, 14:43:51
LR récupère donc par défaut tous les paramètres de configuration du boitier Nikon ?
Sans doute pas TOUS.
Je n'ai pas vérifié dans le détail.
Citation de: B [at] R le Avril 11, 2013, 14:41:57
Non !
Lightroom sait interpréter les paramètres comme le contraste, picture controle, netteté, dlighting...
Mais sans doute ne les interprète-t-il pas exactement de la même manière.
Moi je suis d'accord mais avec un "ne" et un "pas" autour du "sait" ;)
Citation de: B [at] R le Avril 11, 2013, 14:47:05
Sans doute pas TOUS.
Je n'ai pas vérifié dans le détail.
Vérifies plusss, c'est nécessaire.
J'avoue ma perplexité !
Si Lightroom "ne" sait "pas" interpréter les paramètres de prise de vue et de configuration, c'est plutôt gênant. Non ?
Et ce serait un très sérieux handicap face à Capture NX.
Je confirme
Netteté : non
Contraste : non
Picture control : non
D-lighting : ça joue sur l'exposition mais bof
...
Je crois que LR n'interpréte que la balance des blancs
Parfois les différences d'interprétation entre NX et LR sont assez fortes.
Et désolé pour le HS
D'un autre côté, c'est un peu normal car Capture et View NX sont les softs maisons.
J'ai donc toujours ViewNX en complément de lightroom pour avoir un aperçu "réel" de mon image.
Citation de: B [at] R le Avril 11, 2013, 15:03:29
J'avoue ma perplexité !
Si Lightroom "ne" sait "pas" interpréter les paramètres de prise de vue et de configuration, c'est plutôt gênant. Non ?
Et ce serait un très sérieux handicap face à Capture NX.
Seul les logiciels Nikon le font (mais contrairement àLightroom, ils ne traitent que du Nikon).
Et non, je ne pense pas que ce soit un handicap, tu peux faire tous les presets que tu veux dans Ligthroom pour obtenir le rendu que tu souhaites.
Personnellement j'utilise NX2 et je ne me cantonne jamais aux paramètres du boitier (sinon pourquoi utiliser le Raw ?)
Citation de: B [at] R le Avril 11, 2013, 15:03:29
J'avoue ma perplexité !
Si Lightroom "ne" sait "pas" interpréter les paramètres de prise de vue et de configuration, c'est plutôt gênant. Non ?
Et ce serait un très sérieux handicap face à Capture NX.
Oui c'est gênant et oui c'est un handicap.
OK, merci à vous tous. Mon erreur m'a permis d'apprendre quelque chose !
Je vais en tenir compte dans mon choix de logiciel de développement : http://www.chassimages.com/forum/index.php/topic,180671.0.html
Fin du HS.
Citation de: B [at] R le Avril 11, 2013, 15:03:29
J'avoue ma perplexité !
Si Lightroom "ne" sait "pas" interpréter les paramètres de prise de vue et de configuration, c'est plutôt gênant. Non ?
Et ce serait un très sérieux handicap face à Capture NX.
Pour moi ViewNX tournait très mal sur ma config (il y a 2-3ans) et là c'était un véritable handicap, donc aucune envie d'installer Cnx,
d’où j'utilise depuis 2 ans LR3 sans problèmes (et avant CRW/PS) et pas vraiment de handicap :)
Maintenant les dernières versions de Vnx tournent mieux sur cette même config, comme quoi il y a certains progrès!
Après c'est une question d'habitude ou "d'ergonomie" mais je ne pense pas qu'il y ait de choix "handicapant" avec les logiciels cités...
Entre nous ;) , j’essaie de soigner les Jpeg qui sortent de mon boitier ( Bdb PC expo etc) et c'est quand même très sport d'arriver à ses fins régulièrement, alors récupérer systématiquement les paramètres boitiers finalement ne m'intèresse pas tant que ça, les présets de LR sont pour moi plus efficaces
Citation de: jdm le Avril 11, 2013, 15:40:56
Entre nous ;) , j'essaie de soigner les Jpeg qui sortent de mon boitier ( Bdb PC expo etc) et c'est quand même très sport d'arriver à ses fins régulièrement, alors récupérer systématiquement les paramètres boitiers finalement ne m'intèresse pas tant que ça, les présets de LR sont pour moi plus efficaces
Heu !?! Les considérations évoquées sont pour le raw...
Retoucher les paramètres boîtier sur un jpeg ?
Citation de: Inka le Avril 11, 2013, 15:50:30
Heu !?! Les considérations évoquées sont pour le raw...
Les paramètres boîtier sur un jpeg ?
Tu as raison, je ne fais que du Raw, ça ne m'empêche pas d'essayer de soigner le Jpeg "embarqué" dans celui-ci (la prévisualisation en gros)
Citation de: coval95 le Avril 06, 2013, 00:51:59
Ah merci ! Voilà la clé du décodage pour moi ! ;)
A la compression le texte est analysé sous l'angle des successions de caractères et le résultat de l'analyse est stocké sous forme de table de correspondance.
Donc pour une suite de caractères retrouvée plusieurs fois dans le fichier, on aura un code (au lieu d'avoir un code par caractère, d'où le gain de place).
C'est bien ça ?
comem la pierre de rosette de Champollion ;)
Citation de: Manu_14 le Avril 11, 2013, 15:09:30
Seul les logiciels Nikon le font (mais contrairement àLightroom, ils ne traitent que du Nikon).
Et non, je ne pense pas que ce soit un handicap, tu peux faire tous les presets que tu veux dans Ligthroom pour obtenir le rendu que tu souhaites.
Personnellement j'utilise NX2 et je ne me cantonne jamais aux paramètres du boitier (sinon pourquoi utiliser le Raw ?)
Les paramètres boitiers Nikon sont une base de travail commune pour un traitement ultérieur. On peut toujours s'en passer, et tout reprendre à zéro, mais l'affichage arrière du boitier perd une partie de son sens.
Citation de: kochka le Avril 11, 2013, 19:08:30
Les paramètres boitiers Nikon sont une base de travail commune pour un traitement ultérieur. On peut toujours s'en passer, et tout reprendre à zéro, mais l'affichage arrière du boitier perd une partie de son sens.
Personnellement je ne m'en sers que pour vérifier le cadrage et l'histogramme.
Citation de: Manu_14 le Avril 11, 2013, 21:01:33
Personnellement je ne m'en sers que pour vérifier le cadrage et l'histogramme.
L'histogramme est directement dépendant des réglages du boîtier.
Oui, tu as raison. Mais sur le boitier je n'utilise que le réglage standard, pas de D-Lighting, espace sRVB. Je fais tous les changements sur NX2 (en particulier, le choix de Prophoto comme espace de travail et les réglages de picture control). C'est pour ça que je précisais "personnellement".
Quand on utilise la compression sans perte, puis que les photos sont importées dans LR, la décompression se fait bien sans perte ou il faut NX ?
Merci
Il n'y a pas de différences notables dans LR
Citation de: daor le Septembre 15, 2014, 09:50:46
Quand on utilise la compression sans perte, puis que les photos sont importées dans LR, la décompression se fait bien sans perte ou il faut NX ?
S'il y a perte, elle se fait lors de la compression et pas après. ;)
Citation de: daor le Septembre 15, 2014, 09:50:46
Quand on utilise la compression sans perte, puis que les photos sont importées dans LR, la décompression se fait bien sans perte ou il faut NX ?
Merci
Puisque la compression est sans perte, la décompression l'est aussi.
Citation de: Verso92 le Septembre 15, 2014, 12:15:50
Puisque la compression est sans perte, la décompression l'est aussi.
Oui naturellement et c'est bien ce je comprends, mais dans le dernier N° de CI (367) en p119 (test du D810), l'auteur indique que la dynamique du capteur dépasse 14 IL
" [...]et qu'il serait idiot de ne pas profiter de cette qualité maximale par un mauvais de choix de paramétrage d'enregistrement. Pour moi c'est : pas de compression et raw 14 bits. [...]"Surprenant ce choix de pas de compression, non?
La différence que je vois concerne le timing :
En mode compression sans perte, le processeur du boîtier est un peu plus sollicité (calcul de la redondance) et il y un temps d'écriture du raw dans la carte plus rapide que non compressé,
en mode sans compression, il reste le temps d'écriture du fichier non compressé
mais grosso modo, le temps de traitement doit être assez proche et avec plus de photos sur la carte avec le mode compression sans perte!
Pour la qualité finale du fichier, il n'y a pas de différence avec une compression sans perte et pas de compression. l'article a tendance à laisser entendre que non?
Citation de: MBe le Septembre 15, 2014, 21:28:49
Oui naturellement et c'est bien ce je comprends, mais dans le dernier N° de CI (367) en p119 (test du D810), l'auteur indique que la dynamique du capteur dépasse 14 IL " [...]et qu'il serait idiot de ne pas profiter de cette qualité maximale par un mauvais de choix de paramétrage d'enregistrement. Pour moi c'est : pas de compression et raw 14 bits. [...]"
Surprenant ce choix de pas de compression, non?
La différence que je vois concerne le timing :
En mode compression sans perte, le processeur du boîtier est un peu plus sollicité (calcul de la redondance) et il y un temps d'écriture du raw dans la carte plus rapide que non compressé,
en mode sans compression, il reste le temps d'écriture du fichier non compressé
mais grosso modo, le temps de traitement doit être assez proche et avec plus de photos sur la carte avec le mode compression sans perte!
Pour la qualité finale du fichier, il n'y a pas de différence avec une compression sans perte et pas de compression. l'article a tendance à laisser entendre que non?
L'article du petit jeune de CI sur le D810 est presque un sans faute. On dira qu'il fallait un petit accroc, c'est celui-là...
Il n'y a, bien sûr, rigoureusement aucune différence de qualité entre "compression sans pertes" et "sans compression". Et comme le fichier est plus léger et s'écrit plus vite dans la carte, c'est tout bénéfice !
(il serait temps que Nikon supprime cette option débile sur ses boitiers haut de gamme, comme ils l'ont fait sur les boitiers de la gamme en dessous...)
Citation de: Verso92 le Septembre 15, 2014, 23:59:31
Et comme le fichier est plus léger et s'écrit plus vite dans la carte, c'est tout bénéfice !
A condition que le temps nécessaire à la compression ne soit pas supérieur à celui nécessaire à l'écriture du supplément de taille.
Mais c'est un détail qui ne vient en aucun cas remettre en cause le choix judicieux de la compression sans perte.
Une compression sans perte est un algo réversible.
C'est le principe de la mise ne facteur de cours de math du lycée, largement amélioré certes, mais la réversibilité permettant de retrouver exactement le fichier d'origine est assurée. I
C'est ce que ne sait pas faire le JPG qui sacrifie plus ou moins de nuances selon le degré de compression choisi.
Est-ce si dur à comprendre?
Citation de: B [at] R le Septembre 16, 2014, 11:46:07
A condition que le temps nécessaire à la compression ne soit pas supérieur à celui nécessaire à l'écriture du supplément de taille.
Il ne l'est pas... si tu n'es pas convaincu, fais l'essai !
(pourquoi faire des hypothèses... il suffit de vérifier !)
Oui un algo de compression avec l'adjectif sans perte ne laisse pas de doute, mais (oui il y a un mais ;)) l'article Nikon 2272 montrerait que "le petit jeune de CI" à cette information et a peut être validé sont point de vue par des mesures.
Voici le lien de l'article complet : https://nikoneurope-en.custhelp.com/app/answers/detail/a_id/2272/~/fichier-nef-%28nikon-electronic-format%29 (https://nikoneurope-en.custhelp.com/app/answers/detail/a_id/2272/~/fichier-nef-%28nikon-electronic-format%29)
et un extrait qui dit :
"3. Compression sans perte : certains reflex numériques disposent d'une option permettant d'enregistrer dans l'appareil photo le fichier NEF sous forme de fichier compressé sans perte. Dans des conditions normales de visionnage, il existe très peu de différences en termes de qualité entre un fichier NEF compressé sans perte et un fichier NEF compressé. Néanmoins, le format compressé sans perte offre une grande souplesse d'édition de l'image et donne la possibilité de réenregistrer le fichier sans compression."
si cet algo de compression "sans perte" génère a priori quelques pertes (hautes fréquences), elles n'étaient probablement pas visibles sur des APN avec un filtre passe bas, une bande passante capteur + bayer juste inférieure à cette fréquence de coupure haute de cette compression (d'où le qualificatif sans perte), mais commencent peut être (?) à apparaître sur un D8xx.
L'évolution logique serait d'implanter un algorithme de compression réellement sans perte.
Des photos prises dans des conditions strictement identiques, sans compression et avec compression sans perte, sur une mire de ftm (ou mire de Dxo également) permettraient de vérifier facilement l'écart (si il existe, mais j'ai tendance à faire confiance à la publication Nikon) par comparaison des fichiers.
Citation de: MBe le Septembre 16, 2014, 21:27:22
"3. Compression sans perte : certains reflex numériques disposent d'une option permettant d'enregistrer dans l'appareil photo le fichier NEF sous forme de fichier compressé sans perte. Dans des conditions normales de visionnage, il existe très peu de différences en termes de qualité entre un fichier NEF compressé sans perte et un fichier NEF compressé. Néanmoins, le format compressé sans perte offre une grande souplesse d'édition de l'image et donne la possibilité de réenregistrer le fichier sans compression."
En français, ça veut dire que c'est le fichier compressé avec pertes qui a des pertes! ;)
[at] MBe
Et si tu lisais correctement.
Nikon dit qu'il y très peu de différence entre le NEF compressé sans perte et le NEF compressé (sous entendu : avec perte). Nulle part, il n'est question de NEF non compressé. Tout au moins dans l'extrait que tu as copié
Citation de: Nikojorj le Septembre 16, 2014, 21:49:41
En français, ça veut dire que c'est le fichier compressé avec pertes qui a des pertes! ;)
C'est aussi comme cela que je le lis en français...
On peut théoriquement faire une vérification informatique entre un fichier compressé sans perte et un fichier non compressé. Je parle ici d'une comparaison byte à byte. Mais dans la pratique, c'est impossible. D'abord parce que chaque photo sera différente, à la prise de vue, de la suivante (éclairage, luminosité, ...). Ensuite parce qu'aller modifier les réglages NEF fera bouger imperceptiblement l'appareil et faussera toute comparaison.
J'ai un peu de mal à comprendre pourquoi certains ont encore des doutes...
Quand le format de compression est sans perte il l'est à la compression et la décompression car il est mathématiquement fabriqué comme çà.
Un équivalent parlant bureautique du format NEF sans perte est le format ZIP bien connu.
Si on compresse un fichier word ou excel en ZIP, on retrouve toutes ses données intactes à la décompression (heureusement !) et pourtant le fichier ZIP peut être 10 fois plus petit que le fichier original.
En fait l'algorithme de compression applique des règles mathématiques qui ressemblent à l'exemple très simplifié et réduit suivant :
si le fichier original contient :
XAAAAAAAAAAZ
Le fichier compressé pourrait contenir (en simplifiant) :
X10AZ
ce qui est beaucoup plus court.
Le programme de décompression saura toujours retrouver :
XAAAAAAAAAAZ
sans la moindre perte.
C'est une opération analogue qui est exécutée pour obtenir un NEF à compression sans perte qui est donc sans perte par définition..
Citation de: ieu00027 le Septembre 16, 2014, 21:58:50
On peut théoriquement faire une vérification informatique entre un fichier compressé sans perte et un fichier non compressé. Je parle ici d'une comparaison byte à byte. Mais dans la pratique, c'est impossible. D'abord parce que chaque photo sera différente, à la prise de vue, de la suivante (éclairage, luminosité, ...). Ensuite parce qu'aller modifier les réglages NEF fera bouger imperceptiblement l'appareil et faussera toute comparaison.
A l'époque, je l'avais fait.
J'avais pris une photo en NEF "non compressé". J'avais fait une copie de ce fichier et je l'avais compressé via le logiciel Nikon Capture avec l'option "compression sans perte".
J'avais ensuite généré un fichier TIFF 16 bits à partir de ces deux NEF, et j'avais comparé les champs "données" avec un éditeur hexadécimal : strictement identiques, au bit près.
Bien sûr, aucune surprise en ce qui concerne le résultat, sachant qu'il s'agit d'un algorithme de compression
réversible.
Citation de: zuiko le Septembre 16, 2014, 22:10:50
J'ai un peu de mal à comprendre pourquoi certains ont encore des doutes...
Pareil, mais les marketeux aiment bien entretenir un peu de FUD il parait que ça fait acheter...
Citation de: Verso92 le Septembre 16, 2014, 22:11:03
A l'époque, je l'avais fait.
J'avais pris une photo en NEF "non compressé". J'avais fait une copie de ce fichier et je l'avais compressé via le logiciel Nikon Capture avec l'option "compression sans perte".
J'avais ensuite généré un fichier TIFF 16 bits à partir de ces deux NEF, et j'avais comparé les champs "données" avec un éditeur hexadécimal : strictement identiques, au bit près.
Bien sûr, aucune surprise en ce qui concerne le résultat, sachant qu'il s'agit d'un algorithme de compression réversible.
Fait comme cela, effectivement.
Comme l'a très bien dit zuiko, c'est le même principe que le Zip.
La question pour un programmeur n'est pas d'écrire la routine de compression (et donc de décompression). Mais d'optimiser
1. La technique de compression (plus c'est compressé, mieux c'est)
2. La vitesse de traitement (plus c'est rapide, mieux c'est)
3. Trouver un bon compromis entre les points 1 et 2.
Vous avez raison (Nikojorj, Ieu00027...), j'ai mal lu ou compris ce texte!
Il faut donc espérer que CI apporte une correction dans le prochain numéro (?).
Et Nikon pourrait supprimer le mode Nef non compressé...(du fait que tous les logiciels tiers savent interprétés des Nef compressés sans perte)
Amicalement, pour le "petit jeune", comme le qualifie gentiment Verso, Pierre-Marie Salomez : "compression sans perte" c'est sans perte, na ! Au demeurant, je trouve l'article consacré au D810 très bon.
Citation de: MBe le Septembre 21, 2014, 20:01:00
Vous avez raison (Nikojorj, Ieu00027...), j'ai mal lu ou compris ce texte!
Il faut donc espérer que CI apporte une correction dans le prochain numéro (?).
Et Nikon pourrait supprimer le mode Nef non compressé...(du fait que tous les logiciels tiers savent interprétés des Nef compressés sans perte)
Nikon a d'ailleurs supprimé le mode "non compressé" de la plupart de ses boitiers, sauf pour les hauts de gamme (la peur, sans doute, de générer une incompréhension chez les photographes non férus des techniques de compression).
Citation de: Lorca le Septembre 21, 2014, 20:37:16
Amicalement, pour le "petit jeune", comme le qualifie gentiment Verso, Pierre-Marie Salomez : "compression sans perte" c'est sans perte, na ! Au demeurant, je trouve l'article consacré au D810 très bon.
Oui, l'article est très bien ficelé.
(je n'avais pas CI sous les yeux au moment d'écrire mon
post, et je voulais pas prendre le risque d'écorcher le nom de notre jeune journaliste... ;-)
Citation de: Lorca le Septembre 21, 2014, 20:37:16
Amicalement, pour le "petit jeune", comme le qualifie gentiment Verso, Pierre-Marie Salomez : "compression sans perte" c'est sans perte, na ! Au demeurant, je trouve l'article consacré au D810 très bon.
Oui le test du 810 est bien fait, mais depuis quelques mois on a perdu les courbes de rendu (dynamique) dommage ???
Pas grave : DxOMark.
Oui et non, oui car cela ne devait pas beaucoup passionné (et pourtant...), non car il est bien d'avoir pour les intéressés plusieurs avis (même si CI utilise Dxo).
La compression ne peut pas être sans "pertes" parce que s'il n'y en pas elle ne peut pas être au pluriel..... ;D
Presque tout a déjà été dit. Je vais toutefois ajouter une petite goutte:
- Compression sans perte: Vraiment pas de perte du fait que c'est réversible. Gain en taille du fichier 20-40%. J'utilise toujours ce mode.
- Compression avec perte: Les pertes sont minimes (dépendant de la photo). Gain 35-55%. Le gain n'est pas énorme par rapport à la compression sans perte, mais dans la plupart des photos la perte n'est pas visible. Je n'utilise jamais cette compression du fait que la taille diminue très peu.
Pour être clair voici le résultat d'un test d'un fichier RAW 14 bits à 36 Mpx:
Pas comprimé: 77119 ko.
Sans perte: 47274 ko.
Avec perte: 41187 ko.
A y être, on pourrait se poser une autre question, pourquoi pas : 12 ou 14 bits ?