Cissou8

Salut,

la MAD ( dont on donne une description dans la doc https://siril.readthedocs.io/fr/latest/Statistics.html#mad) est une mesure de la dynamique de ton image. Quand on normalise les images avant de les stacker, on egalise leur dynamique. La, dans ton cas, il y en a tellement peu qu'on ne peut pas s'en servir. Tu peux quand meme empiler en desactivant la normalisation. Mais effectivement, monter les ISO, c'est probablement une bonne idee (monter le temps de pose aussi  )

Cecile

10 hours ago, jDef said:

J'ai peut-être mal compris le comportement du filtrage, mais il me semble qu'entre 2 séquences des plans de couleur verte et rouge par exemple, si je choisi un filtrage à 90% sur la FHWM, ça me donne un seuil en FHWM calculé sur la statistique de la FHWM et on ne garde que les images ayant une valeur de FHWM inférieure à ce seuil, donc un nombre d'images variable en fonction de la statistique de FHWM pour chaque plan couleur.

Alors si tu dis de prendre la FWHM a 90%, ca va effectivement calculer le 90eme percentile de la FWHM independamment sur le vert et sur le rouge. Et si tu filtres les images en enlevant les images au dessus de ce seuil, tu auras a la fin 90% de tes images sur chacune des sequences, par definition du percentile. Donc si tu as shoote le meme nombre d'images rouge et verte, tu auras le meme temps d'integration sur ces 2 couches. Par contre, elles pourront avoir des FWHM tres differentes.

10 hours ago, jDef said:

• Séquence 400 images et Filtrage FHWM 90% (300 images) et Filtrage Rondeur 90% (270 images) et Filtrage nombre 250 : au final on garde les 250 premières = Min(250,270)
• Séquence 400 images et Filtrage FHWM 90% (300 images) et Filtrage Rondeur 90% (270 images) et Filtrage nombre 290 : au final on garde les 270 premières = Min(290,270)
• Séquence 400 images et Filtrage nombre 290 : au final on garde les 290 premières images de la séquence (0-->289) = Min(290, 400)

Je suis desolee, j'ai pas compris ton exemple... tu vas au final avoir des temps d'integration differents sur tes couches. L'ordre des filtres n'a pas d'importance. On calcule chaque seuil independemment des autres filtres. On regarde le 90% percentile de la FWHM et le 90% de la rondeur sur l'echantillon total. Et ensuite on rejete les images qui ne remplissent pas tous les criteres a la fois. Donc ca va dependre de comment sont correlees FWHM et rondeur. C'est pour ca que je disais que c'etait pas simple des qu'on etait en multicritere. Quant a garder les X premieres,  c'est un peu dommage... rien ne te dit que tu gardes les meilleures (au sens des criteres de qualite).

Bonsoir,

j'avais du mal a reproduire parce qu'en fait il a deja ete corrige  . La correction sera dans la prochaine version.

merci du retour!

Cecile

Bonsoir,

il existe un fichier txt qui est cree au moment de la conversion (tu dois le voir dans ton repertoire, il finit par _conversion.txt). et qui te donne les correspondances entre images d'entree et images de la sequence.

Mais on ne garde pas ensuite la correspondance avec les images de depart quand on fait la calibration, l'alignement etc... parce que comme on peut choisir les prefixes au fur et a mesure des etapes, ca deviendrait vite complique a gerer.

Cecile

Bonsoir,

alors ca me parait complique en pratique... on prend les N premieres? On prend les N meilleures selon quel indicateur?

Si tu connais la taille de chaque sequence, tu peux lui passer le percentile d'images que tu veux garder sur chacun des criteres de qualite. Mais je vois pas comment on gere les combinaisons de filtre multicriteres en donnant un nombre d'images...

Cecile

Bonsoir,

c'est possible de le scripter, mais pas avec la fonction load.

Au lieu de:

load myimage

Tu peux faire:

calibrate_single myimage -debayer

load pp_myimage

Ca debayerise l'image que tu peux ensuite charger

Cecile

Bonsoir,

effectivement, il manque une protection a l'execution de certaines fonctions graphiques quand on est en cli, on va corriger ca,

merci du retour!

Cecile

Ah super! Non le log pas besoin, a priori, si ca marche, ca marche

Je veux bien oui, que tu testes pour des non-regressions surtout....

Merci!

@shibon,

j'ai commence a regarder. Si tu veux bien tester le paquet ici: https://gitlab.com/free-astro/siril/-/jobs/4082114542/artifacts/download

J'ai essaye sur ton image plus haut, ca marche (ca en trouve plus en tout cas). Faut que je regarde de pas avoir introduit d'autres effets de bord

Ah ben on a parlé de ça le 11 Mars et la bêta est sorti le 12.... non c'est pas dedans

J'ai pas le droit de péter la détection d'etoiles la veille d'une release. J'ai pas encore regarde d'ailleurs

13 hours ago, Lost_In_Space said:

J'ai pensé que la dominante rouge pour les flats était normale : la bande Ha passe entièrement sur les sous-pixels rouges, alors que la bande Oiii se répartit entre les sous-pixels verts et bleu.

Alors, je suis pas bien d'accord avec ca . Je vais faire un raisonnement un peu idéalisé, y a des subtilités a toutes les étapes mais je vais pas les faire, sinon ca alourdit le propos.

Le fond de l'affaire c'est: Les photons ne se repartissent pas.

En considerant que le flux est constant sur tout le spectre, disons que ta source de lumiere pour un flat est vraiment blanche, le même nombre de photons par seconde arrive sur chaque "site" optiquement parlant.

Première étape: ton filtre rejette hors des bandes, il ne reste plus que des photons dans la bande Ha et la bande OIII, a peu pres le meme flux, vu que la largeur des bandes du filtre est a peu pres similaire.

Deuxieme etape: Sur un site qui a en plus un filtre rouge de la matrice de Bayer, les pixels de la bande OIII n'arrivent plus. Le nombre de photons effectivement transformes en electrons depend de la transmission du filtre rouge et de la sensibilite d'un site dans le rouge (a quel taux les photons de telle longueur d'onde  se convertissent en electrons). Sur un site qui a un filtre Vert ou Bleu, c'est l'inverse, il ne recoit que les photons de la bande OIII, et combien sont convertis la fin depend de la transmittance des filtres vert et bleu et du taux de conversion de l'electronique derriere a la longueur d'onde du OIII. A la fin, c'est ce taux de conversion global (transmission du filtre + sensibilte de la cam) qui va faire la valeur que tu lis sur un pixel dans une image (y a en plus le gain mais la tu es a 1 environ, la bitdepth de l'ADC et la tension d'offset mais on s'eloigne du sujet).

Generalement, le taux de conversion global est meilleur dans le vert (c'est pour ca que les images sans filtre sortent avec cette teinte verte).

Mais bon, chaque pixel vit sa vie sans "savoir" ce qui se passe chez son voisin. Un site du capteur ne sait pas qu'il y a un filtre rouge ou vert ou bleu qui va lui enlever des photons. Un capteur couleur, c'est juste un capteur mono qui a une matrice de Bayer au dessus de la tete. Donc ajouter les valeurs des 2 pixels verts et du bleu pour comparer a la valeur du rouge dans le meme bloc de 4, je pense pas que le raisonnement soit bon.

La en regardant tes valeurs, je dirais que ta source de lumiere est pas du tout blanche, voire qu'elle tire meme franchement sur le rouge. Mais si y avait que ca, ca serait pas un probleme, Siril peut recaler les valeurs pour que tout le monde ait la meme moyenne. La ce que je trouve bizarre, c'est que la pattern en bretzel soit identique sur toutes les couches.... Alors, c'est peut-etre la limite de mon raisonnement idealise. C'est pas si binaire... Y a des photons Ha qui peuvent fuiter sur le vert/bleu et vice et versa (parce que les filtres sont pas exactement a zero de transmittance)... Mais y a clairement qqchose a faire sur tes flats. Peut-etre tenter des skyflats?

Pas de souci,

je te fais pas passer d'images la tout de suite parce que mes vitesses d'upload sont vraiment pas folles.

Mais voila:

- un dark de 300s

- une light (300s) et un flat fait au l-extreme (j'avais lu trop vite, j'ai le l-extreme pas le l-ultimate)

- une light (30s) et un flat faits au CLS

20:11:09: Reading FITS: file DARK_300s_G120_O30_T-10C_bin1.fit, 1 layer(s), 4144x2822 pixels, 16 bits
20:11:12: Running command: stat
20:11:13: B&W layer: Mean: 1922.3, Median: 1919.0, Sigma: 125.5, Min: 1862.0, Max: 65532.0, bgnoise: 3.4

20:14:26: Reading FITS: file LIGHT_DualBand_300.00s_G120_O30_T-10.00C_bin1x1_0057.fits, 1 layer(s), 4144x2822 pixels, 16 bits
20:14:31: Running command: stat
20:14:31: Red layer: Mean: 2129.3, Median: 2104.0, Sigma: 526.3, Min: 1820.0, Max: 65532.0, bgnoise: 37.8
20:14:32: Green layer: Mean: 2217.5, Median: 2192.0, Sigma: 678.0, Min: 1956.0, Max: 65532.0, bgnoise: 43.7
20:14:32: Blue layer: Mean: 2074.4, Median: 2060.0, Sigma: 452.8, Min: 1840.0, Max: 65532.0, bgnoise: 30.6

20:14:50: Reading FITS: file FLAT_DualBand_0.60s_G120_O30_T-10.00C_bin1x1_0029.fits, 1 layer(s), 4144x2822 pixels, 16 bits
20:14:53: Running command: stat
20:14:53: Red layer: Mean: 15100.3, Median: 15156.0, Sigma: 416.1, Min: 12972.0, Max: 16720.0, bgnoise: 249.6
20:14:53: Green layer: Mean: 34118.1, Median: 34160.0, Sigma: 574.8, Min: 30968.0, Max: 36624.0, bgnoise: 394.5
20:14:53: Blue layer: Mean: 17699.6, Median: 17700.0, Sigma: 300.0, Min: 16024.0, Max: 20532.0, bgnoise: 275.0

20:11:43: Reading FITS: file LIGHT_CLS_30.00s_G120_O30_T-10.00C_bin1x1_0179.fits, 1 layer(s), 4144x2822 pixels, 16 bits
20:11:50: Running command: stat
20:11:51: Red layer: Mean: 2208.2, Median: 2184.0, Sigma: 599.1, Min: 1928.0, Max: 65532.0, bgnoise: 45.0
20:11:51: Green layer: Mean: 2213.4, Median: 2192.0, Sigma: 618.9, Min: 1944.0, Max: 65532.0, bgnoise: 43.1
20:11:51: Blue layer: Mean: 2150.6, Median: 2132.0, Sigma: 525.6, Min: 1904.0, Max: 65532.0, bgnoise: 36.8

20:12:19: Reading FITS: file FLAT_CLS_0.90s_G120_O30_T-10.00C_bin1x1_0029.fits, 1 layer(s), 4144x2822 pixels, 16 bits
20:12:22: Running command: stat
20:12:22: Red layer: Mean: 32347.8, Median: 32380.0, Sigma: 552.4, Min: 29276.0, Max: 34648.0, bgnoise: 379.8
20:12:23: Green layer: Mean: 31213.1, Median: 31240.0, Sigma: 517.6, Min: 28536.0, Max: 33452.0, bgnoise: 381.0
20:12:23: Blue layer: Mean: 23707.3, Median: 23720.0, Sigma: 439.2, Min: 21356.0, Max: 28460.0, bgnoise: 324.1

J'ai pas du tout cette predominance rouge dans le flat fait avec le filtre dualband.

D'ailleurs, si je debayerise un flat, le rouge et les 2 autres couches ont une tete bien differentes:

- le rouge a le profil en bretzel

- le vert et le bleu non

ROUGE

VERT

1 hour ago, Lost_In_Space said:

Je viens de comprendre : env. 720 de mediane dans un light, ça laisse peu de marge pour déduire les 1920 de mon master dark

Oui c'est ca, le niveau moyen de light-dark est meme tres largement negatif. Si tu bosses en 16b, comme les seules valeurs admissibles sont entre 0 et 65535, les valeurs negatives, elles finissent toutes a zero. D'ou ton image quasiment toute noire.

15 hours ago, Lost_In_Space said:

Mais je me retrouve avec les traces insupportable que laisse un l-ultimate sur le capture d'une ASI294MC Pro.

Bon alors oui, ton flat de la veille corrige pas bien tes lights de la veille. Meme si on a pas ce probleme de dark qui en plus fait tout clipper.

Alors, j'ai l'impression qu'y a 2 choses qui sont venues se melanger:

- les statistiques des couches entre tes flats et tes lights (de la veille) sont pas du tout coherents. Ouvre un light puis un flat (unitaires) et tapes stat -cfa. Tu verras que la couche rouge est completement distordue en echelle entre un flat et un light. C'est ca qui laisse les traces insupportables. Mais normalement, ca s'en va a la calibration (pourvu que les niveaux soient coherents)

- le lendemain, y a encore un truc en plus. Avec un offset regle a 30, tu devrais pas avoir une mediane a 720. Tu as bien ouvert la camera avec le driver ZWO (et pas le driver ASCOM)?

Punaise... j'ai vachement de mal a comprendre ce que je vois... et pourtant, j'ai la meme cam et le meme filtre....

Tu pourrais me faire passer aussi un light de la veille et un flat unitaire?

C'est pas la valeur min le probleme, c'est la moyenne (ou la mediane). En gros, c'est le niveau moyen de ton image (souvent c'est bien representatif de ton fond de ciel). Et bien la, tu vois que c'est 720 pour un light, alors que le dark c'est 1920. Et comme l'operation que tu fais pendant la calibration, c'est soustraire le dark au light, tu te rends compte que forcement, tu vas avoir des tas de pixels qui vont passer en negatif... et ca va clipper a 0.
On a toute une section de la doc qui explique ces histoires de niveau: https://siril.readthedocs.io/fr/latest/preprocessing/calibration.html#understanding-how-the-flats-correct-the-lights

Y a des graphes, ca te permettra de comprendre les differentes etapes de la calibration.

J'essaie de regarder tes fichiers et je te dis

Alors, je comprends pas encore pourquoi, les donnees des headers donnant les memes reglages, mais y a clairement qqchose qui va pas dans le light:

08:30:23: Canal B&W : Moyenne : 718.5, Médiane : 720.0, Sigma : 179.4, Min : 252.0, Max : 65532.0, bgnoise : 221.6

alors que le dark:

08:31:15: Canal B&W : Moyenne : 1923.6, Médiane : 1920.8, Sigma : 50.0, Min : 1871.7, Max : 65532.0, bgnoise : 3.7

Donc c'est normal que ca finisse tout noir

Tu peux me mettre en partage une light, le masterdark et le masterflat stp?

Si tu veux que je regarde, charge une brute dans siril

puis tu tapes dans la ligne de commande, tu tapes:

stat

et ensuite:

dumpheader

et tu fais pareil avec ton masterdark et tu me partages le log ici

Salut,

il faut que tu fasses une statisque d'une brute et d'un dark pour voir. Visiblement, y a un probleme de niveau.... un reglage de la valeur d'offset qui aurait bouge?

Cecile

Ah ben c'est normal alors....

Pour débuter, je te conseille de lire les tutos, notamment celui-ci, dans lequel des images sont partagées également.

https://siril.org/fr/tutorials/tuto-scripts/

Salut,

Tu tapes quoi exactement?

solsys [-mag=17.0]

Ou 

solsys -mag=17.0

?

Re,

Je viens d'essayer, la commande:

solsys -mag=17.0

marche:

20:31:19: Running command: solsys
20:31:24: Found 67P at coordinates:  08h32m39s, +28°58'52" with magnitude: 8.8
20:31:24: Found 1 Solar System Objects with mag < 17.0

Quand on met des arguments entre [], c'est pour dire qu'ils sont optionnels. Faudrait peut-etre qu'on mette la convention qqpart, meme si elle est pas de nous

En regardant ton log, il dit qu'il n'a trouvé aucun fichier a convertir dans le repertoire flats... y sont-ils?

Alors, pour l'extraction Ha/OIII:

- pour la 1.0.6, tu mettais un drizzle pendant la registration pour Ha et OIII pour retrouver en fin de stack la taille du capteur

- pour la 1.2.0: 

    - si tu laisses tout par defaut, tu dois mettre drizzle pour le Ha (pas pour le OIII)

    - si tu upsamples Ha, tu ne mets plus aucun drizzle pendant la registration

    - si tu choisis Downsample OIII, tu dois drizzle Ha et OIII (comme pour la 1.0.6)

Et tu te retrouves en fin de stack avec la taille de ton capteur.

EDIT: pour info, j'ai ouvert un ticket la: https://gitlab.com/free-astro/siril/-/issues/1047

Salut,

oui, on a bcp change de choses dans la détection. Je viens de regarder ton image, ça vient essentiellement de tes étoiles qui occupent vraiment peu de pixels. On a un check (pour eviter de detecter les pixels chauds comme des etoiles) qui dans ton cas particulier (petite focale tres ouverte, "downsample" par l'extraction Ha) devient un peu restrictif. 

Tu veux bien faire un test? Tu traites en manuel ou en script? Si c'est en manuel, prends ton image pp_light_00001.fit, copie-la ailleurs. Fais une extraction Ha/OIII et demande a upsample le Ha:

Et tu me dis ce que donne la detection sur cette nouvelle image Ha. Normalement, il devrait en trouver bien plus.

Ca peut etre un workaround en attendant que je trouve un fix plus perenne.

Sinon, si tu veux avoir la 1.0.6 et la 1.2 en meme temps, tu peux avoir une version "portable" d'une des 2 versions (et l'autre installee): https://siril.readthedocs.io/en/latest/installation/windows.html#installation-of-the-portable-binary

Tu peux recup la version portable sur les downloads de siril.org

Cecile

34 minutes ago, belatrix said:

comment savoir les bugs connus pour ne pas faire doublons?

regarde le lien que je t'ai copie: https://siril.org/fr/download/2023-02-24-siril-1.2.0-beta1/

Juste en dessous de l'intro, on a fait un paragraphe bugs connus. On met a jour la page depuis la release, justement pour que les utilisateurs puissent s'y referer facilement en cas de doute.

Sinon, c'est sur notre gitlab:https://gitlab.com/free-astro/siril/-/issues