Cyril Richard

Sisi. Mais faut bien regarder les infos données en console.

Et aussi, il y'a l'astrométrie de Siril qui informe si l'image doit être retournée ou non :).

Il y a pu avoir d'autre manip sur d'autres softs. Je connais très bien ce soucis d'images inversées et ca ne se produit pas si on utilise Siril de A à Z. Je le saurais depuis le temps. C'est à cause de la façon différente dont les logiciels enregistrent les FITS.

Non. Siril n'inverse pas. D'autant plus sur des images d'APN faite avec siril de A à Z. Il peut y avoir une inversion quand siril travaille avec des FITS fourni par des logiciels tiers qui enregistrent les data dans l'autre sens.

Merci pour vos gentils messages. Ces images Ha + RGB me permettent de développer des outils pour Siril 0.9.12. Du coup c'est bien. En plus, j'ai rarement autant utiliser le logiciel donc je peux corriger les bugs :). La casse à cause des mauvais flats ... Très dur à récupérer. Le piqué du 135 me semble meilleur, mais bon, la focal est bien moindre. Le 200mm de canon (qui est de la série L) est au dessus à mon avis car le vignettage est quasiment nul et je ne faisais pas de flat. Ce qui explique que je me sois fait piéger.

Tu peux contacter le développeur de Sirilic, il répondra a tes questions.

Les deux logiciels n'ont rien à voir. Sirilic a besoin de Siril pour marcher. Sirilic créé des scripts. Oui mais pour ça il faut du temps. Or, coder des logiciels prend déjà beaucoup de temps. Moi personnellement, à choisir, je préfère investir le peu de temps que j'ai dans une journée (qui ne fait que 24h, et je compte pas le boulot, les activités dans le jardin, les enfants et tout le reste) dans le développement logiciel. Donc, oui, les docs je laisse ça aux autres. Deux logiciels séparés, voir plus haut. Sirilic est un utilitaire qui permet de faire des scripts, mais aussi de lancer siril en tache de fond si on le souhaite.

Même en 16bits c'est pas bon.

Pour ca il y a l'utilitaire sirilic.

Faire un stacking par somme, empile les images par somme sur 32 bits puis normalise sur 16bits. Ca fait que la valeur max est de 65535 (si on a bcp suffisamment de dark pour atteindre la valeur max en 32bits : 2^(32), ce qui m'étonnerait quand même). Cependant, on soustrait donc aux lights un dark avec une valeur biaisé. Alors que nous ce qu'on veut faire, c'est une moyenne. Comme j'ai dit, pour les darks on ne normalise pas en 16bits sur la moyenne. Car quand on va soustraire le dark aux lights, on ferait du 8bits - 16bits et ca donnerait des trucs tout noir. La conversion 16bits se fait lors de l'empilement des lights prétraitées. Bien sûr, si tu shoot direct en 16bits pas ce soucis.

A éviter totalement !!! SUrtout si on enregistre en 8bits (mais même en 16bits aussi, car ca change totalement la dynamique et le dark aura un trop haut signal lors de la soustraction).. Il faut empiler par moyenne tous les DOFs et décocher la case de normalisation & 16bits si on shoot en 8bits. On la recochera lors du stack de la vidéo light.

Merci pour vos messages. Je vais essayer de faire la RGB ce soir, en début de soirée. Ensuite en combinant la couche R a la Ha je pense qu'on ne verra plus trop le bruit.

Bonjour tout le monde. Encore une semaine de beau temps !!! Alors on en profite pour tester un 135mm de chez Samyang que j'ai en prêt. Quelle bonne idée !! C'est un excellent caillou que je conseille à tous : il a un super piqué. J'ai cherché une cible, j'étais un peu à court d'idée. mais on m'a alors suggéré de faire NGC 7822. Honnêtement je ne la connaissais pas et j'ai donc jeté un œil à wikipedia. La phrase m'a encore plus motivé à m'aventurer dans cette région HII. J'espère lui faire la RGB prochainement, bien que ma seule prochaine fenêtre semble être vendredi et que la Lune sera encore là en deuxième partie de nuit. Je vous présente donc le premier jet de cette nébuleuse prise hier, avec les EXIFs, et si vous avez des remarques et commentaires, n'hésitez pas :  L'étoile, si je ne me trompe pas, ce trouve là : Les données techniques sont les suivantes : 66x120'' / Ha - 6nm iOptron SkyTracker + Canon100D + Samyang 135mm f/2 ouvert à 2.8 Canapé + séries américaines à la con pendant les poses Traitement avec Siril 0.9.12 beta + GIMP + Darktable

On peut le faire sous siril maintenant ça aussi

Via le site officiel tu as accès à des cours en ligne gratuit. Tu auras tout ce que tu veux la bas.

Justement. Si un empilement en temps normal (et même sur des petits capteurs) prend plusieurs heures c'est parce que les calculs sont nombreux et complexes. Or, dans un livestack on en fait beaucoup moins pour gagner en vitesse et garder l'esprit live. Donc non, on peut pas faire qqchose d'aussi bien en live, c'est mathématique. Le livestack se rapproche du "sum stacking" de Siril en terme d'algorithme. Si après chaque pose on cherche a réévaluer on va très vite s'éloigner du live. Par exemple, calculer une médiane du stack (souvent nécessaire dans le rejet des pixels) nécessite de connaître toutes les valeurs du stack et de les trier (pour certaines approches algorithmiques). Un rejet de pixel type linear fit clipping nécessite lui de connaître tout le stack pour faire un ajustement des data ainsi qu'une minimisation par méthode des moindres carrés. Notre méthode de normalisation contient des algorithmes qui sont très performant mais intrinsèquement lent, avec minimisation ici aussi. Bref, encore un truc ou on a besoin de tout. Moralité : on n'a rien sans rien. Crois moi, on essaye constamment de réduire le temps d'empilement dans Siril. Ça passe par de grosses optimisations (choix d'algorithmes plus rapides), mais on ne peut pas faire de miracles. Et si les algos sont lents, c'est qu'ils permettent de faire des trucs que ne font pas les plus rapides. En fait, à mon sens, c'est l'inverse. C'est bien dommage que sharpcap (ou autres) ne soient pas libres :). Leur implémentation non, mais une implémentation oui. C'est chose prévue dans Siril.

Pas seulement non. Et si sharpcap prend du code de siril il faur respecter la GPL et publier le code correspndant. Pas sûr que ca les intéresse . Sinon, non le live ne peut pas obtenir de meilleur résultat qu'un traitement classique. Ce qui fait que le traitement classique est meilleur c'est justement qu'on a tte les photos en amont pour pouvoir faire une normalisation, des rejets de pixels (qui necessitent les stats du stack complet, etc ....), et aussi, choisir une image de référence.

T'as une selection des frames sur plusieurs critères stellaires

A ton avis Et fait des SER !!

En fait, j'aime pas trop le nom de "SUpression de bruit vert" mais je ne savais pas comment l'appeler. Photoshop a un plugin Hasta la vista Green, PixInsight Subtractive Chromatic Noise Reduction. Mais pour moi on ne supprime pas vraiment du bruit. Disons que cet algo part du postulat que dans l'espace, hormis les comètes et certaines NP, rien n'est vert. Donc si tu as des pixels de couleurs verte c'est du bruit. En fait c'est un peu plus compliqué car ca peut être a cause de l'espace de couleur dans lequel tu bosses, d'un mauvais étalonnage de couleur, ... Bref, cet outil est souvent utilisé la ou il ne devrait pas. Ici par exemple, c'est une belle utilisation détournée qui consiste a remplacer les pixels verts (dans l'espace de couleur inverse) par une combinaison des pixels rouges et bleus.

@Jean-Philippe Cazard: si tu veux enlever cette couleur magenta. Dans siril tape (ctrl + I) pour inverser ton image. Puis dans Traitement de l'image, fait un retrait de bruit vert. Puis enfin, refais CTRL+I. Bonne journée ;)?

Sinon tes images sont très jolies.