RAW: compression sans perte sans pertes?!

Démarré par eengel, Avril 05, 2013, 22:41:39

« précédent - suivant »

d800e

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

Verso92

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.

d800e

#52
 [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

Tonton-Bruno

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é.
Tout ce qui peut être réglé dès la prise de vue gagne à l'être

B@R



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

d800e

#55
 [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

Tonton-Bruno

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 !
Tout ce qui peut être réglé dès la prise de vue gagne à l'être

Verso92

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

d800e

#58
 [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)  ...


Jinx

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.

Tonton-Bruno

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
Tout ce qui peut être réglé dès la prise de vue gagne à l'être

jeanbart

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.
La Touraine: what else ?

Verso92

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

FredEspagne

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).
35 ans de film et labo argentique , 21 de numérique

Verso92

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.

Lyr

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.

sylvatica

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

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.

Verso92

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

sylvatica

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.

Verso92

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)

sylvatica

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.

eengel

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.

Verso92

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

eengel

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.

vjau

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 ?