keymlinux

Bonsoir, Dans le plugin pour ajouter la Terre sur une image solaire, dans la saisie de l'année il n'est plus possible de sélectionner une année antérieure à l'année courante, ce qui pose problème pour traiter des images en retard, ou pour retraiter d'anciennes images. Cordialement

Bonjour, Concernant l'initialisation des polices au premier lancement: - le touch ne suffit pas, j'ai aussi du supprimer la config du plugin qui avait été sauvegardée - cette config n'est plus dans un fichier "~/pyGapM27rc", mais dans "~/Library/Application Support/GIMP/3.0/plug-in-settings/GimpProcedureConfigRun-GapM27DeepSkyCartridge.last" (il y a en fait un fichier différent par plugin) - cela fonctionne tres bien, d'ailleurs le temps de chargement de la fenêtre du plugin a réduit (passant de 8sec à moins de 3sec) Par contre je rencontre un nouveau soucis. A priori tu as mis une borne supérieur (valeur 100) à la "taille de la zone d'information du bas" pour tous les cartouches alors qu'avant cette valeur n'était pas limitée (j'utilise habituellement une valeur entre 200 et 250 avec mes images qui font 6000x4000) Cordialement

Test de la dernière version sur MacOS Test du plugin GapM27DeepSkyCartridge - lors de l'appel du plugin le délai d'attente pour l'affichage de la fenêtre est de 8 à 10 secondes, c'est mieux - voir ci dessous les messages d'avertissement que j'obtiens (gimp lancé vi la ligne de commande pour avoir la log) - sur les 6 selections de police, 5 sont vides, la 6 eme est bien initialisée 1er cas: si je tente de générer la cartouche à ce stade (avec des polices "vides", j'ai des message d'erreur, voir ci dessous) 2eme cas: si je sélectionne des polices -- aucun délai notable additionnel pour obtenir la liste des police, la liste est obtenue tres rapidement, la selection est facile -- pas de message d'erreur lors de la generation du cartouche si les polices ont bien été sélectionnées préalablement Message au lancement du plugin GapM27DeepSkyCartridge Procedure 'GapM27DeepSkyCartridge': no mnemonic for property inner-size Procedure 'GapM27DeepSkyCartridge': no mnemonic for property inner-color Procedure 'GapM27DeepSkyCartridge': no mnemonic for property outer-size Procedure 'GapM27DeepSkyCartridge': no mnemonic for property outer-color Procedure 'GapM27DeepSkyCartridge': no mnemonic for property gauss-radius Procedure 'GapM27DeepSkyCartridge': no mnemonic for property info-height Procedure 'GapM27DeepSkyCartridge': no mnemonic for property font-color Procedure 'GapM27DeepSkyCartridge': no mnemonic for property text-left1 /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Core-CRITIQUE: gimp_object_get_name: assertion 'GIMP_IS_OBJECT (object_typed)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Core-CRITIQUE: gimp_object_get_name: assertion 'GIMP_IS_OBJECT (object_typed)' failed Procedure 'GapM27DeepSkyCartridge': no mnemonic for property font-name-left1 Procedure 'GapM27DeepSkyCartridge': no mnemonic for property font-size-left1 Procedure 'GapM27DeepSkyCartridge': no mnemonic for property text-left2 /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Core-CRITIQUE: gimp_object_get_name: assertion 'GIMP_IS_OBJECT (object_typed)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Core-CRITIQUE: gimp_object_get_name: assertion 'GIMP_IS_OBJECT (object_typed)' failed Procedure 'GapM27DeepSkyCartridge': no mnemonic for property font-name-left2 Procedure 'GapM27DeepSkyCartridge': no mnemonic for property font-size-left2 Procedure 'GapM27DeepSkyCartridge': no mnemonic for property text-middle1 /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Core-CRITIQUE: gimp_object_get_name: assertion 'GIMP_IS_OBJECT (object_typed)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Core-CRITIQUE: gimp_object_get_name: assertion 'GIMP_IS_OBJECT (object_typed)' failed Procedure 'GapM27DeepSkyCartridge': no mnemonic for property font-name-middle1 Procedure 'GapM27DeepSkyCartridge': no mnemonic for property font-size-middle1 Procedure 'GapM27DeepSkyCartridge': no mnemonic for property text-middle2 /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Core-CRITIQUE: gimp_object_get_name: assertion 'GIMP_IS_OBJECT (object_typed)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Core-CRITIQUE: gimp_object_get_name: assertion 'GIMP_IS_OBJECT (object_typed)' failed Procedure 'GapM27DeepSkyCartridge': no mnemonic for property font-name-middle2 Procedure 'GapM27DeepSkyCartridge': no mnemonic for property font-size-middle2 Procedure 'GapM27DeepSkyCartridge': no mnemonic for property text-right1 /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Core-CRITIQUE: gimp_object_get_name: assertion 'GIMP_IS_OBJECT (object_typed)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Core-CRITIQUE: gimp_object_get_name: assertion 'GIMP_IS_OBJECT (object_typed)' failed Procedure 'GapM27DeepSkyCartridge': no mnemonic for property font-name-right1 Procedure 'GapM27DeepSkyCartridge': no mnemonic for property font-size-right1 Procedure 'GapM27DeepSkyCartridge': no mnemonic for property text-right2 Procedure 'GapM27DeepSkyCartridge': no mnemonic for property font-name-right2 Procedure 'GapM27DeepSkyCartridge': no mnemonic for property font-size-right2 Procedure 'GapM27DeepSkyCartridge': no mnemonic for property resize note: lors des appels suivants, si les polices sont initialisées (lues dans le fichier de config, il n'y a plus les messages "Gimp-Core-CRITIQUE", seuls restent les messages "no mnemonic" Message d'erreur si generation du cartouche avec des polices non initialisées /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Text-CRITIQUE: text_get_extents: assertion 'GIMP_IS_FONT (font)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Text-CRITIQUE: text_get_extents: assertion 'GIMP_IS_FONT (font)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Text-CRITIQUE: text_get_extents: assertion 'GIMP_IS_FONT (font)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Text-CRITIQUE: text_render: assertion 'GIMP_IS_FONT (font)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Text-CRITIQUE: text_get_extents: assertion 'GIMP_IS_FONT (font)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Text-CRITIQUE: text_render: assertion 'GIMP_IS_FONT (font)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Text-CRITIQUE: text_get_extents: assertion 'GIMP_IS_FONT (font)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Text-CRITIQUE: text_get_extents: assertion 'GIMP_IS_FONT (font)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Text-CRITIQUE: text_get_extents: assertion 'GIMP_IS_FONT (font)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Text-CRITIQUE: text_render: assertion 'GIMP_IS_FONT (font)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Text-CRITIQUE: text_get_extents: assertion 'GIMP_IS_FONT (font)' failed /Applications/GIMP-v3.app/Contents/MacOS/gimp: Gimp-Text-CRITIQUE: text_render: assertion 'GIMP_IS_FONT (font)' failed (gimp:61104): Gtk-CRITICAL **: 14:04:30.879: gtk_menu_tracker_remove_items: assertion '*change_point != NULL' failed (gimp:61104): Gtk-CRITICAL **: 14:04:30.879: gtk_menu_tracker_remove_items: assertion '*change_point != NULL' failed (gimp:61104): Gtk-CRITICAL **: 14:04:30.879: gtk_menu_tracker_remove_items: assertion '*change_point != NULL' failed (GapM27DeepSkyCartridge.ui:61125): LibGimp-WARNING **: 14:04:32.117: _gimp_procedure_run_array: no return values, shouldn't happen Test du plugin "GapM27AddEarth" - délai d'affichage de la fenêtre de 2 à 3 secondes, c'est OK - plus de "sliders" mais une zone de selection de valeur numérique, c'est parfait - le champ "police" est bien initialisé, pas de message d'erreur "Gimp-Core-CRITIQUE", seuls quelques avertissement "no mnemonic" - pas de problème particulier Procedure 'GapM27AddEarth': no mnemonic for property day Procedure 'GapM27AddEarth': no mnemonic for property month Procedure 'GapM27AddEarth': no mnemonic for property year Procedure 'GapM27AddEarth': no mnemonic for property PixelSize Procedure 'GapM27AddEarth': no mnemonic for property Focal Procedure 'GapM27AddEarth': no mnemonic for property Barlow Procedure 'GapM27AddEarth': no mnemonic for property font Procedure 'GapM27AddEarth': no mnemonic for property font-size Procedure 'GapM27AddEarth': no mnemonic for property font-color Je vais poursuivre mes tests. Cordialement, Stéphane

Je viens de re-telecharger et re-tester, pas vu de différence. (chrono 22secondes avec le macbook sur secteur, 34sec sur batterie 😭 ) Lorsque j'ouvre par exemple le plugin "GapM27DeepSkyCartridge", j'ai tout d'abord plus de 20sec d'attente pour avoir la fenêtre principale, puis j'ai 3 à 4 secondes d'attente pour avoir la liste des polices si je clique sur une des 6 zones de selection de police. Cela m'invite a penser que lors de l'ouverture du plugin il fait 6 fois le listing des polices (même si on ne souhaite rien changer ensuite), donc 6 fois 3 à 4 sec mais en une seule attente de plus de 20 secondes, puis il refait la liste dès que l'on clique sur un bouton de selection de police. D'où ma question, si on souhaite utiliser la police par défaut, ne peut t'on pas l'empêcher de construire "pour rien" 6 fois la liste des polices à l'initiation du plugin ? EDIT; autre sujet non relatif aux polices mais aux réglages numériques avec "sliders" et possibilité ou pas de saisir une valeur numérique Perso je trouve que la selection d'une valeur numérique avec un "slider" ce n'est pas précis, alors je préfère saisir une valeur numérique lorsque c'est possible Avec GIMP v2, dans le plugin pour ajouter l'image de la Terre sur une image solaire, il y avait des sliders pour choisir par exemple la focale, avec possibilité de saisie. Avec Gimp v3, pour le même plugin il y a les sliders mais plus les zones de saisie. On peut pas les remettre ? Gimp v2 Gimp V3 Cordialement, Stéphane

Plusieurs constats - cela ne "crash" plus, la selection des polices est possible - quand tu dis "un poil plus lent", c'est un "gros" poil, après selection du menu, il faut 18 secondes pour afficher la fenêtre des options du plugin (mon macbook a un quad core i7 avec stockage nvme ...) - avant j'avais les menus en anglais, désormais ils sont en français, bien que j'ai toujours les messages suivants [GapM27DeepSkyCartridge] The catalog directory does not exist: /Users/stephane/pygap-m27-gimp3/pythonfu-gimp3/CartridgeDeepSky/locale [GapM27DeepSkyCartridge] Override method set_i18n() for the plug-in to customize or disable localization. [GapM27DeepSkyCartridge] Localization disabled Cordialement, Stéphane

Avec la nouvelle version, même comportement. Le fichier "pyGapM27_stdout.txt" reste vide Par contre lorsque je lance Gimp en ligne de commande j'ai quelques infos loguées sur la console. La dernière ligne avec le "segmentation fault" est générée lorsque je tente de changer la police dans le plugin MLS-MBP:Downloads stephane$ /Applications/GIMP-v3.app/Contents/MacOS/gimp GIMP is started as MacOS application GIMP was built with MacPorts (gimp:28066): Gtk-CRITICAL **: 18:34:40.679: gtk_menu_tracker_remove_items: assertion '*change_point != NULL' failed (gimp:28066): Gtk-CRITICAL **: 18:34:40.884: gtk_menu_tracker_remove_items: assertion '*change_point != NULL' failed (gimp:28066): Gtk-CRITICAL **: 18:34:40.991: gtk_menu_tracker_remove_items: assertion '*change_point != NULL' failed bps: 32 Image dimensions: 6252 x 4176. load_contiguous bytes_per_pixel: 16, format: 16 (gimp:28066): Gtk-CRITICAL **: 18:35:10.383: gtk_menu_tracker_remove_items: assertion '*change_point != NULL' failed (gimp:28066): Gtk-CRITICAL **: 18:35:25.837: gtk_menu_tracker_remove_items: assertion '*change_point != NULL' failed [GapM27DeepSkyCartridge] The catalog directory does not exist: /Users/stephane/pygap-m27-gimp3/pythonfu-gimp3/CartridgeDeepSky/locale [GapM27DeepSkyCartridge] Override method set_i18n() for the plug-in to customize or disable localization. [GapM27DeepSkyCartridge] Localization disabled [GapM27DeepSkyCartridge] The catalog directory does not exist: /Users/stephane/pygap-m27-gimp3/pythonfu-gimp3/CartridgeDeepSky/locale [GapM27DeepSkyCartridge] Override method set_i18n() for the plug-in to customize or disable localization. [GapM27DeepSkyCartridge] Localization disabled /Users/stephane/pygap-m27-gimp3/pythonfu-gimp3/CartridgeDeepSky/CartridgeDeepSky.py: fatal error: Segmentation fault: 11

Je confirme, si on souhaite changer la police/taille dans les différents "DrawingCartridge"cela ferme la fenêtre de config plugin De plus, si on ne change pas manuellement la taille de la police mais que l'on coche l'option "automatic resize" en bas de page de config du plugin, cette option reste sans effet visible Cordialement

Enfin de quoi occuper ce week-end pluvieux 😇

Bonjour, Lors de la composition RVB l'alignement ne peut être que "simple" c'est a dire par translation Si tu as fait tes acquisitions sur 3 nuits tu as peut être en plus un peu de rotation à faire entre les 3 images pour les aligner, il faut donc faire un alignement (registration) avant la composition RVB - creer un repertoire vide - y mettre les 4 images à composer (L, R, V, B ) - dans siril aller dans l'onglet conversion, et ajouter les 4 images L R V B (dans cet ordre) pour créer une séquence - dans siril, aller dans l'onglet alignement pour la séquence précédente --> cela va créer 4 images ayant le préfix r_ dans leur nom et numérotées 1 2 3 4 (si tu as mis les images dans le bon ordre dans la séquence alors tu aura 1 pour L, 2 pour R, 3 pour V, 4 pour B - dans siril, faire une composition RVB avec les 4 images résultantes de l'alignement r_xxx numérotées de 1 à 4 EDIT: voir cette page de la doc Siril qui explique la manip Cordialement

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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