keymlinux

En fait si, sur cette camera il y a une molette pour ajuster la map de la cam de guidage une fois que l'on a fait la mise au point sur le capteur principal Cordialement

Il y a plusieurs solutions 1) si tu as une baque EOS vers M48 de 11mm d'épaisseur: dans ce cas pas de possibilité d'insérer le filtre entre elle GPU et la bague, il faudra mettre le filtre avant le GPU 2) si tu as une baque EOS vers M48 "low profile" (2 à 3mm d'épaisseur) alors là il y a 2 solutions 2a) si tu trouve un porte filtre d'une épaisseur max de 8mm ayant du filetage M48 en entrée et sortie tu peux l'insérer (je doute qu'un porte filtre si mince existe) 2b) solution dangereuse (pour ton APN): certains filtres disposent aussi d'un filetage M48 femelle en entrée mais de très courte longueur, on peut alors avoir le filtre visé coté femelle sur le GPU et coté male sur l'adaptateur EOS-M48. Il faudra aussi ajouter des bagues allonges M48 pour avoir le bon backfocus (mettre le filtre au plus près du capteur, donc les bagues entre elle filtre et le GPU) cette solution est dangereuse car le poids de ton APN sera tenu par le filetage femelle du filtre qui si il est présent sera très court. En cas de problème tu va ramasser ton APN par terre... La conclusion c'est que vouloir insérer un filtre entre un APN et un correcteur (et/ou réducteur) étant contraint par un petit backfocus c'est vraiment très compliqué (le problème c'est que l'APN a lui tout seul consomme 44mm de chemin optique). Avec un APN hybride (où le capteur est plus proche) ou avec une camera astro (chemin optique 12,5 ou 17,5mm) on a moins de problèmes

@alp73 Pour le raspberry il faut une alim externe, par contre un SSD peut être alimenté directement sur le raspberry (personnellement j'utilise un SSD Samsung T5 1TB branché en direct sur 1 des 2 ports USB3 du raspberry pi 4, et sur l'autre port USB3 j'ai un hub usb alimenté pour les autres périphériques (camera imager, camera guidage, focuser, dongle GPS, etc...) Pour booter un raspberry pi sur un disque externe à l'époque où je l'ai fait c'était nouveau et pas trivial, il fallait mettre à jour le firmware et beaucoup bricoler. A priori avec un raspberry récent cela devrait être plus facile. Pour les modes opératoires voici les sites ci dessous (il y en a d'autres) https://www.framboise314.fr/boot-du-raspberry-pi-4-sur-un-disque-ssd-en-usb3/ https://www.maison-et-domotique.com/128294-comment-demarrer-raspberry-pi-4-sur-ssd/ EDIT: un SSD c'est pas obligatoire, mais c'est petit, léger, cela ne vibre pas et cela ne consomme quasiment rien (le raspberry, le ssd et le hub usb sont attachés sur ma lunette donc la compacité est importante) Cordialement

Bonjour Si ton but c'est de limiter la pollution lumineuse alors un L-PRO ou UHC c'est bien les narowband c'est surtout pour faire du HOO et SHO Les filtres EOS clip sont rares. Si tu veux du choix sur les types de filtres et constructeurs tu devra privilégier le M48 (avis personnel) Si tu visses le filtre avant le correcteur pas de changement sur le back focus (mais cela peut augmenter le vignetage), si tu le met entre elle correcteur et l'APN alors il faut tenir compte de son épaisseur pour le calcul du backfocus. Le backfocus du GPU et de 55mm pour une focale de 1000mm. L'APN a un tirage interne de 44mm, reste 11mm pour la bague d'adaptation EOS-48 + filtre, c'est jouable Le mieux est l'ennemi du bien... Plus restrictif cela veut aussi dire plus de temps de pose, et avec ton newton 200/1000 sur une HEQ5 je pense qu'un bon suivi sur des poses de plusieurs minutes cela risque de ne pas le faire.... Pour ta 3eme question je laisse les spécialistes te donner leur avis Juste un point: l'interêt d'un filtre Oiii + Sii en OSC c'est justement que en complement d'un Ha + Oiii il permet de faire du SHO en plus du HOO (mais du coup c'est du dual shot, une fois avec Ha+Oiii et un second avec Oii +Sii) EDIT: concernant ta dernière question: ton APN full frame te condamne à prendre des filtres de grand diamètre (2" pas 1,25") Pour la mise au point tu as un newton, donc il ne souffrira pas de chromatisme comme une lunette, les lentilles du GPU peuvent en ajouter un peu mais je doute que cela soit perceptible (ces lentilles étant proches du capteur) Cordialement

@roro62 Oui vu que tu as déjà un APN avec capteur APSC pour les grandes cibles une petite camera en complement pour les petites cibles me semble être un choix cohérent (j'utilise aussi une petite camera avec capteur imx178 non refroidi en complément d'un capteur apsc 🙂 ) Player One c'est un bon choix, donc avec filtre UV/IR, en 1.25'' suffisant pour petit capteur. Cordialement

Bonjour, 1) Tu peux calculer la taille nécessaire pour un filtre en fonction des caractéristiques de ton telescope et de ta camera ici https://astronomy.tools/calculators/ccd_filter_size 2) Et désolé, mais des capteurs IMX664 et IMX585 ce sont des petits capteurs (entre 9 et 12mm, soit diagonale presque 2.5 à 3 fois plus petite qu'un capteur APS-C...). Pour ces "petits" capteurs un filtre 1.25'' est suffisant. 3) Vu que tu as déjà le correcteur, utilise le, meme si une petite taille de capteur ne le rend pas obligatoire, mais prend des filtre en 1.25'' qui seront suffisant pour ces tailes de capteur (si besoin tu peut utiliser un adaptateur pas très cher pour fixer un filtre 1.25'' sur un filetage pour filtres 2''). Pour le filtre UV/IR tu n'en aura besoin que si le hublot de la camera n'est pas déjà traité (si la camera filtre déjà les UV/IR pas besoin de rajouter ce filtre) 4) Tu dis vouloir faire de l'imagerie non planétaire, mais dans ce cas pourquoi s'orienter vers un "petit" capteur, et pourquoi une cam non refroidie. Bien sûr l'argument du prix/budget est tout a fait valable (on en est tous conscient), mais à part cet argument (important) je ne comprend pas le choix. EDIT: je dis cela parce qu'il faut être conscient que plus la focale du telescope est élevée et plus la taille du capteur est petite alors plus le champ couvert par la photo sera petit. le couple IMX585 + SW 150/750 c'est bien pou les petites galaxies et nébuleuses planétaires, mais pour le grandes nébuleuses cela va être compliqué Tu peux simuler le champs couvert par le telescope et la camera ici https://astronomy.tools/calculators/field_of_view/ exemple: pour M1 (Le Crabe) c'est parfait Mais pour M42 (Orion) c'est trop petit Cordialement

Bonjour, A priori c'est une (vielle) camera SBIG Tu devrais trouver des infos ici (désolé c'est en anglais) https://diffractionlimited.com/legacy-product-support/ Il faudra d'une part installer un driver et d'autre part utiliser un logiciel de capture qui supporte cette camera, il y en a plusieurs listés sur la page ci dessus, pour windows et linux, mais je n'en connait aucun donc je ne pourrais pas t'aider Lien direct vers la doc: https://diffractionlimited.com/wp-content/uploads/2016/03/USBmanRev14.pdf Lien direct vers les drivers pour windows (reste a voir si c'est compatible pour windows 11, faut tester) https://cdn.diffractionlimited.com/downloads/SetupDriverChecker64.exe Cordialement, Stéphane

@alp73A priori ton soucis n'est pas relatif à la puissance de calcul mais au stockage et à la taille des index pour l'astrométrie Il y a plusieurs possibilité: 1) tu as un PI4 avec comme seul stockage une carte SD --> ce n'est pas une bonne idée, car si tu stocke sur la carte SD l'OS + les index de l'astrométrie + les photos prises lors des séances astro photos tu va rapidement manquer de place, de plus en terme de performance la carte SD c'est bof, et en plus tu va la tuer rapidement 2) Tu as un pi4 avec une carte sd pour l'OS et un disque usb externe pour les captures --> c'est un bon compromis, surtout si tu a configuré le répertoires des index astrométriques pour pointer vers le disque EXTERNE (par défaut c'est stocké dans le répertoire de ton utilisateur, donc sur la carte sd) 3) Tu as un pi4 qui démarre directement sur un disque usb externe (c'est ce que j'ai fait, avec un disque SSD 1TB, pas besoin d'alimentation externe) --> dans cette config tout est stocké sur le disque dur, plus de problème de capacité ou de corruption de la carte SD Cordialement

Bonjour, Sur les APN CANON avec objectifs EF (et EF-S, mais pas RF), la distance entre le capteur et le "flange" où appuie l'objectif est de 44mm Avec un adaptateur de 26mm plus les 17,5mm de la camera, on obtient 43,5mm, donc déjà il manque 0,5mm, si en plus on ajoute un filtre, avec par exemple 2mm d'épaisseur pour le filtre, donc 0.6mm à ajouter par le back focus, on a alors 1.1mm manquant, donc oui il faut ajouter une cale de 1mm au moins

@mae_photographer_Si tu ne l'utilises pas déjà, je te conseille d'utiliser l'utilitaire Sirilic qui te permettra de simplifier les étapes du pré-traitement en générant des scripts pour Siril Les détails ici: https://siril.org/fr/docs/sirilic/#:~:text=Option lien symbolique %3A Sirilic offre,à la copie des fichiers. Pour le téléchargement: https://gitlab.com/free-astro/sirilic/-/releases Dans les préférences de Sirilic, activer les options de compression des fits et d'utilisation des liens symboliques pour réduire l'espace disque nécessaire (et si tu est sous Windows, il y a une option "lien symboliques" à activer au niveau de l'OS, sous Linux et MacOs c'est disponible en standard) Cordialement, Stéphane

Non, cela compresse sans perte de qualité (algorithme de compression loss-less). Ce n'est pas du jpeg... voir detail https://siril.readthedocs.io/en/latest/file-formats/FITS.html note: dans la cas où on utilise le codage en 32bits cela n'est pas exactement sans perte, mais sans perte significative)

Bonjour, 1) 1270 images de 50Mo pièce cela fait un peu plus de 60Go 2) lors de la calibration des images (avec les DOFs) cela va générer 1270 autres images préfixées avec "pp_" - si ce sont des images monochromes elles feront la même tailles (donc +60Go) - tu ce sont des images couleur elles seront debayerisées et vont tripler en taille (donc +180Go) 3) si tu applique une extraction de background sur ces images cela va aussi générer 1270 images avec préfixées "bkg_pp_" (ici aussi +60Go ou +180Go selon mono/couleur) 4) lors du register cela va aussi créer 1270 images préfixées "r_pp_" (si tu n'as pas fait l'étape 3) ou "r_bkg_pp_" si tu as fait l'étape 3, donc ici aussi entre +60Go et +180Go et si tu as choisi de faire un drizzle à cette étape alors toutes tes images résultat vont avoir une taille x4 !! Et tout cela c'est en gardant le 16b, si tu passe en 32bits tu multiplie encore tout par 2 ! Une option: aller dans les préférences e Siril et activer la compression des FITS, les images intermédiaires (pp_, bkg_pp_, r_bkg_pp) seront compressées (fichiers .fit.fz au lieu de .fit) Par exemple, mon dernier traitement: 120 brutes, 30 flat, 30 bias, 50 dark, total 230 images, 52Mo pièce, total environ 11.5 Go pré-traitement en 32 bits, avec drizzle lors du register: 53.8 Go de fichiers temporaires (compressés) générés. Si je n'active pas la compression j'ai aussi des problèmes de places... EDIT: je viens de tester, environ 230 Go de fichiers temporaires sans la compression Cordialement, Stéphane

Bonjour, @Thibault Astro dans ton premier post tu détaille tes traitements et tu fais le retrait du gradient à la fin. Il me semble qu'il est "mieux" de la faire dès le début, sur l'image linéaire avant l'étalonnage des couleurs. Tu peux aussi, au lieu de le faire sur l'image "empilée", le faire sur les brutes individuelles, après calibration avec les DOF et avant le register et le stack (voir commande Siril "seqsubsky" applicable sur une sequence) Cordialement, Stéphane

Bonjour, De ce que je comprend, ton asiair est branché sur du 220V (je suppose via un transfo 220V vers 12V DC 5.5mm en entrée de l'asiair) Concernant ton adaptateur "batterie factice", tu ne précise pas de quelle connectique il dispose en entrée (de l'usb 5V comme celui que j'utilise ? ou bien du 12V avec prise DC 5.5mm ?) Si tu connecte ta batterie factice sur les ports USB de l'asiair alors c'est normal que cela fonctionne mal. L'asiair est basé sur un raspberry pi4 dont les ports USB peuvent débiter au max 1.2A sous 5V (1.2A en tout, pas 1.2A par port usb) Personellement je n 'ai pas d'asiair mais un raspberry pi4 avec Kstars/ekos/indi, et je branche ma batterie factice sur un hub usb alimenté (il dispose de 7 ports "data" (max 0.9A sous 5V) et 3 ports dédiés "alim" (délivrant chacun au max 2.4A sous 5V) Cordialement

Bonjour, Si ton image Ha est 2 fois plus petite que l'image Oiii, tu veux donc multiplier sa taille par 2 Dans la console de siril: load image_ha_originale.fit resample 2.0 save image_ha_double.fit Edit: si au lieu d'une image tu en a plusieurs (tu avais n light qui ont donné n images Ha et n images Oiii) Dans ce cas tu met tes "n" Ha dans une séquence et les "n" Oiii dans une autre, puis tu alignes chaque séquence avec le "register", et pour la séquence Ha tu utilises l'option "-drizzle" pour doubler leur taille. C'est ce qui est fait dans le script OSC_Extract_HaOIII.ssf fourni avec Siril Cordialement

Bien vu, je suis un boulet...., c'est corrigé 😅

Bonjour, Histoire de faire dans l'originalité, je viens ici vous montrer ma dernière capture, la Nébuleuse de la Rosette, effectuée dans la nuit du 11 au 12 janvier (première véritable opportunité météo depuis plus d'un mois en région parisienne...) Cette soirée fut l'occasion d'utiliser pour la première fois une camera astro refroidie, en remplacement de mon APN non défiltré, et de passer d'un guidage avec lunette guide à l'utilisation d'un diviseur optique. Oui beaucoup de changement, avec le risque de rencontrer des problèmes et de gaspiller une si rare opportunité météo... Conditions: : ciel sans nuages, température ambiante -3°, au sud de l'Ile de France Détail du matériel: - télescope: SW Equinox 80/500 - réducteur: TRF-2008 x0.8 - camera: Player One Poseidon-C - monture: SW AZ-EQ6 - guidage: OAG + ASI290mm - filtre: UV/IR cut Baader Capture via Kstars/Ekos/Indi sur Raspberry (Nafabox) Traitement: Siril et Gimp Les images: - Lights: 120x120s gain 125 offset 25 temp -10°C - DOF: 50/50/30 Les problèmes rencontrés, à résoudre pour la prochaine fois.. - j'ai mal réglé le diviseur optique, le prisme empiétait un peu sur le capteur, l'ombre générée à bien été traitée par les flats, mais je pense que c'est aussi la source des aigrettes verticales bizarres sur certains étoiles (j'utilise une lunette, donc il ne devrait pas y avoir d'aigrettes) - le backfocus de mon réducteur correcteur n'est pas bon, donc étoiles déformées dans les coins (je dois ajoute run filtre UV/IR cut avec cette camera, et je n'en ai pas tenu compte pour la distance correcteur/capteur - les 120 prises de vues ont été séparées en 4 lots de 30 images (je vérifie la MAP avant chaque lot), 2 lots fait avant le passage au méridien, 2 lots après le passage au mérifdien: pour le 3eme lot, juste après le retournement du méridien, impossible de passer l'étape de calibration du guidage. Au final 90 images prises avec guidage, 30 sans guidage Selon la formule consacrée, vos avis et critiques sont les bienvenus Image réduite à 6000x4000 pixels et compression jpeg pour poster sur le forum Pour les détails du traitement: Stack des Lights avec DOFs, et option drizzle Post-traitement Siril: - Extraction du gradient (Correction : Subtraction) - Photométrie - Transformation asinh : (stretch= 250.0, bp=0.00020) - GHS pivot : 0.010, montant : 19.12, local : 0.00 [0.00 0.60] - GHS LINEAR BP : 0.02 - GHS pivot : 0.244, montant : 7.98, local : -0.83 [0.01 0.50] - SCNR (type=neutre moyen, qté=1.00, préserve=true) - Rehaussement de la saturation (quantité=0.20) Post-traitement Gimp + plugin PyGapM27 - Make Dark Sky (iteration 3, opacité 15) EDIT: version avec réduction d'étoile Réflexion faite, je trouve que mon image a des étoiles trop prononcées. La camera est plus sensible que l'APN que j'utilisais jusqu'a présent, au lieu de poses de 120secondes j'aurai du me limiter à des poses de 60secondes. Je me suis donc lancé dans une réduction d'étoile, une première ici aussi. En terme de post-traitement Siril: - Extraction du gradient - Photométrie - Traitement étoiles: dé-saturation - Traitement étoiles: suppression des étoiles starnet - Réduction du bruit sur le fond de ciel "starless" - Traitement étoiles: recomposition avec étirement séparé starless/starmask - Retrait du bruit vert Cordialement, Stéphane

Au lieu de cibler NGC2237 il faut cibler NGC2244 qui est l'amas ouvert dans la Rosette, là ton cadrage sera OK J'ai fait la même cible dans la soirée du 11/01 et j'ai eu le même problème de décentrage du cadrage, bien que n'utilisant pas le même matos que toi (Player One POSEIDON-C à capteur pus grand et rectangulaire, et astrométrie via Kstars/Ekos/Indi sur un raspberry). En ciblant NGC2237 j'avais un décentrage, avec NGC2244 c'était OK Ci dessous le cadrage dur NGC2237 (ou sur NGC2238 cadrage identique), elle est "décentré", et ton image et la mienne ont le même "centre", une zone de poussière faisant des filament noirs En cadrant sur NGC2244 (cadrage identique en visant NGC 2239) là j'obtiens le cadrage voulu nb: ces images sont des brutes avec une preview "histogramme" sous Siril, la zone sombre en bas c'est l'ombre du diviseur optique qui était réglé un peu bas (à corriger pour les prochaines fois...) Cordialement, Stéphane

Bonjour, La distribution Astroberry est actuellement disponible seulement en 32bits, donc cela te bloque sur la dernière version de Kstars/Ekos/Indi 32bits et t'empêcherais d'utiliser les dernières evolutions du logiciel Kstars (dont les dernières versions ne sont disponibles qu'en 64bits) Il est fort probable que la distribution Astroberry 32bits ne démarrera pas sur un PI5, le support du PI5 ne sera intégré qu'au distributions linux récentes (et donc en 64bits) Et le plus important: l'architecture 64bits c'est surtout ce qui permet de ne pas se limiter à 4GB de mémoire mais de pouvoir utiliser efficacement 8GB La question ne se posera pas en ces termes, tu ne pourra pas démarrer une distribution 32bits Astroberry sur un PI5... Par contre sur la question de fond qui est de savoir si un PI4 est suffisant pour notre usage ou si un PI5 est nécessaire ou au contraire surdimmensionné: - en usage capture ciel profond, un pi 4 est suffisant (j'utilise un pi4 pour faire de la capture ciel profond, avec guidage et astrométrie, pas de problème d'usage cpu constaté sur un PI4) - si on veut faire de la capture planétaire, un PI5 permettrait de monter le nombre de fps nécessaire à la capture planétaire en video (pour info firecapture existe en version compilé pour raspberry 64bits) - si on veut utiliser le raspberry pour faire le traitement (siril/gimp) alors le passage au PI5 s'impose, même si il faut garder à l'esprit que cela restera lent, ce qui fera la différence cela sera surtout d'avoir 8GB de mémoire et pas seulement 4GB (le 8GB de mémoire est aussi disponible sur PI4), mais ce qui est important c'est de ne pas stocker les photos sur la carte SD mais d'utiliser un disque externe SSD (et le mieux c'est d'avoir l'OS aussi sur un SSD externe) Concernant l'acquisition d'une photo de l'APN, il faut effectivement près d'une dizaine de secondes (en plus du temps de pose) pour obtenir l'image, mais le point limitant ici c'est le port USB2 de l'APN qui limite le débit (en tout cas c'est le facteur limitant que je constate avec mon APN Canon 80D, mon raspberry PI4 utilisant un disque SSD en USB3 ce n'est pas l'écriture sur disque qui limite). Ceux qui ont une camera astro équipée d'un port USB3 (ce qui est courant) ou un APN avec un port USB3 (ce qui est rare) n'ont pas ce problème Cordialement

Bonjour, Pour une longue vue "terrestre" où l'on souhaite redresser l'image, on peut le faire avec un prisme (en fait plusieurs) comme dans les jumelles à prisme, mais on peut aussi intercaler une lentille entre l'objectif et l'oculaire. Voir le site de Serge Bertorello (ne pas hésiter à parcourir les autres pages du site, c'est une mine d'information) http://serge.bertorello.free.fr/optique/instrum/longuevue.html Cordialement

Bonjour, Quelques formules utiles... soit D, le diamètre du télescope, ici 200mm soit F, la distance focale du télescope, ici 1200mm soit f (en minuscule), la distance focale de l'oculaire (tu as déjà un 25mm et un 10mm) le rapport F/D, 6 pour ton telescope. C'est surtout utile de le connaitre pour l'astrophoto, mais même en visuel, cela implique: - plus de rapport F/D est petit, plus la mise au point est sensible (la zone de netteté est réduite) - plus le rapport F/D est petit, plus l'image sera déformée sur les bords (coma), et plus il faudra des oculaires de qualité Le grossissement c'est F/f - donc G = 48x pour l'oculaire de 25mm avec ton télescope - et G = 120x pour l'oculaire de 10mm et ton télescope Pour calculer le champ de vision réel, on divise le champ apparent par le grossissement Pour les oculaire de 25 et 10mm le champ apparent est inconnu (probablement 52° ou 68° cela dépend de leur formule optique) Pour la gamme d'oculaire ES 82° et bien c'est 82° - avec l'oculaire de 8mm préconisé par @22Ney44, grossissement de 150x donc champ réel de 82/150= 0.54° - avec l'oculaire de 8mm + barlow, grossissement de 300x, donc champ de vision de 82/300 = 0.27° Pour info, la taille apparente de la lune est de 0.5° environ Avec une barlow x2 tu double le grossissement, donc tu divise par 2 le champ couvert, c'est pas plus compliqué edit: grillé par @Le Gnou qui a été plus rapide à répondre...😉 Cordialement

@berenthorJ'ai vu que les fit ont été générés par Indi. Dans la dernière version (3.6.8) de kstars/ekos/indi il y a de nouveaux "placeholders", tu pourra utiliser %I dans le nom du fichier pour que celui ci contiennent la valeur ISO utilisée à la prise de vue

La brute light est faite a iso 100, le dark à iso 800...

Bonsoir, Pour le réglage de l'alignement, sur la photo ci dessous: "élévation Adj screw" et "Windage Adj scrw", avec une clé 6 pans M3 J'un un viseur point rouge quasi identique monté de base sur mon newton Sumerian Optics, et pour garder la clé 6 pans à portée de main elle est fixée avec 2 petits aimants neodyme sur le coté du viseur... Pour ta question 2, je dirais que cela sent la traduction automatique bullshit 😅 Cordialement

Quelle drôle d'idée ? 😅 Même sans calibration, je trouve que la trame est vraiment importante sur ta brute Ci dessous une brute de 30s à 800iso sur M42, OK c'est pas le même capteur (APN Canon 80D), mais je suis étonné d'avoir une telle différence note: tu n'as pas précisé quel ISO tu utilises sur l'APN note: ci dessous image raw canon ouverte dans siril sans dématricage, affichage en auto ajustement (on vois bien les poussières sur le capteur...) Ceci étant, même avec de la trame sur les brutes, vu que tu as fait du dithering il devrait s'atténuer à l'empilement et cela ne semble pas le cas, les défauts les plus importants sur la brute apparaissent au même endroit sur l'empilement. Tu est sur de tes paramètres de dithéring (toutes les combien de pose ? décalage de combien de pixels ? ) EDIT: - en cherchant sur le net j'ai vu que le Canon 1000D date de 2008, le Canon 80 date de 2016, ceci explique peut être la différence de trame entre les 2 brutes - si il y a d'autres utilisateurs de Canon 1000D qui passent par là il serait interessant qu'ils donnent leur avis sur la trame, pour savoir si ils en ont aussi (et aussi marquée) sur leur APN ou pas Cordialement