La fin de Capture NX-2...

[Patrice]

D'un point de vue théorique c'est jouable.

Avec une matrice de quantification spécifique et des données en entrée pensées pour se trouver dans le cas de figure où la compression entropique finale d'Huffman produit une inflation de la masse de donnée, on peut le faire.

Il n'y a pas de compression de données sans perte universelle.

C'est assez simple à prouver mathématiquement.

Il existe donc pour tout algorithme de compression sans perte un corpus de données en entré qui sera moins volumineux qu'en sortie.

Donc c'est faisable, mais il faut se donner beaucoup de maĺ pour y arriver et l'image de base serait assez abstraite :-)

blablabla

http://www.tsi.telecom-paristech.fr/pages/enseignement/ressources/beti/jpeg_entropie/contenu.html

[Jean-Henri Lambert]

Et ?

Je n'ai pas le droit d'échanger avec Verso ?

Quelle attitude sectaire :-(

[zuiko]

Je pense qu'il y a une incompréhension de base des concepts de codage des différents types de fichiers. Il n'y a rien d'anormal à ce qu'un fichier dématricé, fut-il de type Jpeg, soit plus lourd qu'un fichier non dématricé, par principe...
Une seule chose est certaine : le poids d'un fichier Jpeg ne pourra jamais dépasser celui d'un fichier TIFF 8 bits non compressé.

Ce n'est pas une question de compréhension ou non, il n'y a pas de problème pour comprendre, une fois de plus, qu'on peut si on le veut réaliser des jpeg plus encombrants que le NEF (j'ai du déjà le dire çà  ). Mais lorsqu'on est dans cette démarche je suppose que l'on souhaite dans ce cas conserver la top qualité dans son jpeg. Si c'est le propos et l'usage, dans ce cas il me semble plus intéressant effectivement d'employer le tif qui aura mathématiquement moins de perte (il ne passe pas par l'entropie, lui). Le jpeg me paraissant à privilégier pour son compromis encombrement / qualité donc naturellement intéressant pour des encombrements inférieurs. Encore une fois j'exprime un choix personnel qui n'est évidemment pas forcément celui de tout le monde.

[Jean-Henri Lambert]

tif qui aura mathématiquement moins de perte (il ne passe pas par l'entropie, lui).

Ça aussi c'est une perle :-)

Une compression entropique est par définition une compression sans perte :-)

Au passage un TIFF peut fort bien lui aussi être issu d'une compression entropique.

Le grand Claude Shannon, ne mérite pas cela ;-)

. Encore une fois j'exprime un choix personnel qui n'est évidemment pas forcément celui de tout le monde.

Non, tu exhibes sans vergogne le fait que tu ne sais pas de quoi tu parles :-)

C'est effectivement un choix personnel d'être heureux de montrer à la face du monde les limites certaines de sa compréhension avec une belle constance :-)

[Verso92]

Ce n'est pas une question de compréhension ou non, il n'y a pas de problème pour comprendre, une fois de plus, qu'on peut si on le veut réaliser des jpeg plus encombrants que le NEF (j'ai du déjà le dire çà  ). Mais lorsqu'on est dans cette démarche je suppose que l'on souhaite dans ce cas conserver la top qualité dans son jpeg. Si c'est le propos et l'usage, dans ce cas il me semble plus intéressant effectivement d'employer le tif qui aura mathématiquement moins de perte (il ne passe pas par l'entropie, lui). Le jpeg me paraissant à privilégier pour son compromis encombrement / qualité donc naturellement intéressant pour des encombrements inférieurs. Encore une fois j'exprime un choix personnel qui n'est évidemment pas forcément celui de tout le monde.

Je pense effectivement que tu n'as pas compris les enjeux des différents formats de fichiers... tu sembles considérer le format Jpeg comme un format de basse qualité, et tu te trompes.
Pour résumer :

- le NEF est l'original, qui contient toute l'information. Comme chaque pixel n'est codé que sur un canal couleur*, il sera par définition d'un poids raisonnable (surtout si compressé sans perte).

- le fichier TIFF (en 16 bits) est la passerelle idéale entre le monde du RAW et celui du P/T & retouche sur fichier dématricé. Il est très lourd et ne doit pas être utilisé, sauf circonstances particulières, pour stocker un fichier finalisé.

- le Jpeg : c'est le fichier "fini" par excellence, celui qui sera exploité dans la majeure partie des cas. Si on recherche la qualité maxi, c'est le meilleur compromis qualité/poids. Mais, bien sûr, si on utilise le taux de compression minimal (qualité max), on ne gagnera pas grand chose par rapport à un TIFF 8 bits...
*capteur de type Bayer.

[Jean-Henri Lambert]

- le fichier TIFF (en 16 bits) est la passerelle idéale entre le monde du RAW et celui du P/T & retouche sur fichier dématricé. Il est

Au passage, pour ceux que cela intéresse le DNG est basé sur le format TIFF.

[Verso92]

Au passage, pour ceux que cela intéresse le DNG est basé sur le format TIFF.

Comme n'importe quel format RAW. Le TIFF, c'est une structure de fichier.

[Jean-Henri Lambert]

Yep, mais plus ou moins, sur le DNG c'est vraiment une transposition du TIFF.

[baséli]

Il existe donc pour tout algorithme de compression sans perte un corpus de données en entré qui sera moins volumineux qu'en sortie.

Salut! Je débarque et je prends la conversation en cours. Ce qui est dit ci-dessus me semble assez trivial. Si ce n'était pas le cas, il suffirait de compresser un fichier déjà compressé, et ainsi de suite, et on arriverait au fichier de taille 1 bit. Pour une compression sans perte, ça la foutrait mal.

[Jean-Henri Lambert]

les choses triviales ont beaucoup de mal à passer parfois. ;-)

La pensée magique fait des ravages :-)

[baséli]

Comme n'importe quel format RAW.

Euh non, pas forcément. Il se trouve que le DNG est composé de 3 TIFFs. Mais rien n'empêche de coder un raw comme une seule matrice de mots de 24 bits, chacun représentant une valeur de pixel, en partant du pixel central du capteur, et en suivant un chemin "en spirale" pour finit sur les bords du capteur.

OK c'est idiot, mais c'est un exemple, car je suis un constructeur qui ne veut pas que n'importe quel programme standard puisse voir l'image contenue dans le raw. Alors que si j'ouvre un des trois TIFFs d'un DNG, je vais voir quelque chose, je saurai si c'est une voiture ou un avion, un pot de yaourt ou une fusée, etc.

[baséli]

Plus drôle en fait, on a eu droit à : "un RAW c'est 3x 16bit, alors qu'un JPEG c'est 3x 8bit" :-)

La matrice de Bayer est encore un concept très flou pour certain et ils n'aiment pas qu'on donne de la profondeur de champ ;-)

Pourquoi un jpeg 3x8bits est drôle? Je comprends bien qu'il n'y a pas ça dans le fichier, mais c'est ce que ça représente. Et que vient faire la matrice de Bayer dans le jpeg?

[Jean-Henri Lambert]

C'est le RAW 3x16 bits qui est drôle et atypique pour le moins ;-)

Pour la matrice de Bayer effectivement pas grand chose à voir avec les trois composante du JPEG si ce n'est qu'elle en est la source, par contre pour comprendre la nature d'un RAW ça aide ;-)

[baséli]

et toi tu es de la tendance Lambert c'est cela?

Demande-lui plutôt ses coordonnées, avec un peu de chance tu auras une réponse.

[Jean-Henri Lambert]

Pour les Lambertistes, suivre cette adresse :-)

http://parti-ouvrier-independant.fr

[baséli]

C'est le RAW 3x16 bits qui est drôle et atypique pour le moins ;-)

Oui bon, si tout le monde savait toujours parfaitement de quoi il parle, les forums seraient vides, et les troquets aussi. On peut laisser passer l'approximation qui est vraie en mémoire vive. Enfin presque, je parie que le canal alpha est de la partie avec deux octets de plus, 4*16 faisant 64.

J'ai parcouru ce fil à l'envers, et j'ai compris que tu étais bien habillé avant... trop drôle

[Jean-Henri Lambert]

On peut laisser passer l'approximation qui est vraie en mémoire vive.

Ben, non :-)

Un RAW avec une matrice de bayer, n'est plus un RAW une fois qu'il est dématricé et avant cela il n'y a qu'une information par photo-site.

un RAW , c'est une quantification de niveau par photosite, pas trois.

Je te rappel que la question traitait d'une comparaison assez inepte entre taille de fichier RAW et tailles de fichiers JPEG après dématriçage.

Je suis loin d'être le seul à avoir pointé les inepties misent en avant.

Pour le reste, il n'y a aucun pb à ne pas maitriser un sujet, par contre défendre avec morgue des inepties et faire subir à ceux qui porte une remise en perspective des pb abordés des procès iniques et incessants est une autre histoire. ;-)

Nombre des bêtises pointées du doigt par Ronan proviennent de cela même qui n'ont de cesse que de tenter de m'ostraciser, de me traiter de tous les nom, de ne pas supporter que je reste calme face à leurs attaques et qui s'érigent en censeurs sectaire des opinions qui ont ou non le droit de citer.

Mais certains avis ont pour moi plus de poids.

J'ignore quels sont les contentieux d'égos surchauffés à l'origine de la rage anti-lambertiste, mais force est de reconnaître que, depuis un moment, il est le seul à avoir bien posé le problème et à ne pas raconter d'âneries: j'ai trouvé quelques perles de la plus belle eau sous la plume de ses contempteurs, lesquelles montrent simplement que leurs auteurs n'ont strictement rien compris au film !

Le poids d'un Jpeg doit être comparé à la seule chose comparable, le poids d'un fichier dématricé et non compressé, possédant la même profondeur de quantification. ça s'appelle un TIFF 8bits. Et là, on voit bien l'intérêt du Jpeg "qualité 100" de DxO: fournir un fichier tout de même nettement moins lourd mais dont la qualité est strictement sans compromis. Compte tenu de ma pratique, je m'en porte fort bien et, si je veux des fichiers plus légers, eh bien, j'oublie l'option DxO Jpeg "qualité 100" au profit d'une compression plus forte, point barre. De toute façon, la qualité d'un fichier est directement corrélée à son poids, alors...

Bonne journée, bon WE... je suis amusé de constater que les bonnes habitudes n'ont pas varié !

Plus quelques autres messages fort sympathiques, prouvant que les grandes gueules sectaires ne parlent qu'en leur nom et s'arroge le droit de se croire représentatif de plus que leurs aigreurs  mesquines.

[Patrice]

Très bon choix !

tu avais raison , je le recommande.

[baséli]

Pour le restant de ta contribution

Je parie qu'en mémoire, pour pouvoir afficher quelque chose à l'écran, le raw est dématricé, et sa représentation interne est effectivement sur 3 mots de 16 bits. Comme dans les diverses opérations d'édition on a besoin de gérer la transparence avec un "point" supplémentaire appelé "canal alpha", on obtient que chaque pixel est représenté en interne par 4 mots de 16 bits, qui entrent deux par deux dans des registres processeur de 32 bits pour les "vieilles" machines, soit dans un seul registre de 64 bits pour les "récentes".

Je vois mal un soft compacter les 2*12 bits de quantification de deux pixels du capteur dans trois octets, comme décrit plus haut. On perdrait un temps pas possible pour les traiter sous cette forme. Surtout pour les raw Canon, qui font 14 bits... mais on est dans un forum Nikon.

[Jean-Henri Lambert]

J'avais bien compris que tu parlais de représentation en mémoire après dématriçage, tes propos son claire et sans ambiguité.

Mais notre amis parlais lui du fichier RAW, c'est clairement indiqué par lui à plusieurs reprises et c'était en accord avec le sujet abordé ;-)

Par exemple là :

,  un mot de 12 ou 14 bits fera 16 bits sur le disque.

d'où mon explication du compactage de trois échantillons de 12 bits sur trois octets, un classique pour éviter de se coltiner une flopée de quartet nuls inutiles dans le fichier.


Pour le reste quand j'évoqué le reste de ta contribution, je faisais référence à ça :

J'ai parcouru ce fil à l'envers, et j'ai compris que tu étais bien habillé avant... trop drôle

Pas certain d'en faire une bonne interprétation.

[Jean-Henri Lambert]

Surtout pour les raw Canon, qui font 14 bits... mais on est dans un forum Nikon.

Nous avons aussi des RAW 14 bits ;-)

Le compactage se fait par lot de 4 échantillons soit 56 bits ou 7 octets.

[baséli]

Ben, non :-)

Ben si. Enfin moi je laisse passer si je parle à un photographe, mais pas si je cause avec un informaticien. C'est du même niveau que "un jpeg c'est 3*8 bits". Tant qu'on ne parle pas entre informaticiens ou spécialistes du traitement du signal, c'est suffisant comme niveau de détail me semble-t-il.

Sinon, ceux qui trouvent inepte de comparer les tailles n'ont généralement pas la plus grosse.

[baséli]

Pas certain d'en faire une bonne interprétation.

On prétend que tu étais Surson31. Bien habillé, quoi...

[Jean-Henri Lambert]

, c'est suffisant comme niveau de détail me semble-t-il.

Sauf si c'est utiliser comme argument pour démontrer avec morgue une proposition fausse, il me semble.

Soit on parle de technique avec un minimum de rigueur et de justesse soit on n'en parle pas.

Et on en profites pour avancer vers une meilleurs compréhension quand celle ci vous est offerte.

Et encore moins quand cela vient d'une personne passant son temps à chercher à vous décrédibiliser avec les méthodes les plus viles :-)

[Jean-Henri Lambert]

../..