Petite expérience amusante et instructive avec un capteur imx290

[Roch 1 970]

Bonjour à tous

Bon alors voilà, ce matin je cherchais une information cruciale sur le capteur que j'utilise : le temps de lecture entre le haut et le bas de l'image.
En effet, mon capteur étant un "rolling shutter", cela signifie que le champ utile n'est pas "lu" simultanément, mais progressivement de haut en bas. Cela peut engendrer des problèmes si on image avec une cadence élevée, le problème est bien connu des vidéastes.

Peut être que cette info est disponible sur le net quelque part, mais j'ai pas trouvé, et du coup j'ai mis en place une petite expérience rapide afin de mesurer moi même ce temps de lecture 

 

Etant musicien de profession, j'ai eu l'idée de capturer l'image d'une corde en vibration avec le temps de pose le plus bref possible. Si l'image est capturée instantanément sur tout le champ, la corde apparaîtra rectiligne ; par contre si l'image est capturée à des instants différents selon la position, on verra apparaître une sinusoïdale ; la corde sera positionnée à droite où à gauche selon le moment d'acquisition.
L'avantage d'utiliser une corde est qu'on peut retrouver facilement la fréquence, à l'oreille ou avec un accordeur... dans mon cas elle est de 220Hz, soit 4.55ms/période environ

Voici l'image de la corde "au repos"

 

Puis l'image "en vibration" en mode d'acquisition 8 bits

 

Et enfin en mode 12 bits

 

Les acquisitions sont réalisées à définition maximale, soit 1920x1080 pixels

Je compte environ 16 périodes pour le mode 8 bits. cela nous donne donc 16 x 4.55 soit à peu près 73ms pour une lecture de haut en bas, ou encore 67µs de temps de lecture par pixel.
Pour le mode 16 bits, on compte environ 27 périodes, ce qui donne 122ms pour la lecture totale, ou encore 113µs de temps de lecture par pixel.


Concrètement ça signifie quoi ?

Edit : la suite est fausse, puisque j'ai remarqué avec d'autres tests ( voir plus bas ) que le temps de lecture dépendait de la bande passante de la connectique ( USB2 / USB3, réglage USB Traffic ) ; dans tous les cas il ne pourra jamais durer plus longtemps que le temps de pose maximum pour une cadence donnée ( par exemple, 5ms pour une cadence à 200fps )

 

Donc pas de soucis à se faire en définitive 

Si on image une planète avec un framerate important, il pourrait y avoir un décalage temporel assez conséquent entre le haut et le bas de la planète. Le haut pourrait même être décalé de plusieurs frames avec le bas...
Un exemple : on image Jupiter qui mesure 300 pixels de haut sur notre image. Si on est en mode  8 bits, il y a donc un décalage de 20ms environ entre le haut et le bas. Si on est à 50 images/seconde, ça signifie que le haut du globe est en réalité enregistré sur un fichier image en même temps que le bas du globe sur le fichier image suivant !
L'effet peut être encore bien pire avec des cadences atteignant parfois 200ips, ou des grandissements plus importants.

Du coup, si on imagine un "trou" de turbulence qui durerait 1/100s, il faudrait récupérer le haut du globe sur une image et le bas sur la suivante pour avoir la résolution optimale... pas génial génial 

 

Bon, moi, mon rayon c'est plutôt le ciel profond poses courtes. On reste pour le moment sur des cadences supérieures à 100ms, donc pas de problème à priori, cependant ça pourrait changer... prudence donc.

Et j'avais fait un petit test il y a quelques temps pour essayer de déterminer l'angle d'isoplanétisme... je me rends compte que tout ceci pourrait fausser complètement mes mesures puisque j'avais imagé à 100fps sur tout le champ. Bref, à suivre

Bons cieux !

Romain

Modifié 20 février 2020 par Roch

[astroluma 176]

Houla  je n'y aurais jamais pensé à celle la.

 

il y a 57 minutes, Roch a dit :

Je compte environ 16 périodes pour le mode 8 bits. cela nous donne donc 16 x 4.55 soit à peu près 73ms pour une lecture de haut en bas, ou encore 67µs de temps de lecture par pixel.

Il faudrait plutôt faire (73ms-temps de pose)/nombre de ligne

 

Pour estimer le readout time tu peux faire : 1/(cadence d'image maxi * nombre de ligne de ton capteur)

 

Si on fait ça pour l'IMX 290 on est vers 11µs 

 

Une autre solution  consiste à filmer le clignotement d'une LED dont tu connais le temps d'allumage. En utilisant le temps de pose mini de ta caméra tu va avoir quelque chose comme ça.

         

 

Tu compte le nombre de ligne de pixels illuminées et tu en déduit le temps de lecture par ligne.

 

Exemple 100 lignes illuminées pour un temps d'allumage LED de 1 ms donne 10µs

 

Lionel

[Roch 1 970]

Il y a 1 heure, astroluma a dit :

Il faudrait plutôt faire (73ms-temps de pose)/nombre de ligne

 

Pour estimer le readout time tu peux faire : 1/(cadence d'image maxi * nombre de ligne de ton capteur)

 

Si on fait ça pour l'IMX 290 on est vers 11µs 

 

Ben oui, mais du coup c'est pas du tout conforme à mes valeurs. Pourtant je suis 100% sûr de moi concernant la fréquence de vibration.

 

Le temps de pose était minimal dans pon cas, donc négligeable.

 

Comment connaître le temps d'allumage d'une led ? je peux toujours refaire l'expérience...

 

EDIT : Ah en fait je crois comprendre... le fait que je sois en usb2 y change quelque chose du coup ! J'étais en effet limité à 13fps en 8 bits, donc tout est logique. Je vais retester en usb3 pour voir

 

 

Romain

 

Modifié 20 février 2020 par Roch

[astroluma 176]

il y a 24 minutes, Roch a dit :

Comment connaître le temps d'allumage d'une led ?

Comment faire en partant de rien je ne sais pas te dire.

J'ai une timebox (boitier utilisé pour la mise à l'heure PC pour le suivi d'occultation d'étoile) qui est équipée d'une led que l'on peut faire clignoter avec une durée d'allumage réglable.

 

il y a 32 minutes, Roch a dit :

Je vais retester en usb3 pour voir

Je suis curieux de connaitre le résultat final, je n'aurais jamais pensé à tester ça de cette manière si ça marche c'est beau!

 

Lionel

[Roch 1 970]

Ben ça marche c'est bon

Voilà l'image 8bits en USB3 :


On observe environ 2.6 périodes, soit un temps total de 4.55x2.6 = 11.8ms au total, ou 10.95µs/pixel
 

Image 16Bit sen USB3 :



Environ 8.4 périodes, soit 38.2ms au total, ou 35.4µs/pixel ( cohérent pour un framerate maxi aux alentours de 25fps )

Bon ceci dit je trouve ça débile qu'une vitesse de transmission réduite amplifie ainsi le phénomène de rolling shutter.. vous allez me dire c'est logique, m'enfin puisque le machin "sait" lire les pixels à une certaine vitesse, pourquoi ne pas utiliser toujours la vitesse maximale, sachant qu'on a de toute manière un buffer dans nos caméras ? enfin bref.

Bon du coup j'édite mon premier message... ce n'est pas réellement possible d'avoir un "décalage temporel" dans les images vu que le temps de lecture sera toujours inférieur au framerate.

Romain

Modifié 20 février 2020 par Roch