Guillaume1000R

Retour d'expérience sur le traitement de l'éclipse du 12 août 2026 : 21 brackets de 9 poses, du 1/1000 au 1/4 s, à ISO 400, au Sony A7 V et 600 mm sur monture alt-az. Pour les moins patients, voici le résultat final: Un script PixInsight qui automatise toute la chaîne est donné à la fin. Le détail qui suit reste utile : il explique ce que le script fait, et permet de le refaire à la main ou de comprendre pourquoi un résultat cloche. Une éclipse ne se traite comme rien d'autre. Quatre particularités commandent toute la chaîne : La couronne couvre plus de 14 diaphragmes, du limbe éblouissant aux extensions à trois rayons solaires. Il n'y a pas d'étoiles pour recaler. Les outils habituels ne servent à rien. La Lune se déplace, la couronne non. On ne peut pas aligner les deux à la fois. Le gradient radial est écrasant : j'ai mesuré un rapport de 457 entre 1,1 et 3,5 rayons lunaires. Étape 1 — Préparer les brutesConversion RAW cohérenteDans Format Explorer > RAW > Edit Preferences : Aucune balance des blancs automatique. Toute la fusion suppose que les poses ne diffèrent que par le temps d'exposition. Dématriçage VNG. Aucune récupération de hautes lumières, aucun auto-stretch. En script, on peut se passer de ces préférences : ImageWindow.open(chemin, id, "raw cfa") livre la mosaïque brute, non dématricée, quels que soient les réglages de l'utilisateur. Le piège qui coûte le plus cherConvertir en 32 bits flottant AVANT tout calcul. Si vous appliquez PixelMath à une image 16 bits entière, le résultat est réécrit dans son conteneur d'origine : les valeurs négatives sont écrasées à 0, tout ce qui dépasse est écrêté à 1. La perte est totalement silencieuse. Niveau de noir et pleine échelleLes ARW Sony sont en 14 bits stockés dans un conteneur 16 bits. Deux conséquences : Le niveau de noir vaut 512 ADU, soit 512/65535 = 0,007813. À vérifier sur votre boîtier : mesurez la médiane d'un coin de la pose la plus courte, elle doit être remarquablement uniforme. La saturation tombe à 16383/65535 = 0,25, pas à 1,0. Pour que la saturation atterrisse exactement sur 1,0, divisez par la pleine cuve moins le piédestal : ($T - 512/65535) * 65535/15871Vérifiez que la saturation forme bien un palier : comptez les pixels au maximum sur la pose la plus longue. S'il n'y en a qu'une poignée, votre séquence n'a jamais saturé et la couronne interne est peut-être incomplète. Recadrage de la zone activeLe capteur livre plus large que la zone utile ; le reste est du remplissage à zéro qui fausserait toutes les statistiques. Pour détecter la limite, testez la médiane de chaque colonne et de chaque ligne, jamais la somme : un unique pixel chaud égaré dans le remplissage suffit à tromper une somme. C'est l'erreur que j'ai commise, avec en prime un pas d'échantillonnage trop grossier — j'ai longtemps cru que la zone active de l'A7 V faisait 7008 × 4672 alors qu'elle fait 7040 × 4688. Les 32 colonnes que j'écartais avaient une médiane et un écart-type rigoureusement identiques à la zone utile. Recadrez depuis l'origine (0,0) et avec des dimensions paires, sinon la phase du motif de Bayer se décale et le dématriçage produit des couleurs fausses. Ordre : conversion flottant → Crop → PixelMath (piédestal) → Debayer. Étape 2 — Mettre les poses à la même échelleEntre la plus courte et la plus longue il y a 8 diaphragmes : aucun pixel commun exploitable, donc aucun ajustement direct possible. Il faut procéder de proche en proche, chaque pose sur sa voisine à 1 EV. Sans ordonnée à l'origineC'est le point contre-intuitif. Laisser l'ordonnée libre semble malin — elle paraît absorber le fond de ciel. C'est un piège : la composition de huit estimations bruitées produit un terme soustractif qui finit par dépasser le signal du bout faible. J'ai mesuré, en laissant l'ordonnée libre, un fond variant d'un facteur 88 entre brackets, et une couronne rigoureusement nulle à 2,5 rayons sur l'un d'eux. Physiquement, le fond de ciel est de la lumière : il croît avec le temps de pose comme la couronne. La relation entre deux poses est donc une homothétie pure. Le ciel reste dans le HDR et sera retiré plus tard. Prévoyez un secours : si deux poses voisines n'ont pas assez de pixels communs — bracketing à grands pas — retombez sur le rapport théorique des temps de pose, pas sur une valeur arbitraire. Les vitesses d'obturation sont arrondiesLes valeurs gravées sur le boîtier mentent. Les vraies sont des puissances de 2 : affiché réel affiché réel 1/1000 1/1024 1/60 1/64 1/500 1/512 1/30 1/32 1/250 1/256 1/15 1/16 1/125 1/128 1/8 1/8 Sur mes données, les deux seules paires dont le rapport nominal n'est pas dyadique donnaient des écarts de −3,8 % et +5,7 %. Avec les vraies vitesses, ils disparaissent : le capteur est linéaire à 0,5 % près. Autre détail : triez par EXPTIME lu dans l'en-tête, jamais par nom de fichier. L'ordre de bracketing Sony n'est pas monotone (1/60, 1/125, 1/30, 1/250…). Étape 3 — La fusion HDRMoyenne pondérée des poses, où le poids dépend de la qualité d'exposition du pixel dans sa pose d'origine. Fonction de poids, calculée sur max(R,G,B) pour qu'un canal saturé déclasse le pixel entier plutôt que d'introduire une dérive colorée : iif(v < 3σ, 0,iif(v < 8σ, (v - 3σ)/(5σ), iif(v <= 0.65, 1, iif(v < 0.90, (0.90 - v)/0.25, 0)))) où σ est le bruit de fond mesuré dans le plus sombre des quatre coins de la pose la plus courte. Le point le plus important de tout le traitementPondérez aussi par l'inverse de la variance, soit 1/A², où A est le facteur d'échelle appliqué à la pose. Sans cela, la pose la plus courte apporte son bruit à pleine amplitude alors que la pose longue — la seule correctement exposée dans les zones sombres — est divisée par 250. Une simple excursion à 3σ dans la pose courte pèse alors plus lourd qu'un vrai signal bien mesuré. Le résultat sur mes données, mesuré sur le disque lunaire où il ne peut rien y avoir : > 8σ > 100σ bruit sans pondération 7 374 px 62 px 2,4·10⁻⁵ avec 1/A² 7 px 0 2,4·10⁻⁶ Le bruit est divisé par 10. Et j'ai longtemps cru que les points parasites ainsi produits étaient des étoiles — jusqu'à ce qu'on me fasse remarquer qu'il y en avait devant la Lune. Étape 4 — Trier, puis empilerÉcarter les brackets voilésMesurez le flux de la couronne dans un anneau fixe, entre 1,3 et 1,8 rayon, où elle domine le ciel d'un facteur 10. Un passage nuageux se voit immédiatement. Comparez chaque bracket à la tendance locale, jamais à la moyenne générale. Le ciel s'éclaircit naturellement vers les deux contacts — j'ai mesuré une courbe en U dont le minimum tombe exactement au milieu de la séquence. Comparer à la moyenne écarterait systématiquement le début et la fin de totalité, qui sont pourtant bons. Une médiane glissante sur ±3 brackets fait une excellente référence. Un bracket sous 80 % de cette tendance est très probablement voilé. Deux autres motifs d'exclusion valent la peine d'être testés : un résidu d'ajustement du limbe anormalement élevé, qui signe un bougé ou un voile ; et un rayon lunaire aberrant, qui signe une détection ratée. Faut-il recaler ?Contrairement à l'intuition, corréler la couronne entre deux brackets ne marche pas sur une seule pose : je n'ai jamais fait mieux que 8 px d'erreur, la corrélation suivant en réalité le déplacement du disque. Le contraste de la couronne sur une pose isolée est insuffisant loin du limbe. Il existe une méthode bien plus sûre, qui n'utilise que la position du disque — mesurable, elle, au demi-pixel : Sur mes données : déplacement du disque, bracket 1 → 21 30,0 pxpart expliquée par l'orbite lunaire 26,0 px dérive de monture déduite 0,0 px Conclusion : le suivi avait tenu, et aucune translation n'était à appliquer. Vérifié indépendamment par corrélation sur les HDR fusionnés — la couronne n'avait bougé que de 1,8 px en 92 secondes. Si votre reste dépasse largement l'orbite, corrigez-le par translation. Deux empilementsCouronne : tous les brackets conservés. Normalisez d'abord photométriquement, sur le même anneau de 1,3 à 1,8 rayon. Lune : 3 à 5 brackets consécutifs seulement, recalés sur le centre du disque. Au-delà, la dérive relative brouille les protubérances — elles évoluent réellement au cours de la totalité. Étape 5 — Retirer le fond de cielLe ciel domine au-delà de 2,5 rayons — à 2,0 rayons, c'est déjà moitié couronne, moitié ciel. N'utilisez surtout pas DBE ou ABE : ils prendraient la couronne pour un gradient et la mangeraient. La méthode robuste : mesurez la médiane dans des pavés du champ lointain (au-delà de 5 rayons), au 40ᵉ centile pour ignorer étoiles et streamers, et ajustez un plan de bas ordre par canal que vous soustrayez. Si le cadrage est trop serré pour trouver de tels pavés, mieux vaut ne rien soustraire que d'ajuster un plan sur de la couronne. Une fois le fond parti, des taches de poussière et le vignetage apparaissent, jusque-là masqués. Sans flat, recadrez pour les écarter : la couronne utile ne dépasse pas 3,5 rayons de toute façon. Étape 6 — ÉtirerStretch logarithmique, en PixelMath : log(1 + A*$T/max) / log(1 + A)Il colle à la perception visuelle de la couronne et, contrairement aux Levels et aux Curves, n'écrête ni la couronne interne ni les protubérances. Prenez A = 1e5. Après fusion la médiane tombe vers 10⁻⁴ : un A de quelques milliers ne révélerait rien du tout. Faites la balance des blancs avant, en neutralisant la médiane de la couronne — la couronne K diffuse sans altérer le spectre solaire, la rendre neutre revient donc à équilibrer sur le Soleil lui-même. Étape 7 — Le rehaussementC'est ici que l'image prend vie. Le principe, dû à Druckmüller : travailler en coordonnées polaires depuis le centre de la Lune, de sorte qu'un flou ordinaire y devienne radial et tangentiel une fois l'image repliée. Convolution partielleUn masque flou classique produit un halo au ras du limbe, l'arête la plus contrastée de l'image. La parade tient en quatre opérations : 1. PixelMath image × masque → num2. Convolution num (sigma s) 3. Convolution masque (sigma s) 4. PixelMath num / masque_convolué où le masque vaut 0 sur la Lune et 1 ailleurs. Vérifié sur éclipse synthétique : la convolution normale invente un détail de +0,520 là où le détail réel est nul, la convolution partielle tombe à +0,039. Facteur 13. Passe-bande, pas passe-hautC'est l'erreur qui m'a coûté le plus de temps. image − flou₈ est un passe-haut : il retire ce qui est plus grossier que 8 px, mais laisse passer tout ce qui est plus fin, jusqu'au bruit d'un pixel. On amplifie alors le grain avec la structure. La correction tient en une ligne : flou₈ − flou₁₆ au lieu de image − flou₈Chaque échelle ne prélève plus qu'une bande de fréquences. Le grain disparaît sans toucher au détail. J'avais auparavant tenté trois pansements — allonger le lissage, seuiller le détail, baisser le gain — qui traitaient tous le symptôme. Le seuillage était même contre-productif : en annulant ce qui passe sous le seuil, il fragmente les structures continues en tirets qui ressemblent à de faux streamers. RéglageCombinez 3 ou 4 bandes, avec les poids les plus forts sur les échelles moyennes. Ajoutez le détail à l'image de base : finale = base + gain × détailSauvegardez la base et le détail séparément : tout réglage d'amplitude devient alors immédiat, sans refaire le dépliage polaire ni les convolutions. Le noyau peut être allongé radialement pour lisser davantage. Attention : au-delà d'une centaine de pixels, il force les structures à être rectilignes et produit de longs rayons droits, d'aspect synthétique. Une soixantaine de pixels laisse les filaments suivre leur forme réelle. Étape 8 — Composer le limbeLe stack couronne a un limbe flou : la Lune y est étalée sur toute sa dérive. Composez le stack Lune par-dessus, avec un fondu radial serré juste au-dessus du limbe. Le gain est net et mesurable : stack couronne stack Lune transition 10-90 % 12 px 4 px résidu du cercle 5,45 px 1,98 px Le rayon lui-même était faux sur le stack non recalé : 531,2 px mesurés contre 536,1 px réels, l'étalement déplaçant le point d'inflexion vers l'intérieur. Sur la lumière cendréeNe comptez pas dessus si votre pose la plus longue est courte. Sur le disque j'ai bien trouvé un excès de 8,9 σ, mais sa dispersion interne ne valait que 0,81 fois le bruit de fond : le disque était rigoureusement uniforme. Du relief lunaire donnerait une dispersion plusieurs fois supérieure. Cet excès n'était que de la lumière diffusée par l'optique. À 1/4 s de pose maximale, la cendrée n'est pas enregistrée. Il faut plusieurs secondes. Si vous ajoutez ensuite un disque lunaire et un champ d'étoiles issus d'autres sources, précisez-le en légende. C'est une pratique courante et parfaitement légitime, à condition d'être annoncée. Les contrôles, en résuméÀ faire à chaque étape, ils m'ont tous rattrapé au moins une fois : Après Vérifier Attendu soustraction du piédestal min de l'image négatif fusion HDR somme des poids > 0 partout fusion HDR pixels > 8σ sur le disque lunaire quelques unités empilement gain de bruit ≈ √N avant diffusion pixels ≥ 0,995 < 0,1 % Un contrôle qui ne coûte que trois lignes évite de bâtir tout un raisonnement sur un artefact — j'ai attribué pendant longtemps un mauvais rendement d'empilement à un défaut du capteur, alors que je le fabriquais moi-même. La voie automatique : le scriptLe script EclipseHDR.js fait toute la chaîne. Script > Execute Script File, on désigne un dossier de RAW, et il mesure lui-même le reste. Ce qu'il détecte seul : nombre de brackets et de poses, ordre réel des expositions, niveau de noir, saturation, zone active, motif de Bayer, centre et rayon du disque, rapports entre poses, bruit de fond, fond de ciel. Il accepte aussi bien un dossier unique qu'une arborescence rangée par index de pose, et reconnaît trois types de capteur : Bayer, monochrome, ou images déjà en couleur. Le rapport d'analyse liste chaque bracket avec sa transparence, le déplacement du disque, la part orbitale, la dérive de monture déduite, et le verdict : bracket transp. disque orbite monture limbe verdict 5 100% 9,6 7,8 0,0 2,1 conserve 6 61% 7,9 6,7 0,0 2,2 ECARTE : transparence a 61% de la tendance 8 101% 6,7 4,0 0,0 2,5 conserve Cinq curseurs : amplitude du rehaussement, lissage radial, force du stretch, nombre de brackets pour le limbe, recadrage. Plus un seuil de rejet réglable et deux cases à cocher. Comptez une quinzaine de minutes pour 21 brackets de 33 Mpx. Une limite assumée : la rotation de champ n'est pas mesurable de façon fiable sur une pose isolée, et le script le dit plutôt que d'appliquer une valeur douteuse. Sans conséquence en monture équatoriale ; en azimutal, vérifiez la netteté de la couronne à l'œil. Ce que le traitement ne rattrapera pasLa finesse de structure tient à la quantité de signal, et elle se joue le jour J. Les images les plus détaillées reposent sur plusieurs centaines de poses. Avec 21 brackets sur 92 secondes, on atteint une belle couronne, pas la densité filamentaire des références. Deux choses à emporter la prochaine fois : des darks et des flats — les poussières et le vignetage se voient dès que le fond est propre — et un léger dithering entre les brackets, faute de quoi un suivi parfait fait tomber le même ciel sur les mêmes photosites et le défaut fixe ne se moyenne jamais. El scripto, comme on dit là bas...Pour conclure ce post, voici le script généré à partir de mes itérations. Testé et validé pour Sony, mais il devrait fonctionner sur d'autres APN, j'attends vos retours. Après son passage, il ne vous restera plus qu'à y intégrer la lune, les étoiles ou un avant-plan comme bon vous semblera sous Photoshop. Bon traitement :) Uploading Attachment... EclipseHDR.js

Ah pardon je pensais qu'il fallait tester...

Hello, Tiens un petit audit de code: MSI Retina-0.0.1.msi (installeur WiX pour le logiciel "Retina", traitement d'images astro, embarquant un runtime Python 3.14 complet). J'ai analysé les tables MSI (sans exécuter aucune custom action), extrait le contenu via msiexec /a (admin install, 21266 fichiers, 755 Mo), puis vérifié les signatures Authenticode, les versions des bibliothèques et fait une revue statique du code Python applicatif. Signature et intégrité Le MSI lui-même n'est pas signé numériquement (NotSigned). Retina.exe et la majorité des DLL natives tierces (numpy, scipy, opencv, h5py, PIL/jxl, rawpy, astap_cli.exe...) ne sont pas signées — c'est courant pour des wheels PyPI packagées ainsi, mais ça élimine toute vérification d'intégrité/provenance côté Windows. Seuls Python, OpenSSL, sqlite3 et les runtimes VC++ portent une signature valide (celle de leurs éditeurs amont). Aucun certificat de l'éditeur "jromang" n'est présent : rien n'atteste que le package vient bien du dépôt GitHub annoncé (github.com/jromang/retina2). Composants tiers avec CVE connues Python embarqué : 3.14.4 — des versions ultérieures (3.14.4-2 puis 3.14.5) corrigent plusieurs CVE 2026 (CVE-2026-1502, 2026-4786, 2026-5713, 2026-6100, notamment liées au debugging distant asyncio). Recommandation : mettre à jour vers 3.14.5+. OpenSSL embarqué : libssl/libcrypto 3.0.19 — le lot de sécurité du 9 juin 2026 (branche 3.0 → 3.0.21) corrige entre autres CVE-2026-45447 (use-after-free dans PKCS7_verify, sévérité High, RCE potentielle) et plusieurs DoS. Recommandation : mettre à jour vers 3.0.21+. Ces deux composants ne sont pas des vulnérabilités "dans" Retina lui-même, mais c'est la version embarquée qui compte puisque le MSI fige ces binaires. Code applicatif (app/retina/) — pas de vulnérabilité critique évidente Pas de secrets/clés API en dur dans le code de l'application (les seules occurrences trouvées sont des fixtures de tests dans les dépendances tierces vendorisées — astropy, astroquery, dask). subprocess.run(cmd, shell=True, check=True) dans starremoval.py : sert à invoquer un outil externe (StarNet/GraXpert) configuré par l'utilisateur via un template de commande. Risque d'injection de commande si ce template peut provenir d'une source non fiable (ex. import d'un fichier de préréglages partagé) plutôt que d'une saisie locale de l'utilisateur — à vérifier/durcir (éviter shell=True, passer une liste d'arguments). exec(compile(...)) dans app.py (run_recipe) : exécution de code Python arbitraire — c'est une fonctionnalité de scripting délibérée (comme les "process scripts" de PixInsight). Le risque existe seulement si l'utilisateur exécute une recette provenant d'une source non fiable ; ce n'est pas un défaut d'implémentation. Le serveur local ( security.py ) est bien conçu : jeton aléatoire (secrets.token_urlsafe), comparaison à temps constant, vérification d'Origin sur WebSocket (protection anti DNS-rebinding), cookie HttpOnly + SameSite=Strict, jeton MCP séparé limité à /mcp. Aucun défaut trouvé ici — bon niveau de sécurité pour un serveur loopback. Divers Permissions installées sur INSTALLFOLDER (MsiLockPermissionsEx) : Admins + SYSTEM en accès complet, Users en lecture/exécution seulement — pas de dossier applicatif inscriptible par tout utilisateur (évite le DLL hijacking classique). LaunchCondition exige Windows build ≥ 10240 — rien d'anormal. Pas de custom actions dangereuses dans la table CustomAction (juste des SetProperty). Actions recommandées Mettre à jour le Python embarqué (≥3.14.5) et OpenSSL (≥3.0.21) avant la prochaine release. Signer le MSI et les binaires de l'application (Retina.exe, astap_cli.exe) avec un certificat Authenticode pour garantir l'intégrité/provenance. Vérifier l'origine de la valeur self.command dans starremoval.py — si elle peut être importée depuis un fichier de config externe, éviter shell=True. Python 3.14.4 (avant mise à jour vers 3.14.4-2 / 3.14.5) : CVE CVSS v4.0 Sévérité Description CVE-2026-6100 9.1 Critique Use-after-free dans lzma.LZMADecompressor/bz2.BZ2Decompressor/gzip.GzipFile si l'instance de décompression est réutilisée après un MemoryError. Corrigé dans 3.14.4-2. CVE-2026-4786 7.0 Élevée Contournement du correctif de CVE-2026-4519 : injection de commande shell via webbrowser.open() avec %action dans l'URL. CVE-2026-4224 6.0 Moyenne Stack overflow dans Expat (parsing XML) via un DTD imbriqué profondément — DoS. CVE-2026-3644 6.0 Moyenne Contournement incomplet de la validation des caractères de contrôle dans http.cookies.Morsel (bypass CVE-2026-0672). CVE-2026-5713 5.3 (CVSS v4) Moyenne Stack overflow dans le débogage distant asyncio (3.14+) / profiling.sampling (3.15+) — lecture/écriture mémoire arbitraire dans un process privilégié. Exploitation locale, complexité élevée (ASLR). CVE-2026-1502 5.7 Moyenne Injection CR/LF dans les en-têtes de tunnel proxy HTTP côté client. CVE-2026-2297 Medium (pas de score v4 trouvé) Moyenne Contournement des hooks d'audit (sys.audit) lors du chargement de fichiers .pyc legacy — fuite d'information. CVE-2026-0865 Non trouvé (lié à wsgiref.headers) — Injection de nouvelle ligne dans les en-têtes HTTP via wsgiref.headers.Headers. La plus préoccupante est CVE-2026-6100 (Critique, 9.1) : elle touche directement les modules lzma/bz2/gzip, qui sont embarqués dans le MSI (_lzma.pyd, _bz2.pyd présents dans la liste des fichiers). Si Retina réutilise un objet decompressor Python sur un flux réseau ou fichier non fiable après une erreur mémoire, l'UAF est exploitable. OpenSSL 3.0.19 (avant mise à jour vers 3.0.21) : Le lot de sécurité du 9 juin 2026 corrige : CVE Sévérité Description CVE-2026-45447 High Use-after-free dans PKCS7_verify() — crash, corruption mémoire, potentiellement RCE. CVE-2026-34182 Moderate CMS AuthEnvelopedData accepte des messages forgés — bypass d'intégrité ou récupération de clé. CVE-2026-35188 Moderate Double-free lors de la vérification OCSP stapling côté client TLS — DoS ou RCE potentielle. CVE-2026-42764 Moderate NULL deref dans le traitement des paquets initiaux QUIC serveur. CVE-2026-45445 Moderate IV ignoré sur le chemin EVP_Cipher() pour AES-OCB — perte de confidentialité. CVE-2026-34180, 34181, 42765-42771, 7383, 9076 Low Divers DoS/NULL deref/heap over-read, exploitabilité limitée ou préconditions rares. Pour OpenSSL, seul CVE-2026-45447 (High) mérite une vraie attention — il touche PKCS7_verify(), pas directement le chemin TLS standard utilisé par le serveur MCP local de Retina (qui n'utilise pas PKCS7). Le risque concret dépend de si Retina/ses dépendances Python (_ssl.pyd) appellent des fonctions PKCS7/CMS quelque part — je n'ai pas vu cet usage dans le code applicatif examiné.

on voit les lamelles as aigrettes

Waw, le niveau de détails est très sympa. Je trouve personnellement que c'est très (trop) monochrome, il y a de la couleur à aller chercher dans la galaxie et les étoiles, par contre attention à pas faire trop pop le fond de ciel. Tu pourrais crop la vilaine étoile à gauche ;) En tout cas, belle prise.

Sujet clos

Elle est passée par toutes les couleurs cette M42, (sauf le vert). Le fait d'être deux n'aide pas pour la prise de décision 😄

Vous me l'encadrez celle là Merci, pour les remarques, j'ai aussi remarqué les bavures des étoiles. J'ai un peu changé le traitement pour tester veralux, et le starmask post-stretch était vraiment pas top, du coup j'ai réintégré des étoiles en sortie de HDR.

📍 Identité & localisationNom : Nébuleuse d’Orion Catalogue : Messier 42 (M42) Constellation : Orion Type : Nébuleuse diffuse à émission + réflexion Distance : ~ 1 350 années-lumière Taille réelle : ~ 24 années-lumière 👉 Visible à l’œil nu comme une petite tache floue dans l’« épée » d’Orion, sous la ceinture. 🌟 Une pouponnière d’étoilesM42 est une région de formation stellaire active : Le gaz (hydrogène principalement) est ionisé par des étoiles très jeunes et massives Elle contient des milliers de proto-étoiles Des disques protoplanétaires (proplyds) y ont été observés — futurs systèmes planétaires C’est un véritable laboratoire astrophysique à ciel ouvert. ⭐ Le TrapèzeAu cœur de M42 se trouve l’amas du Trapèze : 4 étoiles principales (θ¹ Orionis A, B, C, D) La plus dominante : θ¹ Orionis C, une étoile très chaude de type O Ce sont elles qui « allument » la nébuleuse en ionisant le gaz Sans le Trapèze, M42 serait bien plus sombre. 🎨 Couleurs & structureEn imagerie (et un peu visuellement) : Rouge → Hydrogène ionisé (Hα) Vert/bleu → Oxygène ionisé (O III) Zones sombres → poussières absorbantes Voiles, fronts d’ionisation, piliers → interactions vent stellaire / gravité La structure est extrêmement complexe, avec beaucoup de relief en 3D. 🔭 ObservationŒil nu : visible sous un bon ciel Jumelles : forme ailée évidente Petit télescope : détails internes + Trapèze Filtres : UHC / OIII très efficaces 👉 C’est souvent le premier objet “wow” pour les débutants… et un incontournable pour les experts. 📸 AstrophotographiePourquoi elle est si populaire (et si piégeuse 😄) : Très lumineuse Dynamique énorme (cœur brûlé vs extensions faibles) Parfaite pour : HDR poses courtes + longues narrowband (HOO, SHO) Résiste étonnamment bien aux ciels pollués Même les astrophotographes chevronnés y reviennent régulièrement. 🧠 Fun factsCharles Messier l’a cataloguée en 1769 Observée et étudiée intensivement par Hubble, JWST Elle fait partie du complexe moléculaire d’Orion, l’une des régions de formation stellaire les plus proches de la Terre 📸 L'image

A vendre, Sony A7S mk1 en kit 28mm f2, 20000 déclenchements. 600€ Non défiltré, utilisé principalement en très grand champ avec le samyang 14. Je comptais le faire défiltrer mais quand je sors avec je ne fais pas de nébuleuses. Bon état général, quelques traces d'usure cosmétiques. Tous les boutons fonctionnent parfaitement. Vendu en lot avec: 5 batteries une résistance chauffante pour objectifs la fausse batterie 12v le sac d'origine le kit d'origine 28mm f2 et l'extendeur 0.75x pour ce même kit. Possible de rajouter un tamron 28-200 f2.8/5.6 Di III RXD pour 450€ supplémentaires.

Petit ménage de printemps ici comme vous pouvez le constater. Je vends mon Samyang 135 que je sous-utilise totalement. TBE 350€

Hello, A vendre une ZWO 224MC gros format. Idéale pour du planétaire même si il y a mieux maintenant. Idéale pour une allsky, vendu avec le fisheye 2.1mm. Eventuellement potable en cam de guidage, MAIS couleur MAIS un peu petite. 120€

Update 2026 :)

Fiche d’identité de M101 (la galaxie du Moulinet)Nom officiel : M101 (Messier 101), aussi appelée NGC 5457. Type : Galaxie spirale dite “à grand disque” (spirale de type Sc). Localisation : Constellation de la Grande Ourse, non loin de l’astérisme du Grand Chariot (la “casserole”). Découverte : 1781 par l’astronome français Pierre Méchain, ami et collaborateur de Charles Messier. Distance : environ 21 millions d’années-lumière. Diamètre : environ 170 000 années-lumière (notre Voie lactée en fait 100 000). Nombre d’étoiles : probablement plus de 1 000 milliards (soit encore plus que dans la Voie lactée). Magnitude apparente : 7,9 (elle est donc trop faible pour l’œil nu, mais accessible aux télescopes amateurs). 🌌 Caractéristiques remarquablesStructure en spirale Ses bras spiraux sont très ouverts et riches en régions HII (nuages de gaz ionisé où naissent de nouvelles étoiles). Ces zones apparaissent roses/rouges en photo longue pose. Formation d’étoiles intense C’est une galaxie très active : de nombreuses étoiles massives et jeunes s’y forment. C’est pour ça qu’elle a beaucoup de régions brillantes. Galaxie asymétrique Sa forme est un peu “déséquilibrée”. Les astronomes pensent que c’est dû à l’interaction gravitationnelle avec de petites galaxies satellites voisines. Supernovae M101 a accueilli plusieurs supernovae observées depuis la Terre. La plus récente, SN 2011fe, était particulièrement brillante et a beaucoup servi aux chercheurs pour mesurer les distances dans l’Univers. 🔭 Observation pour les amateursAux jumelles : difficile à percevoir, juste une tache diffuse. Avec un télescope de 150 mm sous un ciel noir : on voit un disque nébuleux. Avec de plus grands télescopes ou en photo : on commence à distinguer ses bras spiraux et ses détails spectaculaires. 👉 En résumé : M101 est une géante spirale voisine, plus grande que la Voie lactée, remplie de zones de formation d’étoiles, légèrement déformée par ses voisines, et une véritable perle de l’astrophotographie. 📝Commentaires de la prise de vue Elue sujet du mois Avex en mai dernier? on a pointé DORA sur M101 en LRGB un peu pour rigoler entre deux objets. J'y ai rajouté mon signal Ha fait dans le Vexin en 2022 pour une quarantaine d'heures. J'ai volontairement poussé le signal Ha pour distinguer les nébulosités qui accompagnent la galaxie, chose assez peu imagée sur astrobin. J'ai longtemps mis le traitement en pause car non satisfait de l'intégration de notre couche L, force est de constater que la nuit porte conseil. 📷 L'image

Utilisé en solaire en version PRO, c'est vraiment top. Joli déterrage btw :)