Rolling shutter ou global shutter ?

[Francis Adelving 0]

ms,

Il y a quelque chose que je ne comprends pas : tu expliques que le rolling shutter est à proscrire mais tu conseilles d'utiliser, par exemple, la caméra ZWO ASI120MM qui ne fait que du rolling shutter .... ?????

Francis

[chonum 976]

Salut Lucien,

ton sujet m’intéresse pour m'y être penché aussi.
Si tu es partant, je peux te prêter une caméra qui supporte les deux modes d'acquisition. Il faut que tu ais un port GigE en revanche.
Ecrit moi le cas échéant.

Frédéric.

[Lucien 11 292]

ms (Francis),
C'est une interrogation simplement. A mon avis, mais c'est pifométrique pour l'instant, l'effet doit être subtil sur nos images amateur.

Cependant, il y a une information indiquée par Frédéric (Chonum) plus haut: il a constaté une perte de contraste sur certaines images solaires.

Est-ce un hasard mais avant même que je ne lance ce post, j'avais cette impression, je dis bien impression dans mon cas :
- les images planétaires essentiellement sur Jupiter (j'ai l'ASI120MM depuis peu), semblent moins contrastées justement et par rapport à la DMK21AU618 que j'ai gardée pour d'autres usages.

Attention, ce n'est pas une information dans mon cas, c'est une impression pour l'instant.
J'ai fait un test en intérieur et sur des images d'objets statiques; mais je n'ai pas retrouvé cet effet.

C'est par la suite que m'est venue l'idée d'un éventuel effet du Rolling-Shutter.

Pour ta proposition Frédéric, je te tiens au courant rapidement. Merci dans tous les cas.

Lucien

[christian viladrich 7 674]

J'utilisais il y a quelques années une caméra vidéo sur le solaire. La lecture se faisait je crois à 50 images s, ou plus précisément une trame sur deux tous les 1/50 s.
C'était pas du rolling shutter, mais ça y ressemblait un peu ..
Parfois, on pouvait observer des choses un peu bizarres, d'autres fois non. Cela dépendait du niveau d'agitation des images.

[-ms- 2]

quote:

---

la caméra ZWO ASI120MM qui ne fait que du rolling shutter

---

Tout dépend du mode dans lequel se fait l'acquisition : voir le chapitre "Image Acquisition Modes" de la doc Aptiva MT9M034.
Autre possibilité, utiliser le MT9M031 qui est global shutter.

[-ms- 2]

quote:

---

Tu annonçait un soft de traitement basé sur les algo de sélection de "lucky regions" pour Avril 2013.

---

Oui j'ai été un peu optimiste sur les délais mais j'avance actuellement sur la programmation // de ces algos avec Julia (lentement mais sûrement). Je posterais sur un site web, avant la fin du premier semestre 2014, mes travaux effectués sur la mire USAF 1951 ainsi que le traitement des vidéos que m'ont fournis différents astrams. Pour le ciel profond, nous verrons bien qui a raison.

quote:

---

les cartes multicoeur embarquées, c'est pas dans le budget standard de l'astram.

---

Je dois récupérer dans le courant de l'année une carte Parallela 66 coeurs avec la possibilité d'en empiler plusieurs si nécessaire. Le coût de cette carte entre sans problème dans le budget des astrams.

[Francis Adelving 0]

ms

quote:

---

quote:la caméra ZWO ASI120MM qui ne fait que du rolling shutter

Tout dépend du mode dans lequel se fait l'acquisition : voir le chapitre "Image Acquisition Modes" de la doc Aptiva MT9M034.
Autre possibilité, utiliser le MT9M031 qui est global shutter.

---

Je n'ai rien trouvé dans le chapitre "Image Acquisition Modes" de la doc Aptiva MT9M034 qui permette de réaliser des acquisitions en mode global shutter. Qu'ai-je loupé ?

Je n'ai rien trouvé non plus dans le SDK de la ASI120MM qui permette de contrôler le mode d'acquisition ( en clair d'utiliser le mode trigger ) ?

Tu conseilles de hacker l'ASI120MM en remplaçant le capteur par un autre capteur de résolution différente ???? Là je suis paumé.....

[brizhell 2 630]

quote:

---

Pour le ciel profond, nous verrons bien qui a raison.

---

ms, il ne s'agit pas de chercher a savoir qui a raison ou tord, c'est une limitation d'ordre physique, rien d'autre.
Tu continue de penser qu'il s'agit d'un problème informatique, alors que c'est la structure même de la turbulence (sa vitesse) et le flux lumineux aucquel tu es soumis qui rend le problème quasi insoluble sans cameras travaillant en régime de comptage de photon pour le CP. Relis les publis de l'équipe de Cambridge qui travaille sur le sujet.

[-ms- 2]

Tu as un petit exemple sous linux dans le lien suivant pour la carte BeagleBord-xM :
http://github.com/Aptina/BeagleBoard-xM/tree/master/MT9M034

Tu devrait pouvoir l'adapter à n'importe quelle carte ou à ton pc.
En général, tous les CMOS "rolling shutter" d'Aptina offre la possibilité d'utiliser un trigger.

[Francis Adelving 0]

Oui, mais le trigger, comme le temps, ne fait rien à l'affaire.

quote:

---

The single-frame mode operates similar to the video mode. It also scans the rows of the sensor twice, first to reset the rows and second to read the rows.

---

C'est toujours du rolling shutter...

[-ms- 2]

Tu peux appeler cela comme tu veux mais à l'arrivée ça ne produit pas les artéfacts du mode video.

[-ms- 2]

quote:

---

c'est la structure même de la turbulence (sa vitesse) et le flux lumineux aucquel tu es soumis qui rend le problème quasi insoluble sans cameras travaillant en régime de comptage de photon pour le CP.

---

Tu as raison, pour le CP, c'est bien un problème de comptage de photon mais ce comptage peut aussi se faire par logiciel.
Pour obtenir mon compte de photons, je dois ajouter un certain nombre de sous-régions (et non de régions) ce qui "malheureusement" moyenne la turbulence mais "heureusement" me donne une indication à posteriori sur les transformations à effectuer pour recaler les sous-régions.
Après, on peut toujours discuter de la fréquence d'acquisition qui doit bien sûr tenir compte du temps de cohérence.

[Francis Adelving 0]

quote:

---

Tu peux appeler cela comme tu veux mais à l'arrivée ça ne produit pas les artéfacts du mode video.

---

Des preuves, des preuves, des preuves !!!!

[brizhell 2 630]

quote:

---

c'est bien un problème de comptage de photon mais ce comptage peut aussi se faire par logiciel.

---

ms, il faut que tu m'explique : un photon unique issu d'une portion de CP, sur une pose courte (de l'ordre de la milliseconde) tombe sur un pixel. Ce même pixel, après lecture, produit un bruit de lecture, disons de 9e- (et je suis optimiste, un bruit de transfert standard c'est plutôt 3 a 4 fois plus).

Comment ton logiciel peut il détecter un photon de signal pour 9 photons de bruit (rapport signal sur bruit <1), et de plus être sur que ce photon de signal est tombé sur le bon pixel (alors que la turbulence viens de le déplacer vers la pixel d'à coté), et ce sans savoir à quoi ressemble la turbulence à ce moment là (car des pixels voisin de celui sur lequel le photon est tombé, il n'y en a pas 1, il y en a 9).... Si tu veut que je te traduise ça en termes mathématiques, pas de pb. Mais faisons ca sur un autre post (encore désolé Lucien), et exemples à de traitements à l'appui comme le souligne Françis.

[Thierry Legault 5 808]

quote:

---

ms, il faut que tu m'expliques

---

l'explication m'intéresse aussi

[-ms- 2]

Une sous-région ce n'est pas un pixel mais 15 x 15 = 225 pixels.
Une région c'est 80 x 80 = 6400 pixels.
Une image c'est 640 x 480 = 307200 pixels.

A ce stade de la discussion ... vous êtes d'accord ?

[chonum 976]

Le mode global start ou global reset des capteurs rolling shutter fait que les images n'ont pas d'overlap les unes avec les autres (par exemple exposer la dernière ligne L de l'image N en même temps que la premiere ligne de l'image N+1), c'est juste pour être synchro avec une source de lumière pulsante.
Cela ne change rien au fait que les lignes de l'image ne sont pas exposées en même temps.

[Francis Adelving 0]

Je connais le mode Global Reset Release (GRR) de certains capteurs Aptina ( qui conseille alors d'utiliser un obturateur mécanique pour que toutes les lignes soient exposées durant la même durée .... ).
Mais je n'ai rien vu/lu de tel dans la documentation du capteur de la ASI120MM . Et encore moins dans le logiciel de pilotage de cette caméra.

Je rappelle quand même que ma remarque/question d'origine était sur le fait que ms écrivait que
1. le mode rolling shutter est à proscrire
2. il conseille d'utiliser, par exemple, la caméra ASI120MM

Or le capteur de cette caméra est en rolling shutter et il n'y a aucun contrôle logiciel du mode de prise de vue. ( Même le binning est soft ...).

Donc restons, SVP, sur ce sujet. Pas la peine de lister tous les modes et sous-modes possibles de tous les capteurs imaginables, sinon on va y passer l'année....

[Ce message a été modifié par Francis Adelving (Édité le 03-03-2014).]

[-ms- 2]

Qui parle de "proscrire" (où ai-je employé ce terme) ?

Qui parle de "Global reset mode" maintenant ?

Tu ne serais pas en train de passer en mode ERS pour nous pondre des artéfacts de la sorte ?

Je te dis juste qu'Aptina prévoit en général dans ces capteurs "rolling shutter" une possibilité d'éviter les artéfacts.

Et en plus du mode "rolling shutter" certains auraient même tendance à passer en mode "procureur".

[Lucien 11 292]

Bonjour,

Je ne sais si l'on peut arriver à un consensus sur cette question de reconstruction de signal en milieu disons 'turbulent'.
Il faudrait fixer des limites à ce que l'on appelle 'faible-flux', qui n'a pas de définition précise, et fixer des limites basses de rapport signal/bruit à l’acquisition.
En mode comptage de photons, on peut s'accorder à dire que c'est du faible flux.

Disons qu'il y a ici deux avis tranchés si je comprends bien :
ceux qui pensent qu'avec un signal (trop) dégradé on ne peut pas reconstruire par une analyse faisant revenir à l'origine des perturbations,
(on fait alors du Montecarlo, de l'analyse statistique...)
et ceux qui pensent que c'est encore possible

Il s'ajoute l'affaire du 'rolling-shutter' qui ne peut que compliquer la situation si l'acquisition entre pixels proches est faite à des écarts temporels du même ordre de grandeur que la variabilité de l'effet turbulent.
C'est pire encore si cet écart de temps faisant perdre totalement l'accès à la cohérence du phénomène turbulent; on prendrait des clichés à des temps de turbulence où celle-ci a sensiblement varié.

Si ce n'est pas un décalage de temps, un trop médiocre RSB va lui aussi empêcher de remonter aux paramètres du perturbateur avec une précision suffisante pour sa correction.

Rolling-shutter ou pas, là ça me parait sans espoir que de tenter de modéliser le phénomène perturbateur pour le corriger ensuite, temps réel ou pas.
Cependant si quelqu'un y arrive, il décroche le gros lot à mon avis.

Lucien

[christian viladrich 7 674]

Je n'ai pas en tête le temps de lecture en rolling shutter. Quel est l'écart max en ms sur la lecture des pixels du capteur ?

[-ms- 2]

quote:

---

on fait alors du Montecarlo, de l'analyse statistique...

---

J'ai essayé les algorithmes MRF (Markov Random Field) aux sous régions et ça fonctionne. Pour ceux qui veulent essayer, je recommande les lectures suivantes qui sont accessibles sur la toile :

Markov Random Field Modeling in Image Analysis (2009) de Stan Z. Li (3th edition),

Markov Random Fields for Vision and Image Processing (2011).

[Lucien 11 292]

ms,
La lecture ne manque pas, merci à toi.
De plus en plus envie de se remettre à programmer : mais bon mais à moins d'une idée vraiment lumineuse, on va rester raisonnable.
Quand on voit ce que font des logiciels comme Autostakkert avec nos pauvres (en information) images amateur.

Christian,

Écart de temps de lecture entre pixels adjacents :
En rolling-shutter les pixels adjacents sont lus l'un après l'autre, s'ils sont sur la même ligne de lecture (ou colonne suivant comment on raisonne).

Cet écart de temps de lecture est faible par rapport au cas suivant :
si les pixels sont sur UNE ligne adjacente, puisque chaque ligne est lue puis la suivante etc.

Dans cette configuration, l'écart de temps de lecture est en gros le temps de pose divisé par le nombre de lignes (ou colonnes) que contient l'image.

Même dans ce cas, cet écart de temps peut parfois être jugé faible par rapport aux changements/effets dus à la turbulence.

Néanmoins, dans les algorithmes de traitement/correction d'images un peu sophistiqués, on raisonne souvent en zones/régions.
Celles-ci peuvent avoir des tailles variables : par exemple 16x16 pixels ou 64x64 pixels...
Ce qui fait que cet écart de temps de lecture inter-pixel introduit des distorsions de signal fort complexes au sein d'une même zone/région.
Et par effet de propagation, cet effet est encore amplifié entre les différentes zones/régions d'une même image.

Tout ceci c'est dans le cas d'images d'objets en mouvement ou bien d'images troublées par la turbulence.
Les images fixes ne sont pas concernées par ces effets.

Et puis il y a certains modes de lecture: lecture entrelacée par exemple.
Toutes les lignes paires sont lues puis toutes les lignes impaires...c'est ce que tu indiquais plus haut je crois.
Là vraiment, c'est le pire des cas de figure pour les phénomènes dont il est question ici.
D’ailleurs ce mode c'était plutôt du temps de l'imagerie analogique.

Lucien

[christian viladrich 7 674]

C'est pas très clair Lucien ;-)

Le temps de cohérence est de l'ordre de 2 à 3 ms sous nos ciels. Je dirai donc que l'ensemble des pixels du capteur doivent être lus en moins de 2 ms, voire 1 ms pour être tranquille.

D'où ma question : en combien de temps est lu un capteur en mode rolling shutter ?

Si c'est plus court que 1 ms, il ne devrait pas y avoir de problème.

Si c'est plus long que 1 à 2 ms ... je ne sais pas trop ce que l'on peut tirer des résultats. Peut-être ce genre de truc :-)

[Ce message a été modifié par christian viladrich (Édité le 03-03-2014).]

[Lucien 11 292]

Oui Christian,

Donner des temps précis, je ne sais pas si on peut le faire de façon générale car les implémentations 'capteur et électronique' différent.

Dans la pratique, on espère pouvoir faire de essais dans quelques temps, si tout va bien.
Dans l'idéal ce serait dans une application planétaire typique.

C'est vrai qu'il en devient vraiment moche ton ventilateur !

Lucien