keymlinux

Bonjour, J'ai un soucis avec cette version 1.15.7 avec un projet en mode sessions LRGB (par contre pas de problème avec les projets DSLR mono ou multi sessions) Lors de la création du script j'ai les messages d'erreur suivants, et le script généré est incomplet: Traceback (most recent call last): File "/usr/local/lib/python3.10/site-packages/sirilic/lib/callbacks.py", line 959, in CB_BuildScript last_processed_image = builder.Build() File "/usr/local/lib/python3.10/site-packages/sirilic/lib/buildscript.py", line 412, in Build self.BuildScriptPart2() File "/usr/local/lib/python3.10/site-packages/sirilic/lib/buildscript.py", line 441, in BuildScriptPart2 last_processed_image_multi = script_multi.Build(self.script,self.arbre) File "/usr/local/lib/python3.10/site-packages/sirilic/lib/buildscript.py", line 873, in Build if layername == "R" : self.wplatesolveR = self.wplatesolve AttributeError: 'CMultisessionScript' object has no attribute 'wplatesolve'. Did you mean: 'platesolve'? A priori c'est lié aux derniers ajouts pour le platesolving Cordialement, Stephane

Tout a fait, mais je n'ai pas prétendu le contraire 😇, et çà passe bien sur un Arduino Mega, que j'ai utilisé et pas seulement pour les contraintes mémoires de la librairie Ephemeris, pour plein d'autres raisons dont le nombre de ports série (pour les modules gps et bluetooth), le nombre de ports gérant les interruptions (pour les encodeurs), etc...

Pour un projet de push-to perso j'avais utilisé la librairie arduino "Ephemeris" de @Mala voir ici https://github.com/MarScaper/ephemeris Cordialement

Bonjour, Pour adapter ton Canon sur un telescope tu auras besoin de 2 elements - une bague d'adaptation "Canon EOS - T2", à savoir une bague avec d'un coté une baÏonnette au format Canon et de l'autre un filetage T2 (M42x0.75 femelle), compter un peu moins de 20 euros, exemple ici https://www.pierro-astro.com/materiel-astronomique/accessoires-astronomie/accessoires-apn/bagues-canon-eos/bague-t2-pour-apn-canon-eos_detail - un adaptateur T2 - 1.25 pouces, à savoir un tube de diamètre 1.25pouces que tu glisseras dans le porte oculaire du telescope, doté d'un filetage T2 (M42x0.75) male qui sera vissé dans la bague précédente, ici aussi compter un peu moins de 20 euros, voir exemple ici https://www.pierro-astro.com/materiel-astronomique/accessoires-astronomie/accessoires-t2/adaptateur-photo-coulant-1-25-vers-t2_detail note: ce genre de matos est disponible dans toutes les boutiques astro Ta lunette 80ED est dotée d'un porte oculaire 2 pouces mais normalement tu devrais aussi avoir un adaptateur 2 pouces vers 1.25 pouces, donc la solution proposée ci dessus devrais fonctionner avec tes 2 telescopes Néanmoins, un tube 1.25 pouces pourrais causer du vignétage même sur un capteur APS-C, et il pourrais être intéressant de disposer aussi d'un adaptateur "T2 - 2 pouces" (qui ne pourra pas être utilisé avec le Mak, mais si tu as les 2 adaptateurs tu peux les visser dévisser en fonction du besoin) EDIT: en planétaire, le vignétage ne sera pas un problème, le passage au tube 2 pouces ne sera utile que si tu souhaite aussi faire de la photo de ciel profond avec des objets très étendus Attention, avec un smartphone derrière un oculaire tu pratique la "digiscopie", et tu profite du grossissement donné par le couple focale du tube et focale de l'oculaire. Mais avec un APN derrière un telescope, dans le montage proposé ci dessus, cela sera de la photo au foyer, et en mode planétaire avec le Mak pour la lune cela sera très bien, mais pour les autres planètes les objets seront petits sur la photo, sauf a utiliser une barlow Ci dessous un exemple de champ couvert sur la lune avec tes 2 telescopes Et sur Saturne (peu visible mais elle est bien là) Pour simuler le champs de ue en fonction du telescope, de l'oculaire ou imager, avec ou sans réducteur/barlow, voir ici https://astronomy.tools/calculators/field_of_view/ Cordialement

Bonjour, Une fois le plugin activé (option "charger au démarrage" coché) et configuré (normalement les options par défaut suffisent) , pour afficher les satellites il faut utiliser la combinaison de touches Ctrl+Z (et Shift+Z pour afficher les noms, et Alt+Z pour afficher le panneau de config) note: sur un Mac, au lieu de Ctrl+Z c'est Cmd+Z Cordialement

Bonjour, Ton réducteur correcteur x0.85 skywatcher est visiblement le modèle SW0182, il dispose d'un filetage M56 femelle pour se fixer sur la lunette et d'un filetage M48 male coté imageur Tu aura donc besoin de la bague d'adaptation pour APN Canon vers M48 femelle, référence SW0189, qui fait justement 11mm d'épaisseur. Une trentaine d'euros en boutique astro. exemple ici: https://www.pierro-astro.com/materiel-astronomique/accessoires-astronomie/accessoires-apn/bagues-canon-eos/bague-t-m48-pour-canon-eos_detail EDIT: sur la photo que tu fournis on distingue un tube d'environ 20mm de long entre l'adaptateur EOS (qui lui semble bien faire 11mm) et le réducteur. Si ce tube se dévisse, et si c'est un bête tube allonge M48 male vers M48 femelle alors il suffit de l'enlever pour avoir le bon backfocus Si par contre il est solidaire et non démontable de l'adaptateur EOS, alors il faudra utiliser un autre adaptateur EOS (voir lien ci dessus) Cordialement

Bonsoir. Merci pour les détails sur ton protocole de test. A priori avec la bague dédiée d'adaptation ASI vers Nikon on peut donc exclure un problème de distance de capteur. Même avec une bague dédiée, la grosse différence entre l'usage de l'objo avec ton APN et avec l'ASI c'est qu'avec l'APN l'objectif dispose d'une alimentation électrique et cela peut expliquer des différences de comportements en fonction des optimisations dont dispose (ou pas) ton objectif. Tu ne précise pas le modèle de ton objo 70-200 f2.8. Certains disposent d'une option de réduction de bougé (il me semble que chez Nikon ce sont les objo VR) --> des moteurs internes déplacent des blocs de lentilles pour contrer les mouvements --> en utilisation de ce genre d'objectifs avec une camera qui n'alimente pas l'objo je ne sait pas dans quel état de déplacement se trouvent les blocs de lentilles qui sont mobiles pour cette fonctionnalité --> cela pourrait expliquer la différence de map entre l'usage avec app et camera Un test qu'il serait possible de réaliser, c'est l'objo zoom avec l'apn, mais en mettant du scotch sur les contacteurs, pour que le boitier ne puisse pas piloter l'objo (comme la camera si qui ne peut le piloter), pour voir si l'objectif (et sa map) se comporte comme lorsque tu l'utilises avec la camera.

Bonjour, Je vois 2 possibles problèmes 1) comme l'a dit @Fred_76 la distance entre l'objectif (la partie qui viens se poser sur le boitier) et le capteur doit être respectée, c'est 46,5mm pour la monture Nikon F. Comment as tu connecté ta camera avec ton objectif ? avec une bague d'adaptation faite pour ? avec un adaptateur fait maison en impression 3D (pas un problème en soi, mais il faut être sûr des dimensions pour la distance objo-capteur) 2) Sur certains objectifs la mise au point n'est pas mécanique mais électrique, et si l'objo n'est pas connecté à un APN cela ne marche pas. Je ne connait pas les apn/objo Nikon, mais c'est à vérifier aussi Cordialement

Bonjour Robert, Il me semble que tout est expliqué ici https://siril.org/tutorials/synthetic-biases/ A la fois comment determiner le "multiplicateur" mais aussi comment l'utiliser dans Siril (voir le paragraphe "And now what ?") Si comme moi tu utilises Sirilic (et si ce n'est pas le cas tu devrais essayer, cela simplifie la vie) , il suffit au niveau de la liste des fichiers "bias" de faire "edit" et de mettre "=X*$OFFSET", avec X le multiplicateur déterminé Cordialement, Stéphane

Le nom du soft c'est "SBRCoach-Astro", dérivé du nom de son auteur 😉 Pour la dispo je laisse son auteur se prononcer...

Bonjour. Message d'erreur lors la tentative de téléchargement du PDF

Bonsoir, Les curseurs "Noms" et "Marqueurs" permettent de jouer sur la densité d'affichage de ces élements En clair, plus tu pousse ces curseurs vers la droite plus tu verras apparaitre les noms/marqueurs des objets du ciel profond, sans avoir à zoomer. Pour le reste je ne vais pas pouvoir t'aider, je n'utilise pas Stellarium pour générer des cartes. Pour la generation des cartes (et plein d'autre choses) j'utilise Coelix (logiciel est payant mais pas très cher pour une licence permanente) Cordialement, Stéphane

En codant une valeur sur 14 bits dans un raw on peut avoir 16384 valeurs, donc entre 0 et 16383 Pour rappel, dans un fichier jpeg c'est du 8 bits, donc des valeurs entree 0 et 255 par exemple Sur les cameras astro on peut régler un seuil, dit offset, qui est ajouté à la valeur lue venant du capteur. Sur un APN on ne peut pas le régler, le choix est fait par le constructeur. Par exemple sur mon canon 80D l'offset est de 2048 à 800iso. Cet offset sert à éviter le clipping, qui tendrait à envoyer 0 lors de la lecture de 2 valeurs proches de 0 Par exemple si je fais un dark, dans l'absolu tous les pixels devraient être à 0, mais on sait qu'il y aura des pixels chauds avec des valeurs supérieurs, mais les différents bruits et défaut d'homogénéité du capteur peuvent aussi amener à lire des valeurs inférieures, mais inférieur a 0 sur un entier positif c'est pas possible, d'où l'offset ajouté. Exemple sur un dark (exposition de 60s à 800iso, température du capteur de 5° en février dernier), j'obtiens une moyenne de 2047.5, une médiane de 2048.0, mais avec un max de 16383 (pixel chaud saturé) et un min à 1883. Si il n'y avait pas d'offset, toutes les valeurs entre 1883 et 2047 auraient renvoyé 0 générant du clipping Voir le sujet sur les offset synthétiques ici https://siril.org/fr/tutorials/synthetic-biases/ Et un petit rappel sur les DOFs, dont les offsets ici https://sahavre.fr/wp/les-dofs/ Cordialement

Bonsoir, Concernant NINA, je n'utilise pas donc je ne peux pas t'aider sur ce logiciel en particulier, j'utilise Kstars/Ekos/Indi, mais si l'outil est différent, la méthode est la même, il y a aussi un module "automatique" peu fiable ici aussi, et au final je fais comme @Tyler je cherche le bon temps de pose en faisant plusieurs essais en visant un histogramme au 2/3 Concernant les flats que tu obtiens et les stats Siril: Tu dis utiliser un APN mais tu ne donne de pas de détail sur son modèle. Moi par exemple j'utilise en Canon80D, il génère des raw avec des valeurs sur 14 bits, donc les valeurs obtenues sont entre 0 et 16383 (2 puissance 14 = 16384) (en fait des valeurs entre 2000 et 16383 à cause de l'offset). Si ton APN sort lui aussi des valeurs sur 14 bits(supposition) alors au vu des stats que te donne Siril cela me semble très bien, tu a des valeurs mini et maxi qui restent dans la fourchette acceptable, ni trop basse (risque de clipping) ni trop haute (risque de saturation) EDIT: ensuite le problème récurent des écrans ou boites à flat, qu'ils soient achetés tout fait ou bricolés, c'est que le spectre lumineux est rarement homogène (les leds cela tire sur le bleu), mais cela est rarement un problème sauf si utilisation de filtres très sélectifs avec une camera mono par exemple Voir sujet ci dessous: Cordialement

Je viens de tester la version 1.15.6-2, c'est très bien, je pense que tu vas pouvoir officialiser la version. Merci encore pour le travail réalisé et pour ta réactivité. Cordialement, Stéphane

Bonjour, Je vous présente ici la réalisation d'un support pour la réalisation de Flats (PLU) avec un panneau electroluminescent. Donc pas vraiment une boîte à flat avec des leds... Le but: - Pouvoir réaliser des flat sur mon C8 (qui vignette beaucoup avec son réducteur) et avec mon newton 10 pouces Les choix: - Utiliser un panneau electroluminescent rond de diamètre 25cm (compter 40 euros environ, voir ici https://fr.aliexpress.com/item/32906156429.html) - une feuiille de plastique blanc souple pour protéger le panneau (et créer un peu de diffusion), différents formats et densités (plus ou moins transparents), exemple ici: https://fr.aliexpress.com/item/1005004847370228.html - oui je fais le choix de ne pas bricoler une vraie boite à flat avec des led et une alimentation --> l'impression 3D je trouve cela fun, le bricolage électrique et les soudures c'est moins fun (avis perso) Les fichiers STL sont disponibles ici: https://www.tinkercad.com/things/3YRGqgK3p8b-support-flat-25cm-v1 et aussi ici sur Webastro: Le panneau electroluminescent diamètre utile 25cm (avec son transfo 12V) Il a une apparence "rose", mais une fois allumé il éclaire bien en blanc (blanc "froid" comme nous le ferons plus tard) Le transformateur dispose d'une entrée 12V DC (prise standard 5.5mm exterieur, 2.1mm intérieur), et d'un interrupteur 3 positions éteint/clignotant/eclairé Les 4 arcs de cercle blancs sont imprimés 3D en PLA blanc, ils servent de cales et de diffuseurs sur le bord du panneau Le modèles 3D, vue complète Le modèle 3D, vue éclatée Les pièces du support imprimées en PETG noir note: le diamètre total est de 29cm, mon imprimante est limitée à une surface d'impression de 25cmx25cm, donc 5 secteurs à assembler Important: toutes les pièces imprimées 3D le sont avec un remplissage 20%, une buse de 0.4mm et une hauteur de couche de 0.2mm Pour l'assemblage, prévoir: 8 vis M3 longueur 14mm 4 vis M3 longueur 6mm 8 écrous M3 Un petit zoom sur une des 4 parties, dotée d'un creusement pour laisser passer le connecteur du panneau electroluminescent La version assemblée (éteinte) Et allumée notes: - pour protéger le panneau et créer un peu de diffusion, j'ai ajouté une feuille de plastique blanc. - j'ai opté pour une feuille autocollante, et pour ne pas la coller sur le panneau j'en ai coupé 2 feuilles collées l'une sur l'autre. - lors du collage, des bulles d'air ont été emprisonnées (à refaire donc), ce qui explique les taches sombre visibles sur la version allumée Après utilisation pour réaliser quelques FLATs, il apparait que le panneau electroluminescent n'a pas une lumière "blanche" équilibrée, il y a un déficit de rouge et un surplus de bleu/vert (mais je m'en doutais, je ne suis pas vraiment surpris) J'ai fait des tests avec le panneau electroluminescent seul (sans la feuille plastique blanche), et complet (avec la feuille plastique A noter que la feuille plastique absorbe plus le pic bleu/vert que le orange rouge, ce qui m'arrange Spectre lumineux du panneau electroluminescent (sans feuille plastique) Spectre lumineux du panneau avec feuille plastique On note que le pic bleu/vert est plus absorbé que le reste (bon après, vu les conditions dans lesquelles j'ai fait les tests, la qualité de la mesure laisse à désirer) Les statistiques SIRIL d'un FLAT (prise unique sans pré-traitement) note: mon APN Canon donnes des valeurs sur 14bits (0-16383) (en fait 2047-16383 avec l'offset) Un master flat (20 flats empilés avec soustraction d'offset) On note bien le déficit sur le canal rouge, mais à l'usage ce n'est pas vraiment un problème (Siril sait égaliser les canaux) Bilan: Pour moins de 50 euros, j'ai une "boite à flat" fonctionnelle pour le C8 et le Newton 10 pouces, alimentée en 12V DC en nomade Cordialement, Stéphane

Version 1.15.6.1 testée - Les point 3, 4, 5 et 6 sont résolus. - Le point 2 est contourné 🙂 en réduisant la taille du changelog (je sais, je pinaille, le contournement me vas très bien) - Le point 1 est contourné en forçant le lancement de Sirilic en mode plein écran. Mais le problème reste entier si on repasse en mode fenêtré où la fenêtre reste plus grande que le bureau (voir ci dessous pourquoi je déteste les applications qui se lancent en forçant le mode plein écran) - Pour le point 6, c'est OK à un détail près, à savoir les cases à cocher dont le fond semble transparent et qui restent peu visibles en thème "Sombre",, mais ici aussi, je pinaille, cela peut rester comme cela. Aucune anomalie (possible régression) constatée. Histoire de raconter ma vie, le pourquoi je n'aime pas les applications qui se lancent en forçant le mode plein écran - par choix personnel: je préfère le mode fenêtré (les goûts, le couleurs, ...) - par choix pratique: en plus d'un macbook, j'ai aussi un PC de bureau sous Windows, principalement pour faire du FlightSimulator, avec 3 écrans agrégés en 1 seul virtuel (AMD Eyefinity) --> si une application se lance en mode plein écran alors je me retrouve avec une fenêtre de 5760x1200 qui s'étale sur les 3 écrans --> affreux 😉 Cordialement

Bonjour. Oui, c'est compliqué, et d'autant plus que sur certains OS (dont MacOS) l'éditeur ne fait rien pour faciliter les choses, bien au contraire en faisant tout pour garder un système fermé. Tant que c'est cosmétique ce n'est pas important, et le manque d'icônes dans les menus ne me gène pas. J'en profite pour lister ci dessous certains autres problèmes cosmétiques (dont certains sont spécifiques MacOS), qui ne sont pas liés à la dernière version mais présents historiquement... 1) WINDOWS+MACOS: au lancement de Sirilic, la fenêtre principale est en mode fenêtrée (pas plein écran), mais sa hauteur est supérieure à la taille du bureau, il faut redimensionner à chaque fois si on veut rester en mode fenêtre (ou passer en plein écran qui redimensionne automatiquement))... 2) WINDOWS+MACOS: la fenêtre a propos s'ouvre systématiquement avec une hauteur égale à la taille du bureau, elle n'est pas redimensionnable, mais tout le contenu n'est pas visible et pas de possibilité de faire un scroll (peut être ajouter une barre d'ascenseur...) 3) MACOS: dans l'onglet "log", en bas, le champ de recherche est trop petit 4) MACOS: dans les boites de dialogues "nouveau projet"/"modifier un projet" les champs de saisie "nom de l'objet" et "nom de session" sont trop petits 5) MACOS: dans l'onglet "fichiers", le nouveau bouton "charger les fichiers avec un motif", problème de lisibilité, bouton et police de caractère un peu petits 6) MACOS: dans le nouvel éditeur, problème de visiblité des numéros de lignes si utilisation du thème "Sombre" de MacOS 7) MACOS: dans l'onglet propriété, ici aussi divers problème de visibilité si utilisation du mode "sombre" on note: - affichage peu lisible en blanc sur beige dans les lignes "prétraitements"/"alignement"/"detection d'étoiles"... - ici la case à cocher "detection d'étoiles" est cochée et visible, mais si non cochée la case est quasi invisible en beige sur fond beige - même problème pour la case à cocher "correction cosmétique", non cochée la case apparait (difficilement) mauve sur fond mauve Voilà, mais tout cela n'est que cosmétique, on peut faire avec, et cela n'enlève rien au fonctionnalités de Sirilic. Merci encore pour tout tes efforts et pour le temps que tu investit dans le développement de ce logiciel. Cordialement, Stéphane edit: la section 6 en double ci dessus est re-numérotée 7...

Sirilic 1.15.5 testé sur MacOs 10.14 Mojave. Pas d'icones visibles dans les menus. Pour le reste, aucune anomalie constatée.

Bonjour, Les Lights ce sont les photo de l'objet que tu desire imager, donc c'est obligatoire 🙂 L'usage des Dark/Flat/Bias n'est pas obligatoire, mais cela améliore la qualité du résutlat final. Un très bon tutoriel ici: L'auteur propose de télécharger un lot d'images (light/dark/flat/bias) pour que l'on puisse s'entrainer

Avec ce fichier, aucun changement Là par contre c'est mieux - dans la fenêtre de l'éditeur, le menu fichier "ouvrir/sauvegarder/sauvegarder sous" est fonctionnel, les raccourcis clavier aussi - dans la fenêtre principal de sirilic, les menus sont ok aussi, le passage d'un onglet un autre est fonctionnel aussi EDIT: et comme les bugs çà vole en escadrille, voici quelques autre bizarreries - quand j'ouvre le menu à propos j'ai un message d'erreur - et c'est un détail, mais dans la fenêtre "a propos", qui s'ouvre quand même malgré le message précédent, il faudrait corriger le lien vers le gitlab, il y a https://gitlab.com/free-astro/pysolarscan au lieu de https://gitlab.com/free-astro/sirilic Cordialement

Bonsoir, Testé avec le nouveau fichier, pas de modification du comportement, les menus restent grisés (ceux de la fenêtre d'edition, et ceux de la fenêtre principale sirilic). Cordialement

Non le raccourci CMD⌘+S ne fonctionne pas non plus