keymlinux

C'est exact, j'ai juste voulu montrer qu'un filtre n'est pas parfait, ce n'est pas du tout ou rien, style 0% ou 100%, un filtre bleu laissera passer un peu du reste aussi (et c'est comptabilisé dans l'intensité du bleu)... Pour un photosite équipé d'un filtre bleu, la valeur d'intensité est obtenue par la lecture du voltage du photosite, pour la valeur d'intensité verte et rouge qui va lui être attribuée lors du dématricage, elle sera obtenue par interpolation des valeurs des phoposites voisins équipés respectivement des filtres vert et rouge Oui, le filtre (matrice de bayer) bouffe une partie du signal. Pour simplifier le propos l'auteur parle de 30% de perte moyenne, mais la courbe fournie ci dessous pour les canaux couleur montre que cela n''est pas 30% mais que cela dépend de la longueur d'onde considérée. Mais donner un ordre de grandeur reste très valable pour ne pas noyer le lecteur dans des explications techniques (on peut vouloir faire de la photo sans connaitre les détails du fonctionnement du capteur, ou encore utilise rune voiture sans connaitre les détails d'un moteur à combustion) Des lors qu'il y a calcul d'interpolation il y a perte de définition. Je vais tenter de donner une explication plus détaillée. Sur le capteur, chaque photosite va percevoir les photons venant d'une partie du ciel, on va parler d'échantillonnage en arcseconde/pixel. Imaginons que nous ayons un couple capteur plus telescope permettant d'avoir une résolution de 1 arcsec/pixel. Sur un capteur monochrome aucun photosite n'a de filtre. Par contre sur le capteur couleur les photosites auront des filtres RVB en alternance, imaginons que nous ayons un groupe de pixels contigus RVBRVBRVB (dans les faits ils ne sont pas dans cet ordre sur un capteur, on a plutôt des blocs de RVVB disposés en carré, mais peu importe, je met 3 groupes RVB sur la même ligne pour faciliter la démo) Sur le capteur monochrome, prenons aussi 9 pixels qui se suivent Si je fais une image avec un filtre vert, j'obtiens bien pour chacun des 9 photosites l'intensité de lumière verte qui sera reçue de la partie du ciel qu'il représente (1 arc seconde de hauteur et 1 arc seconde de largeur pour chaque pixel dans notre exemple) Puis si je fais pareil avec un filtre bleu et rouge, j'obtiens bien pour chacun des photosites (et donc de la portion de ciel) la bonne indication sur l'intensité reçue de chaque couleur pour la portion de ciel considérée Donc sur le capteur monochrome, j'ai bien pour les 9 photosites les "vraie" intensité de chacune des 3 couleurs, et ces informations reflètent vraiment la proportion de lumière verte, bleue ou rouge reçue de ces parties du ciel . Avec le capteur couleur, sur le 1er photosite rouge je vais obtenir la "vraie" info du rouge, mais pour ses valeurs bleues et vertes je vais INVENTER une valeur en calculant une moyenne par rapport aux autres pixels vert ou bleus les plus proches. Mais ces pixels verts ou bleus proches ne représentent pa la même portion de 1 arc seconde sur le ciel. Si il y a un peu de gaz qui rayonne en Oiii (bleu vert) très localisée dans cette partie du ciel, mais pas sur les pixels voisins, alors mon interpolation va calculer une valeur proche de 0 pour le bleu et vert de ce pixel parce que les voisins sont presque à zéro, mais cela ne reflétera pas la "vraie" valeur que l'on devrait obtenir si on était capable de capter le bleu/vert réellement émis pas cette partie du ciel. C'est en ce sens que l'on perd en définition. Il y a un lissage dû aux calculs de moyenne, pour chaque pixel on a une valeur de couleur (bleu ou vert ou rouge) et on "invente" les 2 autre valeur manquantes en faisant une moyenne des valeur obtenue à coté, et à coté cela veut à la fois dire les photosites d'à coté, mais aussi les parties du ciel qui sont à coté, c'est en cela que cela dégrade la qualité de l'image Et ici aussi les 45% annoncés correspondent à une moyenne, on perd moins sur le vert que sur le bleu et le rouge. C'est du au fait que 50% des photosites du capteur sont pour le vert, 25% rouge et 25% bleus. Ce choix (mettre plus de photosites avec filtre vert que rouge ou bleu) n'est pas anodin, il est liée au fait que l'oeil humain est plus sensible dans le vert (et ce n'est pas par hasard non plus, c'est là que notre Soleil à son pic d'émission dû à sa température de surface...) En résumé, après dématricage, 100% des pixels de l'image ont bien une valeur pour le vert, une pour le rouge et une pour le bleu, mais pour chaque pixel 2 des 3 valeurs ont été calculées par moyenne et c'est ce calcul qui génère la perte de résolution Oui, je pense qu'il y a du vrai la aussi, il n'y a certainement pas seulement de la logique commerciale, les chaines de fabrications ne sont peut être pas les mêmes et les lots produits, certainement plus petits pour le monochrome ne permettent pas la même répartition des coûts De mon coté - une PlayerOne Poseidon-C (IMX571 pour faire du ciel profond en "one shot", et un peu de SHO avec des filtres dual-band, en 2 prises de vue) - une ASI290mm, monochrome dédiée guidage, parce que la sensibilité est meilleure pour les poses courtes du guidage - une ASI178mm, monochrome, utilisée pour la spectro (avec un Sol'ex) et l'imagerie lune et soleil, parce qu'avec une monochrome la résolution est meilleure et que capter la couleur n'est pas indispensable sur ces cibles (à part la lune et le soleil je ne fais pas de planétaire) Voila. Garde à l'esprit que mes réponses reflètent mon expérience et les éléments que j'ai pu lire de ci et de là, éléments que j'ai pu mal comprendre ou interpréter de manière erronée, donc je ne prétend pas que ce que j'écris ne soit pas entaché d'inexactitudes. Je te fais confiance pour recouper ces infos avec d'autres sources Cordialement, Stéphane

Bonjour, En cas d'utilisation du correcteur de coma, tu vissera les filtres devant le correcteur, donc ils ne modifierons pas le backfocus (le rajout de 1/3 de l'épaisseur du filtre c'est seulement si il est intercalé entre le correcteur et le capteur) La contrainte pour les flats tu l'aura dans tout les cas, on les fait pour chaque filtre, et c'est vrai aussi avec un tiroir (ou avec des filtres clip aussi), même si le tiroir n'oblige pas à un démontage du chemin optique, car chaque filtre peut générer un vignettage différent. Cordialement

Donc plutôt que panchromatique il serai préférable d'utiliser polychromatique Pan --> tous (comme dans Pangée, Panthéon) poly --> plusieurs (comme dans Polytechnique) Un photosite ets sensible a une large gamme de longueur d'ondes mais pas toutes , polychromatique EDIT: oui. La première courbe présentée (la sensibilité du capteur monochrome) est une courbe "absolue", la seconde pour la camera couleur est "relative", elle s'applique relativement à la courbe du capteur mono Par exemple: Imaginons de la lumière verte à 530nm de longueur d'onde. Sur le capteur monochrome on a statistiquement 91% (1ere courbe mono) des photons incidents qui vont générer le piégeage d'un électron Sur le capteur couleur à cette longueur d'onde 100% des photons (2eme courbe) vont passer à travers le filtre VERT et 91% (1ere courbe) de ceux qui sont passés vont générer le piégeage d'un électron dans le photosite (ici on est dans le cas de la seule longueur d'onde où on à la même sensibilité entre le capteur mono et celui couleur, parce qu'a cette longueur d'onde le filtre vert laisse passer 100%. Par contre sur le même capteur couleur et à la même longueur d'onde, si le photosite est équipé d'un filtre BLEU, alors seulement 10 à 15% (2eme courbe) des photons vont passer le filtre bleu, et parmis ceux qui sont passés, seuls 91% vont générer le piégeage d'un électron --> 0.1x0.9=0.09 --> 9%du signal Si maintenant on veut voir la sensibilité dans le bleu(différence entre les 2 capteurs) Imaginons de la lumière bleue à 450 nm Sur le capteur mono, on aura statistiquement environ 77% des photons incidents qui vont générer le piégeage d'un electron (1ere courbe) Sur le capteur couleur, pour la même longueur d'onde, le filtre BLEU va statistiquement laisser passer 77% (courbe 2) des photons, et pour ceux qui sont passés seulement 77% (courbe 1) vont générer le piégeage d'un electron, donc au final on a statistiquement 59% (0.77*0.77=0.592) des pixels incidents à l'entrée du filtre BLEU qui vont générer le piégeage d'un électron dans le photosite. Ici on voit bien la différence de sensibilité pour une même longueur d'onde entre les 2 capteurs Donc oui, le filtre (la matrice de bayer) absorbe du flux, donc au final le capteur (avec filtre) d'une camera couleur est moins sensible que la même version monochrome Tu notera au passage qu'un capteur couleur c'est un capteur monochrome auquel on a ajouté une matrice de bayer, donc le prix du capteur couleur devrait être supérieur a celui du capteur mono. Mais comme au final le capteur mono est "meilleur" (au sens plus sensible) que le couleur, la logique en grande partie commerciale impose de le vendre plus cher... J'ai écrit "meilleur" entre guillemet car tout le monde n'a pas les même critère pour définir ce qui est meilleur. Par exemple, pour mon cas personnel, bien que la sensibilité du capteur couleur (avec matrice de bayer) soit inférieure, le fait de ne pas avoir à faire 3 lots de prise de vue différents (avec des filtres R, V et mais une seule fait que je préfère utiliser un capteur couleur (ont dit souvent OSC pour one shot color) Cordialement

Bonjour, On va faire la différence entre les photosites (sur le capteur) et les pixels (dans le fichier image, restituant une information lue ou calculée) 1) Sur une camera dite monochrome, un photosite n'est pas monochrome, il "réagit" (effet photo-électrique) aux photons (ondes électromagnétiques) ayant de nombreuses longueurs d'onde différentes (c'est peut être ce que tu entends par "panchromatique"), mais avec une efficacité différente pour chaque longueur d'onde Ci dessous la courbe d'efficacité (quantique) d'un capteur IMX571 (source P.O.) La lecture du capteur d'une camera monochrome permettra donc d'obtenir une valeur de voltage (qui va dépendre du nombre l'électrons piégés, ces électrons résistant de l'effet photo-électrique) pour chaque photosite, que l'on transcrira en valeur d'intensité lumineuse pour chaque pixel normalisée sur 8, 10, 12, 14 ou 16 bits en fonction de la camera. Pour une IMX571 c'est 16 bits donc on obtiens des valeurs d'intensité entre 0 et 65535 (2 puissance 16 valeurs) L'image obtenue est donc bien monochrome dans le sens où elle n'est constitué que d'un seul canal d'information (on peut parler 'une image en niveau de gris) Si on emploie des filtres (LRGBSHO) sur cette camera on ne fera que réduire la plage de longueur d'onde qui va interagir avec les photosites, et dans tous les cas l'image obtenue est monochrome, restera ensuite à attribuer à chaque couche une couleur arbitraire si l'on veut obtenir une image couleur par combinaison de plusieurs canaux note: les photosites étant aussi sensibles dans l'UV et l'IR, il faut utiliser un filtre 'UV/IR cut' si la camera n'en dispose pas (sur certaines la vitre devant le capteur est traitée pour faire office de filtre UV/IR) 2) Dans le cas d'une camera couleur, les photosites sont eux aussi sensibles à une très large plage de longueur d'onde. On (le constructeur) va ajouter devant le capteur une matrice de Bayer qui va agir comme des filtres rouge/vert/bleu devant respectivement un quart, la moitié et un quart des photosites. Ceci étant cela n'en fait pas des récepteurs monochromatiques, chaque filtre laisse passer une large game de longueur d'onde (donc ici aussi ton appellation panchromatique es peut être valable selon le sens que tu lui donne) Ci dessous la courbe d'efficacité quantique relative pour chaque filtre (même capteur IXM571) On peut noter que par exemple que les photosite recouverts d'un filtre bleu et ceux recouverts d'un filtre vert sont sensible de la même manière à la longueur d'onde à 580nm. La frontière de sensibilité d'un photosite ne s'arrête pas là où démarre celle de son voisin. Et ici aussi malgré la matrice de bayer les photosites restent sensibles dans l'UV et l'IR, donc usage d'un filtre pour les couper si la camera n'en est pas équipée en standard. Et ici aussi la lecture des voltage des photosites va permettre de construire un fichier image mono couche (1 valeur d'intensité lumineuse par pixel). Pour les DARK, FLAT et BIAS, on les utilise sans les debayeriser (dé-matricer), donc on les utilise en tant qu'image RAW qui est monochrome (même si obtenue avec une camera dite couleur) Par contre pour les images 'Light" qui doivent nous servir à montrer les couleurs de l'objet photographié, on va debayériser le RAW pour générer une image comprenant 3 couches. Lors de la débayerisation, pour chaque pixel de l'image on va attribuer la valeur d'intensité lue dans le raw à la couche correspondant à son filtre (de la matrice de bayer), et pour les autres couches on fera un calcul de moyenne (une interpolation) en prenant les valeurs de pixels voisins. C'est le résultat de la débayerisation qui génère une image couleur. https://fr.wikipedia.org/wiki/Dématriçage En résumé, que cela soit une camera couleur ou monochrome, aucun de leur photosite n'est monochrome, ils captent tous une plus ou moins large de longueur d'onde. C'est le fichier image résultant qui est monochrome ou couleur selon qu'il est constitué d'une couche unique ou pas, Cordialement, Stéphane

Bonjour, Ta camera est une camera couleur, donc elle produit des images en couleur si tu les ouvre en les debayerisant. Un "dark" sera utilisé lors du pré-traitement en mode non-débayerisé, donc si tu l'ouvre dans ce mode tu verra les pixels non pas en couleur mais en niveau de gris (si tu les ouvre avec le logiciel Siril par exemple, tu as une option à cocher pour choisir si tu debayerise ou pas à l'ouverture) Un "dark" n'est pas intégralement et totalement noir (ci c'est le cas c'est que tu as la camera parfaite...et donc faire des darks serait inutile...). Il y a un peu de signal, qui dépend de la camera, entre autre si elle produit de l'amglow Cordialement

Bonjour, Merci pour les logs. Sirilic se contente de générer un scrip pour Siril. Si lors des deux tests il génère le même script et que le même jeux d’images est utilisé alors le problème est coté Siril et pas coté Sirilic Ce que je vois: En version bêta 3 lors de l’alignement des éléments des couches ha et oiii siril conserve bien les 5 images, pour l’alignement final des 2 images empilées ha et oiii les 2 images sont alignées. En version bêta 4, lors de l’alignement des éléments ha et oiii Siril élimine chaque fois 1 image, mais l’alignement avec 4 images restantes fonctionne (il reste un nombre d’images suffisant). Cela montre bien qu’ici avec les mêmes images et les mêmes paramètre Siril change de comportement. Lors de l’empilement des 2 couches ha et oiii, on tente d’aligner 2 images et ici aussi Siril en rejete 1, il n’y a plus assez d’images, l y a donc échec de l’alignement et Siril sort en erreur @lock042 Bonjour Cyril, es tu en phase avec cette analyse ? y a t’il eu des modif sur l’algo d’alignement entre la beta3 et la bêta 4 ? Cordialement, Stéphane

196 heures 🤯. Je fais de l'astrophoto depuis 5 ans environ, vu la météo locale j'arrive péniblement à faire entre 8 à 10 sorties par an, et je doute de dépasser une moyenne de 4h de pose par sortie... en fais je suis presque sûr de ne pas avoir atteint 196 heures de poses pour toutes mes cibles (ou alors je le dépasse de peu)... alors 196 heures sur une cible...je suis sidéré....🤩 Le résultat est magnifique, même si je ne suis pas un fan de starless, mais je comprends bien le choix ici de mettre en valeur les détails nébuleux. Bravo. Cordialement, Stéphane

Bonjour, Globalement Sirilic dans sa version 1.15.12 (la dernière) est compatible avec Siril 1.2, et rencontre certains problèmes avec toutes les versions supérieures (pas seulement la beta 4) Cela est surtout dû à des changements de syntaxe de commandes et d'options Siril. Sirilic genère des scripts avec de la syntaxe qui dans certains cas est obsolète avec la nouvelle version de Siril Exemple: lorsque l'on fait l'étape stacking (empilement), si on ne cherche pas à filtrer automatiquement les images sources en fonction de la rondeur ou de la fwhm des étoiles tout va bien mais si on filtre l'option obsolète cause un échec La syntaxe de la commande "stack" Version 1.2 stack seqfilename stack seqfilename { sum | min | max } [filtering] [-output_norm] [-out=filename] stack seqfilename { med | median } [-nonorm, -norm=] [filtering] [-fastnorm] [-rgb_equal] [-output_norm] [-out=filename] stack seqfilename { rej | mean } [rejection type] [sigma_low sigma_high] [-rejmap[s]] [-nonorm, -norm=] [filtering] [-fastnorm] [ -weight_from_noise | -weight_from_nbstack | -weight_from_wfwhm | -weight_from_nbstars ] [-rgb_equal] [-output_norm] [-out=filename] Version 1.4 stack seqfilename stack seqfilename { sum | min | max } [-output_norm] [-out=filename] [-maximize] [-upscale] [-32b] stack seqfilename { med | median } [-nonorm, -norm=] [-fastnorm] [-rgb_equal] [-output_norm] [-out=filename] [-32b] stack seqfilename { rej | mean } [rejection type] [sigma_low sigma_high] [-rejmap[s]] [-nonorm, -norm=] [-fastnorm] [-overlap_norm] [-weight={noise|wfwhm|nbstars|nbstack}] [-feather=] [-rgb_equal] [-output_norm] [-out=filename] [-maximize] [-upscale] [-32b] Les 4 options -weight_from_noise -weight_from_nbstack -weight_from_wfwhm -weight_from_nbstars sont devenues une seule option -weight=<valeur> sui peut prendre 4 valeurs différentes C'est un exemple comme un autre, il y a aussi l'option pour le drizzzle qui ne fonctionne plus Dans ton cas particulier, les messages de warning sur les séquences sont normaux, mais l'échec "aborted" n'est pas explicite (il n'y a pas de détail sur la cause de l'échec). Par contre lorsque l'on regarde plus en détail ta log, on voit qu'a la fin du register (alignement) Siril annonce qu'aucune image n'a été alignée: log: Le traitement de la séquence a réussi. log: Temps d'exécution: 8.85 s log: Aucune image n'a été alignée sur la référence log: Alignement interrompu. log: Échec de la finalisation du traitement de la séquence. C'est donc bien le comportement de Siril qu'il faut ici analyser. Pourrais tu poster l'intégrait" de la log sirilic et pas seulement les 20 dernières lignes ? Je doute que cela soit lié à Python:Sirilic est écrit en python, et utilise une version embarqué dans son binaire pour la version windows), et Siril dans le cas qui nous occupe n'utilise pas python pendant ton pré-traitement, c'est utilisé si on lance des scripts via l'interface graphique Siril ou si on lui demande d'exécuter la commande "pyscript" ce que ne fait pas Sirilic dans le script qu'il génère pour Siril. Je pense plutôt que c'est lié à un changement de valeur par défaut dans le filtrage des images sur certains critères qualitatif qui font que tout est exclu... Exemple (pas prouvé du tout que cela soit la cause du problème, c'est juste une idée en l'air que je lance...) Si sur siril 1.4 beta3 la commande "register" aligne les images en filtrant par défaut sur les images dont la rondeur est >0.5 alors il va certainement garder toute ses images, et le register va aboutir et ne pas faire échouer ton pré-taitement Si sur siril 1.4 beta 4 le même register filtre désormais par défaut sur les images dont la rondeur des étoiles est >0.9 alors si toute ses images ont des rondeur moyenne à 0.89 (je prends cette valeur car c'est ce qui est annoncée au moins pour ton image numéro 2 dans ta log) alors toutes tes images seront exclues et l'alignement va échouer C'est juste une idée, mais cela pourrait expliquer le comportement différent des deux versions de Siril (beta 3 et beta 4) sur un même jeux d'image (mais il faut que tu confirme que tu a fait le test avec les 2 versions sur le même jeux d'images sources). Si tu ne fais pas le même pré-traitement avec le même jeux d'images et les mêmes options avec les 2 versions de Siril alors on ne peut pas conclure (le problème ne serais peut être pas coté Siril mais un problème avec certaines de tes images) EDIT @m27trognondepomme Cher Pascal, la sortie d'une version Siril 1.4 stable approche à grands pas, je pense qu'il faudrait adapter Sirilic aux nouvelles syntaxes de commandes/options de cette nouvelle version. Je reste à ta disposition si tu as besoin de testeurs (notamment sur MacOS) Cordialement, Stéphane

Ce filtre sera très utile devant le quark en remplacement d’un filtre uv-it cut. Si tu l’as déjà alors utilise le, mais si tu ne l’as pas encore, alors autant acheter un uv-ir-cut

Si on pouvait observer en Ha sans passer par un filtre couteux comme un Fabry-Perot cela se saurait... ERF=energy rejection filter , cela permet de rejeter la partie du flux qui ne nous intéresse pas, mais cela n'est pas un filtre à faible bande passante permettant à lui seul d'observer dans le Ha, il permet juste de limiter l'énergie reçue par les filtres spécialisés placés après, pour le pas les abîmer. Un filtre ERF en sortie va jouer le même role qu'un filtre UV-IR cut (cela filtre plus qu'un UV-IR-cut), cela ne va pas en faire un filtre pour observer en Ha. Pour des lunettes jusqu'à 100mm un UV-IR cut suffit, au dessus il vaut mieux utiliser un ERF qui supprimera plus de flux. Par exemple le filtre ERF du lien ci dessous filtre ce qui n'est pas entre 600 et 700nm, donc c'est un filtre le largeur de bande passante 100nm centré sur le Ha, mais on est loin d'une bande passante de 0.05nm (ou 0.5 angstrom) comme sur un Fabry-Perot https://www.pierro-astro.com/baader/37a-filtres-solaires-et-filtres-c-erf-d-erf/filtre-de-rejet-d-erf-diametre-75-mm_detail Le but d'un Fabry-Perot c'est de supprimer presque 100% de la luminosité sur tout le spectre sauf le Ha et de laisser passer presque 100% du Ha, cela permet d'observer cette longueur d'onde avec suffisamment de flux Derrière un astrosolar ou derrière un prisme de herschel+ND, on a divisé par entre 25000 et 100000 tout le flux, pour toute longueur d'onde confondue, donc il ne reste pas suffisamment de flux sur le Ha pour en faire une observation de qualité.

Bonjour, Un filtre ERF de pleine ouverture habituellement c'est pour faire d l'observation en Halpha, et un prisme de Herschel c'est pour faire de l'observation en lumière blanche, donc je dirais que soit je ne comprends pas ce que tu souhaite faire, soit, sans vouloir t'offenser, c'est toi qui n'est pas clair sur ce que tu souhaite observer. Pour observer visuellement en lumière blanche (pour observer les taches et éventuellement la granulation si on a un diamètre suffisant, mais pas pour observer les protubérances) solution 1: - n'importe quel telescope (lunette/newton/SCT) doté à l'ouverture d'un filtre type astrosolar de densité 5 - si c'est pour de la photo et pas du visuel la densité 3.8 c'est OK - densité 5 cela divise la luminosité par 100000, densité 3.8 cela divise par 8000 environ - si on veut on peut ajouter un filtre "UV/IR cut" devant l'oculaire solution 2: - avec un telescope de type lunette seulement et de diamètre inférieur à 150mm, et un prisme de Herschel et un filtre ND 3 (neutre densité 3) - le prisme de Herschel renvoie environ 4% de la luminosité vers l'oculaire (donc division pas 25 de la luminosité), les 96% restants sont envoyés se dissiper vers un radiateur (souvent une plaque céramique) - le filtre ND3 OBLIGATOIRE divise par 1000 le flux issu du prisme (dont en sortie du prisme+filtre on a divisé par 25000 la luminosité). A noter que certains prisme de Herschell sont déjà dotés en interne d'un tel filtre ND, démontable ou pas. - éventuellement un filtre polarisant circulaire pour ajuster la luminosité restante - éventuellement un filtre "UV/IR CUT" juste devant l'oculaire (techniquement ce n'est pas un filtre ERF, mais cela permet de limiter le flux résiduel UV et IR reçu par l'observateur, certains trouvent cela inutile, moi dans le doute j'en met un) Note: le filtre de Herschel ne s'utilise qu'avec un lunette, mais on peut aussi (pour le plus bricoleurs) remplacer le couple lunette+prisme par un telescope Neton dont le miroir primaire est désaluminé Pour observer non pas en lumière blanche mais en Halpha, pour voir les détails de la chromosphère et les protubérance, il faut un filtre de type Fabry-Perot, dont font partie les Daystar Quarks (et les lunt et pst coronado...) Dans ce cas il faut utiliser un filtre ERF à l'ouverture, ou bien par exemple dans le cas du Quark si le diamètre de la lunette n'est pas trop grand (inférieur ou égal à 100mm) on peut se limiter à un filtre "UV/IR cut" à l'entrée du Quark (pour les telescopes autres que lunette, le ERF a l'ouverture est obligatoire). Les Quark chromosphère et protubérance (non combo) ont une barlow telecentrique x4.2 intégrée parce qu'ils sont faits pour être utilisés avec des lunettes ayant un rapport F/D entre 4 et 9, mais le filtre Fabry-Perot impose d'être utilisé avec un rapport F/D plus important. Le quark Combo n'as pas de barlow intégrée car il est fait pour être utilisé avec des SCT et Mark (donc avec filtre ERFF à l'ouverture obligatoire) de plus gros F/D (habituellement entre 10 et 15). Il peut aussi être utilisé avec une lunette de plus petit F/D en rajoutant une barlow devant. Une powermate sera parfaite dans ce cas là. Tu pourra soit utiliser un filtre ERF a l'entrée de la lunette soit un filtre 'UV/IR cut' a l'entrée de la powermate (qui sera devant le quark) Cordialement

Bonjour, Quand tu parles de triplette, je pense que tu veux parler de Kstars/Ekos/Indi, parce qu'a part les détails sur l'OS dans ton post tu ne nous dis pas quel soft tu essais de configurer Si on part du principe que tu utilises la dite triplette, tu ne peux pas configurer les trains optique sans avoir connecté les périphériques et c'est normal c'est pensé comme cela (je sais c'est nul, mais c'est comme cela, et je partage ici ton opinion sur certains choix discutables des développeurs) . Dans la fenêtre principale Ekos il faut sélectionner un profile, lancer ekos et connecter les périphériques (étapes 1, 2 et 3 de la fenêtre). C'est le seul moyen de faire apparaitre les autres onglets où tu pourra trouver le bouton pour configurer les trains optiques Si la fenêtre des trains optique popup toute seule c'est q'un des trains est configuré avec un ou plusieurs périphériques non détectés, ou bien q'un des deux éléments obligatoires est non renseigné (camera et telescope) EDIT: et si vraiment tu veux tester sans aucun périphérique physique attaché, alors il y a le profil "simulateurs" qui est fait pour cela, pour déclarer des périphériques émulés. A noter qu'il faut aussi installer le package "gsc" pour avoir des étoiles sur les captures simulées pour faire fonctionner en mode simulation la mise au point, le guidage et l'astrométrie Cordialement

Bonjour, et bienvenue sur le forum. Pour une première astrophoto je trouve que c'est très bien (j'étais loin d'obtenir ce résultat lors de mes premières photos) mais je suis un peu étonné du résultat avec autant de durée de pose (238*180s cela fait presque 12h), je pense que tu peux obtenir mieux au post traitement. Je ne suis utilisateur ni d'Asiair ni de monture harmonique, mais des utilisateurs de ce type de matériels ne devraient pas tarder à répondre à tes questionnements sur la MES et le guidage avec ce type de monture. Je dirais juste que je ne détecte pas de problème de suivi vu la forme de tes étoiles Pour la partie post traitement avec Siril - j'ai moi aussi régulièrement voire systématiquement le message indiquant une solution imprecise de la correction des couleurs par photometrie, même après correction du gradient, du coup j'ignore ce message... - concernant l'étirement "asinh" tu devrais faire un essai sans tirer au max, juste pour faire apparaitre les nébulosités (tentes plutôt un étirement "à moitié" que "au max", et moi non plus je ne touche pas au point noir à cette étape, je le fais ensuite lors de la poursuite de l'étirement). De toute façon l'étirement de l'histogramme est à mon avis la partie la plus difficile du post traitement, et il n'y a aucune formule magique, tout dépend de l'image de départ. Personnellement je préfère utiliser l'étirement GHS (étirement hyperbolique généralisé), qui est d'une prise en main complexe mais qui me conviens bien en terme de résultats (il y a un tutoriel ici https://siril.org/fr/tutorials/ghs/) N'hésites pas à faire plusieurs essais avec des réglages différents. Cordialement, Stéphane

Un bien bel échauffement, on attend la suite avec impatience.

En fait je pense que nous sommes nombreux à attendre le compte rendu de tes tests et ton avis sur le produit pour se lancer (bon ok, c'est moche, on te laisse prendre le risque seul, mais d'un autre coté cela montre que l'on tiens ton avis en haute estime...😇) Vu que c'est un produit en cours de lancement je ne suis pas sûr qu'il y ait déjà du stock, et il me semble avoir vu quelque part que la dispo était annoncée pour courant octobre... Cordialement, Stéphane

Bonjour Robert, Le problème ici ce n'est pas la présence ou pas du package "packaging", le problème c'est le venv qui n'est pas créé correctement. Ce problème est à régler avant tout autre chose Concernant le package Siril installé, est ce le package Siril standard (installé via apt) ou bien un package Snap ou Flatpak (je dis cela car si tu as installé Kstars-bleeding avec apt alors tu ne peux pas installer en même temps Siril, sauf a utiliser un package alternatif Snap ou Flatpak) Ceci étant peux être que tu n'installe pas Kstars-bleeding sur ton PC principal mais seulement sur ton raspberry) Ce que je t'invite à faire: 1) désinstalle le package Siril 2) supprime le sous-répertoire dans ton "/home/robert" où Siril stocke son venv en ligne de commande avec ton compte perso: rm -rf /home/nafa/.local/share/siril/ 3) re-installe Siril 4) au premier lancement observe si la création du venv est OK Tant que cette étape n'est pas OK cela ne sert à rien de lancer un script python, il échouera La log que tu dois obtenir au lancement (ce que j'obtiens suite a une réinstallation sur un linux ubuntu) 13:55:49: Bienvenue dans siril v1.4.0-beta3 … 13:55:56: Le dépôt local de scripts est à jour ! 13:55:56: Préparation de l'environnement virtuel python : /home/nafa/.local/share/siril/venv. 13:55:56: Vérifier que le module python est à jour... 13:55:56: Installation / mise à jour du module python en arrière-plan. Cela peut prendre quelques secondes... 13:55:57: Le dépôt de la base de données locale SPCC est à jour ! 13:56:07: Le module Python est à jour 13:56:08: Le dépôt local de scripts est à jour !

Sur mon téléphone est installée la version plus 7.6.1, j'ai parfois des soucis avec l'option "toquer pour choisir", qui ne fonctionne pas comme elle devrais, par contre je ne rencontre pas les mêmes problèmes que toi, notamment ce qui ressemble a une perte de le configuration d'un lancement à un autre d'où le coté aléatoire que tu observes Tu peux toujours tenter de contacter le support Skysafari pour décrire ton problème site https://skysafariastronomy.com Menu "ressources" et "submit a ticket", par contre cela va être en anglais.... (google translate peux aider)

Bonjour, @Lau_66 Tu ne précise pas si tu utilise Skysafary sur un ordi ou sur un téléphone, je vais partir du principe que c'est sur un téléphone. Le passage de l'affichage traditionnel (lignes) aux figure mythologiques se fait via un paramètre dans les options, et cela n'est pas censé changer tout seul... Dans le "Menu" (en bas à gauche), choisir "Réglages" puis "Constellations", et cocher ou pas les affichages "Lignes" ou "Mythologiques" ou les deux. MAIS SURTOUT, NE PAS SELECTIONNER L'OPTION "Toquer pour choisir" --> sinon dès que tu secoue ton téléphone ou tapote l'écran un peu vite il va considérer que tu "Toque" et va changer pour passer d'un mode l'autre...(je pense que c'est ton soucis si cela change tout seul)

Il me semble que dans le cas présenté ici une allonge de colonne ne vas pas aider. En effet ces allonges sont utiles lorsque il y a risque de heurter le trépied, mais cela ne semble pas être le cas ici, ce qui va entrer en contact avec la RAF c'est la base de la monture, donc même avec une colonne la distance entre la RAF et la base de la monture ne vas pas changer Ce qu'il faudrait ici c'est ajouter de la distance entre la lulu et sa queue d'aronde, ce qui va aussi éloigner la RAF de la base de la monture Askar en propose pour ses lunettes, je ne sais pas si cela s'adapte à d'autres (dépend des pas de vis utilisés) https://www.pierro-astro.com/materiel-astronomique/accessoires/accessoires-non-optiques/platines-anneaux/rehausseurs-pour-lunettes-sqa-20-mm-askar_detail EDIT: A priori Altair et Primalucelab en font aussi a des tarifs plus compétitifs que c'eux d'Askar

Salut @Colmic, bravo, les détails sur la full sont un régal, et effectivement il y a du monde sur la photo. Etre exigeant sur le tri des brutes c'est visiblement tout bénéf, mais avec tes critères (rondeur >0.9, fwhm<2") , moi je rejète 100% de mes brutes 🥲 Cordialement, Stéphane

J’utilise les Altair L-pro, dualband HaOiii et SiiOiii ( mais en version 4nm) sans soucis de halo Cordialement

Bonjour, Dans le titre tu parles de filtre Antlia et dans le lien c'est un filtre Altaïr... sur lequel souhaite tu des informations ? Cordialement

Ca c'était plutot fait expres car les histos sont petits et c'est pas facile de bien viser. Tu avais remarqué aussi... c'est vrai que cela serait plus facile si le zoom horizontal sur histogramme était lui aussi implémenté, comme dans la fenêtre GHS, mais j'osais pas le demander 😉

@lock042 Pendant que je t'ai sous la main, rien a voir avec le problème Python, j'ai 2 soucis (je ne parle pas de bug car c'est peut être un comportement voulu "work as design") 1) lorsque l'on fait une "Composition RVB", Siril fait un filtrage des fichiers images élligibles à l'ouverture, on peut prendre des fit, des tif mais pas de fit.fz compressés (alors dans la composition CFA ou dans pixelmath on peut le faire) Du coup pour mes compositions SHO je dois désactiver l'option de compression pour enregistrer chaque couche en fit au lieu de fit.fz 2) Lorsque l'on fait un étirement GHS, on peut sélectionner le point de symétrie en cliquant dans l'histogramme ou via une selection dans l'image Par contre lorsque l'on fait une recombinaison d'étoiles starless+starmask, pour le point de symétrie on peut utiliser une selection de l'image mais pas cliquer sur l'histogramme, alors que je trouve cela plus pratique (en espérant ne pas être le seul) Il y a moyen d'arranger cela ? (sauf si c'est voulu) Cordialement

Plus de detail ici (notamment 2 ports USB3 et 3 ports USB2 et entrée DC 5.5 2.5) https://svbony.fr/products/controleur-alimentation-sv241-svbony?_pos=2&_psq=sv241&_ss=e&_v=1.0 Il est fait état d'une compatibilité avec NINA, donc je pense qu'ils ont développé un driver ASCOM pour le pilotage des interfaces 12V switchables, et de la sortie a tension variables, par contre aucune indication pour le support de INDI Cordialement