Win7-64 - Pas d'affichage des imagettes au format NEF (RAW Nikon)
24 réponses
Pierele
Bonjour,
Y a-t-il ici une bonne âme qui pourrait me dire comment paramétrer WIN7
afin que dans un fichier contenant des photos les imagettes au format NEF
( le RAW de Nikon) apparaissent
Ceux au format .jpg sont bien visibles mais pas les NEF
A noter que son mon ex WIN XP Pro elles étaient bien visibles
"Pierre TORRIS" a écrit dans le message de news: > ?? Un codec c'est un codec, pas un programme. Ben si ;o)
Ben non. Un codec permet à un programme de lire ou de générer un type de données. Un codec tout seul sans être rattaché à un programme ne sert à rien.
-- Parce qu'il en faut une.
@wanadoo<nospam.g-lochon@wanadoo.fr> wrote:
"Pierre TORRIS" <contact_sur_site@ptorris.com> a écrit dans le message de
news:mn.6a8e7dc1a3b827ec.114942@ptorris.com...
> ?? Un codec c'est un codec, pas un programme.
Ben si ;o)
Ben non. Un codec permet à un programme de lire ou de générer
un type de données. Un codec tout seul sans être rattaché à un
programme ne sert à rien.
"Pierre TORRIS" a écrit dans le message de news: > ?? Un codec c'est un codec, pas un programme. Ben si ;o)
Ben non. Un codec permet à un programme de lire ou de générer un type de données. Un codec tout seul sans être rattaché à un programme ne sert à rien.
-- Parce qu'il en faut une.
Ben non. Un codec permet à un programme de lire ou de générer un type de données. Un codec tout seul sans être rattaché à un programme ne sert à rien.
Un programme, ce n'est pas qu'un exécutable autonome. Une dll, souvent notée comme ressource, est un ensemble de code et de fonctions.
(Quand il n'est pas un dispositif matériel,) un codec est une suite d'instructions de codage (ou décodage) correspondant à un processus algorithmique. A ce titre, c'est un programme, par opposition à un ensemble de données.
Ben non. Un codec permet à un programme de lire ou de générer un type de
données. Un codec tout seul sans être rattaché à un programme ne sert à
rien.
Un programme, ce n'est pas qu'un exécutable autonome.
Une dll, souvent notée comme ressource, est un ensemble de code et de
fonctions.
(Quand il n'est pas un dispositif matériel,) un codec est une suite
d'instructions de codage (ou décodage) correspondant à un processus
algorithmique.
A ce titre, c'est un programme, par opposition à un ensemble de données.
Ben non. Un codec permet à un programme de lire ou de générer un type de données. Un codec tout seul sans être rattaché à un programme ne sert à rien.
Un programme, ce n'est pas qu'un exécutable autonome. Une dll, souvent notée comme ressource, est un ensemble de code et de fonctions.
(Quand il n'est pas un dispositif matériel,) un codec est une suite d'instructions de codage (ou décodage) correspondant à un processus algorithmique. A ce titre, c'est un programme, par opposition à un ensemble de données.
Tonio le Yéti
Je viens de vérifier, les fichiers du répertoire de NEFCodec ne contiennent aucun programme .exe (application) et sur le disque il ne représente que 11.2 Mo et non 90 comme tu l'indique
Nom du produit NEF Codec Version 1.12.0 Nom du fichier S-NEFCDC-011200WF-ALLIN-ALL___.exe Taille du fichier 90.03 MB (94,407,576 bytes)
94,407,576 bytes pour l'installation d'un "codec" qui ne prend que 11,2 Mo de place (apparente) sur ton disque... Ils sont apparentés à Orange ? mdr A quoi peut bien servir le reste qu'on te fais télécharger et installer ? Néanmoins, merci de confirmer qu'on ne sait pas plus traiter les NEF avec ce "gros" morceau à télécharger.
Je viens de vérifier, les fichiers du répertoire de NEFCodec ne
contiennent
aucun programme .exe
(application) et sur le disque il ne représente que 11.2 Mo et non 90
comme tu l'indique
Nom du produit NEF Codec
Version 1.12.0
Nom du fichier S-NEFCDC-011200WF-ALLIN-ALL___.exe
Taille du fichier 90.03 MB (94,407,576 bytes)
94,407,576 bytes pour l'installation d'un "codec" qui ne prend que 11,2 Mo
de place (apparente) sur ton disque... Ils sont apparentés à Orange ? mdr
A quoi peut bien servir le reste qu'on te fais télécharger et installer ?
Néanmoins, merci de confirmer qu'on ne sait pas plus traiter les NEF
avec ce "gros" morceau à télécharger.
Je viens de vérifier, les fichiers du répertoire de NEFCodec ne contiennent aucun programme .exe (application) et sur le disque il ne représente que 11.2 Mo et non 90 comme tu l'indique
Nom du produit NEF Codec Version 1.12.0 Nom du fichier S-NEFCDC-011200WF-ALLIN-ALL___.exe Taille du fichier 90.03 MB (94,407,576 bytes)
94,407,576 bytes pour l'installation d'un "codec" qui ne prend que 11,2 Mo de place (apparente) sur ton disque... Ils sont apparentés à Orange ? mdr A quoi peut bien servir le reste qu'on te fais télécharger et installer ? Néanmoins, merci de confirmer qu'on ne sait pas plus traiter les NEF avec ce "gros" morceau à télécharger.
Delta Ophiuchus
*Bonjour @wanadoo*, qui a écrit le 13/01/2012 15:57 :
Ben non. Un codec permet à un programme de lire ou de générer un type de données. Un codec tout seul sans être rattaché à un programme ne sert à rien.
Un programme, ce n'est pas qu'un exécutable autonome. Une dll, souvent notée comme ressource, est un ensemble de code et de fonctions.
(Quand il n'est pas un dispositif matériel,) un codec est une suite d'instructions de codage (ou décodage) correspondant à un processus algorithmique.
A ce titre, c'est un programme, par opposition à un ensemble de données.
Non, un codec n'est jamais autonome. Et si est un codec devient autonome, ce n'est plus un codec mais un programme.
*Bonjour @wanadoo*, qui a écrit le 13/01/2012 15:57 :
Ben non. Un codec permet à un programme de lire ou de générer un type
de données. Un codec tout seul sans être rattaché à un programme ne
sert à rien.
Un programme, ce n'est pas qu'un exécutable autonome.
Une dll, souvent notée comme ressource, est un ensemble de code et de
fonctions.
(Quand il n'est pas un dispositif matériel,) un codec est une suite
d'instructions de codage (ou décodage) correspondant à un processus
algorithmique.
A ce titre, c'est un programme, par opposition à un ensemble de données.
Non, un codec n'est jamais autonome. Et si est un codec devient
autonome, ce n'est plus un codec mais un programme.
A ce titre, c'est un programme, par opposition à un ensemble de données.
Non, un codec n'est jamais autonome.
Ai-je dit le contraire ?
Et si est un codec devient autonome, ce n'est plus un codec mais un programme.
Je le redis : il n'y a pas que les programmes autonomes qui sont des programmes.
Delta Ophiuchus
@wanadoo wrote:
> >> A ce titre, c'est un programme, par opposition à un ensemble de données. > > Non, un codec n'est jamais autonome. Ai-je dit le contraire ?
Un programme est un ensemble de codes et de fonctions qui fonctionne de manière autonome, Ce que n'est pas un codec, donc oui, tu as dit le contraire.
> Et si est un codec devient autonome, ce n'est plus un codec mais un > programme. Je le redis : il n'y a pas que les programmes autonomes qui sont des programmes.
Et je te redis : ben non, un codec n'est pas un programme.
-- Parce qu'il en faut une.
@wanadoo<nospam.g-lochon@wanadoo.fr> wrote:
>
>> A ce titre, c'est un programme, par opposition à un ensemble de données.
>
> Non, un codec n'est jamais autonome.
Ai-je dit le contraire ?
Un programme est un ensemble de codes et de fonctions qui fonctionne de manière autonome,
Ce que n'est pas un codec, donc oui, tu as dit le contraire.
> Et si est un codec devient autonome, ce n'est plus un codec mais un
> programme.
Je le redis : il n'y a pas que les programmes autonomes qui sont des
programmes.
Et je te redis : ben non, un codec n'est pas un programme.
> >> A ce titre, c'est un programme, par opposition à un ensemble de données. > > Non, un codec n'est jamais autonome. Ai-je dit le contraire ?
Un programme est un ensemble de codes et de fonctions qui fonctionne de manière autonome, Ce que n'est pas un codec, donc oui, tu as dit le contraire.
> Et si est un codec devient autonome, ce n'est plus un codec mais un > programme. Je le redis : il n'y a pas que les programmes autonomes qui sont des programmes.
Et je te redis : ben non, un codec n'est pas un programme.
-- Parce qu'il en faut une.
Un programme est un ensemble de codes et de fonctions "qui fonctionne de manière autonome",
Non. Une DLL en est le meilleur contre-exemple !
Mais si mon humble avis de développeur qui ne crée des logiciels que depuis 38 ans est inutile, je cesse de discuter, car à ce niveau-là, on n'est plus dans le domaine de la science, mais dans celui de la foi.
Un programme est un ensemble de codes et de fonctions "qui fonctionne de
manière autonome",
Non. Une DLL en est le meilleur contre-exemple !
Mais si mon humble avis de développeur qui ne crée des logiciels que depuis
38 ans est inutile, je cesse de discuter,
car à ce niveau-là, on n'est plus dans le domaine de la science, mais dans
celui de la foi.
Un programme est un ensemble de codes et de fonctions "qui fonctionne de manière autonome",
Non. Une DLL en est le meilleur contre-exemple !
Mais si mon humble avis de développeur qui ne crée des logiciels que depuis 38 ans est inutile, je cesse de discuter, car à ce niveau-là, on n'est plus dans le domaine de la science, mais dans celui de la foi.
Delta Ophiuchus
*Bonjour @wanadoo*, qui a écrit le 14/01/2012 12:23 :
Un programme est un ensemble de codes et de fonctions "qui fonctionne de manière autonome",
Le code contenu dans une DLL n'est chargé qu'une seule fois en mémoire. Ainsi, lorsqu'un processus tente de charger une DLL qui est déjà en mémoire, le code existant est mappé dans la mémoire du programme sans qu'un second chargement soit nécessaire, gagnant de la place en RAM. Fin de citation.
Il est dit : le code est mappé dans la mémoire du programme. le code existant = DLL. Chargé dans la programme qui ne peut pas être la DLL.
Mais si mon humble avis de développeur qui ne crée des logiciels que depuis 38 ans est inutile, je cesse de discuter, car à ce niveau-là, on n'est plus dans le domaine de la science, mais dans celui de la foi.
Alors cela fait 38 ans que tu te trompes sur ce qu'est un DLL, un codec et un programme.
*Bonjour @wanadoo*, qui a écrit le 14/01/2012 12:23 :
Un programme est un ensemble de codes et de fonctions "qui fonctionne
de manière autonome",
Le code contenu dans une DLL n'est chargé qu'une seule fois en mémoire.
Ainsi, lorsqu'un processus tente de charger une DLL qui est déjà en
mémoire, le code existant est mappé dans la mémoire du programme sans
qu'un second chargement soit nécessaire, gagnant de la place en RAM.
Fin de citation.
Il est dit : le code est mappé dans la mémoire du programme. le code
existant = DLL. Chargé dans la programme qui ne peut pas être la DLL.
Mais si mon humble avis de développeur qui ne crée des logiciels que
depuis 38 ans est inutile, je cesse de discuter,
car à ce niveau-là, on n'est plus dans le domaine de la science, mais
dans celui de la foi.
Alors cela fait 38 ans que tu te trompes sur ce qu'est un DLL, un codec
et un programme.
Le code contenu dans une DLL n'est chargé qu'une seule fois en mémoire. Ainsi, lorsqu'un processus tente de charger une DLL qui est déjà en mémoire, le code existant est mappé dans la mémoire du programme sans qu'un second chargement soit nécessaire, gagnant de la place en RAM. Fin de citation.
Il est dit : le code est mappé dans la mémoire du programme. le code existant = DLL. Chargé dans la programme qui ne peut pas être la DLL.
Mais si mon humble avis de développeur qui ne crée des logiciels que depuis 38 ans est inutile, je cesse de discuter, car à ce niveau-là, on n'est plus dans le domaine de la science, mais dans celui de la foi.
Alors cela fait 38 ans que tu te trompes sur ce qu'est un DLL, un codec et un programme.
Delta Ophiuchus
*Bonjour Delta Ophiuchus*, qui a écrit le 14/01/2012 12:51 :
*Bonjour @wanadoo*, qui a écrit le 14/01/2012 12:23 :
Un programme est un ensemble de codes et de fonctions "qui fonctionne de manière autonome",
Le code contenu dans une DLL n'est chargé qu'une seule fois en mémoire. Ainsi, lorsqu'un processus tente de charger une DLL qui est déjà en mémoire, le code existant est mappé dans la mémoire du programme sans qu'un second chargement soit nécessaire, gagnant de la place en RAM. Fin de citation.
Il est dit : le code est mappé dans la mémoire du programme. le code existant = DLL. Chargé dans la programme qui ne peut pas être la DLL.
Mais si mon humble avis de développeur qui ne crée des logiciels que depuis 38 ans est inutile, je cesse de discuter, car à ce niveau-là, on n'est plus dans le domaine de la science, mais dans celui de la foi.
Alors cela fait 38 ans que tu te trompes sur ce qu'est un DLL, un codec et un programme.
Une DLL peut être liée statiquement ou dynamiquement à un programme. Dans le premier cas, le programme déclare explicitement avoir besoin d'une fonction contenue dans une bibliothèque et la résolution de liens est effectuée par l'éditeur de lien au moment de la phase de compilation du programme. Le programme inclut alors dans sa structure binaire la liste des bibliothèques nécessaires à son bon fonctionnement dans sa "table des exportations" (export table). Le chargeur de programmes de Windows vérifie alors lors de l'exécution du programme que toutes les DLL requises sont disponibles, et si ce n'est pas le cas, stoppe le chargement en affichant un message indiquant que des dépendances nécessaires à l'exécutable n'ont pu être trouvées. Dans le second cas, c'est le programme qui demande explicitement le chargement d'une bibliothèque durant son exécution à l'aide de l'API LoadLibrary afin d'obtenir un pointeur sur la fonction désirée. Cette dernière approche est plus pénible car elle nécessite un effort plus important de la part du programmeur, mais elle permet d'une part de ne pas empêcher l'exécution d'un programme lié à une bibliothèque dont l'existence sur le système hôte n'est pas certaine, d'autre part constitue parfois le seul moyen d'accéder à des fonctions qui ne sont pas déclarées dans les fichiers d'interface fournis par l'éditeur et qui sont donc à considérer comme "non documentées".[c]
*Bonjour Delta Ophiuchus*, qui a écrit le 14/01/2012 12:51 :
*Bonjour @wanadoo*, qui a écrit le 14/01/2012 12:23 :
Un programme est un ensemble de codes et de fonctions "qui fonctionne
de manière autonome",
Le code contenu dans une DLL n'est chargé qu'une seule fois en mémoire.
Ainsi, lorsqu'un processus tente de charger une DLL qui est déjà en
mémoire, le code existant est mappé dans la mémoire du programme sans
qu'un second chargement soit nécessaire, gagnant de la place en RAM.
Fin de citation.
Il est dit : le code est mappé dans la mémoire du programme. le code
existant = DLL. Chargé dans la programme qui ne peut pas être la DLL.
Mais si mon humble avis de développeur qui ne crée des logiciels que
depuis 38 ans est inutile, je cesse de discuter,
car à ce niveau-là, on n'est plus dans le domaine de la science, mais
dans celui de la foi.
Alors cela fait 38 ans que tu te trompes sur ce qu'est un DLL, un codec
et un programme.
Une DLL peut être liée statiquement ou dynamiquement à un programme.
Dans le premier cas, le programme déclare explicitement avoir besoin
d'une fonction contenue dans une bibliothèque et la résolution de liens
est effectuée par l'éditeur de lien au moment de la phase de compilation
du programme. Le programme inclut alors dans sa structure binaire la
liste des bibliothèques nécessaires à son bon fonctionnement dans sa
"table des exportations" (export table). Le chargeur de programmes de
Windows vérifie alors lors de l'exécution du programme que toutes les
DLL requises sont disponibles, et si ce n'est pas le cas, stoppe le
chargement en affichant un message indiquant que des dépendances
nécessaires à l'exécutable n'ont pu être trouvées. Dans le second cas,
c'est le programme qui demande explicitement le chargement d'une
bibliothèque durant son exécution à l'aide de l'API LoadLibrary afin
d'obtenir un pointeur sur la fonction désirée. Cette dernière approche
est plus pénible car elle nécessite un effort plus important de la part
du programmeur, mais elle permet d'une part de ne pas empêcher
l'exécution d'un programme lié à une bibliothèque dont l'existence sur
le système hôte n'est pas certaine, d'autre part constitue parfois le
seul moyen d'accéder à des fonctions qui ne sont pas déclarées dans les
fichiers d'interface fournis par l'éditeur et qui sont donc à considérer
comme "non documentées".[c]
Le code contenu dans une DLL n'est chargé qu'une seule fois en mémoire. Ainsi, lorsqu'un processus tente de charger une DLL qui est déjà en mémoire, le code existant est mappé dans la mémoire du programme sans qu'un second chargement soit nécessaire, gagnant de la place en RAM. Fin de citation.
Il est dit : le code est mappé dans la mémoire du programme. le code existant = DLL. Chargé dans la programme qui ne peut pas être la DLL.
Mais si mon humble avis de développeur qui ne crée des logiciels que depuis 38 ans est inutile, je cesse de discuter, car à ce niveau-là, on n'est plus dans le domaine de la science, mais dans celui de la foi.
Alors cela fait 38 ans que tu te trompes sur ce qu'est un DLL, un codec et un programme.
Une DLL peut être liée statiquement ou dynamiquement à un programme. Dans le premier cas, le programme déclare explicitement avoir besoin d'une fonction contenue dans une bibliothèque et la résolution de liens est effectuée par l'éditeur de lien au moment de la phase de compilation du programme. Le programme inclut alors dans sa structure binaire la liste des bibliothèques nécessaires à son bon fonctionnement dans sa "table des exportations" (export table). Le chargeur de programmes de Windows vérifie alors lors de l'exécution du programme que toutes les DLL requises sont disponibles, et si ce n'est pas le cas, stoppe le chargement en affichant un message indiquant que des dépendances nécessaires à l'exécutable n'ont pu être trouvées. Dans le second cas, c'est le programme qui demande explicitement le chargement d'une bibliothèque durant son exécution à l'aide de l'API LoadLibrary afin d'obtenir un pointeur sur la fonction désirée. Cette dernière approche est plus pénible car elle nécessite un effort plus important de la part du programmeur, mais elle permet d'une part de ne pas empêcher l'exécution d'un programme lié à une bibliothèque dont l'existence sur le système hôte n'est pas certaine, d'autre part constitue parfois le seul moyen d'accéder à des fonctions qui ne sont pas déclarées dans les fichiers d'interface fournis par l'éditeur et qui sont donc à considérer comme "non documentées".[c]
Az Sam
"@wanadoo" a écrit dans le message de news:4f1165b8$0$2526$
Un programme est un ensemble de codes et de fonctions "qui fonctionne de manière autonome",
Non. Une DLL en est le meilleur contre-exemple !
Mais si mon humble avis de développeur qui ne crée des logiciels que depuis 38 ans est inutile, je cesse de discuter, car à ce niveau-là, on n'est plus dans le domaine de la science, mais dans celui de la foi.
dommage que tu n'aies pas quotter correctement , il manque le contributeur auquel tu réponds. Dans mon arborescence, je n'ai pas ses réponses, juste les tiennes. (pas vu de Xpost pourtant). Je suppose que c'était donc a Pierre Torris que tu répondais. tu confirmes ?
(et il aurait annuler lui même ses posts qui lui font dire des âneries ?)
-- Cordialement, Az Sam.
"@wanadoo" <nospam.g-lochon@wanadoo.fr> a écrit dans le message de
news:4f1165b8$0$2526$ba4acef3@reader.news.orange.fr...
Un programme est un ensemble de codes et de fonctions "qui fonctionne de
manière autonome",
Non. Une DLL en est le meilleur contre-exemple !
Mais si mon humble avis de développeur qui ne crée des logiciels que
depuis 38 ans est inutile, je cesse de discuter,
car à ce niveau-là, on n'est plus dans le domaine de la science, mais dans
celui de la foi.
dommage que tu n'aies pas quotter correctement , il manque le contributeur
auquel tu réponds.
Dans mon arborescence, je n'ai pas ses réponses, juste les tiennes. (pas vu
de Xpost pourtant).
Je suppose que c'était donc a Pierre Torris que tu répondais. tu confirmes ?
(et il aurait annuler lui même ses posts qui lui font dire des âneries ?)
"@wanadoo" a écrit dans le message de news:4f1165b8$0$2526$
Un programme est un ensemble de codes et de fonctions "qui fonctionne de manière autonome",
Non. Une DLL en est le meilleur contre-exemple !
Mais si mon humble avis de développeur qui ne crée des logiciels que depuis 38 ans est inutile, je cesse de discuter, car à ce niveau-là, on n'est plus dans le domaine de la science, mais dans celui de la foi.
dommage que tu n'aies pas quotter correctement , il manque le contributeur auquel tu réponds. Dans mon arborescence, je n'ai pas ses réponses, juste les tiennes. (pas vu de Xpost pourtant). Je suppose que c'était donc a Pierre Torris que tu répondais. tu confirmes ?
(et il aurait annuler lui même ses posts qui lui font dire des âneries ?)
