Rolling shutter ou global shutter ?

[Thierry Legault 5 848]

A partir du moment où le haut et le bas du capteur ne sont pas dans la même zone de cohérence de turbu, j'ai quand même le sentiment qu'ils peuvent être lus hors de la durée de cohérence, non ? Le coup du ventilateur, c'est parce qu'il y a une continuité (cohérence) des pales sur l'ensemble de l'image.

[Ce message a été modifié par Thierry Legault (Édité le 04-03-2014).]

[-ms- 2]

Tout à fait Thierry, une sous-région c'est 15x15 pixels autrement dit pour une image de 640x480 pixels que l'on va acquérir en 30ms, le temps d'acquisition d'une sous-région sera de : 30 / 32 = 1ms c'est à dire inférieur au temps de cohérence de la turbu observée en France comme dit christian viladrich.

brizhell, 30ms c'est toujours trop long ?

[brizhell 2 671]

Oui ms, 30ms c'est toujours trop long...

N'essaie pas de noyer le poisson, et décorrèle avant tout la structure de la turbulence (ses dimensions caractéristiques à l'échelle de l'image), sa vitesse d'évolution (le temps de cohérence qui est lui même une donnée statistique), des paramètres d'acquisition de la cameras que sont le temps de pose par pixel et le temps de lecture par pixel (qui conditionne le temps de lecture de la matrice). Les découpages en régions et en sous régions comme tu le fait (ce que tu n'a pas inventé d'ailleurs), ne changent rien à la problématique physique posée.
Thierry à en effet raison (comme bien souvent ) si tu pose court et que tu lit vite, les sous régions seront décorrélées et les traitements associés de type autostakkert sont suffisants pour effectuer la restauration (pas besoins de descendre au traitement statistiques de zones, qui je le répète, ne marchent qu'a rapport signal sur bruit important).

Quand tu prend au départ, comme tu le citait plus haut, un temps d'exposition de 30ms, tu es de base trop long, et si t'es pas d'accord, revoit tes fondamentaux sur la structure de la turbulence.

Pour ce qui est des traitements statistiques du bruit quelque soit sa nature (ça c'est un sujet qui m'est très cher ! ), Les traitement de type Bayesiens, Markov et autres, ne fonctionne qu'a partir du moment ou :
1- Soit tu a une connaissance a priori de la structure de l'objet (ou de la distribution statistique d’émission de photon par la source)
2- Soit tu déduit de la statistique d'arrivée des photons (forme de leur distribution), comment se comporte la source en émission (et dans ce cas il te faut distinguer les photons de signal issus de la source, des photons de bruit extérieurs, ce qui est physiquement impossible a faire pour un rapport signal sur bruit <1 (sauf en détection synchrone, et au shot noise, bon courage )

Pour résoudre la dernière condition de la proposition 2, il te faut avoir la condition 1 ou un appareil permettant de ramener le signal au dessus du bruit.

Ca fait 2 ans que tu inonde certains posts sur le traitement d'image statistiques de méthodes absconses pour beaucoup de gens, mais que j'ai suivi avec pas mal d'attention car elles touche pour certaines à mon domaine de recherche. En tout état de cause, toutes les publis que tu citent (y compris la dernière que je connaissait déjà) fonctionnent pour des S/N important ou proche de 1 en valeur supérieures. Au dessous ça ne va pas d'où mon énervement (relatif) à laisser croire que tu peut faire de la restauration d'images en CP avec une webcam a 10 euros....
Je serais le premier à adorer que cette idée marche, mais c'est a peu près comme être persuadé qu'un poule soit capable de pondre des œufs dur carrés déjà en boîte de 12 et le amène, elle même, direct dans ton frigo (désolé mais c'est l'image qui me viens a chaud).
Alors comme tu a déjà testé toutes ces méthodes, "pour l'amour du ciel" (j'adore cette expression pour un astronome), je rejoins Francis et Thierry, montre nous ces résultats que tu annonce (ça leur donnerai un minimum de vraissemblance...).

Quand a faire du traitement statistique temps réel, à ces vitesses là et sur des matrices aussi grosses, va falloir pédaler (je le répètes, c'est pas a la portée des moyens amateurs)....

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

[Lucien 11 305]

On peut être d'accord sur ce point, pas de problème;
la turbulence serait cohérente dans une petite sous-région de l'image.
Supposons même que ce soit toujours le cas.

Si l'on discute du but qui serait de corriger des effets de la turbulence en quasi temps-réel :

La difficulté sur des images turbulentes et avec ces sous-régions, c'est comment leur fixer une position pou ensuite tenter d'y caractériser la perturbation.

Si on les considère de position fixe, la turbulence va y introduire des données qui viennent d'autres sous-régions proches par déformations géométriques et c'est dans les deux sens.

Si l'on grossit la taille des sous-régions, cet effet sera moins marqué mais on s'expose plus à perdre la cohérence de la turbulence.

Pour aller plus loin dans le discours, il faudrait aller dans le détails des algorithmes à proposer et des inévitables paramètres de réglage (réglages statiques ou dynamiques).

A ce niveau on ne peut qu’être dans les généralités, comme avant une étude d’algorithme ; il faut définir une stratégie et puis on implémente, on corrige...

----------------------------------
Encore une fois, si l'on dispose de signaux avec un bon rapport signal/bruit c'est faisable sans doute et sans doute déjà fait.
----------------------------------

Mais en faible flux, les choses se corsent !

Caractériser la turbulence avec des sous-régions de 15x15 pixels (+/-) et avec un rapport signal/bruit classique déplorable à la source, ça ne me semble pas possible et en temps réel c'est insurmontable.

C'est comme si l'on pouvait avec une seule image (disons quelques images successives pour ne pas être trop dur avec l'algorithme), réaliser quasiment en temps réel ce que fait, par exemple Autostakkert, avec des centaines choisies parmi de plus nombreuses encore.

On aimerait bien.

Lucien

[patry 1 977]

Sur une PL1M, le temps max est de l'ordre de 100ms (1280x1024 10i/s, parfois un poil mieux mais je part sur cette base) pour toute une image, soit un écart entre lignes de 97µs. D'après christian on est là très loin de ce qui est gênant sous nos latitudes.
Sur une ASI120/QHY5 le taux d'image est de 30 à 35i/s en pleine trame, soit en gros 30ms pour 960 lignes ... soit cette fois 31µs entre lignes.
Plus cela va vite ... mieux c'est donc (lapalissade).
Mieux encore, en 640x480, la petite dernière aligne 100~110 i/s soit un temps interligne de 20µs.

Maintenant deux choses ; quand la turbulence évolue à 1ms, en général on ne fait pas de bonnes images (y compris en GS). La turbulence haute fréquence aura tôt fait de réduire à néant une collimation aux petits oignons et la capacité de la caméra "amateur" à exposer à ce rythme là (je pense qu'on ne parle pas d'EMCCD ou de sCMOS encore) et j'exclue l'usage solaire pour le moment.
Ensuite l'impact est bien sur d'autant plus important que les zones de l'image sont éloignés (cas des coins diamétralement opposés) et là on parle de 30 à 100ms.

Au final pour moi l'utilisation du RS est contrarié par la "lenteur" de la caméra, la focale de l'instrument et la turbulence.
On est tous d'accord pour dire que hors turbulence, RS=GS non ?

Maintenant si la turbulence est non nulle, ce qui va importer c'est la vitesse que la caméra met pour lire une image sachant que l'on va ainsi déterminer le dT qui existe entre les différentes lignes.
Enfin ce qui importe le plus, et que fred à touché du doigt, c'est l'angle solide couvert par la caméra. Il semble évident que la turbulence à plus de chance de perturber deux zones de la lune ou du soleil (séparés par 30' d'arc au max) que de venir pourrir le pôle nord de Jupiter différemment du pôle sud (30" d'arc).

Donc plus on fait de la HR (grosse focale, petit champ), moins ce sera un problème ! Pour moi, que cela soit la PLA-Mx (ICX618 global shutter) ou QHY5L-II (MT9M034 en rolling shutter) je ne vois pas franchement de différence au C11 à F/D > 25. Ou plutôt quand j'y vois une différence, c'est que la turbulence est tellement forte que de toute façon ce sera pourri. Quand je fait des images au foyer (lune) par contre effectivement la géométrie est parfois mal corrigée mais je suis alors assez loin de faire de la haute résolution.

Marc

[patry 1 977]

doublon

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

[Lucien 11 305]

Salut Marc,

tes informations sont les bienvenues.

C'est vrai qu'à force on ne sait plus tôt dans quel sens va le discours.
Correction de la turbulence, correction temps-réel possible, rolling-shutter...

Lucien

[-ms- 2]

quote:

---

Quand tu prend au départ, comme tu le citait plus haut, un temps d'exposition de 30ms, tu es de base trop long, et si t'es pas d'accord, revoit tes fondamentaux sur la structure de la turbulence.

---

Cool, la caméra ASI120MM (capteur CMOS Aptina MT9M034) travaille ligne par ligne (rolling shutter), en gros 30ms pour 960 lignes comme dit patry soit 0,5ms pour une sous-région de 15x15 pixels. En ciel profond, tu peux travailler en 2x2Bin pour plus de sensibilité ce qui conduit à 30ms pour 480 lignes et au temps de lecture de 1ms que j'ai indiqué plus haut.

quote:

---

La difficulté sur des images turbulentes et avec ces sous-régions, c'est comment leur fixer une position pou ensuite tenter d'y caractériser la perturbation.
Si on les considère de position fixe, la turbulence va y introduire des données qui viennent d'autres sous-régions proches par déformations géométriques et c'est dans les deux sens.

---

D'où l'intérêt de traiter les régions dans un certain ordre comme l'indique Peng par exemple. J'ai eu l'occasion de traiter dernièrement des vidéos (ASI120MM) d'un astram allemand et je comprend maintenant pourquoi le rolling-shutter n'est pas gênant quand on procède par sous-région en suivant le mode d’acquisition de la caméra.
Le vrai problème c'est le temps qui s'écoule entre 2 trames càd 30ms et là, il faut estimer le champ de déplacement des pixels de la sous-région à posteriori mais comme on connait l'évolution de la turbu d'une sous-région à l'autre en moins de 1ms ...

quote:

---

Alors comme tu a déjà testé toutes ces méthodes, "pour l'amour du ciel" (j'adore cette expression pour un astronome), je rejoins Francis et Thierry, montre nous ces résultats que tu annonce (ça leur donnerai un minimum de vraissemblance...).

---

Patience, je le ferais en juin 2014 parce que je ne baigne pas en permanence dans l'espace de Fourier et donc il me faut un peu plus de temps pour assimiler toutes ces méthodes absconses comme tu dis.

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

[chonum 976]

En fait le rolling shutter ne fonctionne pas tout à fait comme cela Lucien.
La séquence n'est pas :

- exposition ligne N
- lecture ligne N
- exposition ligne N+1...

C'est plutôt :

- début d'exposition de la ligne N image I
- attente d'un délai de lecture (temps nécessaire pour ligne une ligne) + délai de reset d'une ligne
- début d'exposition de la ligne N+1 image I
- attente d'un délai de lecture (temps nécessaire pour ligne une ligne) + délai de reset d'une ligne
- Début d'exposition de la ligne N+2 image I

...

- fin d'exposition de la ligne N
- Lecture de la ligne N (donc le délai vu au dessus) et reset
- début d'exposition de la ligne N pour l'image I+1
...

En gros c'est cela :

Dans le cas le plus optimisé (mode overlapping), on a donc deux images exposées en même temps : pendant que l'on fini les dernières lignes de l'image I, les premières de I+1 sont en court d'exposition. Cela est possible si le temps d'exposition est inférieur au délai total de lecture d'une image.

Le délai de non cohérence entre deux lignes, celui qui est à mon avis le plus destructeur, est donc [lecture+reset]. Dans le cas du capteur E2V 76C560 en mode ERS il doit y avoir 16,4ms entre l'exposition d'une même ligne pour I et I+1. Si l'on divise cela par les 1024 lignes du capteur, cela donne 16µS de délai sur le démarrage de chaque ligne.
Et donc 16.4 ms entre la fin d'exposition de la ligne 0 et la ligne 1023.
Si le temps d'exposition est inférieur à 16,4ms, alors on a overlapping et la ligne 1023 de I est exposée en même temps de ma ligne 0 de I+1.
Evidemment il va sans dire que le rolling shutter est un show stopper pour beaucoup d'applications

Plus le temps d'exposition est long et plus les incohérences spatiales entre N et N+1 deviennent négligeables face à la turbulence qui moyennera fortement le contenu des lignes.
En revanche avec une exposition courte et avec un temps de cohérence de la turbulence proche du délai [lecture+reset], cela devient probablement très destructeur. Les effets de cisaillement horizontaux que j'ai vu sur le capteur E2V et sur l'IMX ne peuvent venir que de là pour moi.

Frédéric

[brizhell 2 671]

quote:

---

Cool, la caméra ASI120MM (capteur CMOS Aptina MT9M034) travaille ligne par ligne (rolling shutter), en gros 30ms pour 960 lignes comme dit patry soit 0,5ms pour une sous-région de 15x15 pixels.

---

Le rolling shutter fonctionne soit sur l'ensemble de la matrice, soit sur une région d'intérêt (enfin j'imagine). Quand tu parle d'une région d'intérêt seule (de 15x15pixels), tu ne peut pas travailler sur la région de 15x15pixels adjacent de manière simultanée. Donc sauf a faire des mosaïques de régions de 15x15pixels dans une matrice de 640x480 en espérant faire du lucky imaging sur chaque zone de 15x15 (les unes derrière les autres), la méthode de reconstruction en lucky région ne marche pas de manière "immédiate" (bon courage, il te faudra 1365 régions a imager).
Ensuite, le temps de lecture est représentatif du temps de "décohérence" de la turbulence, mais comme indiqué plus haut, il s'agit d'une statistique. Ce temps de peut être plus court, ou plus long en fonction du type de turbulence (ordres des polynômes de Zernikes). L'intérêt de la question de Lucien est justement de croiser la contrainte de temps de lecture avec la vitesse de déformation de la turbu... Or en full frame, sauf si j'ai loupé quelque chose, les pixels restent tous de toute façon exposés 30ms (puisque l'on s'est arrêté sur cette longueur de temps de pose), même avec un temps de lecture à la 0.5ms. On est donc hors cadre.
Le point critique viens d'être super bien explicité par chonum (merci Frederic). En mode overlapping, on doit avoir décohérence de la turbulence par cisaillement horizontal si le temps de pose est de l'ordre du temps de cohérence de la turbu.

quote:

---

En ciel profond, tu peux travailler en 2x2Bin pour plus de sensibilité ce qui conduit à 30ms pour 480 lignes et au temps de lecture de 1ms que j'ai indiqué plus haut.

---

Arrête ms on sombre dans le ridicule....
Pour le ciel profond, j'ai déterré un vieux truc qu'on avait fait avec JLD il y a quelques années (mise en évidence de la rotation du pulsar du crabe). Ce qu'on a pas lâché quand Jean Luc a fait l'article, c'est la tête des images brutes de la vidéo. Voila une pose en CP de 11ms (donc encore au dessus du temps de cohérence) :

Le RSB des étoiles les plus brillantes est de l'ordre de 8, l'objet à imager au centre du cercle est de mag 16.5, ce qui n'est pas énorme en CP et son S/N sur la séquence vidéo est a peine au dessus de 1. L'addition de 20 poses donne ça :

Bref, pour faire cette image du pulsar du crabe, il à fallu un télescope de 1 mètre, une EMCCD avec le gain poussé à la limite de la saturation... J'ai plus qu’un un doute sur le fait de sortir quelque chose du bruit avec un CMOS standard à 11ms sur un scope d'astram de diamètre raisonnable.

J'ai des choses de faites en CP à ces cadences (quelques dizaines de ms, traitement statistiques sur quelques dizaine de millier d'images) au T60. Je n'aime pas parler de résultats que je n'ai pas encore confirmé (il faut que l'on remonte avec le collègue avec qui on a entamé ça, on était limité par la qualité optique du secondaire), mais on a des résultats probants sur des objets faibles, et ce uniquement parce que l'on a suffisamment de signal par rapport au bruit. Sans EMCCD, tu peut oublier.

quote:

---

J'ai eu l'occasion de traiter dernièrement des vidéos (ASI120MM) d'un astram allemand et je comprend maintenant pourquoi le rolling-shutter n'est pas gênant quand on procède par sous-région en suivant le mode d’acquisition de la caméra.

---

Ben ça contredit le constat de Frederic Jabet sur le RS en pose courte....
Montre nous les résultats de ton analyse pour que l'on puisse se faire une idée. Pour le moment cela ne reste que des affirmations et non des résultats.

[-ms- 2]

Regardes comment se fait le transfert des données :

[brizhell 2 671]

et ? et ? et ?

[chonum 976]

C'est exactement ce que je viens d'expliquer ms

[Lucien 11 305]

Frédéric,
Tu as bien fait de préciser le fonctionnement du rolling-shutter.
A force de vouloir simplifier on passe parfois à côté de certains effets !

Lucien

[-ms- 2]

quote:

---

Quand tu parle d'une région d'intérêt seule (de 15x15pixels), tu ne peut pas travailler sur la région de 15x15pixels adjacent de manière simultanée.

---

Les 15 premières lignes càd 40 sous-régions si ce n'est pas du simultané c'est quoi ? Puis les 15 lignes suivantes transférées à t+1ms ...
La hauteur d'une sous-région est donnée par le cisaillement horizontal (ici 15 pixels pour un temps de cohérence de l'ordre de 1ms).

quote:

---

C'est exactement ce que je viens d'expliquer ms

---

Oui pour le mode "rolling shutter" mais voir remarque ci-dessus qui me fait plus penser au mode "global shutter"

quote:

---

Arrête ms on sombre dans le ridicule....

---

Ton exemple montre que M1 est visible en 20x11=0,22s avec une camera EMCCD reliée à un télescope de 1m et ta conclusion c'est que l'on ne peut pas faire autrement.
Avec une camera CMOS sensible le problème se pose autrement mais tu peux aussi obtenir le résultat. Ce fameux problème c'est de retrouver les transitions à partir d'une région visible où la turbulence est moyennée. Ce problème de recalage à l'aveugle ne se pose pas bien sûr quand le flux lumineux est suffisant (planètes, étoiles doubles, mammographie, cibles terrestres) d'où la profusion de publications depuis 2002 où chacun y va de sa petite amélioration. Attends donc de voir ce que j'ai fait en ciel profond sur M57, M51 et NGC40 ... c'est pas très bon de partir comme une fusée comme tu le fais souvent et je ne parle pas des insultes (hier j'étais un escroc qui sombre maintenant dans le ridicule).

[brizhell 2 671]

Tu parle de régions de 15x15 pixels, pas de régions de (15*40)x15 pixels, ne change pas ton hypothèse entre 2 réponses a ce post.... Ce qui d’ailleurs n'a pas plus de sens que précédemment.
De plus dans ton raisonnement tu ne fait pas intervenir le temps de pose, et c'est lui qui conditionne la décohérence a la turbulence.... Ajouté à cela qu'une milliseconde de temps de lecture c'est aussi limite par rapport a ce temps de cohérence.

quote:

---

Ton exemple montre que M1 est visible en 20x11=0,22s avec une camera EMCCD reliée à un télescope de 1m et ta conclusion c'est que l'on ne peut pas faire autrement.
Avec une camera CMOS sensible le problème se pose autrement mais tu peux aussi obtenir le résultat. Ce fameux problème c'est de retrouver les transitions à partir d'une région visible où la turbulence est moyennée.

---

ms, ce n'est pas moi qui fait la conclusion que l'on ne peut faire autrement, ce sont les lois de la physique. Les poses brutes de 11ms, qui sont déjà au dessus du temps de cohérence de la turbulence montre que le rapport S/N est déjà limite avec une EMCCD et un télescope de 1m, imagine avec un C8 et une Toucam...... Les photons, arrivés sur chaque pixels pendant ta poses, ne sont pas "étiquetés" individuellement "photons de signal" et "photons de bruit". On a eu une discussion intéressante la dessus d'ailleurs avec Thierry Legault. Tu pourrait imaginer ca sans peine si tu a plus de signal que de bruit a l'entrée, mais quand tu a plus de bruit que de signal, ton soft ne peut strictement et rigoureusement rien faire (et encore moins, même si il ségréguait le photons de signal et de bruit), dire : ce photon est tombé sur le mauvais pixel, je le remet sur le pixel d'a coté)....

quote:

---

Ce problème de recalage à l'aveugle ne se pose pas bien sûr quand le flux lumineux est suffisant (planètes, étoiles doubles, mammographie, cibles terrestres) d'où la profusion de publications depuis 2002 où chacun y va de sa petite amélioration. Attends donc de voir ce que j'ai fait en ciel profond sur M57, M51 et NGC40 ... c'est pas très bon de partir comme une fusée comme tu le fais souvent et je ne parle pas des insultes (hier j'étais un escroc qui sombre maintenant dans le ridicule).

---

ms, je ne te connais pas et je te respecte en tant que personne. Si tu t'es senti insulté je m'en excuse, mais cela fait 3 fois au moins que l'on te démontre, preuve a l'appui, à plusieurs personne en plus, que ce que tu dit est faux. Continuer à persister à croire que le traitement en lucky régions sur le CP est a la portée du premier astram venu est une erreur (non parce que je le croit, mais parce que cela se démontre). Et si de plus cet astram ne maîtrise pas son setup, son optique et se dit "ben finalement je m'en fout, le soft de ms va me corriger tout ça", c'est l'envoyer dans le mur.
Quand a partir comme une fusée, je pense avoir été plutôt patient, mais truster un post dont ce n'est pas le sujet sur une démonstration de promesse fausse me fait un peu monter la moutarde au nez.

Encore une fois désolé Lucien, j'ai l'impression d'avoir trollé ton post, j'arrête là et je suis les débats.

[chonum 976]

Je ne comprends pas. Tes schémas montrent respectivement le rolling shutter et le global shutter. Et ?

[patry 1 977]

Je ne comprends toujours pas en quoi un déphasage temporel serait préjudiciable en imagerie planétaire ?

Le diagramme de séquence montre qu'on utilise beaucoup mieux la bande passante du lien de communication (on continue à imager pendant la transmission en RS, pas en GS) donc que cela permet, à iso lien, de bien meilleurs débits. Par contre en cas de latence, une fraction de l'image est perturbée les images coupées en deux que l'on a parfois en RS, chose impossible en GS, ou plutôt qui aura alors un effet global (image mal exposée).

Le décalage temporel n'est finalement que de celui du temps de reset de la ligne. Il se compte en µs (voire en dizaine/centaine de ns) entre deux lignes. Donc des milliers, voire centaines de milliers de fois plus court que le temps d'exposition de 10ms de la ligne/image elle même (valeur déjà bien courte en planétaire, on est plus souvent à 15~30ms en monochrome, et plus de 50~100ms en couleur).

L'impact global (sur une diagonale du capteur) revient à modifier la fonction de transfert de la turbulence (on déphase le seeing) mais en quoi ce serait perturbant à moins de faire non pas de l'imagerie mais de la vidéo bien sur !

Marc

[chonum 976]

Non, l’intérêt de l'ERS n'est pas de réduire la bande passante entre la caméra et le PC, l'image étant reconstruite en amont dans la caméra, mais de réduire la cadence des convertisseurs et donc d'en utiliser de moins performants (et donc moins chers) à bruit de lecture identique.

Et non le temps de latence n'est pas que le reset, mais en plus et surtout le temps de conversion A/D d'une ligne.

[patry 1 977]

Pour le transfert, je n'ai pas dit que c'était un but, mais la conséquence du mode de fonctionnement.
En GS, les données sont transmises par rafales une fois l'image acquise et peut alors retarder l'acquisition de l'image d'après. Alors que en RS, les données sont transmises au fur et à mesure pendant l'exposition de lignes suivantes. Pour ce qui est de l'optimisation de la bande passante, crois moi c'est incomparablement mieux de faire le second cas. Et c'est ça qui entraîne de meilleurs débits !

Par contre ta phrase sur les convertisseurs est encore une conséquence du mode de fonctionnement et je la préfère ainsi ;

"si en GS tu veux obtenir le même niveau de bruit que ceux utilisé en RS, alors il te faudra prendre des convertisseurs beaucoup plus chers".

L'expérience montre même que les caméras à RS sont globalement meilleures (sur cet aspect de bruit de lecture) que les caméras GS de la même catégorie, signe que finalement les industriels n'essaient même pas de résoudre cette problématique (i.e. de gagner 2 ou 3 bits de bruit) en upgradant l’électronique. Le problème est conjoncturel, dans une caméra qui fonctionne dans les deux mode, il n'y a pas deux séries de CAN. Et le choix d'un CAN pour une caméra donnée c'est une histoire de positionnement sur le marché. Rien n'empêche un industriel de faire une caméra 2000x2000 avec un CAN pourri, ou l'inverse avec une caméra VGA et le meilleur CAN du monde, si cela peut se vendre, cela peut se produire !

Et cette histoire de bruit cela aide car avec ma QHY, j'arrive à disposer de plus de 13 magnitude entre une cible (Saturne, mag 0) et les informations les plus faibles (mimas, mag 13,2) le dernier sortant du bruit de fond. J'ai essayé avec l'ICX618 sans y réussir alors même que l'histogramme à la capture dans les deux cas n'était pas "plein" (capture à 25~30ms, gain moyen, C11 à F/D>25, filtre 23A, histogramme à 70~80%). Avec la même caméra, la magnitude 14 est atteinte en 60ms (même setup sauf que ma cible était uranus). Je ne présume rien des autres modèles mais pour le coup Aptina a fait très fort sur CE modèle.

Marc

[-ms- 2]

En RS l'exposition des pixels est plus longue (voir les zones bleues dans le lien fourni plus haut) donc le capteur est plus sensible que le même capteur utilisé en GS.

La magnitude 14 atteinte en 60ms avec un CMOS Aptina ... mais que reste-t'il aux grandes ?

[chonum 976]

Etant édifié par les deux derniers posts, je vais en resté là...

[patry 1 977]

ms>
Voila mon image pour Uranus http://www.webastro.net/forum/showthread.php?t=110645

Et pour Saturne http://www.astrobin.com/56038/
et http://www.astrobin.com/56039/

Il s'agit de la même image à chaque fois. J'ai seulement joué de l'histogramme pour resserrer la gamme autour des premières valeurs.
Il est évident qu'aucun écran n'est capable de différencier une telle différence de niveau !
Mais ce qui compte c'est de savoir si l'objet arrive à se distinguer du bruit de fond ou pas. Pour moi la réponse est oui et c'est directement lié à la dynamique de la caméra, de son faible bruit de lecture, bref c'est un tout. A vrai dire j'ai essayé de faire la même chose avec un ICX 618 sans y arriver (i.e. en 12 bit, histogramme à 80%). Dans le fond du ciel, il n'y a que dalle !

Marc

[-ms- 2]

Comme je l'ai indiqué plus haut, tu peux très bien atteindre des cibles du ciel profond avec ce type de capteur CMOS en 30ms. L'escroquerie c'est plutôt de dire qu'en dehors de l'EMCCD ou du sCMOS il n'y a point de salut et que l'infortuné astram doit passer son chemin.

D'autres renchérissent en affirmant qu'en dehors d'une électronique haut de gamme et coûteuse, il n'y aussi point de salut pour l'infortuné astram.

Tu as un autre test qui est intéressant c'est l'étoile centrale de M57.

[brizhell 2 671]

Comme le dit Frederic, édifiant...
Ce qui est dommage, reste de perdre la contribution sur ce sujet de quelqu'un de compétent.

Pour le reste, ca se passe de commentaire. en ce qui me concerne, c'est maglré tout dommage d'avoir vu un post au départ interessant, pourri de la sorte.