Toute l’activité

Pour la version 2 de siril on la fera au même prix que la version actuelle. Promis.

C'est très simple et Juan y avait pensé avant Russel et son évolution en ML5 ($auf qu€ le gar$ ruru a été bi€n plus rapid€ à compr€ndr€ qu€ Juan..). C'est dans la FAQ du site de Pix : https://pixinsight.com/faq/index.html

D'où le "souvent", auparavant j'aurais dis "toujours". Dans tous les cas c'est bien, ça stimule la concurrence et ça les force à se sortir les doigts du cul. La "stretch war"... 🤣 Le terme est bien trouvé, c'est vraiment ce qu'il s'est passé ! Il est réjouissant de se dire qu'on peut encore innover en terme de traitement d'image 2D.

Il me semble que la "stretch war" a commencé après la sortie des scripts Veralux sous Siril

Certes. Et très enclins à aider leur prochain. Merci ! Après, l'innovation est souvent venue du côté de Pixinsight, directement ou non, et l'interface est vraiment géniale. Je pensais à un truc, avec la 1.9.5 on se rapproche de la 2.0, qu'est-ce qu'il se passe ce jour là ?

Je pense que c'est la différence fondamentale entre l'Espagne et la France... Pareil, les forces armées locales ont été très cool, habitués à des gens globalement plutôt cools. Tant qu'on est pas à l'initiative de feux incontrôlables. Donc, si on se tient "carré" , je pense que les autorités seront plutôt coulantes de l'autre coté de la frontière. On en parlait en débriefing de l'éclipse, avec un Belge qui s'était installé...5 j avant l'évènement. Aucun souci pour lui, tant qu'on ramasse ses déchets, qu'on chie pas partout, et qu'on explique ce que l'on fait ici. la population locale semble elle aussi bien moins vindicative que nous autres Gaulois, la pédagogie semble être appliquée bien plus que la répression chez nous (les torts sont partagés, plus les gens sont violents, plus la réponse l'est....)

Ca m'étonnerait. Le goulot d'étrangement ici c'est les lectures/écritures des fichiers. Et ça... On peut rien faire avec le GPU. Il faut utiliser Siril, les dev sont moins ... caractériels ? Je confirme.

Plus forcément en fait, avec le gain de rapidité opéré par PI il n'y a plus une différence aussi énorme. On est passé de 5 à 10x plus rapide, à seulement quelques dizaines de pourcent. C'est encore beaucoup pour des gros sets d'image mais plus aussi spectaculaire. Enfin ceci dit vous ne m'avez pas attendu pour faire ce que vous voulez hein Une autre question que je me pose c'est : est-ce que les GPU ont leur mot à dire dans cette histoire ? Il y a une partie du boulot qui est faite avec dans Siril (pas bien compris quoi) et dans PI il y avait un utilisateur qui avait conçu un script pour PI qui démultipliait les performances. C'est, je crois, ce qui a fait péter les plombs à Juan d'ailleurs, et a mené à la fermeture du forum officiel. Avec leur premier pied dans le monde de l'utilisation du GPU est-ce que le prétraitement va en profiter ? Je ne sais pas. Déléguer le boulot au GPU ne présente pas toujours d'intérêt selon la tâche mais ça dépasse très nettement mes connaissances en la matière.

Pareil ! Cela reste impressionnant de voir, dans l'image 1, le paquet de Ha qu'il y a dans cette galaxie !... (même si, là, il est trèèès mis en valeur )

Queee—wouah ! On a donc raison, tous autant qu’on est, de pré traiter sur Siril ! 😂 Et là, on peut remercier @Tromat qui nous a fait un test sérieux, pas du Raoult…😀

Bien le bonsoir, Bon, pas facile de rattraper le retard de traitement...pfiou... Je dépile quand même cette LDN 1295 dans Cassiopée, nébuleuse sombre de la Girafe, du 20/09, environ 5h d'acquisition gardées avec le C8 et la 294C, avec la Lune et des nuages...Ca mérite plus c'est certain... Siril+Sirilic comme d'hab pour le stacking et pix en mode "tout droit" rgb Finalisation PS néanmoins car il a fallut étirer le signal et remettre un peu tout ça propre !

Erratum : je viens de comprendre l'origine de cette différence de texture. Je me suis rappelé que tu m'as dis que les vues étaient réalignées après le stacking, il y a donc une interpolation à ce moment qui vient dégrader le bruit. Je suis reparti des vues L cette fois, en prenant la version non alignée pour comparer et là il n'y a pour ainsi dire aucune différence entre les deux logiciels. A part que ça sort plus vite de Siril ! Le souci d'alignement sera corrigé avec la prochaine version si j'ai bien compris. Pixinsight : Siril :

Alors, je ne compare que par rapport à des images prises ces derniers jours. J’ai posté des version sans traitements localisés. La teinte des anneaux est très proche du globe. Faire la bdb sur les anneaux rend le globe fade.

Celui-ci ? Pas de halos avec les étoiles brillantes ? Pourquoi ils proposent aussi le 4nm ? Ancienne version ?

Attention à l'effet Seeliger.... Lors du mois de l'opposition, les anneaux deviennent étonnement brillants et virent sur le blanc. A 3 mois d'intervalle, les images brutes sont franchement différentes....

Bon alors, mea culpa, après avoir corrigé une petite erreur de ma part le résultat est finalement vraiment similaire. Il est toujours difficile d'obtenir deux vues vraiment identiques au pixel près sans affecter l'un ou l'autre des logiciels dont j'ai fait au mieux avec un gros crop. Il y a quelques différences de signal mais je pense que c'est dû au paramètres de rejet différents et que je n'ai pas chercher à affiner. Dans les deux cas c'est du drizzle 1x. La seul différence que je vois c'est cette texture de bruit beaucoup plus nette avec PI. Ma première conclusion, les deux se valent ! Je vous laisse juger : Pixinsight : Siril :

Comme mes camarades : un mix entre la V2 et la V3

Un traitement local. Comment veux tu faire autrement ? J’ai posé plusieurs fois la question, je n’ai jamais eu de réponse. Vu le nombre de saturne qu’on voit avec les anneaux beaucoup moins saturés que le globe alors que sur les bruts c’est très proche, j’imagine que c’est une pratique courante.

Bonjour à tous, Je me lance dans un projet que je vais essayer de documenter ici au fur et à mesure de son développement, avec l’objectif de partager aussi bien la partie conception que les essais, le code, les éventuels problèmes rencontrés et les résultats obtenus. L’idée est de réaliser un système de surveillance du ciel destiné à l’astronomie, avec notamment la détection de la couverture nuageuse, la mesure de la température et de l’humidité extérieure, la gestion de la condensation au niveau du capteur infrarouge et, à terme, la possibilité d’utiliser ces informations pour déterminer automatiquement si les conditions sont suffisamment sûres pour laisser fonctionner un observatoire. Le projet va normalement s’étaler sur un à deux mois, avec comme objectif d’avoir quelque chose de réellement finalisé avant décembre : électronique terminée, boîtier construit, programmation suffisamment stable et surtout une vraie phase de tests en conditions extérieures. Je préfère le préciser dès le départ : le projet est volontairement et très fortement inspiré du système AAG CloudWatcher de Lunático Astronomía. Je ne cherche absolument pas à réinventer le principe. Au contraire, je trouve que le travail réalisé par Lunático sur le CloudWatcher est extrêmement qualitatif et c’est clairement ce qui m’a donné envie de comprendre plus précisément le fonctionnement de ce type de système et d’essayer d’en construire une version personnelle, en choisissant moi-même les capteurs, l’électronique, la mécanique et le logiciel. L’objectif n’est donc pas de faire une copie commerciale du produit, mais plutôt de reprendre le principe général du CloudWatcher et de développer une solution DIY, ouverte, modifiable et surtout totalement adaptée à ce que je veux faire avec mon installation. Le CloudWatcher utilise notamment le principe de mesure de la température apparente du ciel dans l’infrarouge : un ciel parfaitement dégagé présente une température radiative extrêmement basse, alors qu’un ciel couvert par des nuages apparaît beaucoup plus chaud. À partir de cette différence, il devient possible de déterminer si le ciel est clair, partiellement couvert ou complètement couvert, y compris évidemment pendant la nuit. Le capteur principal que j’ai retenu est un MLX90640 en version BAA (110°). C’est une matrice thermique infrarouge 32 × 24 pixels, donc 768 points de mesure indépendants. Mon choix est justement de ne pas utiliser uniquement une thermopile mesurant une zone unique du ciel, mais une véritable matrice thermique. Cela va permettre d’avoir une information spatiale beaucoup plus intéressante : plutôt que de connaître uniquement une température moyenne du ciel, je pourrai analyser la répartition des températures dans le champ observé, détecter par exemple une zone nuageuse traversant progressivement le champ, calculer différentes statistiques sur l’image thermique et potentiellement développer des algorithmes beaucoup plus intéressants qu’un simple seuil sur une valeur unique. Le MLX90640 fonctionne sans contact et communique en I²C, ce qui facilite énormément son intégration avec un microcontrôleur. Je vais devoir travailler correctement sur la fréquence d’acquisition, les corrections internes du capteur, les valeurs aberrantes, l’émissivité et surtout la manière de transformer les températures mesurées en un indice réellement exploitable de couverture nuageuse. La partie contrôle sera réalisée autour d’un ESP32-S3. Je l’ai choisi parce qu’il offre largement suffisamment de puissance pour récupérer les données du MLX90640, effectuer les traitements nécessaires, gérer plusieurs capteurs en parallèle et assurer toute la partie communication. A voir si je ne vais pas partir sur plus gros pour pouvoir y mettre et developper une véritable interface. Le projet est également d'arriver à une version finale avec ASCOM Alpaca. Il apporte également le Wi-Fi et le Bluetooth directement, ce qui permettra ensuite d’avoir une interface réseau sans ajouter de matériel supplémentaire. À terme, l’idée est que le boîtier puisse fonctionner de manière totalement autonome : acquisition des données, calcul de l’état du ciel, surveillance de l’humidité, gestion du chauffage de la fenêtre, éventuellement publication des données sur le réseau et communication avec le reste du système d'acquisition. Je veux également conserver suffisamment de marge en ressources pour pouvoir faire évoluer le logiciel par la suite, par exemple en ajoutant une interface Web, un historique des mesures, une API ou différents protocoles permettant d’envoyer directement les informations vers un logiciel. Pour mesurer les conditions atmosphériques locales, je vais utiliser un SHT40 dans une version extérieure/IP67. Son rôle sera de mesurer précisément la température ambiante et l’humidité relative. Ces deux valeurs sont importantes en elles-mêmes pour caractériser les conditions météo, mais elles vont surtout servir à calculer le point de rosée. C’est un élément très important du système, parce que je ne veux pas simplement allumer un chauffage en permanence autour du capteur infrarouge. L’objectif est au contraire d’avoir un chauffage réellement piloté : lorsque la température de la fenêtre se rapproche trop du point de rosée, l’ESP32 pourra activer progressivement ou temporairement le chauffage afin d’éviter l’apparition de condensation. Cela permettra d’avoir un système beaucoup plus propre énergétiquement et surtout d’éviter de chauffer inutilement la partie optique, ce qui pourrait perturber les mesures infrarouges. Le CloudWatcher commercial mesure lui aussi plusieurs paramètres météorologiques en complément de la température du ciel, notamment la température extérieure, l’humidité, la pluie et la luminosité ambiante. Le MLX90640 ne sera évidemment pas directement exposé aux intempéries. Je vais utiliser devant lui une fenêtre optique en ZnSe, de 12,7 mm de diamètre. Le ZnSe, ou séléniure de zinc, est utilisé parce qu’il possède une très bonne transmission dans l’infrarouge thermique, contrairement à un verre classique qui bloquerait une grande partie du rayonnement intéressant pour ce type de mesure. Cette petite fenêtre sera donc l’un des éléments mécaniques les plus importants du système. Elle devra être maintenue correctement dans le boîtier avec une collerette adaptée et un joint afin d’empêcher l’eau de pénétrer directement au niveau de l’ouverture optique. L’idée actuelle est de concevoir cette partie entièrement en impression 3D : logement du verre, gorge pour le joint, bague de maintien et support du chauffage. Le joint doit travailler en compression autour de la fenêtre, le but étant que le verre soit correctement maintenu sans lui imposer de contrainte mécanique excessive. L'objectif pour l'instant c'est de faire clairement une mini station météo portable résistante à l'humidité et non à la pluie et aux élements extérieurs. Je recommande l'AAG CW pour ça. Concernant justement le chauffage, après dimensionnement, pour une fenêtre de seulement 12,7 mm L’idée actuelle est donc d’utiliser un petit anneau chauffant placé autour de la collerette de la fenêtre. Le modèle qui correspond actuellement le mieux au montage est un anneau d’environ 28 mm de diamètre extérieur, 19 mm de diamètre intérieur, fonctionnant en 12 V pour une puissance de 4 W. Le diamètre intérieur de 19 mm laisse suffisamment de place pour entourer la collerette mécanique qui maintiendra la fenêtre ZnSe et les 4 W donnent une marge suffisante pour transmettre la chaleur jusqu’au bord de la fenêtre sans tomber dans un chauffage complètement surdimensionné. Une variante autour de 3 W reste également envisageable si les essais montrent que 4 W sont inutiles. Comme le reste de l’électronique sera principalement alimenté en 5 V via USB-C, le chauffage 12 V lui passera donc à 0.7W ce qui est suffiseant pour une fenêtre de 1,27cm. L’idée est plutôt d’avoir un ensemble résistant à l’humidité et aux légères projections d’eau, tout en acceptant qu’un faible échange d’air puisse exister. Dans ce contexte, la protection du PCB devient particulièrement importante. Je prévois donc d’utiliser un vernis de tropicalisation/conformal coating sur l’électronique, éventuellement accompagné d’un petit sachet de gel de silice à l’intérieur. Le passage du câble sera conçu de manière à empêcher autant que possible le ruissellement direct dans le boîtier, avec notamment une boucle anti-goutte. La fenêtre ZnSe restera en revanche réellement protégée par son joint, puisque c’est à la fois l’élément optique principal et l’une des pièces les plus sensibles du montage. La partie qui va probablement me demander le plus de travail sera finalement le logiciel. Je veux éviter de faire simplement un programme qui affiche la température du ciel. Le but est vraiment d’exploiter le MLX90640 au maximum. Je vais commencer par récupérer correctement les 768 températures de la matrice, afficher éventuellement une représentation thermique (comme un radar météo si vous voulez), déterminer la température moyenne, la médiane, les valeurs minimum et maximum, puis observer comment évoluent ces paramètres entre un ciel parfaitement clair (si vous voulez un étallonage), quelques passages nuageux, un ciel totalement couvert, du brouillard, etc. Ensuite il faudra construire une logique permettant d’obtenir un état exploitable du type CLEAR / CLOUDY / UNSAFE. Je pense également travailler sur la différence entre température apparente du ciel et température ambiante plutôt que sur une température absolue, puisque les conditions atmosphériques changent forcément selon les saisons, l’humidité et la température extérieure. Tout ça devra surtout être déterminé expérimentalement : je préfère enregistrer beaucoup de données réelles (sur une bonne année), comparer avec les conditions observées et construire les seuils à partir de ces mesures plutôt que de choisir arbitrairement trois valeurs. À terme, l’intérêt est évidemment de pouvoir utiliser cette information comme véritable système de sécurité. Si le logiciel estime que les conditions deviennent dangereuses, par exemple en cas de couverture nuageuse importante ou éventuellement plus tard en combinant cela avec un capteur de pluie, l’état pourra être envoyé au système d’automatisation d'alerte. ’est exactement cette philosophie qui rend le CloudWatcher particulièrement intéressant : les mesures n’ont pas seulement vocation à être affichées, elles doivent pouvoir déclencher une action automatique pour protéger le matériel. Lunático propose d’ailleurs tout un écosystème autour de ce principe, avec notamment des contrôleurs d’observatoire et de toiture qui peuvent utiliser directement l’état de sécurité du CloudWatcher. Pour l’instant, l’architecture globale du projet est donc : MLX90640 BAA pour l’analyse thermique du ciel, SHT40 IP67 pour température/humidité et calcul du point de rosée, ESP32-S3 pour l’acquisition, les calculs et les communications, fenêtre ZnSe de 12,7 mm pour protéger l’optique infrarouge, joint torique et collerette imprimée en 3D pour la partie mécanique, anneau chauffant 12 V d’environ 4 W réduit à 0.7W en 5V pour le chauffage et protection du PCB par conformal coating. Le reste viendra progressivement en fonction des premiers essais... Je vais essayer de mettre ici les différentes étapes au fur et à mesure : conception du boîtier et des pièces imprimées en 3D, schéma électronique, câblage, premières acquisitions du MLX90640, développement du firmware ESP32, logique de détection des nuages, pilotage du chauffage, tests de nuit puis tests météo sur plusieurs semaines. Je publierai aussi les résultats qui ne fonctionnent pas, parce que je pense que ce sera justement intéressant de voir ce qui doit être corrigé entre la théorie et les conditions réelles. L’objectif que je me fixe est d’arriver avant décembre à une version qui ne soit plus seulement un prototype posé sur une table, mais un système réellement monté à l’extérieur, capable de fonctionner plusieurs nuits en nomade, d’enregistrer des données cohérentes et de commencer à donner une indication fiable de l’état du ciel. Ensuite, en fonction des résultats, il sera toujours possible de faire évoluer le matériel et surtout les algorithmes. Je vais donc utiliser ce sujet comme journal de développement du projet, et je mettrai les avancées au fur et à mesure. Si vous avez des remarques, vous trouvez des failles au problème, lachez vous ! Je suis preuneur de tout ce qui peut m'aider à faire avance le programme ! Bon ciel, Clément

Arf, certes ... Mais le titre ; manifestement il n'y a pas que les maths ...

Merci pour le commentaire, j'étais déjà passé sur ce site, et je vais envoyer des mails dès que possible à nombre d'entre eux.

J'appellerai pas ça comme ça. Mais du coup tu peux choisir ta préférence.

Une préférence pour la 3 également. Beau travail !

Ouhla ! tes images sont superbes. Vraiment superbes. Tu as parfaitement cerné le truc : oui, ça peut donner vraiment n'importe quoi, comme une apod. J'y réfléchis depuis Ningaloo 2023 - il y avait des récifs coralliens, ce qui m'a donné l'idée. Toutefois ce n'est absolument pas mon domaine. Déjà, voir si un système capable d'opérer en autonomie sous l'eau existe ... L'idée ce serait soit de viser la zone approximative du ciel avec une optique pas trop courte (admettons entre 70 et 100 mm), histoire de voir le disque solaire et la couronne, depuis une profondeur modérée (mais laquelle ?), ... ou alors d'assurer le coup avec une optique plus large, affleurant éventuellement la surface, juste sous le niveau des vagues, par exemple, et de mitrailler en continu pendant les 4 ou 5 minutes d'éclipse, de façon à saisir LA bonne image ; voire de reconstituer un timelapse. Au pire, tirer une séquence vidéo en 4k. En tout cas, je ne sais pas si ça a jamais été tenté ; je n'ai pu trouver aucune image dans le genre. C

Le pseudo SHO apporte un vrai plus dans les détails 👌🏻