Ca ne change pas le bruit, ça change la correction des flats. Je n'ai pas bien compris la logique là, il faut juste diviser la médiane par la valeur d'offset (aussi appelée luminosité chez ZWO).

Bonsoir, Gros déterrage, mais d'une part j'ai de plus en plus besoin de temps pour assimiler et, d'autre part, les possibilités d'imager ont été rarissimes. C'est à l'occasion de nouvelles sessions très récentes que j'ai dû me remettre en question. Et tout reprendre du début. En reprenant mes résultats (obtenus avec une BdB et BdR correctes) et en divisant les valeurs median par 64, je me suis rendu compte qu'elles résultaient offset +1. Il me semble donc évident que si je souhaite des résultats corrects il me faut renseigner dans siril 64*$offset, car avec 1024 ce n'est bon que pour un offset de 16, or j'utilise 12 lors de mes prises de vues (pour laquelle 768 conviendrait mieux). J'ignore si l'écart peut être significatif au point d'expliquer le bruit très important que j'ai relevé sur mes traitements récents. Ou si je me triture une fois de plus les neurones inutilement.

Ici il s'agit d'un "snapshot" du dépôt qui contenait les scripts, mais ces derniers ne sont plus développés et je conseille fortement de ne pas les utiliser. C'est pourtant quelque chose que nous avons expliqué à la sortie de la première version qui a supprimé les scripts français : https://siril.org/fr/download/2023-06-01-siril-1.2.0-rc1/#fin-de-la-distribution-des-scripts-français Aussi, on l'a écrit dans la doc : https://siril.readthedocs.io/fr/stable/Scripts.html Et oui, je conseille d'utiliser les scripts officiels, donc anglais, pour les traitements classiques : - ils sont mis à jour continuellement - ils profitent des dernières fonctionnalités

Bonjour, Ok... faudrait donc utiliser le script OSC_Preprocessing, pour une cam couleur... C'est pas forcément intuitif... Sinon, les scripts français fonctionnent toujours sur Siril 1.2.1 ... Ce coup-ci, j'ai effectué mon traitement avec un script fr! Ça fonctionne! JM

Les scripts aux noms "francais" n'existent plus depuis l'introduction de la version 1.2.0. Ils ne sont aussi plus compatibles. Il est donc recommandé de n'utiliser que les scripts "à jour". Il y a un petit laius dans la doc, ici

C'est ce que j'utilise avec une 2600MC

Oui... OSC cela veut dire One-Shot Color... Cela ne ressemble pas à quelque chose de compatible avec le traitement RGB d'une cam couleurs! Non ?? JM

Tu es sûr pour OSC... Je retrouve plus ce que cela veut dire, mais je suis pas sûr! Par contre j'ai trouvé les bons scripts, ici: https://gitlab.com/free-astro/siril/-/tree/cae0c7f813140ca1cde6c9945a0f6a4426e24760/3rdparty/scripts/fr Mais c'était pas facile à trouver! JM

Bonjour @pti-jean Tous les scripts sur cette page https://gitlab.com/free-astro/siril-scripts/-/tree/main/preprocessing?ref_type=heads pour les cam couleur, ce doit être OSC_Startrail.ssf

Bonjour, Le script Couleur_Pre-traitement.ssf ne fonctionne plus sous Siril: Définir le répertoire de travail à '/home/jean-marc/tmp/Siril' 14:31:21: Début du script /home/jean-marc/.siril/scripts/Couleur_Pre-traitement.ssf 14:31:21: La commande "requires" est manquante en début du fichier script. Cette commande est nécessaire pour s'assurer de la compatibilité des scripts. 14:31:21: Définir le répertoire de travail à '/home/jean-marc/tmp/Siril' 14:31:21: L'exécution du script s'est terminée avec succès. 14:31:21: Temps d'exécution total: 7.03 ms Et je ne trouve plus de scripts pour traiter les photos d'une cam couleur... Vous avez une solution ? Merci, JM

Bonsoir Cyril, La raison du rejet massif, j'ai fini par la comprendre : montée de brume chargée de particules fines en haute altitude peu après le début. Nous étions en alerte rouge jusqu'à mercredi, il faut croire que les prévisions étaient erronées et trop optimistes. Je m'en suis réellement rendu compte samedi soir, après avoir lancé deux heures d'acquisition à 30 s, le temps de voir un film. J'ai mis mes difficultés à effectuer la map sur le compte d'une fatigue extrême accumulée ces trois derniers jours et de l'objet lui-même très faible - dans le voisinage immédiat de M51. C'est en examinant les vues après-coup que j'ai commencé à comprendre : fond du ciel tirant sur le caca-d'oie et bord inférieur très lumineux, comme si quelque chose avait amplifié la pollution lumineuse de la ville. Je suis tout de même allé jusqu'à l'alignement des brutes, pour voir : seules 27 photos ont été retenues, 213 ont été écartées, et dans la foulée, j'ai détruit l'intégralité des prises y compris celles des deux précédentes soirées. Ceci étant, je serais content si le cas se reproduit de pouvoir trouver une liste des photos originales correspondant à celles rejetées, histoire de ne pas rajouter encore plus à mes conneries habituelles...

Avoir les logs aiderait largement à comprendre en détail.

Bonjour, Lors de l'alignement des brutes, certaines peuvent être écartées. Elles sont indiquées dans le log de la console, mais je ne suis pas parvenu à faire le lien entre le numéro indiqué en rouge et l'image originale. Par exemple, j'ai l'indication «... image 34 écartée». Dans le fichier LightConversion.txt je vois que la n° 39 correspond au fichier 234921.fits. Mais si je supprime ce dernier et que je recommence toute la procédure depuis la conversion des light jusqu'à l'alignement (dois-je préciser que j'ai bien pris son de supprimer tous les fichiers précédemment générés ?), j'ai de nouveau une image écartée - qui peut être le même numéro que précédemment ou un autre. Accessoirement, je peux même me retrouver avec des images écartées non listées dans la console. J'explique : je démarre l'alignement avec 64 images dans la séquence pp_light, deux sont déclarées écartées, et je me retrouve avec 51 une fois l'alignement terminé. Où sont passées les 11 autres ? C'est du concret, j'ai recommencé dix fois avec deux lots de photos différents après m'en être aperçu tandis que je rédigeais ce message, les dix fois j'ai obtenu les mêmes résultats. Mon souhait serait de pouvoir éliminer à la source les photos écartées, donc trouver quelque part dans les logs un fichier listant les images originales correspondant à celles écartées lors de l'alignement. Un grand merci par anticipation si cela peut voir le jour. J.-Luc

Merci beaucoup 👍Cyril pour ce lien et les conseils qui y sont présentés. Avec les réglages standards 6 étoiles sont détectées. J'ai bougé tous les curseurs et seul celui du seuil a une influence. Avec seuil = 0,15 il y a 25 étoiles, pour 0,10 : 65 étoiles et pour 0,05 : 873 étoiles. Donc énormément de bruit ce qui ne m'étonne pas trop, la lune était là et les lampadaires pas loin. Que me conseillerez vous pour traiter quand même cette image ? Cordialement, Michel

Bonjour, une petite visite ici : https://siril.org/fr/faq/#pourquoi-lalignement-ne-trouve-t-il-pas-détoiles-dans-mes-images- ?

Bonjour, j'ai imagé récemment la galaxie NGC2683 avec un C8 et une caméra 533MC. 120 poses de 15 s chacune avec un gain de 450. Lors du traitement Siril ne trouve pas assez d'étoiles dans les images et le traitement est stoppé. Pourtant quand je veux ouvrir un des fichiers "light" la fenêtre de visualisation du fichier montre un nombre conséquent d'étoiles. Voir image copie d'écran jointe. Par contre en effet l'ouverture d'un de ces fichiers en linéaire ne montre aucune étoile et seulement quelques unes en mode "auto ajustement". JE suis un peu dépité car il me semble qu'il y a moyen de faire quelques chose avec ces images ? Merci de vos conseils, Michel

Hello !!! Merci pour ta reponse Lock !!! En effet je sais que le SSD aiderait beaucoup, il faut que j'investisse !!! Je capture avec Nina, je vais donc verifier si pas de soucis dans les metadonnées.... Bonne idée en tous cas, d'ouvrir le SER !!! au moins j'avance ! Merci encore !! VerBaL

Utilise un disque dur SSD si possible. Tu vas diviser le temps de traiter par bcp. Normalement il y en a pas. Le SER est bien lu si le logiciel de capture a bien renseigné les bonnes infos. Et sinon il suffit d'ouvrir le SER et de le dématricer à la volé pour se rendre compte.

Content que tu ai pu régler ton problème !!! Pour ma part, alors que les réglages de Siril sont d'origine, c'est la galère...car je fais en ce moment du Lucky-imaging (4 à 5000 photos par objet) et ce n'est que lorsque que la photo est traité complètement par Siril ( 24 a 72h après) que je découvre si la matrice utilisée est la bonne... si ce n'est pas le cas je dois modifier la matrice et ré-éssayer... Une méthode ou une idée pour déterminer ce soucis de flip de SER à l'avance? Bien a tous ! VerBaL

Cyril J'ai modifié le paramétrage....et ça marche ! Encore merci. Cordialement. Patrick

Bonjour Cyril Merci de ta réponse, enfin j'ai une solution ! OK pour les pdf auxquels il vaut mieux préférer les jpeg, je ne savais pas (comme tant de choses bien sûr). J'aurais du te poser la question dès la sortie de la version 1.2.0 Cordialement. Patrick

Bonjour. Pour les captures il faut éviter le format PDF. Les images sont directement lisibles dans le forum, c'est mieux. Une petite aide pour mieux poster ces soucis : https://siril.readthedocs.io/fr/stable/Issues.html Sinon, la première capture montre que tu ne récupères pas le motif de Bayer a partir de l'entête. Donc c'est normal pour moi quoi ca foire. Laisse les paramètres par défaut, dans 99% des cas siril sait faire.

Voilà les captures d'écran des options les plus importantes (enfin je pense) Merci par avance. Cordialement. Patrick Capture-1.pdf Capture-2.pdf Capture-3.pdf

OK Cyril Je vais faire ça et l'envoie Cordialement. Patrick

Il faut laisser généralement Siril trouver tout seul. Fait une capture d'écran de tes préférences