keymlinux

Bonsoir, 1) pour les offsets on fait des images à faible temps e pose (ici 1/8000 sec), et pour les darks des temps de pose de même durée que les images "light" de l'objet photographi, mais ces images sont NOIRES, donc il n'y a pas d'étoiles à y trouver et donc la FWHM sera de -1, c'est normal Et c'est normal aussi de les traiter sur 1 seul canal monochrome 2) si ce sont tes lights de M101 que tu traites par contre, alors il est nécessaire de cocher l'option "debayer" (dématricer) dans l'onglet conversion et donc tu obtiens des images avec 3 couches couleur EDIT: et quand je regarde ta copie d'écran en detail je ne comprend pas ce que tu fait... - l'image affichée montre des étoiles donc a priori tu traite des lights - mais le message d'erreur dans la log est a priori généré sur le traitement de flats vu que cela tente de lire un fichier flat_00001.fit (dans le cas des flats il faut une normalisation multiplicative) - mais quelques lignes plus bas je vois des temps de pose de 1/8000 sec, qui sert plutôt pour des offsets que pour des flats (sauf si tu fait tes flats avec un éclairage de 200W) EDIT 2: et si ce sont les lights que tu traite, alors le fait qu'il n'y ait qu'un canal montre que tu a oublié de dematricer L'erreur MAD, tu l'as pour les darks, pour les offsets, pour les flats ou pour les light ? Normalement offset et dark on ne fait pas de normalisation, pour les flats c'est normalisation multiplicative, et pour les lights c'est normalisation additive

Si on enlève les problèmes déjà annoncés dus a l'absence de DOF, moi ce qui surprend c'est que sur un empilement de 36 images il y ait la trace d'um passage de satellite... Tu est sût de ton empilement ? De plus im me semble qu'empiler des images avec différents temps de pose/gains ce n'est pas la bonne façon de faire pour par exemple décramer le coeur d'une galaxie Normalement on fait un empilement séparé pour chaque temps de pose (donc en ayant suffisamment d'images pour chaque temps de pose), et on fusionne ensuite pour faire un semblant de HDR Un conseil, empile les 30 images de 180s gain 100 et pour le moment ignore les 6 autres Si l'image que tu pose est la version RVB alors c'est suspect, elle semble monochrome, tu a bien coché l'option debayer sous Siril ? (la camera 2600MC est une cam couleur) Cordialement

Bonjour, A une époque je me suis posé les mêmes questionnements, et je me permet de décrire ici les choix que j'ai retenus (et vous êtes libres de ne pas êtr en accord avec ce que je pense 😉) Quand j'ai commencé à pratiquer l'observation sur le terrain, je me suis contrait à ne pas utiliser de monture avec goto (ni même un simple suivi motorisé), parce que "le goto c'est la facilité" et cela ne permet pa d'apprendre le ciel. Rien ne vaut le saut d'une étoile à une autre avec un atlas sur les genoux (si vous avez l'impression que cela tient un peu de l'intégrisme anti GOTO c'est voulu 🙂 ). Et je ne regrette pas ce choix, mail il est vrai qu'il faut être motivé, car on galère pas mal à trouver l'objet tant recherché. Il st vrai que cela peut rebuter les débutants les moins passionnés (quoi, on a galère 2 heures pour trouver la galaxie tartempion et tout çà pour voir une pauvre tachouille floue ? et le matos fini sur le bon coin...) Par contre, dans le cadre d'une approche purement astrophotographique ce qui est important c'est de poser le maximum de temps pour emmagasiner du signal. Vu que la météo limite le nombre de soirées exploitables, vu que je dois faire 1h de trajet pour aller sous un ciel correct (pas exceptionnel, juste correct), vu que selon les saisons la nuit peut être courte, si je doit passer 2 heures à trouver l'objet recherché et à peaufiner le cadrage, et bien la session d'imagerie va se réduire à peau de chagrin. Et là je n'hésite pas comme certains l'on déjà exprimé ici à automatiser un maximum mon process d'imagerie. - la monture motorisée pilotée par un ordi (un raspberry pi) - utilisation de l'astrométrie pour améliorer la précision et le cadrage (pratique pour les cibles où il faut cumuler les sessions sur plusieurs nuits, pour retrouver le même cadrage) Voila, ma pratique de l'observation et de la photos sont très éloignées l'une de l'autre, cela n'empêche pas de m'éclater à pratiquer les deux note: je fais mes sorties astro photo avec un autre membre du club qui lui a commencé la photo a l'époque de l'argentique. Je l'aide sur la partie "informatique" de l'astrophoto, et lui partage sa grande connaissance du ciel Cordialement, Stephane

C'est parce qu'il y a 2 types de rejets différents, l'un qui porte sur la totalité d'une image, l'autre qui travaille sur chaque pixel individuel lors de l'empilement Le premier type de "rejet" (que je préfère appeler "filtrage" pour éviter justement la confusion), vise a ne pas prendre en compte des images jugées mauvaises, que ce filtrage soit manuel (fait par l'opérateur), soit automatique par Siril en donnant les critères tels que la FWHM, la rondeur, le nombre d'étoiles détectées, etc.... Ce filtrage vise à supprimer des images qui par exemple ont subi un problème de mise au point, de suivi (filé d'étoile), de turbulence, etc... Une trainée de satellite sur une image très piquée (fwhm basse) n'est dont pas exclue automatiquement par Siril, mais peut l'être par un opérateur humain...(à mon avis à tort) Une fois le filtrage effectué, les images retenues vont être empilée, et là c'est l'algorithme d'empilement qui va effectué un rejet des pixel deviants, et ici il ne s'agit pas d'exclure une image en totalité, mais bien d'analyser chaque pixel, de regarder la valeur qu'il a sur chaque photo à empiler, et ne retenir que ceux qui ne s'eloignent pas trop de la moyenne (par défaut l'algorithme utilisée c'est Winsorized sigma clipping). Et c'est cet algorithme qui permet de réduire le bruit et les trainées de satellites qui par nature vont éloigner la valeur du pixel de celle du signal (qui lui sera a peu près constant sur chaque image) Si tu as 100 photos, même si 50% d'entres elles ont un passage de satellite, il est très peu probable que sur les 50 photos concernées les trainées soient sur les mêmes pixels (sauf si des starlink se suivent à 30 secondes d'intervalle pile sur la même orbite !). Lorsque l'algorithme va (pour chaque pixel) calculer la moyenne des valeur sur les 100 photos, les valeurs pour les pixels contenant un passage de satellite seront très éloignés de la moyenne et la valeur aberrante sera éliminée. note: quand je parle de pixel de l'image qui sont comparés, l'algorithme tient compte du fait qu'entre chaque image on peut avoir bougé le capteur (par exemple avec du dithering), et ils se sert des décalage calculés à l'étape d'alignement (register) pour comparer les pixels à l'étape empilement (stack) Plus d'infos sur l'empilement ici: https://siril.readthedocs.io/fr/latest/preprocessing/stacking.html edit: ou encore ici https://ciel-astro-ccd.com/wp/methodes_de_compositage/

Pour la FWHM, oui, c'est bien de filtrer, et c'est normal qu'elle varie en cours de nuit, mais cela n'est pas du à la temperature du capteur (la temperature du capteur va augmenter le bruit) Elle va dépendre d'une part de l'évolution de la qualité du ciel au cours de la nuit (taux d'humidité, turbulence), et cela on ne peut pas y faire grand chose, mais d'autre part elle va aussi dépendre de l'évolution de la temperature ambiante au cours de la nuit, qui va causer une dilatation (si le temp augmente) ou une contraction du tube du telescope, et donc faire varier la mise au point. Pour limiter cet effet, il faut refaire la MAP plusieurs fois au cours de la séance (c'est plus facile avec une focuseur électrique et un soft qui automatise le process en calculant la FWHM de étoiles pour trouver la MAP optimum) Pour le filtrage des images, moi à ta place je ferais un test en faisant un empilement en conservant les images où il y a des passages avions/satellites, et en n'enlevant que celle ou il y a un éventuel défaut de suivi avec un filé d'étoile (qui peut aussi être dû à une rafale de vent), mais ce cas là devrait être filtré avec la FWHM des étoiles. Si tu as 20% des images qui sont bien nettes avec juste un passage de satellite cela serait dommage d'éliminer tout ce temps de pose alors que l'algo de rejection à l'empilement se chargera d'éliminer les pixels déviants qui contiennent les trainées, mais garder les autres pixels qui contiennent le signal si précieux et si difficile à obtenir... Cordialement

Bonjour, Belle progression, et puis comme cela cela te fait une version avec la supernova 2023ixf et une sans... 🙂 J'ai 2 questions: - pour la mise au point, tu utilises un masque de bahtinov ou bien c'est au jugé avec le live view ? (et du coup Siril te donne quoi comme FWHM pour tes brutes ?) - quand tu dis qu'il y a 20% d'image rejetée, c'est toi qui le a exclues manuellement après visualisation ?, cela me semble dommage de les exclure totalement. Je dis cela car moi je laisse les photos avec passage de satellite (sinon c'est plus de 50% que je dois jeter sur des poses de 120s ou 180s), et je compte sur l'algorithme de rejection de Siril pour éliminer ces trainées qui par definition ne se trouvent pas sur toutes les images. (mais ne suis pas sûr que mon choix soit le meilleur...) Cordialement

Bonjour, Sur le fond, oui cela existe, voir ici https://www.pierro-astro.com/materiel-astronomique/accessoires-astronomie/accessoires-t2/bague-adaptatrice-t2-vers-m48_detail Sur la forme je partage l'avis de @schizophrene Cordialement, Stéphane

@JMDSommeBonjour. Tu ne precise pas si tu utilises un Windows version 10 ou 11, ni si tu utilise l'option "liens" au lieu de copier de fichiers des options de Sirilic Si tu utilise les liens, sous windows cela implique d'activer un mode développeur que la mise à jour windows a certainement changé. Tu devrais essayer: - de changer l'option "utilisation de liens symboliques" dans Sirilic (la désactiver) - si tu souhaite garder cette option, il faudrait réactiver l'option mode développer de windows (je ne peut pas te dire comment, je suis sous MacOS) Et si rien ne marche, abandonne Windows et passe sous linux ou MacOs Cordialement

Bonjour. Concernant la diffusion des chaines TV, de nombreux paramètres entrent en ligne de compte, et pa seulement le temps d'un aller/retour vers l'orbite géostationnaire. Le passage au numérique avec les temps de traitement liés à l'encodage/compression à la source, et le décodage/décompression à la destination entraine de nombreux délais additionnels. Quelques infos ici https://www.lesnumeriques.com/disque-dur-multimedia/decalage-tv-et-latence-comment-ne-plus-voir-les-buts-en-retard-lors-des-matchs-de-foot-a191723.html EDIT: je cite ce site juste pour info, parce que personnellement je n'aime pas le foot, alors le décalage des buts je n'en ai rien a f...

Bonjour, Ta lunette de visée de chasse dispose de 2 anneaux de support qui ont normalement une base de serrage au format "picatinny" de 21mm de largeur C'est aussi ce format qui est utilisé pour les chercheurs point rouge que l'on utilise en astro, il il existe des adaptateurs entre ce format "picatinny" et le format "mini-vixen" utilisé pour les chercheurs sur nos lunettes/telescopes exemple ici (je n'ai pas le lien avec Pierro, on trouve ce genre d'accessoires sur autres sites astro): https://www.pierro-astro.com/materiel-astronomique/accessoires-optiques/chercheurs/pied-metal-pour-viseur-point-rouge_detail Important: habituellement ta lunette est fixée sur un fusil avec 2 anneaux, mais sur l'adaptateur de chercheur de ton telescope tu ne pourra en utiliser qu'un, donc vu la longueur de ta lunette de visée la rigidité de la visée va être compromise...

Si on a droit à un léger hors sujet, alors je présente la photo suivante, prise le 19 juillet 2020 vers 5h, juste un peu avant le lever de soleil. Après une nuit astrophoto j'étais en voiture sur le chemin du retour pour aller me coucher, en voyant le croissant de lune je décide de me garer et d'immortaliser la scène.. Canon 80D + Sigma 105mm ouvert à f2.8, pose de 1/60sec 5400iso

Oui, avec l'altitude et la limpidité de l'air qui va avec cela aide. Mais je n'ai jamais réussi à faire de photos de ciel étoilé en avion, et comme toi je reste dubitatif sur certaines photos "astro" prises depuis des hublots d'avion que l'on trouve sur le net. Une petite dernière, prise soleil couchant, mais le vrai objectif c'était la comète Néowise, pas le ciel du soleil couchant... Canon 80D + objectif Sigma 30mm ouvert à 2.8, pose unique de 4 secondes à 800iso, juillet 2020

J'en ait quelques uns aussi... Au bord des étangs, à Draveil (91) (avec en prime une petite lune sur l'une des photos....) Prises depuis un avion Cordialement

@m27trognondepomme j'ai trouvé un contournement dans le fichier "callbacks.py" de sirilic, ligne 886 en remplaçant result = subprocess.run( editor+" "+ script, capture_output=True, text=True ) par result = subprocess.run( editor+" "+ script, capture_output=True, text=True , shell=True ) note: je n'ai pas trouvé tout seul, voir ici https://github.com/pyinstaller/pyinstaller/issues/4859 MacOs c'est que du bonheur... 😉 note: cela fonctionne avec ou sans le chemin complet pour la commande "open" donc ce n'était pas un problème d'env PATH

@m27trognondepomme 1) Cela ne fonctionne pas (voir ci dessous la log). Je suspecte un problème d'environnement PATH pour les commandes lancées par python, il faudrait tester en utilisant le chemin complet de la commande "open" /usr/bin/open -a TextEdit /path/file.ext au lieu de open -a TextEdit EDIT: testé, cela ne fonctionne pas non plus en mettant le chemin complet. En fait je pense que cela viens du fait que l'on demande à python de lancer la commande "/usr/bin/open -a TextEdit /path/file.ext", alors qu'en fait dans la commande il ne devrait y avoir que "/usr/bin/open" et le reste "-a TextEdit /path/file.ext" devrais être mis dans le tableau des arguments de la commande La log: Traceback (most recent call last): File "/usr/local/lib/python3.10/site-packages/sirilic/lib/callbacks.py", line 120, in <lambda> i_gui.Bind(wx.EVT_MENU, lambda evt: self.CB_run(evt,True), id=gui.myID_EDIT_RUN ) File "/usr/local/lib/python3.10/site-packages/sirilic/lib/callbacks.py", line 886, in CB_run result = subprocess.run( editor+" "+ script, capture_output=True, text=True ) File "/usr/local/Cellar/python@3.10/3.10.10_1/Frameworks/Python.framework/Versions/3.10/lib/python3.10/subprocess.py", line 503, in run with Popen(*popenargs, **kwargs) as process: File "/usr/local/Cellar/python@3.10/3.10.10_1/Frameworks/Python.framework/Versions/3.10/lib/python3.10/subprocess.py", line 971, in __init__ self._execute_child(args, executable, preexec_fn, close_fds, File "/usr/local/Cellar/python@3.10/3.10.10_1/Frameworks/Python.framework/Versions/3.10/lib/python3.10/subprocess.py", line 1847, in _execute_child raise child_exception_type(errno_num, err_msg, err_filename) FileNotFoundError: [Errno 2] No such file or directory: 'open -a TextEdit /Users/stephane/Pictures/Siril/script/sirilic.ssf' 2) autre problème qui n'a rien à voir avec l'edit. Suite à la modification du paramètre "pixelsize" pour la commande "setfindstar", on peut désormais le saisir avec 2 digits après la virgule, mais dans le fichier projet il est enregistré arrondi avec 1 digit seulement (mon 3.75 deviens 3.8)

Sur MacOS c'est TextEdit. Pour ouvrir un fichier avec il faut lancer la commande "open" en spécifiant l'application "TextEdit" ex: open -a TextEdit /path/file.ext Si on essaie de lancer la commande avec son chemin complet de binaire pour ouvrir un fichier (comme on le ferait avec "vi") cela ne fonctionne pas ex: /Applications/TextEdit.app/Contents/MacOS/TextEdit /path/file.ext Cordialement

Bonjour @m27trognondepommej'ai fait différents tests avec la version 1.15.2xx1, cela me semble OK. Merci. Concernant l'ajout d'un éventuel bouton edit&run, je suis pour. Il y a bien la possibilité d'afficher le script (ce qui le génère sur disque), pour ensuite éditer avant lancement manuel avec siril en ligne de commande, mais un bouton edit&run permettrait d'éviter de se taper la ligne de commande. Cordialement, Stéphane

Bonjour, Effectivement ce logiciel est compilé uniquement pour Windows, mais personnellement je l'utilise sous MacOs (10.14 Mojave) en le lançant via Wine (qui existe aussi sous Linux). Cela me permet aussi de lancer L'Atlas Virtuel de la Lune, Registax, Autostakkert, etc... Oui, il fait cette simulation en 2D, pas en 3D Coelix n'est pas très coûteux, et c'est vraiment un soft avec plein de fonctionnalités, mais plutôt calcul d'éphémérides et modélisation 2D (pour tracer des cartes du ciel entre autres). Une des rares modélisations 3D (perspective) disponible dans le soft, c'est par exemple de modéliser la trajectoire d'une comète dans le système solaire (il y e a quelques autres) L'orbite de Venus est effectivement un peu inclinée par rapport au plan de l'écliptique (3.4° environ). Si toutes les planètes étaient strictement dans le même plan, on aurait pour Mercure et Venus des transits beaucoup plus souvent. Pour la modélisation en 3D du système solaire il faut utiliser des logiciels comme Celestia (gratuit et nativement multi OS) https://celestia.space Cordialement

Bonjour, La fente du Solex fait 4,5mm de hauteur. L'image projetée du soleil au foyer de la lunette (donc sur la fente) fait environ focale/100mm de diamètre (approximation). Donc pour avoir le soleil en entier il faut se limiter à une focale entre 420 et 450mm (avec un peu de marge) Personnellement j'ai une lulu 80/500, mais avec le réducteur x0,8 j'ai le soleil en entier, par contre je diaphragme l'entrée du tube pour remonter le rapport f/d à 7. Christian explique cela dans les derniers paragraphes de la page suivante http://www.astrosurf.com/solex/sol-ex-theorie.html Et comme vous j'ai fait en impression 3D un support pour le filtre ND, et qui me sert aussi à faire varier le diamètre d'ouverture pour ajuster le rapport FD. @Discret68tes filetages imprimés sont superbes. Le bouchon porte filtre pour la lulu Avec le capuchon pour protéger le filtre La vue coté intérieur avec les bagues empilables pour faire varier le diamètre d'ouverture (mais cela ne rend pas bien en noir...) Une vue globale du montage avec lulu et solex Cordialement

Bonjour, 1) L'élongation solaire de Venus (angle entre Venus et le Soleil, vus depuis la Terre), est actuellement de près de 38°, et va continuer à croitre jusqu'au 6 juin pour atteindre 45,34° 2) ci dessous l'emplacement de la Terre et de Venus sur leurs orbites respectives autour du Soleil à la date du jour (à noter que le Soleil, Mercure et Venus sont à peu près alignés, mais ce n'es pas l'objet du sujet) 3) La même chose pour le 6 juin (le max de l'elongation sera en fait le 4 juin) A cette date Venus sera a peu près au sommet d'un triangle isocèle rectangle (distance Terre-Venus égale à la distance Venus-Soleil, et vus de Venus la Terre et le Soleil seront à une distance angulaire de 90° environ) EDIT 3) ensuite, après le 6 juin et jusqu'au 13 août l'élongation solaire de Venus va décroître jusqu'a 0° (où venus passera entre la Terre et le Soleil) 4) Puis augmentera jusqu'au 24 novembre pour une élongation max de 46°, mais en novembre cela nous paraitre peut être moins spectaculaire car les journées seront plus courtes, et cette fois ci les observations devrons se faire le matin et pas le soir (Venus se lever avant le Soleil) note: ces schémas sont obtenus avec le logiciel Coelix EDIT 2: Et pour répondre précisent aux questions... a) quel est l'écart maximal entre Vénus et le Soleil --> toujours autour de 45° (pas exactement 45° car les orbites sont des orbites elliptiques et pas circulaires) b) en degrés d'élévation (hauteur --> les planètes ont à peu près leur orbite dans le plan de l'écliptique (je rappelle que Pluton n'est PAS ou plus une planète), donc leur élévation, comme celle du soleil sera maximale au solstice d'été, fin juin (or on va avoir une elongation max Venus Soleil le 6 juin, donc on est proche du meilleur des cas...) c) en temps (durée maxi de coucher de Vénus après le coucher du Soleil) --> vu que dans ces cas l'élongation max est proche de 45°, et comme la Terre tourne sur elle même d'environ 15° par heure, on a un max autour de 3 heures... d) Et ça arrive souvent, un si fort « décalage » on aura juin et octobre 2023, puis janvier et juin 2025 on connaît l'orbite de la Terre et celle de Venus, un matheux vas bien nous calculer la périodicité, mais là je déclare forfait... La table ci dessous générée par le logiciel Coelix, pour les elongations max de Venus et Mercure sur les 36 prochains mois Plus grandes Èlongations de Mercure et de VÈnus Les temps sont donnÈs en heure normale pour Juvisy (2∞ 22' 19" E, 48∞ 41' 30" N, zone A). Cliquez dans une cellule donnant l'heure pour voir le phÈnomËne ‡ ce moment. Date Heure PlanËte …longation A. D. DÈcl. Const. Lever Passage Coucher aaaa mm jj hh:mm ∞ gÈocentrique gÈocentrique hh:mm hh:mm hh:mm 2023 04 11 18:00 Mercure 19,3∞ E 2h 30m 11,1s +17∞ 38' 45" Ari 06:35 14:02 21:31 2023 05 29 06:00 Mercure 24,7∞ O 2h 46m 22,0s +12∞ 21' 21" Ari 04:10 11:11 18:13 2023 06 04 18:00 VÈnus 45,3∞ E 8h 7m 34,0s +22∞ 48' 42" Cnc 08:08 16:06 00:06 2023 08 10 00:00 Mercure 27,4∞ E 11h 0m 10,2s +4∞ 35' 19" Leo 08:15 14:37 20:59 2023 09 22 12:00 Mercure 17,8∞ O 10h 52m 25,5s +8∞ 3' 31" Leo 04:58 11:39 18:19 2023 10 24 00:00 VÈnus 46,4∞ O 11h 0m 18,3s +6∞ 12' 34" Leo 03:11 09:43 16:13 2023 12 04 18:00 Mercure 21,2∞ E 18h 15m 13,0s -25∞ 35' 52" Sgr 10:21 14:12 18:04 2024 01 12 18:00 Mercure 23,5∞ O 17h 53m 38,1s -21∞ 50' 53" Sgr 07:02 11:17 15:32 2024 03 24 18:00 Mercure 18,6∞ E 1h 21m 52,9s +11∞ 11' 8" Psc 07:08 14:02 20:57 2024 05 09 18:00 Mercure 26,2∞ O 1h 31m 8,7s +6∞ 9' 23" Psc 04:39 11:10 17:41 2024 07 22 06:00 Mercure 26,9∞ E 9h 54m 50,7s +11∞ 42' 37" Leo 07:46 14:43 21:39 2024 09 05 06:00 Mercure 18,1∞ O 9h 49m 31,3s +13∞ 13' 1" Leo 04:36 11:41 18:46 2024 11 16 12:00 Mercure 22,4∞ E 17h 2m 18,3s -25∞ 25' 17" Oph 10:16 14:09 18:02 2024 12 25 06:00 Mercure 22,0∞ O 16h 42m 52,2s -20∞ 11' 15" Oph 06:52 11:17 15:41 2025 01 10 12:00 VÈnus 47,2∞ E 22h 38m 10,9s -9∞ 18' 18" Aqr 10:48 16:08 21:29 2025 03 08 00:00 Mercure 18,2∞ E 0h 18m 20,4s +3∞ 57' 39" Psc 07:43 14:05 20:28 2025 04 21 18:00 Mercure 27,3∞ O 0h 20m 38,6s -0∞ 28' 34" Psc 05:11 11:11 17:12 2025 06 01 00:00 VÈnus 45,8∞ O 1h 35m 23,8s +7∞ 38' 18" Psc 03:09 09:47 16:26 2025 07 04 06:00 Mercure 25,9∞ E 8h 43m 23,5s +18∞ 8' 40" Cnc 07:13 14:44 22:13 2025 08 19 12:00 Mercure 18,6∞ O 8h 41m 23,9s +17∞ 23' 58" Cnc 04:13 11:40 19:07 2025 10 30 00:00 Mercure 23,7∞ E 15h 50m 46,2s -23∞ 3' 17" Sco 10:00 14:07 18:14 2025 12 08 00:00 Mercure 20,6∞ O 15h 34m 56,1s -16∞ 52' 45" Lib 06:36 11:18 15:59 2026 02 19 18:00 Mercure 18,1∞ E 23h 18m 14,2s -3∞ 12' 56" Aqr 08:23 14:10 19:59

@m27trognondepommeMerci pour ta réactivité. La correction permet bien l'ajout de la commande "setfindstar" dans le script, mais les paramètres ne sont pas les bon La ligne ajoutée est setfindstar 1.0 0.5 -layer=0 Ce qui génère une erreur la syntaxe devrait être setfindstar -sigma=1.0 -roundness=0.5 -layer=0 En fait cela devrait même être la ligne suivante vu que dans les options disponibles dans l'interface j'ai changé les valeurs pour la focale (modifiée de 0 à 500) et la taille de pixel (modifié de 0 à 3.7) setfindstar -sigma=1.0 -roundness=0.5 -layer=0 -focal=500 -pixelsize=3.7 EDIT (pas de dysfonctionnement, juste une demande d'amélioration): 1) dans le script généré, il serait bien d'insérer une commande "setfindstar" sans paramètres juste avant le register, comme cela cela farsait apparaitre dans la log d'execution les valeurs de paramètre en vigueur 2) concernant le paramètre de taille de pixel pour le setfindstar, il faudrait pouvoir saisir 2 digit apr!ès la virgule, actuellement l'interface limite à 1 digit Cordialement

@m27trognondepommeBonsoir, je confirme c'es OK pour les fichiers compressés et le drizzle. Par contre nouveau problème, dans l'onglet "propriétés", sous onglet "plus de propriétés", si je coche l'option "Détection d'étoiles" alors dans le script généré après la generation des masters dark/flat il manque les commandes register et stack Ci joint mon fichier projet et le script généré. A priori entre "#TAG#} [3]" et "#TAG#{ [4] ... Terminé ..." il manque des choses sirilic.ssfM81_M82_test.prj

Bonjour, - Dans la doc de la 294MC il est indiqué qu'il est préconisé d'utiliser une alimentation 12V 5A, mais dans les fait tu ne consommera jamais 5A, si on observe la courbe de consommation en fonction du refroidissement choisi on plafonne à 1.8A (peltier+ventilateur, sans la resistance chauffante anti buée), mais même avec l'anti-buée je ne pense pas que cela consomme au total plus que 2.5A sous 12V - Pour la 120mini, elles est alimentée en 5V via un port USB 2.0 (donc conso max 0.5A sous 5V), donc théorique max 2.5W (la doc indique une consommation réelle max de 1.85W) donc sur du 12V on sera à moins de 0.2A - Si par auto focuser tu parles de l'EAF, il est annoncé pour une consommation max de 0.5A en 12V Donc a mon avis avec une alimentation 12V 7.5A c'est largement suffisant Cordialement

Absolument, car en gardant les lights et DOF, on peut refaire les traitements et post traitements donc si on doit garder quelque chose ce sont bien les images sorties de l'APN/CAMERA-> du temps pour refaire les traitements informatique on peut en trouver, alors que refaire des captures c'est plus compliqué (surtout si on vit dans une coin avec une meteo aléatoire) Et éventuellement on peut faire du multi session si on reviens sur un même objet l'année suivante...