Précision de la datation des photos sur l'exemple des Canon EOS

[invite0c4f2837]

En astro, je suis utilisateur habitué aux Canon EOS - successivement : 550D, 600D, 6D, 5D Mark IV - et j'utilise souvent le mode rafale.
Le fonctionnement des rafales apparaît extraordinairement répétable, disons au millième de seconde près sur plusieurs minutes. Il y a de temps en temps des ratés et des absences de répétabilité parfaite, cependant les écarts constatés jusqu'à présent sont restés inférieurs ou de l'ordre du centième de seconde.
Notons par ailleurs que, la dérive de l'horloge interne à quartz des Canon EOS étant de l'ordre d'une seconde par jour, on aura dérivé d'un centième de seconde par rapport au TU tous les quarts d'heure environ.

A première vue, ceci montre que les Canon EOS ont des possibilités chronométriques très intéressantes pour l'observation astronomique de précision (satellites artificiels, occultations astéroidales, astrométrie fine, etc.). Pourtant la prise des temps au moyen des Canon EOS souffre d'une sévère limitation, que j'estime liée à un grave bug, non corrigé et qui affecte les différents appareils de la marque y compris le récent 5D Mark IV.

J'ai détaillé en quoi consiste le bug ici :
https://www.flickr.com/groups/satell...7692399623741/

Ma conclusion est que Canon se satisfait d'un outil autorisant l'astronome à fonctionner au mieux à une ou 2 secondes près, s'il se fie aux temps au centième de seconde enregistrés par l'appareil, ce qui est notoirement insuffisant en astronomie de position.

Je désirerais savoir :
1) si ce bug est connu au sein de la communauté des astrophotographes
2) si ce bug est spécifique à Canon ou si des bugs du même genre affectent d'autres marques.
Je suis tenté en effet de passer de Canon à Nikon s'il apparaît que les Nikon sont fiables au centième ou au dixième de seconde près.

Alain
-----

[lmdlg]

Bonjour,

La précision d'une montre à quartz "oscille" (si j'ose me permettre ce jeu de mots) entre 2 et 15 s par mois. Cette dérive est d'autant plus grande qu'elle est fonction de la température du quartz qui est étalonné sur une valeur trop "douce" par rapport à celle d'une froide nuit d'hiver. Donc, à moins que l'horloge ne soit pas réglée automatiquement et régulièrement par un signal radio, ça ne me choque pas que l'on tronque à la seconde, la dérive pouvant se propager de mois en mois.
Une solution serait de copier directement la photo sur un PC et que l'exif soit modifiée avec l'heure du PC, elle même calée sur l'heure atomique (serveur NTP). Il suffit juste de calculer le temps de latence entre la prise de la photo et sa copie sur le disque dur du PC. Ou plus efficacement lire l'heure de l'APN, le comparer avec le serveur NTP, et retirer le delta qui devra être recalculé régulièrement, en fonction des conditions thermométriques notamment.

J'espère ne pas avoir répondu à côté de la plaque.

À bientôt !

PS : l'heure TU subit régulièrement des modifications par la mise en place d'une seconde "intercalaire" afin de tenir compte de l'irrégularité de la rotation de la Terre. Cela rend crucial ce calage sur un serveur NTP ou sur une horloge atomique par onde radio.

[Longues-Poses]

Bonjour Alain,

Je ne sais pas si tu connais magic lantern:
https://www.magiclantern.fm/

Je m'en suis servis plusieurs années et l'ai installé sur pas loin de 100 boitiers de modèles différents.
Ce firmware modifié s'installe sur la carte mémoire et débride littéralement l'appareil !
Je ne sais pas si cela résout ton souci, mais je pense que c'est une piste à tester ...
tu peux aussi demander à la communauté ML qui est très active si l'un d'entre eux est intéressé à faire la modif

@+
Jo

[invite0c4f2837]

Bonjour,

La précision d'une montre à quartz "oscille" (si j'ose me permettre ce jeu de mots) entre 2 et 15 s par mois. Cette dérive est d'autant plus grande qu'elle est fonction de la température du quartz qui est étalonné sur une valeur trop "douce" par rapport à celle d'une froide nuit d'hiver. Donc, à moins que l'horloge ne soit pas réglée automatiquement et régulièrement par un signal radio, ça ne me choque pas que l'on tronque à la seconde, la dérive pouvant se propager de mois en mois.

Sur mes deux appareils les mieux étalonnés, la dérive est typiquement légèrement supérieure à une seconde par jour et j'ai mesuré depuis plusieurs années qu'elle est relativement constante dans le temps, assez en tout cas pour me permettre de garantir le dixième de seconde en interpolant d'un jour à l'autre pour avoir la valeur de la dérive à prendre en compte selon l'heure de la prise de vues. La relative constance observée expérimentalement doit tenir à mes conditions d'observation et de stockage de mon appareil.

C'est pourquoi je ne remets jamais l'horloge de mon appareil à l'heure, et je me contente de suivre l'évolution de la dérive jour après jour. Chaque jour je photographie l'heure sur la mire "Time-is" avec l'appareil pour mettre à jour la valeur de l'écart avec le TU.
Lorsque je fais une observation nécessitant une grande précision (occultation astéroidale par exemple) je photographie la mire Time-is, AVANT et APRES l'observation, de manière à m'assurer de l'écart avec le TU. S'il y a un problème avec Time-is , je le détecte immédiatement. Je contrôle alors la mire de Time-IS avec l'horloge parlante
La plupart des sources de temps radiocommandées ne sont pas fiables à 100% et des écarts de l'ordre de 0.2 à 0.3s sont monnaie courante.

Ma façon de gérer le raccordement au TU, d'une grande simplicité, permettrait de garantir le 10è ou 20ème de seconde, s'il n'y avait pas ce maudit bug Canon, qui m'oblige à des tas de contorsions supplémentaires pour le contourner plus ou moins bien.

Alain

[A voir en vidéo sur Futura]

[invite0c4f2837]

Ce firmware modifié s'installe sur la carte mémoire et débride littéralement l'appareil !
Je ne sais pas si cela résout ton souci, mais je pense que c'est une piste à tester ...

Effectivement, c'est une idée à creuser.

J'avais déjà entendu parler de ce logiciel et la liste de ses fonctionnalités principales ne m'avait pas paru évoquer la solution possible du problème.
En effet, rien ne dit que le bug ne se situe pas EN AMONT des possibilités de cet add-on.

Si ce bug était si facile à corriger par un simple add-on, je doute que Canon l'ait laissé perdurer aussi longtemps. Ils n'ont pas jugé utile de s'attaquer au problème - je suspecte- parce qu'ils ont dû faire le même raisonnement que lmdlg :
"ça ne me choque pas que l'on tronque à la seconde, la dérive pouvant se propager de mois en mois."

J'ajoute que le problème n'est pas tant qu'on tronque à la seconde, il est que : 'tantôt on tronque et tantôt on ne tronque pas' ! C'est cet aspect ALEATOIRE qui est la signature du bug.

De toutes façons la plupart des astronomes résolvent le problème en ne tenant pas compte des indications de l'EXIF. Ils déclenchent la photo sur un top d'horloge parlante. Ils font donc comme si le Canon ne possédait pas d'horloge interne.

Alain

[Longues-Poses]

En fait ce qu'il te faut c'est une timebox.
Par contre je sais pas si il est possible de piloter un canon avec ?
Celle la par ex:
http://airylab.fr/timebox/

Jo

[invite0c4f2837]

Il y a effectivement différentes bonnes façons d'obtenir une datation précise des photos sans se fier aux indications horaires figurant dans l'EXIF de l'appareil, moyennant un équipement supplémentaire.
Mais cela nous éloigne des questions posées, sur lesquelles je n'ai toujours pas mes réponses.

"Je désirerais savoir :
1) si ce bug est connu au sein de la communauté des astrophotographes
2) si ce bug est spécifique à Canon ou si des bugs du même genre affectent d'autres marques. "

[lmdlg]

Bonjour,

En regardant ceci, on peut voir que la fonction
0x9003 DateTimeOriginal Description Date de la prise de vue Texte aaaa:mm:jj hh:mm:ss
est codé sur 20 caractères et je me demande si elle n'est pas limitée à la seconde « par construction ».
The format is "YYYY:MMD HH:MM:SS" with time shown in 24-hour format, and the date and time separated by one blank character (hex 20).
The character string length is 20 bytes including NULL for termination. When the field is left blank, it is treated as unknown.
Cette limitation ne serait donc pas le fait de Canon, mais du format des Exif.
Je pense donc que le 1/100 de seconde visible sous Picassa (d'après le lien Flickr que tu as laissé) ne correspond à rien. Peut-être une anticipation future de l'évolution du format Exif ?

à bientôt !

[invite0c4f2837]

Cette limitation ne serait donc pas le fait de Canon, mais du format des Exif.
Je pense donc que le 1/100 de seconde visible sous Picassa (d'après le lien Flickr que tu as laissé) ne correspond à rien. Peut-être une anticipation future de l'évolution du format Exif ?

En fait, les centièmes de seconde sont stockés dans un autre champ de l'EXIF, en complément du champ principal codé sur 20 caractères.
J'utilise Picasa pour les faire apparaître, mais on peut les faire apparaître à l'aide de n'importe quel outil spécialisé capable de manipuler l'EXIF. C'est un collègue qui m'a montré le truc. Il utilisait d'ailleurs plusieurs autres outils ; autres que Picasa (le prédécesseur de Google Photos) dont il n'était pas lui-même utilisateur.

Je garantis le fait que les centièmes visibles sur l'EXIF sont parfaitement signifiants. Ils permettent de contrôler la parfaite répétitivité, au millième de seconde près, de l'écart qui sépare 2 photos dans une rafale de plusieurs centaines de photos.
Avant d'utiliser Picasa, j'avais trouvé une méthode personnelle qui me permettait de déduire les centièmes de seconde manquants chez Canon, grâce à un travail de calcul relativement fastidieux. J'ai expliqué en détail cette méthode sur mon site Flickr. Mais elle n'a plus de raison d'être, une fois qu'on a découvert que les centièmes de seconde sont bel et bien stockés dans l'EXIF.
En outre, j'ai pu vérifier que ma méthode de déduction des centièmes manquants était parfaitement validée, car elle donnait exactement le même résultat que celui figurant dans l'EXIF.

Alain

[lmdlg]

Peux-tu m'indiquer le nom du champ en question ?

à bientôt !

PS : désolé de ne pas t'aider, mais cette problématique m'intéresse...

[lmdlg]

Ah j'ai trouvé : SubSecTime
0x9290 37520 Photo Exif.Photo.SubSecTime Ascii A tag used to record fractions of seconds for the <DateTime> tag.

Je continue à investiguer de mon côté...

[lmdlg]

Re !

J'ai - sous Linux - la commande : exiv2 -K Exif.Photo.SubSecTimeOriginal IMG_xxxx.JPG
qui donne une valeur au centième différente d'une photo à l'autre. Le champ est donc rempli (mais je ne sais pas s'il est juste) pour mon Canon 1000D. Est-ce que dans ton cas tu as un champ vide, un champ invariant ou un champ faux ?

à bientôt !

[invite0c4f2837]

Est-ce que dans ton cas tu as un champ vide, un champ invariant ou un champ faux ?

Comme j'ai expliqué précédemment dans mon premier post, le champ des centièmes est toujours correctement rempli dans les rafales. Du moins à partir de la seconde photo, car les centièmes figurant sur la première photo de la rafale sont assez fréquemment égaux à 0.00. Normalement cela ne devrait arriver qu'une fois sur 100 en moyenne, mais cela arrive bien plus que 20 fois sur 100, ce qui démontre la réalité du bug.

Parallèlement, lorsqu'on prend une seule photo, et pas une rafale, les centièmes sont assez fréquemment égaux à .00 , bien plus que 20 fois sur 100, ce qui démontre la réalité du bug, et le fait que la troncature par erreur arrive aléatoirement.

Ce même problème arrive sur mon 600D, mon 6D et un 5D Mark IV qu'on m'a prêté.

Alain

[lmdlg]

Je viens de tester sur tous mes fichiers Astro de l'année 2017 soit 765 photos.
Avec la commande
find -iname "*.JPG" -exec exiv2 -K Exif.Photo.SubSecTime {} \; > Listing.csv
J'ouvre le fichier Listing.csv avec Calc, et je trouve 12 occurrences de 0 (soit 1,5%), donc rien d'anormal sur mon 1000D.
Ne faisant pas de mode rafales (mais utilisation d'un intervallomètre de temps en temps) je ne peux pas conclure pour ce cas précis.
Je t'invite à faire de même sur ton répertoire pour avoir un calcul précis de cette occurrence, car c'est quand même curieux que des APN haut de gamme plantent alors qu'un basique 1000D fonctionne correctement (hors mode rafales que je n'ai pas pu vérifier).

à suivre...

[invite0c4f2837]

J'ai fait le décompte sur les 151 photos prises en test du 5D Mark IV le 3 mars 2018 où il y avait un mélange de rafales de poses diverses et de photos prises isolément : (c'est très fastidieux parce qu'il faut vérifier à chaque fois qu'il s'agit de rafales ou de photos isolées, puisqu'on ne considère que la première photo d'une rafale).

69 photos étaient des "premières photos" sur lesquelles j'ai testé les centièmes de seconde.

42 photos avaient 2 digits non égaux à 00
27 photos avaient les 2 digits égaux à 00 (soit 39%).
Les autres photos étaient à l'intérieur de rafales.

Je peux te garantir que c'est représentatif de ce que j'observe depuis 4 ans sur le 6D.

A noter que je déclenche pratiquement toutes mes photos à l'aide d'un déclencheur souple ordinaire; (j'ai essayé divers types de déclencheurs souples dans le passé, dont certains programmables, mais cela ne change rien au problème).
Je ne me souviens plus avoir testé ce que ça donne lorsque je déclenche directement l'appareil, mais je ne le fais généralement pas à cause du bougé, et parce que le retardateur de 2 secondes n'est pas approprié pour le suivi des satellites.

Alain

[invite0c4f2837]

Je viens de vérifier rapidement sur des photos touristiques prises sans déclencheur souple :
Le problème demeure sur le 6D et sur le 600D.

EN REVANCHE il est ABSENT sur mon vieux mini-appareil CANON Ixus 860 IS, comme il est absent sur mon PANASONIC LUMIX récent.

Conclusion : mieux vaut avoir un CANON entrée de gamme !!

Alain

[lmdlg]

Bonjour,

J'ai demandé à des amis de m'amener leur disques durs de photos pour voir comment ça se passe avec leurs APN... Mais ça va prendre un peu de temps...
En attendant, as-tu lu cette discussion en anglais ? Un des développeurs d'un logiciel d'EXIF a remarqué la même chose que toi.
Ici, un utilisateur d'un 50D trouve que le champ Exif.Photo.SubSecTime n'est pas rempli correctement (ordre des centièmes de seconde différent de celui des numéros de photos).
Cette autre discussion en allemand, indique que le Help-Desk de Canon ne sait pas exactement ce qui est écrit dans ce champ Exif.Photo.SubSecTime.

À suivre...

PS : j'utilise en général le retardateur et parfois l'intervallomètre.

[invite0c4f2837]

BRAVO et Félicitations !
Merci beaucoup, lmdlg, pour avoir abouti dans votre recherche, et déniché ces discussions en anglais et en allemand qui répondent parfaitement à mes deux questions :

> Je désirerais savoir :
> 1) si ce bug est connu au sein de la communauté des astrophotographes

La réponse serait donc : "OUI ... mais apparemment plus connu à l'étranger qu'en France !"


> 2) si ce bug est spécifique à Canon ou si des bugs du même genre affectent d'autres marques.

La réponse est donc :"bug spécifique à certains appareils de Canon, surtout parmi les plus chers"

> Je suis tenté en effet de passer de Canon à Nikon s'il apparaît que les Nikon sont fiables au centième ou au dixième de seconde près.

Ma décision est prise. Je vais quitter Canon qui n'a pas su ou pas jugé utile de corriger un bug aussi énorme - connu au moins depuis 2011 - sur ses appareils parmi les plus sophistiqués ! Cela me paraît disqualifier cette firme au plan scientifique.

Alain

[invite0c4f2837]

Je viens de tester sur tous mes fichiers Astro de l'année 2017 soit 765 photos.
(...) je trouve 12 occurrences de 0 (soit 1,5%), donc rien d'anormal sur mon 1000D.

Breaking news !
En réalité, il semble bien que le 1000D soit affecté lui-aussi d'un bug au niveau des centièmes, mais ce n'est pas exactement le même bug que celui qui affecte d'autres modèles. Il est cependant de même nature.

Un ami m'a en effet transmis un article de 2013 extrêmement complet qui fait le point sur la précision des relevés des temps sur les DSLR de nombreuses marques, incluant Canon et Nikon.
Instruments et Methods : Cameras as clocks
Journal of Glaciology, Vol. 59, No. 214, 2013 doi:10.3189/2013JoG12J12 de Ethan Z. WELTY,1 Timothy C. BARTHOLOMAUS,2 Shad O’NEEL,3,1 W. Tad PFEFFER1
1Institute of Arctic and Alpine Research, University of Colorado, Boulder, CO, USA 2Geophysical Institute, University of Alaska, Fairbanks, AK, USA
3Alaska Science Center, US Geological Survey, Anchorage, AK, USA

Les auteurs ont notamment étudié la fréquence d'apparition de chacun des 100 centièmes de .00 à .99 sur un très grand nombre de modèles et cela montre différents types d'irrégularité.
La distribution des centièmes observée pour le Canon EOS 1000D est ainsi irrégulière, elle-aussi, mais avec une prépondérance du .02 et du .03 tandis que le .00 est normal !! (fondé sur 586 photos de 82 utilisateurs de Canon EOS 1000D)

Je vous invite donc à reprendre l'analyse de vos 765 photos sur ce principe : fréquence d'apparition comparée de chacune des 100 valeurs prises par les centièmes.

Alain

[lmdlg]

Bonjour,

Alors effectivement, en calculant les pourcentage d’occurrences (via un tableau croisé dynamique), on se rend compte qu'avec mon 1000D, la répartition n'est pas uniforme.
Les occurrences les plus fréquentes finissent souvent par le chiffre 1 :

1/100 sec - Nb d'occurrences - pourcentage
61 19 2,48 %
71 18 2,35 %
41 17 2,22 %
81 17 2,22 %
91 17 2,22 %
1 16 2,09 %
11 15 1,96 %
7 14 1,83 %
20 13 1,70 %
51 13 1,70 %
0 12 1,57 %
21 12 1,57 %

Pour les moins fréquentes c'est moins net :
8 4 0,52 %
16 4 0,52 %
24 4 0,52 %
76 4 0,52 %
87 4 0,52 %
6 3 0,39 %
43 3 0,39 %
45 3 0,39 %
54 3 0,39 %
59 3 0,39 %
62 3 0,39 %
68 3 0,39 %
86 2 0,26 %
89 2 0,26 %
97 2 0,26 %
56 1 0,13 %

Je ne pense pas que sur 735 photos cela suffise pour que ce soit statistiquement inattaquable vu qu'il existe 100 classes de valeurs – mais je peux le faire sur l'ensemble de mes photos, si vous le souhaitez – mais effectivement on a déjà un signal d'une forme de dissymétrie. Bravo pour votre ténacité !

à bientôt !

[lmdlg]

L'idée de la taille de l'échantillon me chagrine. Je pense que pour 100 classes, il nous faut bien plus de 700 photos pour conclure...
De mes souvenirs de stats, on avait une formule empirique pour déterminer le nombre de classes par rapport à un échantillon de taille n
nbc = 1+3.3log(n) - corrigez-moi si je me trompe.
Donc avec 700 photos, on ne peut faire que 10 classes.
Avec 10³⁰ on peut faire nos cents classes, soit plus que ce que peut tirer un APN, même de haut de gamme.
Ce qui veut dire que statistiquement, ça n'a pas de sens de vouloir classer les événements au centième près. Il ne s'agirait donc pas d'une erreur de Canon, mais d'un impossibilité statistique de conclure à un défaut ou pas de l'APN.

Tout au plus pouvons-nous reprendre nos calculs avec des intervalles 1..10 11..20 21..30, etc...

J'aimerai bien qu'un vrai matheux supervise mon raisonnement...

à suivre...

[lmdlg]

PS : je me suis « amusé » à regrouper les valeurs des centièmes par classe 0..9 10..19 20..29 ... 90..99
et on tombe sur 10% par classe, résultat statistiquement robuste.

[invite0c4f2837]

Il y a deux choses qui me frappent sur votre exemple :
1) Il y a une assez belle uniformité dans la répartition des fréquences , qui est très encourageante, car une répartition de 0.13 à 2.48 , c'est quand même très resserré autour de la valeur de 1. On imagine une belle courbe de répartition avec un écart-type assez faible (de l'ordre ou inférieur à 0.5 % ?). Certes il y a le curieux cas des valeurs qui se terminent par 1 , mais je serais tenté à vue de rejeter l'existence d'un bug caractérisé sur votre appareil.
2) Vous ne retrouvez pas les résultats de l'article de 2013 qui a trouvé une grosse prépondérance des valeurs .02 et .03 .

Plutôt que d'essayer de résoudre le problème au plan de la théorie statistique - ce qui va probablement nous mener dans le décor - je vous suggère une méthode pragmatique plus simple et plus efficace.
Vous prenez un autre échantillon avec 500 à 1000 mesures indépendantes des 7 à 800 premières. Et ensuite on compare les résultats sur ces 2 échantillons indépendants.
Ou bien les résultats ont un air de famille. ou bien ils sont totalement discordants. S'ils sont assez discordants, on pourra confirmer l'hypothèse de l'absence de bug caractérisé.

Alain

[invite0c4f2837]

PS : je me suis « amusé » à regrouper les valeurs des centièmes par classe 0..9 10..19 20..29 ... 90..99
et on tombe sur 10% par classe, résultat statistiquement robuste.

C'est très intéressant et probablement décisif, mais ce n'est pas encore totalement concluant sur l'absence de bug. En effet, sur les répartitions montrées par les auteurs de l'article de 2013, il y a certains appareils qui présentent des gros maxima tous les 10 à peu près (un peu comme dans votre cas avec les 1 surreprésentés). S'ils avaient travaillé par classes de 10, ils n'auraient mis en évidence l'anomalie.

Alain

[lmdlg]

C'est ce que je faisais à l'instant, sur un autre paquet de photos (2875 photos)

Pour les plus fréquents :
1/100 sec - Nb d'occurrences - pourcentage
66 43 1,50 %
60 41 1,43 %
27 40 1,39 %
34 40 1,39 %
61 40 1,39 %
15 39 1,36 %
52 39 1,36 %
31 38 1,32 %
18 37 1,29 %
71 37 1,29 %


Pour les moins :
1/100 sec - Nb d'occurrences - pourcentage
3 22 0,77 %
97 22 0,77 %
4 20 0,70 %
10 20 0,70 %
51 20 0,70 %
57 20 0,70 %
65 20 0,70 %
67 20 0,70 %
6 19 0,66 %
41 19 0,66 %
58 19 0,66 %
19 18 0,63 %
76 10 0,35 %

On voit déjà que ça se ressert au niveau pourcentage, et qu'ils ne sont pas trop ressemblants aux premiers résultats.
La question qui me vient ensuite, c'est si on peut étendre ce raisonnement à vos APN ? Sachant qu'il faut un grand nombre de photo pour conclure, soit Canon s'abrite derrière les stats pour ne pas corriger le bug, soit le bug n'existe pas, et c'est juste une coïncidence due au sous-dimensionnement de l'échantillon étudié... Mais ça me gêne de penser que les auteurs de l'article dont vous parlez n'aient pas vu cette impossibilité statistique.

Emmanuel.

[invite0c4f2837]

Bien. La cause est entendue. Sur votre appareil, il n'y a pas de bug.

Sur d'autres appareils comme mon EOS 6D ou l'EOS 5D Mark IV, on n'a pas besoin d'analyser 3000 photos pour tirer la conclusion inverse. Un simple coup d'oeil suffit. Voir ci-dessus mon résultat sur 151 photos, qui est concluant statistiquement parce qu'on n'a à analyser que l'occurrence .00 et pas les 99 autres. Le bug est présent et évident à déceler.

Mon ami qui a testé un autre EOS 5D Mark IV m'a écrit :
"Je n'avais pas encore remarqué le problème. Je ne l'ai apparemment pas sur mon 5D MK2, mais sur mon 5D MK4 j'ai même trouvé une série complète de 26 images, prises individuellement sans rafale, avec 100% d'images avec secondes entières! ".

Les auteurs de l'article ont testé la plupart du temps sur de trop petits échantillons ce qui est une faiblesse. Ils ont utilisé le site Flickr sur lequel on pouvait facilement trouver des dizaines de milliers de photos avec l'Exif.
Mais leurs résultats sont hétérogènes : sur certains appareils j'estime qu' ILS DEMONTRENT le bug, et que sur d'autres ILS NE LE DEMONTRENT PAS. Car ils ont manifestement généralisé un peu trop vite, en affirmant que le bug était présent sur un très grand nombre d'appareils, ce qui est exagéré. D'ailleurs, les diagrammes qu'ils présentent ne sont à l'évidence pas tous concluants.

Je vous transmets copie de l'article en privé.

Alain

[invite0c4f2837]

Bonjour Emmanuel,

Déçu par l'imprécision des instants enregistrés par le CANON, je me suis rabattu sur NIKON.

Je teste actuellement le NIKON D850; cela va prendre plusieurs semaines mais voici mes premiers résultats.
Ils sont apparemment de la même eau que pour les CANON haut de gamme, c'est-à-dire pas brillants: pour avoir une approximation acceptable du TU mieux vaut investir dans une horloge de cuisine radiocommandée à 30€ que dans un appareil photo à 3800 € !


Je conserve cependant l'espoir qu'on puisse tirer un peu plus du NIKON que des CANON, avec peut-être une incertitude sur le TU de l'ordre de la demi-seconde, alors que sur le CANON on travaille à moins bien qu'une seconde.
Voir mon blog :

https://www.flickr.com/groups/satell...7693366546311/

Alain

[lmdlg]

Bonjour et merci pour les nouvelles.
Je me demande si l'observatoire de Besançon, qui délivre des certifications chronométriques à des montres mécaniques (norme européenne ISO 3159) ne s'est pas penchée sur le sujet. Ça vaudrait peut-être le coup de les contacter, au moins pour savoir si on leur a déjà fait la demande.

à bientôt !