vinvin

La normalisation n'est calculée qu'une fois, ça ne date pas de 2004 mais de 2018 L'empilement est toujours refait du début à part ça.

En fait si tu additionnes des images 16 bits qui ont une bonne dynamique, ça revient à une moyenne dans le cas de siril vu qu'on normalise à 16 bits au final. C'est pour ça que Cyril a ajouté l'empilement par moyenne avec rejet, qui donne le même genre de S/N au final. La somme apporte vraiment quelque chose pour des images 8 bits, avec la sortie en 16.

Ok il faudrait diviser par le nombre d'images dans ton cas en fait, mais le résultat ne sera pas aussi bon que si on empile toutes les images en même temps il me semble. Il faudrait vraiment que je fasse les séquences dynamiques dont je parlais dans l'autre discussion...

visiblement le forum ne gère pas le changement de page quand on poste

ça m'étonnerait que ça fasse ça si tu ne l'as pas codé, ça doit faire valeur & 65535 donc valeur % 65536 plutôt. On avait prévu de faire une sauvegarde de l'empilement dans un format 32 ou 64 bits, y'aura pas besoin de normaliser à 16 bits dans ce cas, mais vu que les traitements de siril utilisent encore du 16 bits, ce n'était pas prioritaire. Mais quel est le problème avec cette normalisation en fait ? Si tu affiches en asinh ou autre ça donnera le même résultat peu importe la dynamique.

En général avec les window managers de X on peut bouger les fenêtres hors de l'écran en utilisant alt ou la touche windows avant de cliquer dedans pour les déplacer (on peut faire ça sous windows avec le logiciel altdrag d'ailleurs). C'est aussi chiant pour siril dont la fenêtre principale fait presque 800px...

Après empilement par somme, on obtient une valeur pour chaque pixel qui vaut N, et un maximum de tous les N qui est M. Si M < 65535, on garde la valeur N pour tous les pixels, sinon on prend N * 65535 / M. Donc dans ton cas, si 80000 est la plus haute valeur de l'image, ça deviendra 65535, mais les autres valeurs plus petites de l'image se retrouveront entre 0 et 65535.

Voir https://free-astro.org/index.php/Siril:Commands#stack pour les arguments supportés, pour la somme c'est comme dans la GUI, y'a pas de rejet. C'est bien une somme mais il faut que la somme rentre dans le résultat qui est en 16 bits, alors si la somme dépasse 65535, on normalise par 65536 divisé par la valeur maximale de la somme.

Hors de question de donner de l'argent à microsoft ou verisign.

Tiens pour info aujourd'hui et demain le Raspberry Pi 3 Model B+ est à 40 euros sur LDLC avec le code promo PREDATOR.

On pourrait utiliser ça aussi, ça fait double emploi avec le wiki pour siril actuellement https://gitlab.com/help/user/project/releases/index

Je suis d'accord avec tout ce que tu as dit. Merci

Faut voir ce qui est le plus utile aux gens, un package qui a les deux c'est bien aussi probablement pour windows, tant que c'est clair que c'est siril + sirilic + sirilot. Perso ça ne me choque pas, mais vu qu'avec python le package sera beaucoup plus gros je pense, ça serait bien d'avoir aussi le package de siril seul, mais ça fait plus de boulot de packaging, le truc le plus chiant du monde...

Dans ta capture d'écran, la couleur associée à la couche rouge est assombrie pour devenir rouge à 50.76% de luminosité, ainsi que la couche H-alpha pour que la somme des deux ne dépasse pas 100% pour les valeurs maximales de chaque image. Donc ce sont bien deux couches différente de couleur identique dans ce cas. Tu peux choisir de faire du H-alpha rose pour mieux le différencier du filtre rouge, mais ça ne sera pas la couleur réelle.

L'ajustement a pour but de ne pas faire dépasser les valeurs des pixels dans l'image finale. Quand on ajoute deux fois du rouge, c'est deux fois trop pour le résultat, donc ça les divise par deux pour des images en pleine dynamique. Pareil si on ajoute du violet à du bleu et du rouge, ça fait trop de bleu et de rouge donc il faut réduire les trois.