Étrange comportement D850 ou Nikon (en rafale)..

Démarré par hyago, Septembre 24, 2018, 13:59:38

« précédent - suivant »
Imprimer
En bas Pages1 2 3 Toutes
Actions de l'utilisateur

hyago

Septembre 24, 2018, 13:59:38 Dernière édition: Septembre 24, 2018, 14:09:13 par hyago
Bonjour les amis,

je n'ai jamais eu à faire des rafales donc je ne connaissais pas cette particularité que j'ai découverte et que j'explique. Évidemment elle m'est arrivée avec le D850 mais je pense que ça doit être pareil avec n'importe quel autre modèle de Nikon bien que je n'ai jamais fait le constat, car c'est la première fois que je fais des petites rafales..  ;D

J'ai eu à saisir (ce dernier samedi soir) des spectacles de rue: jongleurs, etc... J'ai considéré que la rafale était nécessaire dans ce contexte, et je me suis servi d'elle sur mon D850 équipé de XQD + SD.

Le numéro des photos (il n'en manque aucune) est en parfait ordre de déclenchement, par contre la marque de temps (Time-stamp) ne correspond pas a la séquence de photos. Je me sers de Google-photos pour partager certains reportages avec mes amis. Google photo n'ordonne pas selon le numéro de la photo mais selon la marque de temps... et si bien le numéro de chaque photo se correspond à la réalité, il n'en est pas du tout de même sur la marque de temps. Exemple de petite rafale: DSC_0040.NEF, DSC_0041.NEF [...] DSC_0045.NEF...

J'ai traité ces NEFs avec DxO Labs, et quand j'ai monté mes JPG sur google-photos, qui ordonne par défaut par "temps" (il ne permet pas d'ordonner par nº de photo), j'obtiens à peu-près ça comme ordre de temps: DSC_0045.jpg, DSC_0040.jpg, DSC_0043.jpg, etc...

Je sais, on peut changer la marque de temps en éditant les exifs, ou ordonner avec un autre logiciel par numéro de photo... hélas ce n'est pas très commode, quand on arrive à DSC_0999.NEF (ce qui m'est arrivé précisément au cours de ce petit reportage) et qu'on passe après à un DSC_0001.NEF sur un nouveau répertoire dans la carte... 

Ce n'est pas forcément grave ni très gênant, mais je trouve ça un peu bizarre... je crois que le boîtier enregistre les NEFs du buffer sur la carte et leur met la marque de temps au moment de les enregistrer sans tenir compte de l'ordre de déclenchement, donc de la chronologie de la rafale... C'est la seule explication qui me vient à l'esprit. J'imagine que pas mal d'entre vous ont du être confrontés à cette particularité... Mais bon, je tenais à vous la remarquer...  ;)
Un médiocre amateur.

Tonton-Bruno

#1
Septembre 24, 2018, 14:44:09 Dernière édition: Septembre 24, 2018, 14:50:46 par Tonton-Bruno
Bonjour Hyago.
J'utilise Nikon Transfer pour renommer les photos durant leur transfert sur le PC et ce logiciel renomme les images à ma demande selon le modèle AAMMJJ_hhmmss_00
Les 00 correspondent au numéro d'ordre dans la rafale.
Voir copie d'écran jointe.

Je crois que tu es sous Linux et que tu ne peux pas utiliser les logiciels Nikon.

Je ne sais pas s'il existe sous Linux un logiciel capable de lire correctement la date et l'heure des fichiers NEF, alors que celle-ci est stockée en clair dans les EXIF au centième de seconde près, et que je n'ai aucune difficulté non plus pour lire ces information sous Photoshop.

Je joins aussi une photo affichée avec la visionneuse de Nikon View.
On constate que l'heure est donnée jusqu'au 1/100s.

hyago

#2
Septembre 24, 2018, 15:11:35 Dernière édition: Septembre 24, 2018, 15:21:06 par hyago
Merci Tonton,

Je me sers de linux dans le jour le jour, mais pas avec DxO... donc là c'est Windows 10 avec DxO Elite (je crois que c'est le nom de leur dernière mouture). Je traite les PdV avec ce DxO, et je les monte sur Google photos avec Chrome dans Windows 10 après leur conversion en JPG... Certes je suis en Linux en ce moment pour le mail, web, etc... mais toute la procédure que j'ai cité pour traiter mes photos issues du D850 est faite sur Windows à 100%... C'est vraiment étonnant...mais je peux faire un petit album Google-photos pour vous montrer... La je t'assure que Linux n'a pas participé au traitement...  ???

Je peux donc faire servir un logiciel Windows comme toi... Bien que je ne comptais pas surcharger mon système Windows avec d'autres applications, s'il le faut, je le ferai en suivant tes conseills... ;)

Voici le lien, tout le monde peut le voir sur ce petit Album partagé que je viens de créer chez Google photos...  ;) https://photos.app.goo.gl/dJiYJkphS72s1Qi17

Tu peux vérifier l'ordre des images qui est selon le temps, du moins c'est ce que dit Google-Photos (je l'ai révisé à nouveau).. Si tu veux regarder le time-stamp des images, je t'en serai reconnaissant. Ce n'est pas grave, mais tout de même étrange... Je te répète que c'est le classement qu'a fait Google pour cette mini-rafale, moi je n'y suis pour rien...  ::)

Voici l'ordre que Google a choisi pour cette mini-série: DSC_9566.jpg, DSC_9567.jpg,DSC_9569.jpg, DSC_9568.jpg, DSC_9570.jpg,DSC_9572.jpg ,DSC_9571.jpg

Etonnant quand-même....

Re-merci Tonton...  :) ;)

Évidemment, en cas de besoin, j'ai aussi les NEFs disponibles en 14bits compressés sans perte... :)
Un médiocre amateur.

hyago

#3
Septembre 24, 2018, 15:34:02
Évidemment, si bien les 5 premières PdV sont de la même petite rafale, les deux autres sont d'une autre rafale: je le souligne bien que c'est évident... ;)
Un médiocre amateur.

Tonton-Bruno

#4
Septembre 24, 2018, 16:10:19
Donc c'est Google photos que se plante et ne sait pas lire l'heure incluse dans les photos.

Donc c'est un bug Google et pas un bug Nikon, et encore moins un bug du D850 comme le suggère ton titre que tyu ne peux plus changer.

Tu devrais poser la question à Google.

Il se pourrait que ce soit DXO qui ait effacé les données EXIF originales de tes photos.

En résumé:

Aucun problème sur le D850
Aucun problème avec les logiciels Nikon
Aucun problème avec les logiciels Adobe
Problème potentiel avec DXO
Problème potentiel avec Google images

hyago

#5
Septembre 24, 2018, 16:35:40
Citation de: Tonton-Bruno le Septembre 24, 2018, 16:10:19
Donc c'est Google photos que se plante et ne sait pas lire l'heure incluse dans les photos.

Donc c'est un bug Google et pas un bug Nikon, et encore moins un bug du D850 comme le suggère ton titre que tyu ne peux plus changer.

Tu devrais poser la question à Google.

Il se pourrait que ce soit DXO qui ait effacé les données EXIF originales de tes photos.

En résumé:

Aucun problème sur le D850
Aucun problème avec les logiciels Nikon
Aucun problème avec les logiciels Adobe
Problème potentiel avec DXO
Problème potentiel avec Google images

Bien content de lire ça Bruno,

J'y ai réfléchi et j'ai bien consulté l'album photo des rafales du samedi. J'ai plein de petites rafales de 2 a 10 photos, et dans toutes elles, on y trouve une sacrée danse de photos toujours mal ordonnées.  Bien content de savoir que ce n'est pas la faute a Nikon...  :) Je vais signaler ça illico a Google, car pas mal d'usagers de CI doivent certainement se servir des services  Google pour partager leur production photo...  ;)

Tel que j'ai dit plus haut, je n'avais jamais eu ce souci, car jamais je n'avais fait des rafales...  ::)

Merci à nouveau...  ;)
Un médiocre amateur.

PhR

#6
Septembre 24, 2018, 21:22:20
Sur Joomeo, il y a le même soucis lors de petites rafales.  Désagréable lorsque l'on veut lancer un diaporama. >:( 
et il n'y a pas qu'avec Nikon que ça se passe, avec Canon et Sony aussi .  ;D

ChatOuille

#7
Septembre 25, 2018, 02:51:29
Voilà ma modeste opinion:
● Il semble bien que le Raw de Nikon enregistre le time stamp à la 1/100 de seconde. C'est la moindre des choses car les rafales sont prévues.
● Mais je pense que le temps de la prise de vue, incrustée dans le fichier JPEG, n'a de précision que la seconde.
Dès lors, toutes les prises de la rafale dans la même seconde ont le même time stamp lorsqu'elles ont été converties au JPEG. Ce n'est pas que l'un ou l'autre logiciel ne sache pas le lire, mais il ne peut pas le lire car cette information n'existe pas dans le JPEG.

C'est à vérifier, mais je te conseille de vérifier dans ce sens. Si j'ai le temps je vais le faire, mais je ne fais pas non plus des rafales habituellement.

Sillusus

#8
Septembre 25, 2018, 03:14:15
Citation de: ChatOuille le Septembre 25, 2018, 02:51:29
Voilà ma modeste opinion:
● Il semble bien que le Raw de Nikon enregistre le time stamp à la 1/100 de seconde. C'est la moindre des choses car les rafales sont prévues.
● Mais je pense que le temps de la prise de vue, incrustée dans le fichier JPEG, n'a de précision que la seconde.
Dès lors, toutes les prises de la rafale dans la même seconde ont le même time stamp lorsqu'elles ont été converties au JPEG. Ce n'est pas que l'un ou l'autre logiciel ne sache pas le lire, mais il ne peut pas le lire car cette information n'existe pas dans le JPEG.

C'est à vérifier, mais je te conseille de vérifier dans ce sens. Si j'ai le temps je vais le faire, mais je ne fais pas non plus des rafales habituellement.

Même le D3400 conserve les centièmes sur des raw+jpeg et des jpeg tirés du raw avec Capture NX-D ainsi que des photos prisent directement en jpeg, même chose avec le D750.

ChatOuille

#9
Septembre 25, 2018, 03:52:45
Pour en avoir le cœur net je viens d'analyser les jpeg bit par bit. Il ne faut certainement rien reprocher à Nikon. Il fait bien son boulot.
Les jpeg contiennent plusieurs champs. Un champ qui est utilisé habituellement pour les logiciels non-spécialisés (Windows...) et celui-ci ne contient pas les centièmes. En revanche, ils contiennent bien un champ avec les centièmes de seconde et qui probablement est uniquement utilisé par les logiciels avancés dédiés à la photo. Remarque: ce champ semble avoir été généré par le traitement avec LR.

Voici :

coval95

#10
Septembre 25, 2018, 15:42:17
Citation de: ChatOuille le Septembre 25, 2018, 02:51:29
Voilà ma modeste opinion:
● Il semble bien que le Raw de Nikon enregistre le time stamp à la 1/100 de seconde. C'est la moindre des choses car les rafales sont prévues.
● Mais je pense que le temps de la prise de vue, incrustée dans le fichier JPEG, n'a de précision que la seconde.
Dès lors, toutes les prises de la rafale dans la même seconde ont le même time stamp lorsqu'elles ont été converties au JPEG. Ce n'est pas que l'un ou l'autre logiciel ne sache pas le lire, mais il ne peut pas le lire car cette information n'existe pas dans le JPEG.

C'est à vérifier, mais je te conseille de vérifier dans ce sens. Si j'ai le temps je vais le faire, mais je ne fais pas non plus des rafales habituellement.
ChatOuille, tu devrais relire les posts de hyago et de Tonton Bruno :
- hyago explique qu'il traite ses NEF avec DxO, donc les JPEG dont il parle sont issus de DxO, pas directement du boîtier.
- et comme l'explique Tonton Bruno, puisqu'il a vérifié que l'heure de PdV dans les NEF est précise au 1/100 s près, le problème viendrait soit de DxO qui ne reprendrait pas les centièmes de seconde des NEF pour les intégrer dans les JPEG, soit de Google qui ne reprendrait pas les centièmes de seconde des JPEG de DxO pour les ordonner, à supposer qu'ils y soient bien présents.

Donc il faut vérifier les dates/heures dans les EXIF des JPEG issus de DxO ainsi que ceux "ordonnés" par Google pour savoir d'où vient le problème.

ChatOuille

#11
Septembre 25, 2018, 18:25:54
Je vais essayer de m'expliquer pour le mieux. C'est difficile car la cause est très simple. Je viens de vérifier mon hypothèse et c'est bien ça.

Il ne s'agit pas du tout, mais du tout que le logiciel prenne les centièmes ou il les coupe.
Un JPEG (généraliste) ne contient pas en tant que donnée standard l'instant de prise de vue avec les centièmes.
Les JPEG issus du boîter contient bien ce champ. Même si le JPEG provient d'un Raw, j'ai pu vérifier que LR copie cette donné dans le fichier JPEG exporté, mais dans un autre champ qui n'a rien à voir avec le premier. Pour DxO je n'en sais rien car je n'ai pas essayé. Il ne s'agit donc pas de lire ou omettre les centièmes, mais de lire un autre champ de structure totalement différente. Seulement les logiciels avancés permettent de lire ce champ de données.

Le premier champ (standard) a un format de ce type "2018:09:25■□03:12:56". ■ =ASCII(35H) et □=ASCII(61H). Vous pouvez vérifier cela sur les images que j'ai montré.
Le deuxième champ (uniquement lisible par les logiciels avancés) a ce format "2018-09-19T12:51:04.30"

Cela nous montre bien qu'il ne s'agit pas de lire ou pas les centièmes, car il s'agit d'une autre lecture. Ce sont deux langages différents.

J'ai traité ce JPEG qui au départ contenait ce champ (provenant du boîtier et repris par LR), par un logiciel qui fourni juste un JPEG standard pour le web, et ce champ n'apparaît nulle part. C'est donc impossible de le lire car il n'existe pas.

PhR

#12
Septembre 25, 2018, 20:50:38
Citation de: PhR le Septembre 24, 2018, 21:22:20
Sur Joomeo, il y a le même soucis lors de petites rafales.  Désagréable lorsque l'on veut lancer un diaporama. >:( 
et il n'y a pas qu'avec Nikon que ça se passe, avec Canon et Sony aussi .  ;D

Pour info, j'ai demandé à Joomeo la raison de ce 'désordre'.
La réponse a été claire et rapide , le logiciel Joomeo ne prend en compte que les secondes.  (et d'ailleurs même les raw sont impactés)
Alors , sans se prendre la tête, c'est peut être la même chose chez Gogole.

Verso92

#13
Septembre 25, 2018, 20:52:32
Citation de: PhR le Septembre 25, 2018, 20:50:38
Pour info, j'ai demandé à Joomeo la raison de ce 'désordre'.
La réponse a été claire et rapide , le logiciel Joomeo ne prend en compte que les secondes.  (et d'ailleurs même les raw sont impactés)
Alors , sans se prendre la tête, c'est peut être la même chose chez Gogole.

Ah, ces codeurs du dimanche...

coval95

#14
Septembre 26, 2018, 00:31:21
Citation de: ChatOuille le Septembre 25, 2018, 18:25:54
Je vais essayer de m'expliquer pour le mieux. C'est difficile car la cause est très simple. Je viens de vérifier mon hypothèse et c'est bien ça.

Il ne s'agit pas du tout, mais du tout que le logiciel prenne les centièmes ou il les coupe.
Un JPEG (généraliste) ne contient pas en tant que donnée standard l'instant de prise de vue avec les centièmes.
Les JPEG issus du boîter contient bien ce champ. Même si le JPEG provient d'un Raw, j'ai pu vérifier que LR copie cette donné dans le fichier JPEG exporté, mais dans un autre champ qui n'a rien à voir avec le premier. Pour DxO je n'en sais rien car je n'ai pas essayé. Il ne s'agit donc pas de lire ou omettre les centièmes, mais de lire un autre champ de structure totalement différente. Seulement les logiciels avancés permettent de lire ce champ de données.

Le premier champ (standard) a un format de ce type "2018:09:25■□03:12:56". ■ =ASCII(35H) et □=ASCII(61H). Vous pouvez vérifier cela sur les images que j'ai montré.
Le deuxième champ (uniquement lisible par les logiciels avancés) a ce format "2018-09-19T12:51:04.30"

Cela nous montre bien qu'il ne s'agit pas de lire ou pas les centièmes, car il s'agit d'une autre lecture. Ce sont deux langages différents.

J'ai traité ce JPEG qui au départ contenait ce champ (provenant du boîtier et repris par LR), par un logiciel qui fourni juste un JPEG standard pour le web, et ce champ n'apparaît nulle part. C'est donc impossible de le lire car il n'existe pas.
OK, c'est plus clair comme ça.  ;)

ChatOuille

#15
Septembre 26, 2018, 01:44:22
Citation de: Verso92 le Septembre 25, 2018, 20:52:32
Ah, ces codeurs du dimanche...
Même si ça nous gêne ils ont une raison. Je peux le dire car j'ai fait de la programmation. Le fait n'est pas qu'il prennent les centièmes en compte ou pas lors qu'il s'agit de publication. Ça serait simple de coder et de modifier. Ce qui complique le codage est que d'abord ils doivent essayer de lire un champ qui peut-être existe ou peut-être pas. En cas d'erreur (le champ n'existe pas) il faut alors lire un autre champ qui lui existe toujours dans tous les jpegs et ce champ ne contient jamais les centièmes. C'est faisable, mais du fait que pour la publication, on a rarement besoin des centièmes, ils ont choisi l'option la plus facile. Ce n'est pas pour défendre ces codeurs, mais c'est compréhensible. En revanche, les codeurs des logiciels de traitement sont bien obligés d'examiner à fond le contenu des jpegs car c'est leur boulot.
Dans le cas de hyago le mieux est de tricher et changer les secondes.

egtegt²

#16
Septembre 26, 2018, 11:13:08
Citation de: ChatOuille le Septembre 26, 2018, 01:44:22
Même si ça nous gêne ils ont une raison. Je peux le dire car j'ai fait de la programmation. Le fait n'est pas qu'il prennent les centièmes en compte ou pas lors qu'il s'agit de publication. Ça serait simple de coder et de modifier. Ce qui complique le codage est que d'abord ils doivent essayer de lire un champ qui peut-être existe ou peut-être pas. En cas d'erreur (le champ n'existe pas) il faut alors lire un autre champ qui lui existe toujours dans tous les jpegs et ce champ ne contient jamais les centièmes. C'est faisable, mais du fait que pour la publication, on a rarement besoin des centièmes, ils ont choisi l'option la plus facile. Ce n'est pas pour défendre ces codeurs, mais c'est compréhensible. En revanche, les codeurs des logiciels de traitement sont bien obligés d'examiner à fond le contenu des jpegs car c'est leur boulot.
Dans le cas de hyago le mieux est de tricher et changer les secondes.
Je suis d'accord, sauf sur la dernière proposition. C'est un boulot énorme s'il faut modifier les secondes d'une grosse rafale, sans compter que tu risques de dépasser l'heure de la photo suivante et donc d'avoir des photos ultérieures au milieu de ta rafale

Tonton-Bruno

#17
Septembre 26, 2018, 11:15:02
Dans le cas de Hyago, ne suffirait-il pas d'activer l'option de tri sur le nom du fichier au lieu de la date ?

egtegt²

#18
Septembre 26, 2018, 11:18:45
En fait, j'ai résolu le problème de façon simple : quand je transfère les images sur mon PC, je les renomme avec nikon transfert en mettant la date et l'heure de PDV dans le nom. Et s'il y en a plusieurs dans la même seconde, il ajoute un numéro d'ordre derrière. du coup, trier dans l'ordre alphabétique suffit pour avoir tout dans le bon ordre.

Tonton-Bruno

#19
Septembre 26, 2018, 11:27:32
Citation de: egtegt² le Septembre 26, 2018, 11:18:45
En fait, j'ai résolu le problème de façon simple : quand je transfère les images sur mon PC, je les renomme avec nikon transfert en mettant la date et l'heure de PDV dans le nom. Et s'il y en a plusieurs dans la même seconde, il ajoute un numéro d'ordre derrière. du coup, trier dans l'ordre alphabétique suffit pour avoir tout dans le bon ordre.
C'est ce que je fais moi aussi depuis 15 ans et je l'avais signalé dans mon premier message.

hyago

#20
Septembre 26, 2018, 13:35:26
Bonjour le fil,

Désolé je viens du toubib et du mécano... pas eu le temps de vous lire...

Perso j'ai codé des centaines de bases de données et en général elles ont toutes une date en forme de TimeStamp qui n'est autre qu'un chiffre entier (sans décimales). Ce chiffre est unique (on a besoin de l'unicité dans les Bases de Données), et il es censé représenter (si mes souvenirs sont exacts) le temps écoulé depuis le 1 janvier 1970 (je peux me tromper sur la date, mais pas sur le concept). Donc on a des chiffres entiers de milliards mais finalement avec une simple fonction de 3 lignes déjà incorporée au langage de programmation, on obtient une date du genre: jour: 26/09/2018 Heure: 12h 45mn 20s et 99 centièmes de seconde...  Je suis donc convaincu de MON erreur dans le titre de ce fil, car Nikon fait bien les choses, c'est amha le codage JPG qui est défectueux... De fait, quand j'ai ouvert ce millier de NEFs (de mes mini-rafales du samedi soir) sous Windows 10 dans DxO, DxO les a d'abord ouvertes ordonnées par nº de photo. Comme j'avais sauté de 999 a 1 j'ai préféré demander a DxO de me les montrer ordonnées par date, et il les a très bien ordonnées: rafales ou pas rafales... c'était 100% corrélatif. Donc je me suis trompé et je m'en excuse, le NEF est parfaitement estampé dans sa date.

Si le JPG ne tient compte que des secondes, et une rafale de D850 peut faire 6 photos par seconde, c'est la galère. Bien sur à moins d'employer la technique de Bruno qui compte tenu du codage de la date sur les JPG me semble la seule solution possible... Par contre, même si ma question est hors sujet, je me demande ce que fait un quelconque boîtier quand l'usager fait des rafales en JPG direct ???  ::)
Un médiocre amateur.

Tonton-Bruno

#21
Septembre 26, 2018, 15:00:37
Les JPG ont eux aussi la date sous forme de TimeStanp, bien entendu.
Simplement par flemme certains développeurs se contentent de lire la date fournie en clair dans les données XML et là ils perdent les centièmes.

J'avais rencontré ce problème il y a une dizaine d'années avec les galeris Picasa pour des photos issues de mon compact Canon, donc non prises en compte par Nikon Transfer.

Hyago tu devrais essayer Nikon Transfer, comme ça toutes tes photos seront bien nommées et bien classées pour les cent ans à venir !

egtegt²

#22
Septembre 26, 2018, 15:07:25
En fait, les timestamp en informatique sont en secondes depuis le 1er janvier 1970 (ou étaient, parfois ça a changé à cause du passage de l'an 2000), les centièmes de seconde sont gérés de façon spécifique. Mais en l'occurrence, si je ne me trompe pas, les Exifs prévoient la date à la seconde près dans les champs normalisés, le centième est mis dans des champs additionnels non normalisés. C'est pourquoi ils existent mais sont potentiellement différents d'un constructeur à l'autre.

Bernard2

#23
Septembre 26, 2018, 15:12:34
Citation de: Tonton-Bruno le Septembre 24, 2018, 14:44:09
Bonjour Hyago.
J'utilise Nikon Transfer pour renommer les photos durant leur transfert sur le PC et ce logiciel renomme les images à ma demande selon le modèle AAMMJJ_hhmmss_00
Les 00 correspondent au numéro d'ordre dans la rafale.
Voir copie d'écran jointe.

Je crois que tu es sous Linux et que tu ne peux pas utiliser les logiciels Nikon.

Je ne sais pas s'il existe sous Linux un logiciel capable de lire correctement la date et l'heure des fichiers NEF, alors que celle-ci est stockée en clair dans les EXIF au centième de seconde près, et que je n'ai aucune difficulté non plus pour lire ces information sous Photoshop.

Je joins aussi une photo affichée avec la visionneuse de Nikon View.
On constate que l'heure est donnée jusqu'au 1/100s.
Salut Bruno,

Je fais sans doute une erreur quelque p

Bernard2

#24
Septembre 26, 2018, 15:19:14 Dernière édition: Septembre 26, 2018, 15:32:15 par Bernard2
Citation de: Tonton-Bruno le Septembre 24, 2018, 14:44:09
Bonjour Hyago.
J'utilise Nikon Transfer pour renommer les photos durant leur transfert sur le PC et ce logiciel renomme les images à ma demande selon le modèle AAMMJJ_hhmmss_00
Les 00 correspondent au numéro d'ordre dans la rafale.
Voir copie d'écran jointe.

Je crois que tu es sous Linux et que tu ne peux pas utiliser les logiciels Nikon.

Je ne sais pas s'il existe sous Linux un logiciel capable de lire correctement la date et l'heure des fichiers NEF, alors que celle-ci est stockée en clair dans les EXIF au centième de seconde près, et que je n'ai aucune difficulté non plus pour lire ces information sous Photoshop.

Je joins aussi une photo affichée avec la visionneuse de Nikon View.
On constate que l'heure est donnée jusqu'au 1/100s.
Salut Bruno,
Je fais sans doute une erreur quelque part, mais lorsque je paramètre Nikon transfer2 selon tes réglages j'obtiens ce classement dans le disque et dans View NX-i
(la première image ne semble pas classée comme "00" ) D'autre part les secondes sont aussi bizarres pour une rafale à 9 im/s...il y a toujours 2 images avec un écart de 2 secondes en début.
Imprimer
En haut Pages1 2 3 Toutes
Actions de l'utilisateur