Vincent-FA

C'est toujours fou le nombre d'étoiles qu'on peut voir sur ces champs, surtout avec le seeing de Calern ! Merci pour le partage !

C'est probablement une question de gestion de mémoire, je suppose que pour éviter de sortir de la RAM siril n'utilise qu'un core au lieu de 4. Peut-être que tu peux essayer la commande setmem 2, sinon il faudra attendre la version suivante. Tu as combien de mémoire RAM sur l'ordi ? En fermant les autres applications ça pourrait améliorer la chose aussi.

Oui, bravo ! Bonne idée les presets !

Ca manque un peu de RGB en fait pour avoir une référence un peu neutre RGBHaOIII ça serait cool !

Dans la nouvelle version de siril, la suppression de fond de ciel a été revue et arrive mieux qu'avant à supprimer les dégradés, même sans étirer les images avant. Par contre on ne peut plus visualiser l'image de fond avant de l'enlever, mais on peut revenir en arrière si ce n'était pas bien.

Oui. Si c'est bien calculé, pas besoin de les ajuster il me semble. L'ajustement sert à ce que si on a mis deux images complètement vertes par exemple ça les mette en demi-vert, ce qui est aussi une possibilité. La suppression du bruit vert baah à toi de voir après, le vert de l'image sera issu de ce que tu as mis dans les couleurs des différentes couches, si c'est trop vert, soit tu peux faire ça, soit tu peux mettre un vert moins vert, genre #00CF00 au lieu de #00FF00.

Réponse à Cyril et Michel : le but de l'opération est de faire une image qui ne ressemble pas à la réalité en mélangeant des trucs pour que ça fasse joli. HOO ça n'existe pas en vrai, pour plus de réalisme, il y a déjà la sélection des filtres dans la composition RGB de siril, et par exemple, la conversion de longueur d'onde de OIII en RGB donne du vert à 100% et bleu à 54%. Pour répondre à une question précédente : j'ai vérifié à quoi ressemblait la fenêtre de modification de couleur dans l'outil de composition RGB, et en fait pour faire du 50-50% sur une couleur à partir de deux couches, c'est plus simple d'utiliser les couleurs de la deuxième ligne, celles qui sont un peu plus sombres que les couleurs franches, et d'affecter une de celles-là à deux couches dupliquées. J'ai du mal à voir comment on pourrait faire un curseur qui mélange les deux couches avec un rapport variable, l'interface n'est pas faite pour. La fenêtre avec le choix de la couleur dans le dégradé et l'inscription en hexadécimal en haut est une fenêtre générique fournie par GTK+, mais permet de voir quelle quantité on met de chaque couleur. En calculant rapidement le ratio qu'on veut, on peut mettre la bonne valeur en hexa... Exemple avec deux couches, mais ça marche aussi avec 18 si on veut : image 1: 100% dans le rouge et 20% dans le vert image 2 : 100% dans le bleu et 80% dans le vert Le niveau de sortie maximal est 255, soit ff en hexadécimal. et 20% de 255 c'est 51, ce qui donne 33 en hexa, je mets donc #ff3300 pour l'image 1 et #00ccff pour l'image 2, puisque ff - 33 = cc (ou 255-51=204).

En alignement multi-points il n'y a pas besoin de faire de la rotation normalement, en tout cas aucun des logiciels de référence n'en font à ma connaissance. Dans siril on l'utilise pour le ciel profond, souvent à contre-coeur parce que ça modifie les données d'une façon qu'on aime pas trop, mais au final le gain en FWHM est positif. Je ne me rappelle pas avoir vu de trame comme ça à cause de la rotation par contre, mais je sais aussi qu'il faut faire attention à l'interpolation utilisée lors de la rotation, lanczos-4 est généralement la meilleure. Pour le calcul en parallèle, ça dépend du langage. En C ou C++, il y'a OpenMP qui fait tout le boulot. En C# il y Parallel.For par exemple comme équivalent.

Oui comme ça, l'autre technique c'est de mettre une couleur qui est un mélange sur les deux couches, en hexa ça donnerait 0xff7f00 et 0x007fff.

C'est pas le même vinvin Faire du H (H+O) O, c'est possible, mais pas très intuitif : soit on le fait avec 4 couches dont deux fois les deux mêmes chargées, et la même couleur (verte) affectée à deux différentes, soit avec deux couches qui ont une couleur rouge + demi-vert et bleu + demi-vert, ce qui se calcule avec l'outil GTK+ de sélection de couleur je crois.

Pour siril il y a des cours en ligne spécialement faits pour, avec des exemples et des fichiers pour s’entraîner : https://www.learn.siril.org/?lang=fr Il y a aussi le tuto de Colmic qui est fait pour les images d'APN, mais ça s'adapte... Pour les caméras monochromes, où on se retrouve avec beaucoup d'images, les gens utilisent plutôt sirilic qui est un outil de gestion des fichiers et création de scripts pour siril. Voir ici https://astroslacholet.wordpress.com/2019/05/12/utilitaire-conv2siril/ ou ici https://www.siril.org/fr/2018/11/15/sirilic-et-sirilot-deux-utilitaires-tres-utiles-pour-siril/ pour plus d'infos. Bon ciel

Original tiens, bien joué

C'est pas que c'est nécessaire, mais comment définirais-tu la limite entre celles qui sont bonnes et celles qui ne le sont pas ? Si leur magnitude relative n'est pas stable, et que leur couleur change, le problème de la calibration B-V n'a pas de solution exacte et donc on fait un résultat approximé.

Merci pour l'info, je regarderai ça.

Siril n'utilise actuellement pas les GPU. Mais c'est prévu qu'on travaille dessus, pas forcément cette année... Quelqu'un a parlé de développé pour les NVidia, j'ai parlé d'utiliser les ARM-Mali. Ca prend beaucoup de temps de porter du code CPU vers le GPU (surtout qu'il faut un ordinateur qui en soit équipé), mais le gain est souvent de 10 à 100 fois. Pour le dématriçage et l'empilement, nous avons pu voir que c'était plus rapide de plusieurs dizaines de fois que siril dans les premiers tests, ça vaut franchement le coup, et pour le ciel profond rapide ça changerait la donne. Donc pour l'instant je dis comme Colmic. Plus on a de cores mieux c'est, plus on a de mémoire mieux c'est. Plus on a de mémoire, plus les cores peuvent être utilisés, plus on a de mémoire, moins on est limité par le disque. Plus on a de cores, plus on a besoin d'un disque rapide ou de mettre les fichiers en mémoire. Edit: tant que j'y pense la version 0.9.11 améliore d'un facteur non négligeable la vitesse de traitement par rapport à la 0.9.10, et utilise en plus mieux la mémoire et les cores pour s'adapter aux limites de chaque.