keymlinux

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...

Bonjour, La problématique et les outils associés ne seront pas la même selon que l'on image avec un APN (raw/jpeg) ou avec une camera dédié astro (fits) (sans parler de ceux qui font de la capture video en planétaire) Comme toi pour les photos non astro j'utilise Lightroom pour cataloguer (et aussi pour importer et renommer les fichiers), avec des mots clés (puis je fais un grand usage des collections dynamiques) Pour la partie astro: 1) Au debut j'utilisais mon APN Canon avec soit un intevalometre filaire, soit via EOS Utility J'avais donc import des RAW+JPEG via lightroom, + mise en place de mots clés (CP/planetaire, nom de l'objet, type light/dark/bias/flat, etc...) Je garde les fichiers raw+jpeg, le résultat d'empilement siril (pas les fichiers intermédiaires) avant et après post-traitement (donc plusieurs si j'ai tenté plusieurs post-traitements). A noter que j'utilise l'option de compression sans perte des fits. 2) maintenant j'utilise kstars/ekos/indi pour piloter mes prises de vues, cela implique que EKOS m'enregistre les images en format FIT sur le disque dur du raspberry (avec infos d'astrométrie), mais sur la carte SD de ll'APN je conserve les RAW (pas les jpeg car le driver INDI les désactive) Pour les RAW je les catalogues via Lightroom comme pour le point 1) Pour les fits, non gérables dans lightroom, je les stockes dans une autre arborescence du type objet cible/ date session/[light|dark|flat|bias]/fichier exemple: M42/20230227a/light/M42_light_180s_800iso_001.fit Donc ici je garde les raw et les fit même si cela peut sembler faire double usage. Ici aussi je garde le resultats d'empilement de Siril et les tentatives de post-traitement 3) Dans le futur j'envisage de passer à une camera astro refroidie, je n'aurais donc lus les raw/jpeg à gérer, seulement les fits, et je resterais sur mon workflow utilisé pour les fit au point 2) Pour ce qui du problème de la volumétrie, oui tout cela prend de la place, j'utilise un NAS pour stocker les photos (et il se réplique sur un autre NAS à l'autre bout de la France(hébergé dans la famille 🙂 ) Je pense que le vrai problème de volumétrie c'et pour ceux qui font du CP pose courte avec plusieurs centaines voir millier d'images pour une session (moi perso une session c'est max 200 images DOF compris, avec es lots et darks variant de 120s à 300s selon les cibles), ou bien du CP avec CAM mono où les lights sont multipliées par le nombre de filtres, ou bien ceux qui font du planétaire avec des vidéos à forte cadence d'image EDIT: - pour les fits je n'utilise pas d'outil de catalogage, cela repose juste sur une organisation en "répertoires" de stockage - par contre pour leur visualisation j'utilise ASIFitsView (la suite logicielle ASIStudio est téléchargeable gratuitement sur le site de ZWO), et Siril - Une fois que je suis satisfait par mes traitements Siril, j'exporte en TIFF, je fais éventuellement un peu de retouche via GIMP sur les TIFF, puis enregistrement des versions finales en TIFF aussi, et ces TIFF sont catalogués dans LightRoom Cordialement, Stephane

Bonjour, Il faut rajouter la ligne suivante au debut de tes scripts Il me semble que c'était déjà obligatoire avec les versions 1.0.x requires 1.0.0 Edit: je viens de regarder dans le fichier de log que tu fournis, il est fait pour les versions SiriL 0.9, il faut mettre à jour les scripts Voir la doc ici https://siril.readthedocs.io/fr/latest/Scripts.html Cordialement

Bonjour, La nature nous offre des spectacles magnifiques C'est une belle prise, il y l'arc principal et l'arc secondaire, séparés pas une zone plus sombre appelée bande d'Alexandre Voir explications ici: https://fr.wikipedia.org/wiki/Arc-en-ciel Ci dessous, arc en ciel photographié en octobre 2021 depuis mon balcon Dommage pour le pilier au milieu du panoramique... Cordialement, Stéphane

Bonjour, Tout d'abord, malgré la trame, je trouve ton image superbe. Avec le guidage on veut éviter le "bougé" pendant les poses. Avec le dithering on veut générer un "bougé" entre les poses. Le problème c'est que si tu guide d'une part avec PHD et que tu prend les poses d'autre part avec un autre soft (Shutter ou EOS utility), alors le problème c'est: comment générer un bougé entre les poses que le guidage n'interprétera pas comme une erreur soudaine de suivi à corriger ? Avec le couple EOS Utility PHD il y a la possibilité d 'utiliser PHDMax comme le precise @krotdebouk. J'ai aussi commencé avec EosUtility + PHD , mais je n'ai pas utilisé personnellement PHDMax, car j'utilisais un MacBook sous MacOs, PHDMax et purement Windows et ms tentatives de le faire fonctionner avec Wine ont échoué... Si on utilise un un logiciel intégré qui prend les poses et fait le guidage et le dithering alors cela résoudra le problème, il suspendra le guidage pendant le dithering. Personnellement je suis passé à Kstars/Ekos cela gère la prise de vue, la mise au point motorisée, le guidage (avec dithering), et l'astrométrie, et en plus cela tourne sur une config minimale (un petit raspberry). Le macbook ne me sert d'en debut et fin de seance pour contrôler la session. C'est important en usage remote où l'autonomie électrique est un problème. Possibilité à tester: vu qu'il n'est pas nécessaire de faire du dithering à chaque pose, tu peux essayer de suspendre le guidage toutes les 5 ou 10 poses, puis déplacer légèrement le pointage en utilisant la raquette en donnant une courte impulsion (dans une direction différente à chaque fois), puis reprendre le guidage. Mais cela t'oblige à rester à coté du setup (et c'est galère de faire à la main ce que des softs font plus efficacement)

Bonjour, Cela me semble être une bonne alternative, avec un prix "mesuré" pour le package total. https://all3dp.com/2/rock-pi-vs-raspberry-pi-difference/ Par contre attention, le site de vente OKdo est en Angleterre, il faut ajouter la TVA en France (ceci étant on devrais alors payer le prix HT en Angleterre...) Le même kit est disponible sur la Zone à 193 euros (177 si on passe par un vendeur tier) Même à 193 euros pour le pack complet cela reste concurrentiel par rapport à un pi4 "nu" à plus de 200 euros... EDIT: 2 remarques 1) A priori il y a un site pour la france et un pour UK (choix en bas de page à droite) et a priori ils précisent que si on ne dépasse pas 180 euros sur la commande c'est bien du TTC pour nous sans frais additionnels 2) Le pack complet à 142 euros il est bien, mais pour l'usage que l'on cherche (seance astro nomade avec alimentation à base de batterie), les cables HDMI et l'alimentation on s'en fout. En fait ce dont on a besoin c'est d'une carte Rock 4C+, les radiateurs, le boitier et la carte SD, alors autant faire l'acquisition d'une carte nue à 80 euros sur le site OKdo, et pour le reste on se débrouille (d'ailleurs le Rock 4 C+ et le Raspberry PI 4 peuvent utiliser le même boitier !) Histoire d'être en totale contradiction avec mon message precedent, je crois que je ne vas pas attendre la baisse de prix du rpi4 et que je vais me laisser tenter par un rock 4 C+ et passer commande.... 🙂

Bonjour, Il est vrai qu'avec la pénurie et des vendeurs qui proposent un rpi4 a plus de 200 euros, il deviens urgent de trouver des alternatives Si tu cherche a peu près les même specs qu'un rpi4, il faut voir du coté des différents modèles Orange Pi (ou aussi Banana Pi), mais je crains qu'ici aussi il y ait des problèmes d'approvisionnement) Un Orange PI avec un quad core, 4Go de ram, 16Go de stockage on le trouve à 125 euros https://orangepi.com/index.php?route=product/product&product_id=896 On peut y installer une distribution Ubuntu et en faire une nafabox Un autre alternative, même si cela me fend le coeur, c'est de se réfugier sur sun modèle de miniPC a processeur Intel, avec 4 à 8Go de ram et un processeur x86 (mais on peut aussi y installer une ubuntu + stars ekos et en faire une nafabox) Exemple ici un minipc avec un x86 dual core, 4Go de ram et 64 Go de stockage à 135euros (plus cher qu'un rpi4 au tarif "normal" mais moins cher qu'un rpi4 au tarif "actuel") https://www.amazon.fr/Nouvelle-Z83-F-Processeur-préinstallé-Automatique/dp/B07NZSYQ2N/ref=sr_1_19?keywords=orange+pi&qid=1679335020&s=computers&sr=1-19 Vu que 4Go de memoire c'est un peu juste, un modèle un peu plus pêchu mais moins compact sous la barre des 200 euros(quad core, 12 Go ram, 256Go de stockage) https://www.amazon.fr/Nouvelle-Z83-F-Processeur-préinstallé-Automatique/dp/B07NZSYQ2N/ref=sr_1_19?keywords=orange+pi&qid=1679335020&s=computers&sr=1-19 note: je n'ai pas testé personnellement ces alternatives, j'attend que le prix des rpi baisse (j'en ai plusieurs donc je ne suis pas pressé) Cordialement

@m27trognondepommeBonsoir, je pense avoir détecté 2 anomalies dans cette version 1.15 1) Concernant le "register" en 2 passes et la commande "seqapplyreg", j'ai une anomalie si j'utilise l'option "drizzle" Dans le script généré par sirilic on obtiens les commandes suivantes: register pp_images -drizzle -2pass -layer=0 seqapplyreg pp_images Mais vu que le register avec option -2pass ne génère pas les fit et que c'es le seqapplyreg qui le fait, il faut appliquer l'option drizzle à cette dernière commande et avoir les commandes ci dessous: register pp_images -drizzle -2pass -layer=0 seqapplyreg pp_images -drizzle 2) Avec sirilic v1.2, si on utilise la compression des fit alors les fichiers générés sont des .fit.fz au lieu de .fit Pour le contenu des sequences ce n'est pas un problème, mais lors de la génération des master (offset/flat/dark/darkflat) ils se retrouvent nommés en .fit.fz, mais lors de leur utilisation sirilic code des commandes dans le script avec le nom sans l'extension .fz, cela génère un échec Modification préconisée: utilisation de .fit.fz au lieu de .fit si "setcompress" est different de "0" voir sujet ici Cordialement, Stephane

Il ne faut pas les ajouter Le newton est annoncé avec un back focus de 69mm --> cela signifie que le foyer sort de 69mm par rapport au bord du porte oculaire rétracté. Si tu y monte un alpy600 avec module de calibration et de guidage, alors la fente d'entrée du spectre va être à 64mm de l'entrée de l'alpy et donc lors de la mise au point ton PO sortira de 5mm pour que le foyer du newton soit situé sur la fente d'entrée de l'Alpy. Derrière l'alpy, tu peut mettre une camera qui a entre 10.5 et 20mm de tirage optique, avec 13mm c'es OK tu pourra faire la mise au point. Important: il y a 2 mises au point: la mise au point du newton focalisé sur la fente de l'alpy, et en sortie de l'alpy, le flux du spectre lumineux étalé, qui doit être mis au point sur le capteur de la camera Tu peux télécharger la doc e l'alpy sur le site Shelyak https://www.shelyak.com/produit/alpy-600/ Cordialement

Bonjour, Pour info, il y en a un en vente sur ebay pour 300 dollars US (vendeur au Texas) https://www.ebay.com/itm/134218635811 Cordialement

Suite à la lecture (en diagonale) de la doc du K-3 J'ai une possible piste Chez Pentax il y a 2 modes longues poses, le mode B et le mode T Le mode B, c'est: on appuie sur le déclencheur, puis on relâche au but du temps voulu, le temps de pose étant le temps écoulé entre l'appui et le relâchement, c'est le mode normal souhaité Le mode T c'est: on appuie et on relâche le déclencheur, cela démarre la pose, et pour stopper la pose on appuie et relâche une deuxième fois Si ton Pentax est en mode T cela pourrait expliquer pourquoi tu obtiens une photo sur 2 avec l'intervalomètre externe (mais tu devrais avoir le même fonctionnement en utilisant le bouton de déclenchement à la main) Pour vérifier si le mode B fait du B ou du T, il faut aller dans les menus de config, preférences perso (menu C1), option 7 nommée "option mode B" qui peut prendre la valeur "Mode 1" ou "Mode 2". Le mode 1 est le comportement que l'on souhaite (pose B standard), le mode 2 c'est ce que pentax appelle la pose T. Ceci étant ce n'est qu'une piste, pas forcement la solution (si ton APN en en mode "pose T" tu devrais déjà t'en être rendu compte en faisant une pose bulb à la main avec le bouton de déclenchement) Cordialement

@lock042Bonjour. Je ne sais pas si il s'agit d'un comportement voulu ou d'un bug, mais la version 1.2.0 me génère des fichiers .fit.fz ou lieu de .fit Est ce lié au fait que je demande dans les options à compresser les fit ?, sachant qu'avec la version 1.0.6 je compresse aussi les fit et Siril me génère des .fit pas des .fit.fz Dans les scripts pour les séquences ce n'est pas vraiment un problème car le fichier sequence contient visiblement une option fz_flag et tant que l'on appelle des commandes avec des noms de sequences c'est OK, Siril trouve les fichiers. Le problème c'est quand on génère les master flat et dark, même si on utilise une option "-out=master-dark.fit" il y a systématiquement l'extension .fz qui est ajouté, et donc quand on veut utiliser le fit du master généré, si on demande à siril de prendre le .fit il ne le trouve pas Est ce une anomalie ou bien est ce voulu (dans ce cas je vais devoir modifier mes scripts ) note: test fait avec Siril 1.0.6 e 1.2.0-beta2 sous MacOS 10.14 Mojave (oui, un OS obsolete) Edit de dernière minute: une fois de plus cela confirme que lire la doc est important, c'est expliqué ici https://siril.readthedocs.io/en/latest/preferences/preferences_gui.html#fits-options Ceci étant mon opinion (qui vaut ce qu'elle vaut) c'est que l'ajout de cette extension .fz c'est galère, certains softs ne la gèrent pas Cordialement, Stephane