Siril 0.9.0 stable

[alphamax]

merci !

 

je me demande, pour des filé pas trop longs, avec des poses unitaires longues, une moyenne sans rejet ne permet-elle pas de minimiser le bruit ? On aurait des étoiles un peu estompées, mais je crois que je vais tester la prochaine fois !

 

Dans la rubrique, j'ai testé pour vous, voici ce que donne un empilement par moyenne sans rejet :

 

 

Ca minimise en peut trop et pas que le bruit

Je n'ai pris qu'une soixantaine de photos pour faire le test.

[TIbasic]

Dans la rubrique, j'ai testé pour vous, voici ce que donne un empilement par moyenne sans rejet :

 

 

Ca minimise en peut trop et pas que le bruit

Je n'ai pris qu'une soixantaine de photos pour faire le test.

 

Je pensais à beaucoup moins de poses que ça moi, comme 10 poses de 4 ou 5 minutes, qui suffisent déjà pour moi à produire de bons filés !

[alphamax]

Je pensais à beaucoup moins de poses que ça moi, comme 10 poses de 4 ou 5 minutes, qui suffisent déjà pour moi à produire de bons filés !

 

ça ne changera rien quant à la lueur des étoiles !!!! A moins de le faire avec un apn beaucoup plus sensible que mon vieux 400D tu vas seulement augmenter le bruit du capteur et le fond du ciel (tes étoiles bougent ).

 

Pour info, j'ai 380 poses de 40 secondes.

[TIbasic]

ça ne changera rien quant à la lueur des étoiles !!!! A moins de le faire avec un apn beaucoup plus sensible que mon vieux 400D tu vas seulement augmenter le bruit du capteur et le fond du ciel (tes étoiles bougent ).

 

Pour info, j'ai 380 poses de 40 secondes.

 

Même si les étoiles son pas plus fortes, à mon avis, moyenner sur 10 photos ou 60, ça change la donne, quand je vois les traînées de satellites sur les photos parfois...

 

pi j'ai un 6D, légèrement plus sensible qu'un 400D...

Bon, je ferais des essais, la moyenne va défoncer les étoiles même si je faisais 3 poses de 10 minutes, mais à voir en fonction de l'avant plan...

[Spectrahm]

Bonjour Cyril,

 

Tout d'abord, mes remerciement pour SIRIL, qui change vraiment la donne sous Linux.

 

Suite à notre discussion je découvre que le programme gère maintenant la photométrie, et je souhaitais savoir si la partie spectro était aussi à l'étude. Songez-vous à terme à implémenter des fonctions de corrections géométriques de spectres (tilt, slant etc.) comme le fait IRIS ?

 

L'offre spectro est encore peu qualitative sous Linux, il reste difficile de se passer d'une VM Windows pour IRIS et ISIS. Mais je suis bien conscient que votre équipe est bénévole, c'est donc juste une suggestion à terme.

[lock042]

Bonjour.

Étant spectroscopiste de formation et de métier, oui c'est quelque chose que j'aimerais ajouter dans le futur. C'est d'ailleurs dans les tuyaux. Cependant, comme tu le soulignes, il faut trouver le temps. Et surtout, tellement de choses méritent d'être améliorées avant de passer à ça .

[Spectrahm]

Merci Cyril, c'est une très bonne nouvelle ! Je compte donc les jours avant de pouvoir me débarrasser de ma VM.

[vinvin]

J'ai aussi des spectres à traiter Pas avant 2018 à mon avis.

Les priorités de la 1.0 sont l'accélération de l'affichage, la gestion interne des images en 32 bits et l'alignement planétaire multi-points, ces 3 trucs nécessitent de réécrire une bonne partie du code.

[Spectrahm]

De toute façon, le pré-traitement des spectres comme le fait IRIS sera une bonne avancée, mais il restera ensuite à trouver un substitut correct à ISIS pour la partie analyse. Ce n'est pas pour demain je pense...

[lock042]

En fait, je sais même pas quel type de traitement/analyse propose ISIS.

[Spectrahm]

Certaines fonctions de correction se télescopent avec IRIS, mais la partie analyse et étalonnage lui est propre.

 

Voici un tutoriel pour le Star Analyser qui donne un bon aperçu :

http://www.astrosurf.com/buil/isis/guide_sa/tuto.htm

[TIbasic]

Perso, je n'utilise isis que pour évaluer les bruit de.lecture et qe de mes capteurs (enfin j'utilise un pote qui utilise ISIS)

 

ça serait sympa comme fonction à terme, d'aider les astrams à déterminer l'iso ou le gain de leur cam cmos optimum en analysant une paire d'offset ! Après, c'est pas du tout prioritaire hein ? Je lance ça comme ça, une fois que le logiciel sera hyper complet de ouf, si les dev s'ennuient...

[lock042]

Bon pour ISIS c'est de la spectro de base. Je développais des trucs similaires pendant ma thèse. C'est pas dur a faire, faut juste avoir le temps... Et là c'est pas gagner .

 

TIbasic : si tu donnes plus d'info on peut le faire avec Siril. Tu sais, on développe souvent en fonction des requêtes des gens .

[Ryo]

Salut Cyril j'ai la revue il me semble avoir mieux compris ce soir après le boulot je mis met, très bon article

[lock042]

Merci.

 

Content que l'article soit lu et apprécié .

Un autre est en préparation.

[alphamax]

Bonjour Cyril et Vincent,

 

je viens de rencontrer un comportement bizarre lors de la conversion d'une séquence n&b croppée vers rgb (dématriçage) en utilisant l'interpolation super pixel.

 

Les images apparaissent complètement de "travioles":confused:

 

 

Voici le résultat de la console (rien de transcendant) :

 

18:11:37: Conversion : en cours...
18:11:37: Lecture du fichier FITS : cropped_pp_L_00001.fit, 1 canal(aux), 2879x2124 pixels
18:11:37: Motif du Filtre : RGGB
18:11:37: Fichier FITS enregistré : fichier RGB_00001.fit, 3 canal(aux), 1440x1062 pixels

En utilisant une autre méthode d'interpolation ça fonctionne bien. C'est vraiment quand on utilise le super pixel sur des images croppées (car je l'ai utilisé dans d'autre contexte sans soucis).

 

J'ai vidé le répertoire de travail au cas où, mais même résultat.

 

Bien cordialement,

Christian

[lock042]

Bonjour. Il ne faut jamais cropper avant un dematricage. Il faut cropper après.

[alphamax]

Bonjour. Il ne faut jamais cropper avant un dematricage. Il faut cropper après.

 

 

Egon: J’ai oublié de vous faire une recommandation essentielle.

 

Peter: Quoi ?

 

Egon: Ne jamais croiser les effluves.

 

Peter: Pourquoi ?

 

Egon: Ce serait mal !

 

Ah . On en apprend tous les jours.

 

Merci Cyril

[lock042]

Héhé.

 

En fait, si tu crop tu perds les informations de taille du capteur et positions des photosites. Il va donc être difficile de reconstruire les couleurs sans les infos.

Si les autres dématriçage semblent marcher c'est juste en apparence. Il suffit de croper d'une taille impaire pour que le shéma de dématriçage ne soit plus bon.

[mbnb24]

Bonjour, lors du prétraitement d'une série. Si j'utilise des darks sans retrait de l'offset et des flats sur une série, ca va très vite (moins de 2s/brute)

Si j'utilise dark (dont j'ai retiré l'offset) flat et offset le prétraitement est très long (8s/brute)

Je travaille sur des séries de 500 à 800 brutes.

Comment expliquer cette différence de vitesse ?

[lock042]

Est-ce que la case "optimiser les darks" est cochée ?

[mbnb24]

non

[lock042]

ok. Si tu décoches la correction cosmétique est-ce aussi long ?

[mbnb24]

je lancerai le test cet après midi et te dirais, je suis toujours sur le prétraitement de ma série de cette nuit

[lock042]

C'est très étrange que ca prenne autant de temps.

Il doit y avoir un problème avec la correction cosmétique. Si le nombre de pixel rejeté est en rouge il faut changer les paramètres. Si ca reste en rouge, notamment pour le rejet bas, il faut décocher la ou c'est rouge.

[mbnb24]

C'est vrai qu'habituellement je fais un dark sans enlever l'offset et que traite juste avec flat et dark, j'ai voulu voir si en prétraitant mes darks j'avais une meilleure réduction de la trame mais c'est long

[mbnb24]

Effectivement quand je fais estimer la correction cosmétique je suis à 0 dans le froid et 91000 dans le chaud

Je refais mon prétraitement comme à l'habitude, la série présente une trame oblique majeure visible dès les brutes

[lock042]

En fait on enlève l'offset au dark quand on désire faire une optimisation des darks. Sinon ca n'est pas vraiment utile.

[mbnb24]

et ce coup-ci aucune trame visible en mode histsogramme sur les brutes et le prétraitement a duré moins de 5 min pour la série

[mbnb24]

qu'est ce qu'apporte une optimisation des darks ?