alx

Le diagramme ci-dessus (montré par @Adlucem) me ferait plutôt penser à un remplacement par les mammifères, plutôt qu'à une simple disparition des dinosaures. Et remplacement assez brutal puisqu'à égalité avec les mammifères en -67 millions d'année, les proportions d'avant s'inversent complètement en un petit million d'années, semble-t-il. Une compétition à moyens de survie constants ? alx.

J'utilise la même technique que Nicolas (mais en moins osé !) puisque mon Dobson (SW 305 flextube) ne permet pas un suivi assez précis pour imager quoi que ce soit en pose lente. Il y a donc forcément une dérive, chez moi moins importante (typiquement quelques secondes d'arc par seconde de temps), mais qu'il est facile de compenser par un recentrage numérique (en temps différé (Astrosurface, etc...) ou en temps réel (''live stacking'')). Ce qu'il faut comprendre, c'est que l'interpolation bilinéaire d'une image (l'opération mathématique utilisée dans ces algos) ne dégrade pas le rapport signal à bruit puisque la variance de l'image y est conservée. On ajoute juste du bruit de lecture, négligeable avec les CMOS modernes. Le défilement de Nicolas (par rapport à un suivi rustique) réduit juste le champ utilisable après traitement de chaque film. alx.

Autrement, j'ai effectué un suivi de T CrB chaque soir (au crépuscule) de ces mois de juillet et août (quand le temps le permettait !) avec un objectif de 50 mm et la caméra ASI120 (videos de 200x1seconde, champ d'un peu plus de 1°, magnitude limite ~12). Certains soirs, il n'y a eu aucun passage de satellite enregistré. D'autres soirs, les plus nombreux, il y a eu jusqu'à un passage toutes les ~30 secondes (dans des directions variables, donc pas seulement des cochonneries à Musk). La distribution des visibilités de passage, depuis un site donné, n'est donc certainement pas aléatoire. Elle s'est aussi grandement densifiée depuis l'été dernier. alx.

Bonjour, Le "soir" des Perséides (vers 22h TU) j'ai fait un test d'un quart d'heure avec une caméra ASI120 et un objectif "fish-eye''', donnant à eu près le rendu visuel (magnitude limite ~6) dans une bonne partie du ciel au-dessus de chez moi (Bretagne, sans lumières parasites). Résultat: 17 passages de satellites, 2 avions et une étoile filante... alx.

Je ne suis pas sûr que cela soit toujours vrai. Pour les caméras que je connais (ASI120 et ASI533 de ZWO), le débit est contrôlé par la trame de lignes (horloge), quels que soit le nombre de colonnes ou la taille du pixel. Pour la 533, par exemple le nombre de lignes par secondes est de 60000, ce qui donne 20 fps pour une hauteur d'image de 3008 pixels . Acquérir en 8 bits ou 16 bits n'y change rien. Les faibles contrastes (faibles différences d'intensités mesurés en adu) résident dans les bits de poids faibles. Même ''noyés dans le bruit de photons'', ils obéissent à la loi des grandes nombres , et deviennent ''utilisables'' après empilement d'un grand nombre d'images, de bonne qualité statistique. C'est à mon avis important dans le cas de l'imagerie planétaire (Jupiter, Saturne). Dans le cas de l'imagerie solaire (pour laquelle je n'ai aucune expérience ), j'ai le sentiment que le contraste est toujours plutôt fort en comparaison.

Pourquoi ? Au gain de 100, une IMX533 par exemple, échantillonne parfaitement le FW disponible sur 14 bits. Ce serait bête de s'en priver. S'il s'agit simplement d'économiser de la place sur disque, il vaut mieux effectuer l'acquisition sur un disque en compression automatique.

Les choses se simplifient si l'on admet que le bruit de lecture est effectivement négligeable, ce qui me semble être le cas avec ces caméras de dernière génération. En effet, le rapport signal à bruit ne dépend alors plus du gain puisque le bruit effectif est le bruit photonique dont la variance est égale au signal. Le meilleur ''remplissage de l'histogramme'' n'est plus à rechercher non plus puisque l'erreur d'arrondi entier (variance 1/12) est elle aussi négligeable. On peut donc travailler à gain faible: le rapport signal à bruit final ne va plus dépendre que de la cadence et du nombre d'images finalement empilées. Le seul critère qui reste à respecter est d'éviter d'introduire des non linéarités avant l'empilage, donc de régler correctement la dynamique pour éviter toute saturation, ce qui va dans le sens d'utiliser un gain faible (à moduler pour les caméras qui ont deux réglages de gain différents).

@George Black: je suis d'accord avec l'essentiel de votre message et l'image de l'iceberg est bien trouvée. Mais ici, mon constat est qu'il s'agit plutôt d'une fusée de trop. Et la question sous jacente est: pourquoi diable chercher un moyen d'extraire ~100 tonnes de charge utile à l'attraction terrestre ? Cela me semble ne se justifier que pour des explorations interplanétaires habitées, dont la faisabilité/utilité reste à démontrer. Est-ce donc pour réaliser un projet faisable/utile ou est-ce poursuivre une chimère ?

Je vais, à dessein de pédagogie, faire un peu de provocation . De quoi s'agit-il ? Une (très) grosse fusée à deux étages, sans charge utile, a atteint l'altitude et la vitesse de mise en orbite, après une séparation réussie, et les deux morceaux sont retombés au sol à vitesse contrôlée, mais sans récupération. Une performance qui aurait sans doute fait date dans les années 1960s. Et où est le génie ? Certes, la centaine d'ingénieurs de très haut niveau (qu'il faut saluer) a formidablement bien travaillé (mais sous le fouet). Et, ici, je n'évoque pas la question de la finalité de l'entreprise, ''la conquête de l'Espace par l'être humain", qui a toujours été un rêve, mais pourrait aussi devenir un cauchemar par excès de démesure. alx.

Cela correspond, je crois, aux flux de rayons X mesurés dans deux bandes (basse et haute) à l'intérieur de la fenêtre 1-8 Angströms. alx.

Bonjour, Sur mon Mele 4Q que je viens juste d'installer, je n'ai pas ce problème. Une solution pourrait être d'augmenter la puissance de fonctionnement limitée d'usine à 8 W, en modifiant les paramètres du BIOS. La façon de faire est documentée sur le site de MELE et dans les vidéos de Cuiv. Alx.

Attention, ce qui est écrit dans le fichier SER n'est pas généré par la caméra (au moins pas par les miennes (ZWO) qui n'ont pas cette capacité). C'est généré par le programme d'acquisition en soustrayant de la date d'acquisition de l'image la durée estimée du transfert. Pour SharpCap, cela m'a été confirmé par Robin Glover, à qui j'ai posé la question.

Je rebondis sur ce sujet de datation d'occultation afin de comparer avec mon expérience personnelle. Si on dispose d'une caméra qui à son propre horodatage, ou qui peut transmettre une synchro (PPS) au PC d'acquisition, il n' y a, en principe, pas de problème. Dans le second cas, on peut vérifier facilement (c'est bien montré ci-dessus) qu'un PC sous Windows peut dater en absolu un événement INTERNE (via PPS ou protocole NTP) avec une précision de l'ordre de la granularité temporelle de l'OS (de l'ordre de la milliseconde sur les PCs modernes). Avec le logiciel Meinberg ou même simplement l'API Windows. La difficulté vient (et c'est mon cas) quand la caméra utilisée n'a pas d'horodatage. C'est bien illustré dans la présentation référencée plus haut dans ce fil. L'inconnue est l'intervalle de temps entre la date (le début) de la pose optique (ce qu'on veut connaître) et le signal de fin d'acquisition en mémoire du PC via l'USB (ce que peut seulement mesurer l'OS). Cet intervalle peut être estimé à partir du débit USB (5 Gbits) et de la taille de l'image (par exemple 10 millions de pixels en 16 bits) , soit quelques dizaines de millisecondes. Auquel il faut ajouter le temps passé dans les électroniques USB côté caméra (''buffering'') et côté PC. Je n'ai pas trouvé de moyen d'en faire une mesure précise. Je croyais en avoir trouvé un en filmant l'écran du PC d'acquisition avec son horodatage interne, mais tout ce que j'ai mesuré c'est le temps de rafraichissement de l'écran (60 Hz) Tout ce qu'on peut dire, c'est que la régularité des temps d'acquisition (compte-tenu de la régularité très probable de l'horloge de ma caméra) semble indiquer que cet intervalle est à peu près constant, et devrait donc pouvoir être mesuré une fois pour toute (à paramètres d'acquisition donnés). Si quelqu'un a une idée. Alx.

Pour nos caméras, je pense que la liaison USB a encore de beaux jours devant elle: L'USB 3.2 (en attendant l'USB 4) débite entre 5 et 10 Gb sur des longueurs honorables (plusieurs x 10m avec un câble actif) . Le câble Ethernet atteint aussi 10 Gb (en câble cat7 ou 8) mais sur des longueurs pas si grandes que ça (~50m typiquement). Quant à la fibre (malgré les pubs incessantes assez trompeuses) elle est limitée à 8 Gb (en FFTH), mais à 1 Gb usuellement. Et ne confondons pas les Gb (bits) et les GB (bytes = octets): 10 Gb par seconde cela fournit en gros 1 Giga octets par seconde. Une caméra 3000x3000 qui débite des mots de 16 bits sature une ligne de 10 Gb à ~30-40 images/seconde. L'avenir serait plutôt, à mon avis, dans le traitement du flux video en temps réel, que nous effectuons actuellement en différé. alx.

Bonjour, Si j'ai bien noté, votre (merveilleux) atlas est écrit en Pascal sous Lazarus. Avec une licence Delphi, il devrait être possible sans trop de travail de produire un exécutable sous Android, directement à partir de vos sources. Il resterait évidemment le problème des mises à jour, pour suivre l'évolution délirante d'Android. Alx.