keymlinux

@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)

il y a 33 minutes, m27trognondepomme a dit :

Ne connaissant pas MacOs,  quelle éditeur de texte dois-je mettre dans le choix par défaut  ?

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,

il y a 20 minutes, Eric38 a dit :

le logiciel Coelix est mono-OS et pas de ceux que je pratique

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

il y a 22 minutes, Eric38 a dit :

le logiciel de calcul est-il purement 2D, ou bien ce n'est qu'un effet de la représentation ?

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)

il y a 23 minutes, Eric38 a dit :

Je ne sais pas si les orbites de Vénus et de Terre sont coplanaires, ou pas ; j'imagine qu'il y a une petite différence

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

Il y a 4 heures, Discret68 a dit :

Cela signifie à priori que je n'aurai pas non plus le soleil en totalité ! Flute.

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

Il y a 11 heures, 180Vision a dit :

Après "stacking", gardes-tu les fichiers d'origine néanmoins bruts/DOFs ?

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

Le 16/03/2023 à 11:40, Théo_lsle a dit :

e backfocus du spectro (avec module de guidage et calibration) est de 64mm et celui de la caméra est de 13mm. J'arrive donc à un backfocus total de 77mm.

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

il y a 10 minutes, Alhajoth a dit :

Intervallomètre, pas multimètre.

Non, il s'agit bien ici d'un test de  l'intervallomètre avec un multimètre pour verifier sa logique.

Les mesures confirment que l'intervallomètre fonctionne comme indiqué dans sa doc (ou aussi selon le schéma du bas dans l'image postée par Fred_76)

Je ne vois pas de problème dans cette logique, mais vu que sur ton APN l'obturateur ne se ferme pas en fin de pose mais seulement lors du debut de pose suivante, je reste sur l'idée qu elle mode relevage du miroir est activé

@fbarca@lock042Bonjour. En tut cas sur MacOs Mojave 10.14 je n'ai pas ce problème d'affichage du menu "scripts"

Bon, ayant pris mon courage a 2 mains, j'ai refais les tests avec les images pleine taille (6000x4000px et pas 1500x1000px)

Donc tu a bien utilisé ton objo à 300mm de focale (et pas 72)

Mais la taille moyenne de tes étoiles n'est plus de 3.4 pixels (ce chiffre ne m'avais pas choqué car c'est ce que j'obtiens avec mon APN) mais 4 fois plus grosses, on est a 12 pixels, c'est pas bon, et le findstar avec ses paramètres par défaut zappe les étoiles trop grosses

Donc ma première tentative d'alignement des 2 images est en échec (comme chez toi)

Par contre en augmentant le paramètre "rayon" de 10 à 20 c'est Ok (onglet alignement, clique sur le bouton avec le dessin d'engrenage, une fenêtre PSF apparaît passe le rayon à 20, ferme la boite de dialogue et relance l'alignement global ciel profond)

1) 1er test d'alignement avec les param par défaut : échec

23:55:40: Alignement : traitement en cours utilisant la méthode : Alignement global (ciel profond)
23:55:40: Alignement global sur les étoiles : avec la mémoire actuelle et les limites de threads, jusqu'à 4 thread (s) peuvent être utilisés
23:55:40: Recalcule les informations d'alignement déjà existantes pour ce canal
23:55:41: Lecture du fichier FITS : test2_00001.fit, 3 canal(aux), 6000x4000 pixels
23:55:41: Image de Référence :
23:55:41: Findstar : en cours...
23:55:42: 239 étoiles trouvées dans l'image référence, canal #1
23:55:42: FWHMx :       13.28 px
23:55:42: FWHMy :       11.23 px
23:55:42: Alignement global sur les étoiles : en cours...
23:55:43: Lecture du fichier FITS : test2_00002.fit, 3 canal(aux), 6000x4000 pixels
23:55:43: Findstar : en cours...
23:55:43: Lecture du fichier FITS : test2_00001.fit, 3 canal(aux), 6000x4000 pixels
23:55:44: Sauvegarde du fichier FITS : r_test2_00001.fit, 3 canal(aux), 6000x4000 pixels
23:55:46: 1076 étoiles trouvées dans l'image 2, canal #1
23:55:46: Impossible d'effectuer un alignement sur les étoiles : essai #3. Image 2 écartée
23:55:46: Le traitement de la séquence a partiellement réussi, avec 1 image(s) en échec et temporairement exclue(s) de la séquence.
23:55:46: Temps d'exécution: 6.23 s.
23:55:46: Alignement fini.
23:55:46: 2 images traitées
23:55:46: Total : 1 en échec, 1 alignées.
23:55:47: Lecture du fichier FITS : r_test2_00001.fit, 3 canal(aux), 6000x4000 pixels
23:55:47: Séquence chargée : r_test2_ (1->1)
23:55:47: Fermeture de la séquence test2_

2) 2eme tentative après le changement du paramètre "rayon" pour la detection d'étoiles
23:55:58: Lecture du fichier FITS : test2_00001.fit, 3 canal(aux), 6000x4000 pixels
23:55:58: Séquence chargée : test2_ (1->2)
23:55:58: Fermeture de la séquence r_test2_
23:56:12: Alignement : traitement en cours utilisant la méthode : Alignement global (ciel profond)
23:56:12: Alignement global sur les étoiles : avec la mémoire actuelle et les limites de threads, jusqu'à 4 thread (s) peuvent être utilisés
23:56:12: Recalcule les informations d'alignement déjà existantes pour ce canal
23:56:13: Lecture du fichier FITS : test2_00001.fit, 3 canal(aux), 6000x4000 pixels
23:56:13: Image de Référence :
23:56:13: Findstar : en cours...
23:56:16: 426 étoiles trouvées dans l'image référence, canal #1
23:56:16: FWHMx :       12.43 px
23:56:16: FWHMy :       10.42 px
23:56:16: Alignement global sur les étoiles : en cours...
23:56:17: Lecture du fichier FITS : test2_00001.fit, 3 canal(aux), 6000x4000 pixels
23:56:17: Lecture du fichier FITS : test2_00002.fit, 3 canal(aux), 6000x4000 pixels
23:56:17: Findstar : en cours...
23:56:18: Sauvegarde du fichier FITS : r_test2_00001.fit, 3 canal(aux), 6000x4000 pixels
23:56:28: 1204 étoiles trouvées dans l'image 2, canal #1
23:56:28: Correspondance des étoiles dans l'image 2 : finie
23:56:28: Paires correspondantes initiales : 385
23:56:28: Paires correspondantes après ajustement : 380
23:56:28: Pts OK :         0.987
23:56:28: échelleX :       1.002
23:56:28: échelleY :       1.001
23:56:28: échelle :        1.002
23:56:28: rotation :   +0.087 deg
23:56:28: dx :        +160.98 px
23:56:28: dy :          -1.20 px
23:56:28: FWHMx :       15.08 px
23:56:28: FWHMy :        9.93 px
23:56:30: Sauvegarde du fichier FITS : r_test2_00002.fit, 3 canal(aux), 6000x4000 pixels
23:56:30: Le traitement de la séquence a réussi.
23:56:30: Temps d'exécution: 17.52 s.
23:56:30: Alignement fini.
23:56:30: 2 images traitées
23:56:30: Total : 0 en échec, 2 alignées.
23:56:31: Lecture du fichier FITS : r_test2_00001.fit, 3 canal(aux), 6000x4000 pixels
23:56:31: Séquence chargée : r_test2_ (1->2)
23:56:31: Fermeture de la séquence test2_
 

Bilan: il faut absolument travailler la mise au point pour réduire la taille des étoiles. C'est facile avec un masque de bathinov sur un telescope, mais compliqué avec un objectif -->ce qui est compliqué ce n'est pas l'utilisation du masque, c'est de trouver un masque adapté aux courtes focales des objos