keymlinux

Merci, mais c'est la raison d'être de ce forum, pourvoir partager nos succès comme nos problèmes Il y a en fait une question que tu as posée et a laquelle je n'ai pas répondu, c'est de savoir "où trouver de l'aide" Et bien ici même, sur Webastro, qui est un forum dédié à la pratique de de l'astronomie (ou aux pratiques, si l'on considère que le visuel, l'astrophoto, l'astrodessin, la spectroscopie, etc... sont autant de pratiques différentes), mais aussi sur le forum d'en face Astrosurf, lui aussi dédié à notre passion Pixels.us est plutôt dédié à la photo en général (pas seulement l'astrophoto), et à l'usage de logiciels libres (dont Siril fait partie) Toute information est bonne a prendre ou quelle se trouve (sauf sur les sites platistes bien entendu 🙂 ) Cordialement

Capture flightradar24 du 23/03 vers 9h50 On voit bien les vols civil, mais rien qui ressemble a un A400M mais je ne suis pas trop étonné, le M de A400M c'est pour Militaire...

Bonjour, J'ai aussi l'impression qu'il s'agit de moteurs a helices L'empenage arrière est en position haute (sur la queue, les surfaces de contrôle horizontales sont placées en haut de la dérive et pas à sa base) Vu l'empennage et la forme des ailes, cela pourrait être un A400M effectivement (grillé par @fox qui a été plus rapide) peux tu poster la photo en resolution native (je doute que ton APN des photos en 600x400) EDIT: si tu as la date et l'heure précise, ainsi que le lieu cela me permettrait de verifier dans flightradar (même si pour un vol militaire c'est pas gagné) Cordialement

Cela a le même effet. L'échantillonnage (en arc seconde par pixel) est proportionnel à la taille du pixel et inversement proportionnel à la focale. Donc si tu auras le même résultat si tu multiplie par 3.5 la taille de pixel ou bien si tu divises par 3.5 la valeur de la focale formule simplifiée: echantillonnage = 206 x taillepixel / focale échantillonnage en arc seconde par pixel taillepixel en microns focale en millimètres Cordialement

Bonjour, Pour Siril, detecter les étoiles en mode linéaire n'est pas un problème. Et donc oui, la correction de colorimétrie par photométries ce fait bien a l'étape du traitement linéaire avant étirement de l'histogramme Avec auto-ajustement En mode lineaire Pour tester la detection d'étoilée, aller dans le menu hamburger (les 3 lignes horizontales en haut a droite), puis sous menu information de l'image, sous menu PSF dynamique Ton problème ce n''est pas la detection des étoiles, c'est le calcul des distances angulaires entre elles L'image FIT contient des informations sur la focale et la taille de pixel qui vont permettre à siril de connaitre l'échantillonnage en arc seconde par pixel Dans l'image de M51 il y a des pixels de 3.75 microns, et une focale de 1260 (le C8 avec réducteur) Le problème c'est que l'image n'a plus sa taille d'origine 6000x4000 environ mais 1920x1080, soit environ 3.5 fois plus petite en X et Y (en fait 3,25x plus petite en X et 3,86x plus petite en y) Tu peux réussir une astrométries en changeant la valeur de taille de pixel et la passer de 3.75 à 13.16 (=3.75x3.5) pour que Siril retombe sur ses pieds Ci dessous la resolution astrométrique réussie de ton image... EDIT: - avant de lancer la resolution la valeur de focale renseignée était de 1260, issue de ton image - après calcul cette valeur est corrigée à 1446, car le multiplicateur réel du réducteur va varier avec son éloignement/raprochement (sur un C8 la focale va varier avec le déplacement du miroir primaire, donc avec la mise au point) Cordialement, Stéphane

Bonjour. J'ai eu le même problème, que j'ai résolu en baissant le pas initial à 100 (donc non, 200 ce n'est pas trop peu, cela depend...) Sachant que lors du déplacement initial il applique un multiplicateur (x4 chez moi), donc déplacement initial=400 (cela serait 800 dans ton cas) Le déplacement initial causait une telle délocalisation que les étoiles étaient des patates (que l'algo ne prend plus en charge pour le calcul de HFR) et au final je le soupçonne de faire le calcul sur des pixels chauds --> plus tu es dans les choux sur la mise au point et plus tu obtiens un calcul HFR qui est bon, c'est du n'importe quoi Dans la capture d'écran ci dessous réalisée le 28/11/2024 (ED80 equinox + réducteur x0.8 + EAF) Mise au point par itérations manuelles au pas 8600 Je démarre la mise au point auto, premier déplacement vers l'extérieur qui me positionne à 9000 Puis itération par pas de 100 vers l'intérieur (la HFR est calculée plus petite à 9000 qu'a 8900 ou 8800, cela part mal) A partir de 8700 (iteration 4) il commence a me calculer une hfr plus petite (ouf), qui remonte a la position 8400 (itération 6) A la fin de la mise au point auto il me trouve un minimum à la position 8538 (mon positionnement initial n'était pas loin du focus) note lors de ma dernière sortie du 17/03/2025 j'ai finalement encore réduit le pas initial à 50 au lieu de 100... Cordialement, Stéphane

Viens en region parisienne, avec la météo ici on est pas bousculé par les sorties astro... 😭 J'avais bien vu, mais si je dois scripter alors j'ai l'impression d'être au boulot 😇 Ce qui me plait (entre autres) dans Sirilic c'est qu'avec quelques clics de souris cela génère un script complet pour le pré-traitement, je lance çà mouline 1/2h à 1h mais pendant ce temps je fais autre chose, si je dois faire le pré-traitement à la main dans Siril je m'arrache les cheveux (ergonomie discutable) D'ailleurs dans les versions de dev 1.3.x il y a désormais un python embarqué (python 3.12 avec la 1.3.6) et la possibilité de lancer directement des script python pour interagir avec Siril (au 1er lancement Siril créé un "venv" et installe des packages dont "sirilpy", à priori un équivalent de ton package "pysiril") . D'où une question, en terme d'evolution de Sirilic, vas tu continuer à générer des scripts "ssf" avec les commandes de bases de Siril (suffisant pour la majorité des usages), ou bien dans le futur va tu générer des scripts python ? (pour quelque cas d'usage comme par exemple certaines commandes siril qui n'agissent pas sur des sequences mais sur des fichiers uniques et pour lesquelles il faut actuellement scripter des boucles en shell unix ou powershell windows) Cordialement

Salut @180Vision. J'ai fait des tests de sirilic avec la version 1.3.6 de siril et pour les fonctionnalités que j'utilise je n'ai pas noté de problème (mais je ne fais que du OSC, pas de HOO ou SHO ... donc j'ai pas tout testé...) Par contre dans siril 1.3.6 il y a des fonctionnalités nouvelles qui m'intéressent (je pense que c'est pareil pour toi 😉) et que je souhaiterais scripter via sirilic (comme extraire le gradient via graxpert sur la sequence avant le stack, ou bien encore faire une extraction d'étoile via starnet sur la sequence, puis faire le stack sur les starless, etc...) et pour cela pour le moment il faut se fader le script à la main en attendant l'integration de ces fonctionnalités dans sirilic Mais j'ai déjà donné un peu de boulot à @m27trognondepomme pour adapter les plugins pyGapM27 pour Gimp 3 (la release candidate RC3 est dispo, la version finale va bientôt sortir) Cordialement

Bonjour, je pense avoir trouvé le "problème"... Par défaut lorsque l'on ouvre une image avec asifitsview il fait une balance de blancs (WB) et un étirement (stretch) (y compris sur une image non linéaire...) Une fois l'image fit ouverte avec asifitsview, il faut afficher l'histogramme, cliquer sur le bouton WB pour désélectionner la balance des plans auto, cliquer sur le bouton "auto stretch" pour désactiver l'étirement auto, puis cliquer sur "reset stretch" pour qu'il affiche l'image en annulant les motifs qu'il a faites à l'ouverture. Ensuite on peut enregistrer le jpeg, et on obtiendra la même image que le jpeg enregistré par Siril Cordialement Quelques tests: image FIT d'origine, fit 32bits 1.25 Go image JPEG exportée avec SIRIL, qualité compression 100, fichier 76 Mo image JPEG exportée avec ASIfitsview (avec WB et stretch), fichier 80 Mo image JPEG exportée avec ASIfitsview (après avoir annulé le WB et stretch), fichier 76 Mo les stats sur cette dernière image sont proches des stats du jpeg généré par siril

C'est pour nous préparer psychologiquement au fait que le prix va piquer les yeux... 😇

Non cela ne reviens pas au même car le dark ne contiendra qu'un peu de signal thermique et un peu de bruit, alors que la brute contiendra du signal venant du ciel, un peu de signal thermique et un peu de bruit. Le but étant de poser assez longtemps pour que le signal venant du ciel arrive a devenir non négligeable par rapport au reste, ce qui permettra de garder des valeur positives lors de la soustraction du dark si au lieu de daphragmer à f/8 tu diaphragme à f/5.6 alors du captera 2 fois plus de lumière (donc 20s à f/8 équivalent environ 10s à f/4 en terme de signal) Si ne veux pas (ou ne peux pas) poser trop long, dans ce cas augmente l'ouverture (réduit le x du f/x). Fais des poses de 20s mais à f/4 au lieu de f/8 tu aura 4 fois plus de signal venant du ciel, sans augmenter le signal thermique (qui lui va dépendre du temps de pose) Un filtre ND atténue toutes les longueurs d'ondes (ou couleurs), ici on parle d'un filtre qui va faire un tri et atténuer de façon différente les longueurs d'ondes (filtre interférentiel). Le L-extreme, tu peut considérer qu'il laisse passer moins de 1% (voire 0.1%) des longueurs d'onde qu'il bloque, et il laisse passer à environ 92% de transmission les longueurs d'ondes autour du Ha et du OIII --> c'est ce qu'indique globalement le diagramme que j'ai posté, dans l'axe des x (horizontal) il y a les longueurs d'onde, en y (vertical) il y a le % de transmission) Cordialement

Salut, Désolé, je n'avais pas vu ta réponse de samedi, voici quelques éléments de réponse Le filtre L-extreme est un filtre dual bande, il laisse passer le rouge autour de la longueur d'onde du Ha, et le bleu/vert autour de la longueur d'onde du OIII. Le problème c'est que si tu utilises pour les flats une source lumineuse intense dans le bleu/vert et peu lumineuse dans le rouge (comme la plupart des panneaux leds), alors ton flat peut être saturé dans le vert, normal dans le bleu et manquant de rouge Voici le spectre que laisse passer le filtre l-extreme Et pour info voici le spectre de la source lumineuse que j'utilise pour les flats. Je n'utilise pas encore de filtres très selectifs, mais cela va venir et je vais avoir le même problème que toi pour faire des flats Il faut que les darks aient le même temps d'exposition que la brute, avec même gain et offset. Il ne faut pas réduire le durée du dark, il faut augmenter la durée d'exposition de la brute pour que son signal se retrouve bien différencié des dark) Poser 20 secondes avec un filtre aussi sélectif que le l-extreme cela me semble trop peu,, même avec un objectif très ouvert (tu as écrit 135mm à f/8, c'est bien f/8 ou tu voulais écrire f/1.8 ou f/2.8, car f/8 c'est tout sauf lumineux, il faudrais plutôt viser des poses à 2 ou 3 minutes avec ce filtre, par contre avec f/1.8 ou f/2.8 là oui, c'est très ouvert et peut être que 20 ou 30 secondes suffisent, mais cela me parait peu, mais je manque d'experience à ces ouvertures) Perso j'utilise kstars, mais je n'utilise pas la calibration auto des flat, je fais des tests pour trouver la durée idéale à la main. Le truc qui me semble prioritaire à faire pour utiliser le mode auto sans qu'il s'emmêle les pinceaux c'est d'avoir une source de lumière plus équilibrée, et donc avec plus de signal rouge Le filtre est très selectif. si tu considère que le spectre visible c'est entre 400 et 700nm, soit une largeur de 300 nm, le filtre laisse passer 7nm autour du Ha et 7nm autour du OIII, donc 14 sur 300, on est plutôt à 95% d'absorption en moyenne. Cela ne veut pas dire qu'il faut multiplier le temps de pose par 20, mais cela me conforte dans l'idée que 20s de pose c'est trop peu C'est bien d'avoir vérifié, mais je ne pense pas que cela soit un problème de balance des canaux, plutôt un problème de déséquilibre de la source lumineuse (lumière blanche un peu froide, qui tire sur le bleu et manque de rouge) Je ne suis pas sûr, mais je pense que les valeurs écrêtées sont liées aux étoiles qui saturent vite. En tout cas 20secondes à f/8 avec un filtre el-extreme on est pas en sur-exposition (si tu as un objo f/1.8 ou f/2.8 cela se discute effectivement) Il est préconisé d'avoir le filtre au plus près du capteur, donc cela me semble parfait. Je reste sur l'idée qu'il faut augmenter le temps de pose sur les brutes Il est dommage qu'il n'y ait pas d'utilisateur de la même camera qui se manifeste (ma cam est différente, on ne peux pas vraiment comparer, chaque capteur a ses spécificités) Cordialement, Stéphane

Bonjour, Je me permet de m'auto citer vu que j'ai écrit une ânerie 1) J'ai dit que je trouvais ton master dark non cohérent car avec une valeur min 2 fois supérieur à celle des dark unitaires. En fait je suis dans l'erreur c'est cohérent, les valeurs les plus basses sont rejetées comme les plus déviantes à l'empilement, et il est normal que la valeur min du master dark tende à se rapprocher des valeurs moyennes et médianes. - sur ton dark unitaire on a un min entre 400 et 500 et des valeurs moyennes et médianes de l'ordre de 1100 - sur le master dark le min est aux alentour de 1000, mais les moyennes et médianes sont a environ 1100 -- le problème (comme 5 mois plus tôt) est que sur tes brutes les valeurs moyennes et médianes sont aussi aux alentour de 1100, donc plein de pixels négatifs à la soustraction du dark On retrouve le même problème, à savoir qu'il y a en moyenne le même signal sur tes brutes et sur les darks Ci dessous l'ouverture et le calcul de statistique des 3 fichiers "dark unitaire", "masterdark" et "brute unitaire" 1:10:41: Lecture FITS : fichier 120_2025-02-05T00-51-06_12_001.fits, 1 canal(aux), 5496x3672 pixels, 16bits 01:10:49: Exécution de la commande : stat 01:10:49: Canal Red : Moyenne : 1101.731772, Médiane : 1104.0, Sigma : 44.125629, Min : 496.0, Max : 36512.0, bgnoise : 36.309345 01:10:50: Canal Green : Moyenne : 1098.804320, Médiane : 1104.0, Sigma : 44.389149, Min : 464.0, Max : 65504.0, bgnoise : 36.446809 01:10:50: Canal Blue : Moyenne : 1099.365845, Médiane : 1104.0, Sigma : 50.563368, Min : 480.0, Max : 65504.0, bgnoise : 36.057991 01:11:09: Lecture FITS : fichier MasterDark.fit, 1 canal(aux), 5496x3672 pixels, 32bits 01:11:15: Exécution de la commande : stat 01:11:16: Canal Red : Moyenne : 1101.4, Médiane : 1100.6, Sigma : 29.8, Min : 1026.1, Max : 43624.1, bgnoise : 5.5 01:11:16: Canal Green : Moyenne : 1099.2, Médiane : 1098.5, Sigma : 26.4, Min : 1039.3, Max : 65504.0, bgnoise : 5.0 01:11:16: Canal Blue : Moyenne : 1099.8, Médiane : 1099.1, Sigma : 37.6, Min : 1040.0, Max : 65504.0, bgnoise : 5.1 01:11:30: Lecture FITS : fichier 2025-02-04T18-52-40_13_001.fits, 1 canal(aux), 5496x3672 pixels, 16bits 01:11:35: Exécution de la commande : stat 01:11:35: Canal Red : Moyenne : 1106.693673, Médiane : 1104.0, Sigma : 71.256312, Min : 272.0, Max : 65504.0, bgnoise : 37.420775 01:11:35: Canal Green : Moyenne : 1104.733748, Médiane : 1104.0, Sigma : 102.073330, Min : 368.0, Max : 65504.0, bgnoise : 37.916831 01:11:35: Canal Blue : Moyenne : 1102.444708, Médiane : 1104.0, Sigma : 78.895934, Min : 464.0, Max : 65504.0, bgnoise : 37.071912 Pour comparaison, 3 fichiers perso, dark unitaire de 30s, masterdark (empilement de 50 dark) et une brute de 30 secondes sur M42 - le dark unitaire a une moyenne et médiane vers 200, et un min vers 40 - le master dark a aussi une moyenne et médiane vers 200 et un min vers 170 (ici aussi l'empilement supprime des extremes) - mais ma brute a une moyenne et mediane vers 300 (260 pour le canal rouge le plus faible), mais donc très éloigné des valeurs du masterdark ce qui évite d'avoir trop de pixels négatifs, même si il y en aura, vu que le min de la brute est vers 100 1:19:22: Lecture FITS : fichier Dark_30_secs_125_25_-10_2024-01-13T20-32-59_001.fits, 1 canal(aux), 6252x4176 pixels, 16bits 01:19:29: Exécution de la commande : stat 01:19:30: Canal Red : Moyenne : 202.198451, Médiane : 202.0, Sigma : 5.428679, Min : 45.0, Max : 482.0, bgnoise : 4.175201 01:19:30: Canal Green : Moyenne : 202.798290, Médiane : 203.0, Sigma : 6.044971, Min : 36.0, Max : 6525.0, bgnoise : 4.265051 01:19:30: Canal Blue : Moyenne : 202.922420, Médiane : 203.0, Sigma : 5.749064, Min : 27.0, Max : 2267.0, bgnoise : 4.406098 01:19:44: Lecture FITS : fichier toto_stacked.fit, 1 canal(aux), 6252x4176 pixels, 32bits 01:19:50: Exécution de la commande : stat 01:19:50: Canal Red : Moyenne : 202.2, Médiane : 202.1, Sigma : 0.9, Min : 175.9, Max : 358.9, bgnoise : 0.8 01:19:51: Canal Green : Moyenne : 202.7, Médiane : 202.6, Sigma : 2.4, Min : 174.2, Max : 6509.2, bgnoise : 0.9 01:19:51: Canal Blue : Moyenne : 202.8, Médiane : 202.7, Sigma : 1.2, Min : 174.4, Max : 359.0, bgnoise : 1.0 01:20:15: Lecture FITS : fichier M_42_Light_30_secs_125_25_-10_2024-10-24T01-39-58_001.fits, 1 canal(aux), 6252x4176 pixels, 16bits 01:20:22: Exécution de la commande : stat 01:20:22: Canal Red : Moyenne : 278.221671, Médiane : 266.0, Sigma : 356.078296, Min : 97.0, Max : 65535.0, bgnoise : 18.088107 01:20:23: Canal Green : Moyenne : 326.347591, Médiane : 314.0, Sigma : 466.737987, Min : 126.0, Max : 65535.0, bgnoise : 22.876768 01:20:23: Canal Blue : Moyenne : 309.962664, Médiane : 299.0, Sigma : 452.889225, Min : 116.0, Max : 65535.0, bgnoise : 21.509166 Ceci étant, je reste sur le constat mais je n'ai pas de solution à t'apporter, désolé... Cordialement, Stéphane

Bonjour, Je trouve 2 problèmes 1) problème de dark - sur la brute unitaire, je vois des statistiques avec valeur min dans les canaux RVB entre 400 et 500 - sur le dark unitaire les statistiques pour les valeurs min RVB sont du même ordre entre 400 et 500 (jusque là c'est cohérent) - sur le master dark la valeur min RVB sont à 1000 cela ne me semble pas cohérent --> donc lors de la soustraction du masterdark aux brutes on a plein de valeur négatives comment réalises tu ton master dark (type d'empilement, type de normalisation, valeurs sigma choisies) 2) sur le flat unitaire et sur le masterflat - le canal vert est saturé, le min et le max sont à 65535 (il faut réduire le temps de pose) --> flat inutilisable - mais le canal rouge est très faible, donc si tu réduit le temps de pose il n'y aura pas assez de signal rouge) --> ta source lumineuse est trop déséquilibrée sur les 3 canaux, manque de rouge, trop de vert EDIT Tu dis trouver que la brute est surexposée. Sur quels critères te base tu ? Je ne trouve pas de surexpo ni que le coeur d'Orion soit cramé Cordialement, Stéphane

Oui, c'est une erreur de copier coller de ma part, c'est bien 180s et pas 30s pour les brutes. Le seul doute que j'ai c'est sur la temperature (mais faible différence)

Bonjour, @Petitprost J'ai fait un test de soustraction de ton master dark sur ta brute, je ne vois pas d'ampglow résiduel (mais c'est peut être mes yeux..) Dans la brute l'en-tête fit montre gain 119, offset 30 durée 30sec, temperature -10° Dans le master dark, pas de gain, pas d'offset, durée 180s (47 dark), mais temperature -8.8° (ok, je doute qu'une variation de 1.2° soit source de problème) resultat de brute - dark pp_M101-8.fit EDIT: quelques profils d'intensité sur les différentes images, profil réalisé sur la partie en haut a droite de l'image (ligne verticale bleue) sur la brute non calibrée sur le master dark sur la brute calibrée avec le master dark Cordialement

Bonjour @roza, Je suis nomade mais j'ai bricolé moi même ma boite à alim, pas sûr que cela colle à ton besoin si tu préfère une solution "clé en main" A noter que depuis j'ai remplacé la batterie au plomb (12V 60Ah 15kg) par une batterie Lithium (12V 100Ah 10kg), aucun problème pour tenir 10h même par temp très froid. Le setup alimente: monture az-eq6 + camera refroidie P.O. POSEIDON-C, camera de guidage ASI290mm, focuser EAF, hub usb, raspberry pi 4 + disque SSD, bande chauffante pour la lunette, routeur wifi GL-inet Opal. Occasionnellement je branche aussi le macbook si sa batterie interne faiblit (le macbook ne sert pas a piloter le setup, c'est le raspberry qui s'en occupe, le macbook c'est juste pour prendre la main dessus via VNC ou NoMachine pour lancer la session de capture et contrôler le déroulement de temps en temps) @Ant-1 Tu as raison, une capacité en Ah ne vaut rien si on ne précise en même temps pas la tension de sortie Là où il y a habituellement arnaque c'est le vendeur qui parle d'une batterie lithium 12V, mais qui annonce un nombre d'Ah basée non pas sur une tension de 12V mais sur la tension unitaire d'une cellule de la batterie (habituellement 3.2V pour du LifePo4) au final on a 4 fois moins de capacité qu'annoncé. Une verification facile de la cohérence de l'annonce: souvent le vendeur annonce le poids (ou plutôt la masse) de la batterie, en LifePo4 il faut compter 10Ah (sous 12V) par kilo. Si on te vend une batterie 12V 100Ah a un prix defiant toute concurrence mais que la batterie fais 2,5kg alors en fait c'est une 12V 25Ah (ou encore 3.2V 100Ah) Ci dessous le lien vers le sujet où je parle du bricolage Cordialement, Stéphane

Bonjour, Pour changer la taille de police - Menu "Configuration Générale F2" - Onglet "Outils" - Il y a 2 réglages de taille de police "écran" et "GUI" La taille "écran" change ce qui est affiché dans le planétarium, dont l'encart du détail des objet sélecgtionnés La taille "GUI" c'est pour les fenêtres de menus (dont le menu de config) Une fois que tu es satisfait des réglages tu peux les enregistrer dans l'onglet "Principal" Cordialement, Stéphane

Bonjour, Il me semble que ce que tu cherches c'est : 1) dans "Configuration générale" (F2), onglet "Extras", choisir de faire apparaitre les boutons supplémentaires "Relevé DSS" et "Relevés HiPS" 2) pour afficher le relevé DSS il suffit d'utiliser le nouveau bouton DSS affiché 3) pour afficher un relevé Hips, il faut d'abord aller dans "Affichage" (F4) , onglet "Relevés" et choisir des relevés à afficher (par exemple DSS2 Red) Exemple, les alentours d'Orion en affichage normal Avec l'affichage DSS Avec l'affichage HiPs et le relevé "DSS2 Red" Cordialement, Stéphane

@vibe 42 Bonjour, je t'invite a photographier les cibles suivantes qui sont de saison: M45 Les pléiades Les nébuleuses de la Tête de Cheval et de la Flamme dans Orion Les galaxies de Bode et du Cigare (M81/M82) La nébuleuse de la Rosette (plus difficile si ton appareil photo n'est pas défiltré) Plus tard au printemps tu pourra tenter les champs de galaxies dans le Lion et dans la Vierge (mais les petites galaxies en grand champ c'est moins coloré) note(s): quelques galaxies proches comme M31 et M33 rendent bien avec peu de focale, mais la plupart des autres galaxies sont loin, donc soit il faut avoir une plus grande focale, soit se contenter de les avoir moins détaillées dans un grand champs Pour les nébuleuses c'est plus sympa en grand champ car il y en a pas mal qui ont une grande étendue, mais le problème ce sont les nébuleuses en emission Ha qui sont rouges dans une zone du spectre électromagnétique où les APN sont peu sensibles, il faut poser longtemps ou faire défiltrer son APN, ou passer à une camera astro Cordialement, Stéphane EDIT: tu peux simuler le champs couvert pour ta focale et taille de capteur sur le site https://astronomy.tools/calculators/field_of_view/ Exemples M31 M45 M33 M81/M82

Merci pour le partage Cordialement, Stéphane

@rguinamard RPI4: Raspberry Pi version 4 Un mini ordinateur conçu par la Raspberry PI Fondation https://www.raspberrypi.com Si le PiFinder porte ce nom c'est qu'il y a un reaspberry pi dedans... D'ailleurs on peut en acheter un tout fait, ou bien on peut acheter les composants (dont le RPI4) séparément, imprimer le boitier (impression 3D) et bricoler un peu https://pifinder.readthedocs.io/en/release/index.html Kstars c'est un logiciel tout en un pour avoir un planetarium + outils de capture photo (pilote la monture, la camera, le focus, le guidage, la resolution astrométrique, etc...) https://kstars.kde.org/fr/ Cordialement, Stéphane

La solution c'est de ne pas utiliser une distribution Debian (pour lesquelles Jasem ne fourni pas de packages) mais d'utiliser une distribution Ubuntu. Tu pourra alors installer des packages sans avoir a gérer de compilation. Cordialement, Stéphane

Bonjour, Je t'invite a lire le topic suivant De mon avis perso: le gain à 100 avec une ASI2600 c'est très bien. Pour le temps d'expo, entre 30s et 180s, en fonction d'une part de la cible visée (M42 est une cible qui ne demande pas de gros temps de pose par exemple) et d'autre part de la qualité de ton ciel (pollution lumineuse ou pas) ou de l'usage de filtres sélectifs. Plus le temps de pose sera long plus le suivi sera exigeant en effet. Mais plus que tout, le plus important sera le nombre de poses, 10 ou 15 ce n'est clairement pas suffisant. En terme de temps cumulé il faudrais au moins 2 heures par cible (voir plus), donc 120 poses de 60s, ou 60 poses de 120s par exemple exemples: - M8 et M20 avec environ 60 poses de 60 secondes (cela aurait mérité plus de poses) https://www.webastro.net/forums/topic/254585-m8-m20-nébuleuses-de-la-lagune-et-trifide-14072024/#comment-3153496 - La Rosette avec 120 poses de 120 secondes https://www.webastro.net/forums/topic/248337-nébuleuse-de-la-rosette-soirée-du-11012024/#comment-3123401 - La Nébuleuse Californie avec 60 poses de 180s https://www.webastro.net/forums/topic/258281-ngc1499-nébuleuse-californie-28112024/ Dans les trois cas j'ai adapté le temps de pose unitaire en fonction du résultat visible sur une brute, qui dépend de l'objet ciblé et des conditions de prise de vue (qualité du ciel du lieux d'observation, présence ou pas de la lune, humidité, etc...) La méthodes des 3 sigma donnée dans le topic sur les CMOS me permet d'obtenir de bons résultats (en tout cas des résultats que je trouve personnellement satisfaisants) EDIT ajout de la visualisation des brutes pour les 3 cibles Je ne colle pas les brutes directement, les fichiers sont un peu gros, il s'agit ici de copies d'écran réduites à 900x600 (l'acquisition originale fait environ 6000x4000) de la visualisation avec ASIfitsViewer des brutes pour les 3 cibles, l'idée étant de donnée une idée de l'exposition obtenue sur la cible (en partant du principe que le soft a fait la même montée d'histogramme pour la visualisation, ce qui n'est pas garantis) Cordialement

Oui, moi aussi, alors j'ai fouillé un peu plus, et il apparait deux elements liés la faiblesse du porte oculaire de ma lunette - la mise au point n'est pas homogène sur les 3 tests --> sur les tests avec backfocus à 56mm et 57mm la mise au point est moins bonne, le PO a du glisser un peu après la MAP . Mon PO n'a pas de crémaillère, c'est un galet à friction, et c'est sensible aux écarts de temperature, et c'est d'autant plus un problème si l'on vise une cible haute dans le ciel comme c'était le cas ce soir là (presque au zenith) - il y a du tilt sur les 2 premiers tests. Su le PO il n'y a qu'une vis de serrage pour tenir le coulant du réducteur, même serré cela bouge un peu (et pas possible de faire un montage tout vissé sur ce PO) Il faut que je refasse des tests plus rigoureux en soignant la MAP et en vérifiant le tilt Ci dessous les analyse psf/tilt via Siril backfocus 56mm backfocus 57mm backfocus 56.5mm Cordialement, Stéphane