Expérimentations poses courtes

[cissou8]

Alors, desolee, j'arrive bien apres la bataille
Oui, empiler en 32b permet d'eviter cet ecueuil des valeurs negatives que le ser ne gere pas vu qu'il est au mieux en 16b entier non signe.

Pour obtenir la normalisation après empilement, j'ai dû changer de méthode d'empilement (au lieu de somme, j'ai pris empilement par moyenne avec rejet des pixels déviants). Mais du coup je suis tombé sur un souci du nombre max de fichiers ouverts (2048 max alors que Siril voulait 4000). Du coup, j'ai empilé avec Siril mais sous Linux. (je n'aime pas bricoler windows)

De memoire, parce que ca fait longtemps que j'ai pas fait, si on est en 32b en pref et que la sequence est en ser, la somme renormalise automatiquement entre [0,1] mais il faudrait que j'aille regarder. Sinon, oui, cocher la case de normalisation de l'output sur l'empilement avec rejet des deviants fait de meme.
Par contre, ca vaudrait le coup de comprendre pourquoi certaines images clippent au noir.... (ah, j'avais pas lu le truc sur la deconvo)

Et sinon, tres bel amas !

[steph37]

Merci @cissou8 pour les infos et les compliments

[steph37]

M57, je l'aime bien cette nébuleuse mais c'est pas immédiat d'en faire une belle image. Un essai sans prétention, 4000 images sélectionnées 600ms, gain + 35dB, bin 2, il y a environ 3h de traitement Siril (dont 2 h pour la déconvolution de chaque brute).
On aimerait bien encore plus de détails, ptet qu'on est un peu juste dans le nombre d'images empilées et c'est pas impossible que des poses un peu plus longues soient bénéfiques. (Je suis encore tombé sur de nombreux pixels négatifs au moment de la calibration).

M57-1.png (99.58 Kio) Consulté 2016 fois

[clouzot]

Honnêtement cette histoire de pixels a valeur négative ne m’inquiète pas outre mesure. Deconvoluer un signal aussi faible, c’est l’exemple type de l’inversion mal conditionnée, normal qu’il parte un peu en vrille. Tu protèges un peu le fond de ciel (SiriL le permet si je ne m’abuse) ?

[steph37]

Tu protèges un peu le fond de ciel (SiriL le permet si je ne m’abuse) ?

Euh non je ne fais rien de spécial dans Siril à ce sujet ; dans Affinity je fais subir à la nébuleuse des réglages qui ne touchent pas le fond de ciel (par exemple augmenter le contraste).
Comment ça se passe dans Siril pour protéger le fond de ciel ?

Honnêtement cette histoire de pixels a valeur négative ne m’inquiète pas outre mesure.

bon bin je ne vais pas m'inquiéter plus que ça

[clouzot]

Comment ça se passe dans Siril pour protéger le fond de ciel ?

En fait c'est assez indirect, il y a cette histoire de seuil de micro contraste (Contrast Threshold) qui crée un masque pour protéger les zones "lisses" (ie le fond de ciel, en l'espèce).
De base il est sur auto, mais on peut le bouger à la main. Ici sur une très vieille brute de M42, 8 secondes de pose au C6, j'y suis allé fort pour montrer l'effet. Je ne sais pas si c'est réellement réglable quand tu es mode batch, par contre...

[steph37]

Merci @clouzot pour ces infos !

Je ne sais pas si c'est réellement réglable quand tu es mode batch, par contre...

Je n'ai pas réussi à trouver quelque chose qui ressemble dans la déconvolution d'une séquence.
Je vais faire un nouvel essai sans changer la durée d'expo mais en ajoutant un bon paquet d'images à celles que j'ai déjà pour essayer de donner plus de pêche au résultat

Une autre piste après serait de combiner des images avec des durées d'expo différentes

[steph37]

dec_r_pp_JA_M57_stacked_apres_etirement.png (423.97 Kio) Consulté 1968 fois

Toujours M57, mon objectif du moment. J'ai fait de nombreux essais car je n'arrivais pas à augmenter le niveau de détail en restant autour de +35 dB et 500 ms même en empilant beaucoup d'images. Ici je crois qu'il y a un peu d'amélioration avec seulement 3000 images stackées. Il a fallu augmenter le gain à 400 (+40 dB) et l'expo à 800 ms

[steph37]

dec_r_pp_JAJB_M57_stacked_mini.png (542.6 Kio) Consulté 1939 fois

Une dernière de M57. Là j'ai remis sur la table toutes les images prises sur 2 soirées avec les mêmes réglages que précédemment. J'ai pré-traité chaque séquence avec son dark puis cumulé les séquences prétraitées avec la commande merge de Siril. Et hop ensuite alignement, sélection avec l'outil graphique (4000 images sur 9500) et puis déconvolution de chaque image et enfin empilement.

On pourrait continuer à utiliser la même méthode pour une troisième soirée... et ainsi de suite mais il n'est pas exclu qu'on tombe à un moment sur un problème d'espace disque. Il faudra alors renoncer "à remettre sur la table l'ensemble des images" ce qui est dommage (car l'idée me plaît ) mais on pourra sans doute regrouper un premier paquet de brutes, le traiter jusqu'au bout. Faire pareil avec un second paquet de brutes puis combiner les images obtenues.

Bon après tout ces essais, je trouve cette option "poses courtes" toujours très sympa, ça vaut le coup d'essayer ! Par contre, il ne faut pas s'attendre à des résultats miraculeux si on n'a que peu d'images. A mon sens, il faut dans l'idéal viser x fois 10 000 images brutes, x variant selon sa patience. Avec le matériel que j'ai, pas très lumineux, il est pratiquement obligatoire de combiner les images de plusieurs nuits pour obtenir un nombre suffisant d'images. Les poses courtes nécessitent de la patience

Si on a l'impression que "ça ne marche pas", on a peut-être choisi une cible pas assez lumineuse ou il faut songer à augmenter le gain et/ou le temps d'expo.

[Ubuntu]

Très jolie M57, bravo!!! on voit qu'il y a du boulot

[steph37]

Super merci @Ubuntu !
Avec Siril ( et Affinity pour la cosmétique) on arrive à sortir des images fines à partir de milliers de brutes infâmes, ça continue de m'étonner

[soulearth]

Ton expérimentation prend vraiment des allures de solide expérience. Chapeau.

[clouzot]

Superbe !
Sur l’espace disque, est-ce qu’il serait possible de graduellement dégager les brutes au fur et à mesure que tu montes en critère de qualité, soirée après soirée ? Sans forcément les stacker par paquet

[steph37]

Merci beaucoup @soulearth et @clouzot !
Oui tu as raison @clouzot c'est nettement plus malin !
Il y a déjà des brutes qui sont tellement moches qu'il est inutile de les poser sur la table à chaque fois, elles ne seront de toute façon jamais choisies.

Ensuite en ayant une idée du nombre de brutes que l'on veut garder au final, on voit une sorte d'effet cliquet pour éliminer les plus moches au fur et à mesure que le stock de chouettes monte en qualité. On va dire qu'on veut conserver au final 5000 images, par exemple.

On imagine un réservoir de 5000 images, résultat des nuits précédentes. On verse la moisson de la nuit, on a maintenant 8000 images au total, on garde les 5000 meilleures et on continue.

Et voilà une nouvelle fonction dans Siril, mergeif avec le paramètre count (le nombre d'images maxi conservé), une demande pour @cissou8 ?
il faudrait que le résultat du mergeif ne conserve physiquement que les images sélectionnées (car il faut économiser l'espace disque)

[soulearth]

C'est vrai que conserver uniquement les x meilleurs suivant les critères habituels ce serait bien pratique. En gros ne conserver que ceux qui passent la sélection pour être stacké.

[steph37]

Oui @soulearth et le truc à bien voir c'est que le critère de sélection, dans mon idée (non c'est l'idée de @clouzot ) il est en fait mobile, il a tendance à décroître.
Ce que j'imagine fixe c'est le nombre d'images retenues, le réservoir.
Quand tu amènes une bonne moisson de brutes, tu les insères et tu dégages les plus moches, la FWHM maxi du paquet peut ainsi diminuer.
Par ex :
nuit A : on a 5000 images avec FWHM < 3
nuit B : on a de bonnes images on les insère dans le réservoir et on dégage les plus moches. Après le mergeif, on a toujours 5000 images dans le réservoir mais on a, par exemple, FWHM < 2.8
nuit C, c'est nul toutes les images sont avec FWHM > 2.8 : on ne fait rien, le contenu du réservoir est inchangé
nuit D , c'est dingue on a des images au top et on se retrouve par exemple avec 5000 images dans le réservoir avec, par exemple, FWHM < 2.5

[steph37]

En fait @clouzot je bute sur un point.
On imagine que j'ai produit des images au cours de deux nuits, j'ai converti les .SER en séquence fits, calibré et je me retrouve avec 2 fits, par exemple

pp_nuitA de 50 Go
pp_nuitB de 30 Go

Quand je les fusionne avec merge, j'obtiens pp_nuitAnuitB de 80 Go

Si je sélectionne les 1000 meilleures avec l'outil Graphique de Siril, seules ces images seront traitées par la suite mais le volume occupé sur le disque par pp_nuitAnuitB est toujours de 80 Go.
Ce que que ne sais pas faire, c'est effacer physiquement d'une séquence les images non sélectionnées dans le but de réduire le volume occupé.

Que t'en semble ?

Edit :
Il se pourrait qu'une solution soit de sélectionner dans graphiques les images intéressantes puis d'aller dans l'onglet séquence et d'exporter au format .fits puis d'aller dans Conversion pour transformer ces images en séquence fits ; on se porte bien de préfixer le nom cette séquence par les lettres pp_ . Cette séquence, il reste à la merger avec le fichier pp_ de la dernière nuit et puis de dérouler la suite du traitement.
Honnêtement ça marche mais c'est lourd.

[clouzot]

De ma connaissance très parcellaire de SiriL j’aurais fait pareil. Mais peut-être existe-t-il une meilleure solution. On demande @cissou8 au parloir

[steph37]

Merci @clouzot !
Ah oui on pourrait rêver dans la partie Graphique de Siril d'une touche de "dégonflage" permettant d'effacer pour de vrai les images non sélectionnées

@cissou8 avec nous !

[cissou8]

Et voilà une nouvelle fonction dans Siril, mergeif avec le paramètre count (le nombre d'images maxi conservé), une demande pour @cissou8 ?

Aie aie, je profite de mes vacances pour faire mon plan de dev mais celle-la, elle est carrement pas sur la liste. On a deja eu des demandes un peu similaires (garder X images maxi, sans le merge qui rajoute un twist supplementaire ) mais des qu'on se penche sur les details, ca coince. Garder X images ok, mais selon quel critere? FWHM, wFWHM, roundeur, un mix de plusieurs... combien pese chacun des criteres etc... bref, c'est un peu epineux pour un cas d'usage qui nous parait un peu a la marge et sur lequel aucun d'entre nous s'est jete pour l'implementer.
Pour aller plus loin, je t'avoue que j'ai un peu du mal a voir le bien-fonde de la demarche "je limite a XXX images" (je n'oublie pas bien sur le probleme de place).... je m'explique. Pourquoi 5000? Si durant ta troisieme nuit que tu as pas encore shootee, tu as un seeing de fou et que tu 'en mets pour 30000 images et que 50% sont en dessous de x" de FWHM et au-dessus de 0.9 de roundness, tu vas qd meme pas jeter 10000 images alors que tu t'etais dit 2 nuits avant que 5000, c'etait le bon nombre (= le nombre que tu peux stocker). Dit autrement, je t'avoue qu'un tri/stockage sur autre chose que sur de la mesure de finesse des etoiles, j'ai du mal a voir le truc. Par contre jeter les images avec des etoiles en patate que c'est sur que tu voudras jamais les sauver, oui. Tu selectionnes, tu vas dans Export dans l'Onglet séquence et tu les sauves en fits. Et ainsi de suite au fur et a mesure de tes nuits. Et a la fin tu en auras le nombre que tes nuits t'auront permis d'engranger. Pour avoir essayer le lucky a un moment, le nerf de la guerre c'est vraiment le stockage....(la patience aussi et j'en ai pas trop)

Ce que que ne sais pas faire, c'est effacer physiquement d'une séquence les images non sélectionnées dans le but de réduire le volume occupé.

Ca, par contre, on a tranche et on veut juste pas le faire. C'est trop dangereux. On a trop d'users pas experimentes qui feraient des ravages avec une commande du style `rm`. On a meme une entree dans la FAQ pour expliquer pourquoi: https://siril.org/faq/#could-you-add-co ... -sequences

Apres, pour ce que tu racontes, ca se scripte super bien en bash/powershell/python (rayer les mensions inutiles... je sais deja ce que @clouzot va rayer ). Je peux t'expliquer un peu le contenu du fichier seq qui est pas tres complique a comprendre et qui a toutes les infos necessaires. Je crois meme que dans pySiril, y a des methodes pour les lire et remplir un dictionnaire avec leur contenu.

[steph37]

Merci pour ta réponse @cissou8 alors que tu es en vacances !

Je suis pas sûr qu'on se soit bien compris, alors j'essaie de mieux expliquer.

Le nombre de 5000 images
C'est pour moi, la quantité d'images, qui une fois stackées, feront une image finale de qualité suffisante. C'est une constatation expérimentale, pratique, valable pour mon setup et mes cibles. Ça serait encore mieux avec 50 000 images mais, de façon certaine, je n'aurai pas la patience nécessaire. 5000 ce n'est donc pas une limite imposée par mon stockage. Dans la pratique, je sais que ça me suffit pour ce que je veux obtenir.
Je pense qu'au bout d'un certain temps chacun doit pouvoir déterminer le nombre d'images qui lui conviennent, dans le cadre de cette pratique en mode dilettante. Dans mon idée de commande mergeif, ce nombre est paramétrable.

La qualité des images
J'aime bien les solutions simples mais encore faut-il qu'elles fonctionnent Bin voilà, en pratique, coup de chance, j'ai constaté que ça me suffit de prendre en compte la FWHM

La constitution du réservoir d'images
L'idée (suggérée par l'ami @clouzot ) c'est de se constituer progressivement un réservoir de bonnes images. Quand on apporte la moisson d'une nuit, on insère dans le réservoir les images qui sont meilleures que celles qu'on a déjà et du coup on se sépare de quelques moches. Du coup, le FWHM max de ce paquet d'images a une tendance naturelle à diminuer. Finalement on trie bien sur la finesse des étoiles mais la limite est variable Garder une grande quantité d'images moyennes ne sert vraiment à rien (expérimenté pour vous).

La commande merge actuelle
En ajoutant la moisson de chaque nuit, on ajoute des gigas de données alors qu'on ne retiendra peut-être que quelques images. Pouvoir dire : ajoute moi ça et ne garde dans le résultat que les 5000 (par ex) meilleures serait pour moi un grand plus

Et voilà !

Je te remercie pour ta proposition sympa de me passer un kit pour développer moi-même le script qui me manque. Je ne suis pas développeur, suis un blaireau en Python donc n'hésite pas à charger le panier.

[cissou8]

Je te remercie pour ta proposition sympa de me passer un kit pour développer moi-même le script qui me manque. Je ne suis pas développeur, suis un blaireau en Python donc n'hésite pas à charger le panier

Alors, pour que je t'aiguille sans te noyer sous les infos pas pertinentes, je vais avoir besoin d'avoir qqs détails en plus sur ton workflow/système
- quel os? Parce que si c'est pas windows, on peut bosser par images fits seules alors que sinon, on va devoir passer par des formats multi-images (fitseq, ser) et ça va rendre le truc moins souple
- dans ta "réserve" d'images, c'est quoi que tu stockes, images brutes/pretraitees/deconvoluees? Deconvoluees, ça va rajouter un step à l'export parce qu'il faudrait refaire une registration 2pass pour faire évaluer les nouvelles data sur les etoiles

A+

C.

[steph37]

Merci @cissou8 !
Siril je l'utilise essentiellement sous Windows (car j'ai Affinity Photo en complément) et si, je suis coincé, j'utilise Siril sous Linux.

Je ne sais pas si ce que je fais est malin mais j'ai trouvé que stocker les images au format fitseq et après la calibration est un bon plan pour moi. (ma caméra n'est pas refroidie, je fais des darks sur le terrain, ils sont spécifiques à une nuit).

J'ai donc par nuit un fitseq que j'ai pré_traité (dark uniquement) et qui apparait en fichier pp_nuitx... (mes images stockées à ce stade ne sont pas déconvoluées)

A un moment, je décide que j'ai assez d'images. J'utilise alors le merge sur les fichiers pp_ nuitA, pp_nuitB ... pour fabriquer un fichier pp_fusion (toujours au format fitseq)

Ensuite sur le fichier pp_fusion, j'aligne, je lance "graphique" pour sélectionner un paquet de 4 ou 5000 meilleures (FWHM) et je lance la déconvolution sur chaque brute sélectionnée. Je procède comme ça car la déconvolution prend quand même beaucoup de temps et ça n'a pas de sens de la lancer sur la totalité des images.

Cette façon de faire fonctionne très bien, elle a le désavantage de consommer beaucoup d'espace disque.

[cissou8]

Je ne sais pas si ce que je fais est malin

C'est pas malin ou pas malin, disons que pour joindre des sequences, c'est pas le format le plus pratique. Malheureusement ss Windows, pour ce que tu fais, c'est normal que tu te sois retrouve coince avec ce format vu que tu peux pas faire des sequences de plus de 2048 fichiers.

Pourquoi c'est pas pratique dans le cas d'usage que tu m'as decrit:
Tu veux pouvoir virer des images de tes sequences calibrees au fur et a mesure des nuits. Pour faire ca en fitseq, il faut reecrire un nouveau fitseq, puisque c'est un tout. Tu ne peux pas dire "enleve de la memoire telles images". Tu dois creer un nouveau container, ecrire les images selectionnees dedans, et ensuite effacer l'ancien fichier.

Si on reste sur ce worflow, il faut:
- chaque nuit, faire un fitseq calibre, pp_nuitx
- lui faire un alignement 2 pass ou 1,2,3 etoiles juste pour mesurer tes etoiles
- regarder quelle fwhm t'emmene a 5000 sur l'ensemble de tes nuits (ca, ca se scripte en analysant les differents .seq)
- faire un export de chaque fitseq en ayant sette un filtre sur la FWHM (ca, ca se scripte pas.... on a un ticket ouvert la-dessus donc c'est a la pogne. C'est meme pas que le filtrage, c'est juste l'export...) pour que, par la grace de l'analyse faite a l'etape d'avant, chaque fitseq ne contienne que des images avec la FWHM qui va bien pour que sur l'ensemble on arrive a 5000. Puis virer les fitseq parents.
C'est pas infaisable mais un peu relou

Si tu passes ss Linux:
- chaque nuit, faire des fits calibres, pp_nuitx_00001,2 etc...
- lui faire un alignement 2 pass ou 1,2,3 etoiles juste pour mesurer tes etoiles
- regarder quelle fwhm t'emmene a 5000 sur l'ensemble de tes nuits (ca, ca se scripte en analysant les differents .seq)
- et c'est la que ca devient interessant. L'analyse de tes .seq te dit quelles images calibrees tu peux aller detruire. Ca se scripte en python aussi. Donc ton analyseur de sequences, il peut aussi aller faire le menage pour toi. Et te reecrire le .seq propre, qui a garde les infos des etoiles mais qui s'est recale sur uniquement les images existantes.
Quand tu as fini, tu vas pecher toutes tes images individuelles dans chacun des folders, tu convertis en une grosse sequence de 5000 images (ca se scripte aussi au cas ou t'aies pas encore compris, je kiffe un peu scripter...), tu realignes tout ce beau monde (alors, si tu aimes les matrices d'homographie, on pourrait meme eviter cette etape mais enfin bon, ca plait pas a tout le monde) et tu enquilles ta deconvo et ton stack...

Voila, tu sais tout... donc dis-moi quelle voie te tente et je te donnerai les grandes lignes, et les bons outils

C.

[steph37]

Merci @cissou8 d'avoir réfléchi à l'affaire. Je trouvais le format fitseq diablement pratique car il permet de ne pas se retrouver avec des milliers de fichiers... Oui mais je comprends qu'il devient un handicap si on veut bricoler à l'intérieur

Mon redoutable instinct me fait croire que la version "Linux" te sourit d'avantage et ça me sourit aussi ! (Windows, c'est juste pour faire tourner mes outils "photo" que je l'ai installé et du coup j'en profitais pour Siril. Mais le reste du temps je suis sous Linux)

Donc je signe pour la version Linux, merci à toi !