keymlinux

Oui, le port a un format usb-C mais en terme de protocole/débit cela sera de l'USB 2.0 EDIT: d'ailleurs dans la boite P.O a aussi mis 2 petits cables USB 2.0 de 50cm, un usb-c/usb-c et un usb-c/usb-b qui sont justement fait pour brancher un autre périphérique en mode chainé sur le port "device" de la camera

Bonjour, Sur la caméra poseidon-c il y a un ports usb pour brancher un autre périphérique. Certes il est en usb-c, mais l’eaf-n aussi, et pour un focuser conçurent avec prise usb-a, avec un adaptateur usb-c mâle vers usb-a femelle tu dois pouvoir connecter. note: j’ai un eaf gen1 avec alim12v, donc non concerné par ton problème pour alimenter en usb. l’eaf a certes du backslash mais cela ne ma jamais posé problème, la plupart des softs de mise au point gèrent bien cela (kstars/ekos/indi en ce qui me concerne) Sinon tu peux aussi migrer vers un hub usb alimenté, comme cela cela ne vas pas tirer sur le port usb de la tablette Cordialement

Bonjour, Il y a un objectif Laowa 11mm f2.8 disponible en monture RF mais avec mise au point manuelle seulement (en RF Canon ferme les spécifications pour l'autofocus pour les optiques de fournisseurs tiers, mais l'usage de connectivité physique de la baïonnette RF n'est pas interdite) https://laowa.fr/ultra-grand-angle/117-457-10mm-f28-zero-d-ff.html#/41-monture-canon_rf/73-mise_au_point-manuelle_mf De plus les objectifs tiers en monture EF devraient (usage du conditionnel) fonctionner avec l'adaptateur RF-EF, y compris pour l'autofocus --> as tu testé des objectifs tiers EF avec adaptateur RF-EF ? note: ma question n'est pas totalement désintéressée, je compte acquérir un Canon FF à monture RF, je compte utiliser un adaptateur RF-EF pour quelques objectifs Canon et Sigma que j'ai déjà en monture EF... Cordialement, Stéphane

Salut @gregastro, tu as fait un bon choix pour la P.O Poseidon-C Histoire de ne pas encombrer le forum qui manque de place en ce moment, je ne reposte pas les images, mais voici les liens sur les post où j'ai mis mes images faites avec cette caméra Cordialement, Stéphane

La camera asi1600 pro a un backfocus de 17.5mm avec sa bague d'adaptation, mais effectivement elle peut être enlevée pour obtenir un backfocus de 6.5mm (on passe alors d'un filetage M42 femelle à M42 mâle) Avoir un objectif photo a monture EF ou EF-S + adaptateur Canon vers M42 + roue a filtre (M42 femelle de chaque coté) + ASI1600 est possible. C'est décrit dans la doc de l'ASI1600, schéma page 14 de la doc ci dessous https://i.zwoastro.com/zwo-website/manuals/ASI1600_Manual_EN_V1.5.pdf Si ta camera est monochrome (ASI1600MM) alors la roue a filtre se justifie, mais si ta camera est couleur (ASI1600MC), moi a ta place je me passerais de roue a filtre et j'utiliserais un diviseur optique a la place (sauf a vouloir faire du SHO avec des filtres dual-band) L'objectif Samyang 135mm F2 est a mise au point manuelle, donc c'est motorisable avec un EAF et une courroie type GT2 (les courroies crantées utilisées su rue imprimantes 3D). Reste à trouver un dispositif pour le fixer sur cet objectif et bonne nouvelle, en faisant une recherche sur le net je suis tombé sur le sujet suivant: Cordialement

Salut @norma, un beau projet en perspective. J'espère que tu a pris soin de mettre des repères sur la tranche des lentilles pour les remonter avec le même alignement, et de récupérer les éventuelles cales qui séparaient les 2 lentilles.

Bonjour, Les APN Canon "EOS M" qui utilisent des objectifs a monture EF-M ont un format de capteur de type APS-C, qui est plus grand que la capteur 4/3 de l'ASI 1600. Donc ce type d'objectif est capable de bien illuminer le capteur de ta camera (un objectif capable de produire un cercle d'image bien corrigé pour un capteur de 30mm de diagonale le fera très bien aussi sur un capteur de seulement 22mm de diagonale) Par contre ces mêmes objectifs Canon EF-M disposent d'un tirage optique de 18mm (bien plus court que les objectifs Canon EF et EF-S qui ont un tirage optique de 44mm) Cela signifie que le capteur de ta camera devra être positionné 18mm derrière l'objectif (distance comptée à partir de la surface de contact de la monture, pas à partir de l'extrémité de la baïonnette qui rentre dans le boitier de l'APN). Ta camera, l'ASI 1600 pro a un tirage optique de 17,5mm. Désolé mais je ne vois pas comment il va être possible d'avoir un adapteur de seulement 0.5mm entre la baïonnette format EF-M et le pas de vis M42 de la camera Avec un objectif EF ou EF-S qui a un chemin optique de 44mm il resterait 26.5mm (soit 44-17.5), ce qui est suffisant pour intercaler un adaptateur EF-M vers M42 (si tant est qu'un tel adaptateur existe dans le commerce ou que l'on puisse le fabriquer via impression 3D), mais insuffisant pour une roue a filtre (souvent 20mm de large) et un OAG (souvent 15mm de large) Cordialement, Stéphane

Bonjour à tous, Si vous ne savez pas quoi faire le weekend prochain (du 14 au 16 novembre 2025), le club d'astronomie de Juvisy sur Orge vous invite à venir découvrir la 5eme édition de son festival "Astr'automne" (voir affiche et programme ci dessous) Vu que weekend s'annonce pluvieux (en tout cas en région parisienne), et que vous êtes condamnés à annuler vos sorties d'observation ou d'astrophoto, profitez en pour passer nous voir, pour discuter de tout, mais surtout d'astronomie Perso vous pourrez me croiser sur le stand "spectroscopie" Cordialement, Stéphane

Dans l'image ci dessous - le tube du porte oculaire coté intérieur du tube optique rentre entre les parties orange et violettes - sur la partie verte, tu peux voir 4 attaches percées qui permettent de fixer le tout a la cage du secondaire (qui est ajouré dans mon cas) avec de la cordelette élastique - la partie bleue, sur laquelle sont fixés les filtres coulisse entre les parties vertes et jaunes Je m'interdit de percer des trous dans mon dobson Mais sur ton Taurus la cage du secondaire est du tube plein, il ne sera effectivement pas facile d'y accrocher qui que ce soit sans perçage/vissage

Bonjour, Pour info, dans le sujet ci dessous je présente un porte filtre a glissière que j'avais fabriqué en impression 3D pour mon dobson important: comme le tube du porte oculaire ressort de la cage du secondaire (empiète sur l'intérieur du tube), j'ai du faire un support de filtre qui se fixe dessus (il n'est pas fixé sur la cage du secondaire), avec les photos c'est plus clair...

Certes, mais avec l'onduleur qui passe le 12V en 220V, après il faut ajouter le transfo du PC qui convertit le 220V en 19V, et vu la température qu'atteint ce transfo (en tout cas sur mon macbook, peut être pas généralisable) je doute qu'ili ait une efficacité de 98%... Tu me garantit que 12V continu --98%efficace--> 220V alternatif --??%efficace--> 19V continu c'est toujours plus efficace que 12V continu --93%efficace--> 19V continu ?

En fait non, pour plusieurs raisons différentes: - pour certains PC c'est 19V, pour d'autres 19,5, etc... souvent entre 19 et 21V (mais tu pourra me dire qu'avec un modele sortant du 12-25 tu pourra lever cette limite) - la plupart des ordi récents veulent "dialoguer" avec leur alim pour réguler la charge (ce qui est devenu la norme pour les smartphone ou plutôt les normes avec des appellations propriétaires telles que "Power Delivery", "Quick Charge" ou encore "Adoptive Fast Charging" Mon ordi étant un macbook équipe d'un connecteur magsafe j'ai opté pour un adaptateur dédié au modèle. Sur les macbook récents alimentés en USC-C, toute alim compatible "Power Delivery" et permettant de sortir l'amperage requis fait l'affaire. Pour les PC c'est un peu la jungle, DELL, HP, Lenovo, autant de modèle que de format de prises et de voltages (là aussi la normalisation récente vers l'USB-C deviens pratique) Ci dessous exemple pour un macbook avec port magsafe (vu le prix on est tenté de le fabriquer sois même ...) https://www.amazon.fr/portatilmovil-chargeur-voiture-MacBook-MagSafe/dp/B07F2HJY5Z/ref=sr_1_11?__mk_fr_FR=ÅMÅŽÕÑ&crid=U1ZPS243NQJ3&dib=eyJ2IjoiMSJ9.jIPOJkl3Qj00ZIjDTg8HTMSnaldLqaZcmtDTBCzNH5V4PcbpwgIq7U4PsuLLAiAecrJUR65NFjT6cHUw4bYJRoZdbHmCGDWnULGq8kLFNsJQeIWg45Wf89g8UQjHURenKheciFSKeHDmtUVoISSo7UMWg6k3WWet8FnEOo3hQoS7oRHaxsqeQY8dfK901R3aKR0NGdS9_suHh9ivcH-9dlZCNn9AQFPNTdJGXEoqu3P2354u-fJjzKf6FOPTlxSPnFpVekav-ui0PsUfZNkrHpMJi1KPip_GtXIZSU8XaDQ.sBwqBHHWN8aB5iQKYLhH0g6_kHAr2ryzuzQCINb9jZM&dib_tag=se&keywords=adaptateur+allume+cigare+macbook+magsafe&qid=1760966706&sprefix=adaptateur+allume+cigare+macbook+magsafe%2Caps%2C79&sr=8-11 Pour ton cas perso et bien cela va dépendre de ton ordi, quel voltage et amperage max il nécessite et surtout si il nécessite un dialogue avec l'alim. Si c'est un pc "à l'ancienne" qui ne nécessite pas de dialogue alors un simple transfo capable de prendre entre 12 et 14V en entrée et sortir entre 18 et 21V en sortie devrait faire l'affaire. A noter que le modèle que tu donne en exemple est annoncé comme prenant entre 10V et 16V en entrée tout en ayant une sortie stable à 19V (reste a voir si le s19V c'est OK pour ton ordi). Il est aussi annoncé comme permettant un débit de 190W, mais comme les ordi portables c'est entre 60 et 90W, pas de risque de trop chauffer (ne pas utiliser un composant à 100% de ses spécifications) Restera ensuite à trouver le bon connecteur. Regarde le détails (photos) du modèle générique ci dessous, cela te donnera une idée de la multitude des connecteurs existants https://www.amazon.fr/Chargeur-Universel-Chromebook-Pavilion-Connecteurs/dp/B0CF54WKQJ/ref=sr_1_7?__mk_fr_FR=ÅMÅŽÕÑ&crid=1LWJT0DJJ4M7D&dib=eyJ2IjoiMSJ9.DhSYOrWipxJz19e6zvOaX1wt78HJfKAMRTOeKtKr_yCQ63HSYYo4FbFs5L9Vj8eWy-JlatuOxnXki30AY7y4DI3rN0IJ0UWs2RyBGe8iq3EJ3KwZJiQj3CeFqr7k0eHku-usMFPnph7Ll6gdPNR8RrrHgDpFQBJlGXsx5M6RTu45PhvXpRyWqS5VDjBttfbcvrsU9BNiwkaXjqPLWiZZz02aWJTmxsD9gVGABbcLiqWbHQou0zNVBInJ8-8t0D4dU43bowQ2RyGgYDN38Simx7eClQymzEcXtPd5yVm15iY.X9nDeVcIl7FcSSKxe0GfLUzXfK4KEbxaM7Cn5UMYc_I&dib_tag=se&keywords=prise+allume+cigare+pc+dell&qid=1760967501&sprefix=prise+alume+cigare+pc+dell%2Caps%2C96&sr=8-7 Cordialement

Bonjour, Concernant des derniers darks fournis (fichier unitaire et master). Il sont bien, pas de problème d'homogénéité. note: pour afficher avec des fausses couleurs pour mieux distinguer les dégradés, c'est dans siril, avec les 2 boutons comportant une grosse étoile en bas et au centre de l'interface: l'étoile en noir et blanc permet d'inverser le lumineux/sombre pour avoir un effet "négatif", l'autre étoile en couleur permet d'appliquer des couleurs plus tranchées (les modifications s'appliquent à la visualisation, mais l'image sur laquelle on travaille n'est pas modifiée) Concernant les images brutes, je te confirme que les brutes unitaires font apparaître la trainée bleue partant en diagonale du coté haut-droit de l'image. C'est pas flagrant mais c'est présent. Et comme le signal est présent sur toutes les brutes, plus on en empile et plus cela ressort (l'empilement permet de moyenner le bruit, c'est a dire les éléments non systématiques d'une image à l'autre, pour faire ressortir le signal, c'est a dire les éléments reproductibles d'une image a l'autre, dont cette légère trainée bleue). Ci dessous des captures d'écran des canaux rouges/vert/bleus d'une image light unitaire, zoomé dans l'angle en haut à droite (ouverture du fichier "frame" avec Siril, avec dématricage à l'ouverture, affichage en mode "histogramme" pour exacerber les différences de luminosité Canal rouge Canal vert Canal bleu Donc a priori la diagonale bleue ne viens pas d'un problème de traitement (car présente sur la capture), même si l'empilement la met en valeur (façon de parler...) Cordialement

Bonjour Raphaël, En ce qui me concerne: - setup a base de AZ-EQ6, camera refroidie, camera de guidage, focuser, résistance chauffante pour la lulu, routeur GL.inet Opal, raspberry pi pour piloter le tout, dongle gps, hub usb - ordi portable (pas utilisé en permanence, juste pour lancer la session + contrôle périodique en cours de session via connection prise en main a distance sur le raspberry pi) Mon premier setup "batterie" était avec une batterie au plomb de 60 Ah. Cela semble beaucoup mais en fait on ne peut (doit) pas tirer plus de 50% de la batterie, et par nuit très froide la batterie plomb montre vite ses limites. Depuis j'ai remplacé la batterie plomb par une Lithium LiFePO4 de 100Ah (que l'on peut consommer à 80%) Bilan: je passe de 30Ah efficace pour 15Kg à 80Ah efficace pour 10 Kg, et j'atteint les 2 nuits d'autonomie (y compris pour les nuits froides et longues de hiver.Pour les nuits d'été je tiens sans problème 4 nuits (le refroidissement de la caméra est plus sollicité, mais pas de résistance chauffante pour la lulu, et souvent la nuit de capture ne dépasse pas 4 heures) Important: j'ai fait le choix de ne pas utiliser le convertisseur 220V, car la transformation 12v-->220V-->12V (pour le matos astro) ou 19V (pour les ordi portables) au final on perd beaucoup d'énergie (transformée en chaleur) Pour alimenter l'ordi j'ai une prise allume-cigare qui convertit du 12V en 19V avec connecteur au format requis pour l'ordi. Pour mon montage batterie voir le post ici: Depuis ce post ce qui a été changé c'est la batterie (de même taille physique) pour passer au Lithium, et l'ajout d'un peu d'isolant pour le froid Cordialement

Bonsoir, J'ai un problème avec ton dark (en fait 2 problèmes) 1) il y a un gradient haut/bas (plus lumineux en haut) 2) il présente une luminosité 2 fois supérieure à une "frame" (light) de même exposition Le dark de 30s Le même affichage et calcul de stats pour le light de 30s Le gradient est moins prononcé, mais surtout il y a 2 fois moins de signal !? Et j'ai vérifié les infos dans l'entête fit, les 2 images ont bien 30 secondes d'exposition, avec un gain à 200 et un offset à 0 En passant, ta camera aura un gain optimum à 252, pas à 200 (déclenchement du HCG) De plus l'offset à 0 c'est pas extra, il faut augmenter pour être supérieur à 0 (teste avec 20) Mais bon, vu que ton dark est plus lumineux que ton light j'ai un doute (tu n'aurais pas inverti dark et light ?) Lorsque j'empile les 5 fichiers frame (sans le dark) je ne vois pas de dominante bleu dans le coin... Cordialement

Bonjour, Merci pour le fichier dark. Effectivement sur ce dark on ne voit pas de dominante lumineuse dans la diagonale qui pourrait être a l'origine de la trainée bleue, mais on y voit un autre problème, les détails ont leur importance Procédons a un peu d'analyse avec des détails afin d'être le plus didactique possible. Lorsque j'ouvre le dark avec Siril, sans dématriçage, l'affichage en mode linéaire ne fait rien apparaitre d'anormal (quelques pixels "chauds" isolés (lumineux), mais c'est normal, le dark sert justement à les corriger) Si je passe l'affichage en mode "auto ajustement", déjà je vois un problème, un gradient lumineux apparait (image plus sombre à gauche et plus lumineuse à droite). Mais je vous l'accorde ce n'est pas flagrant, cela dépend beaucoup des capacités de votre ecran Si je passe l'affichage en mode "histogramme" pour accentuer cela deviens flagrant Et en choisissant un affichage en dégradé de couleur c'est encore plus visible Donc on a un gros problème, la caméra ASI662MC est annoncée pour être dépourvue d'ampglow (de plus ce gradient ne ressemble pas à de l'ampglow). D'où viens ce dégradé ? Une analyse un peu plus quantitative, en calculant les statistiques sur une zone à droite et une autre à gauche A gauche de l'image A droite On passe d'une moyenne de 1100 à 1300, près de 20% de signal en plus ! Au passage autre "problème", cette camera est annoncée comme sortant des valeurs sur 12bits, donc des valeurs entre 0 et 4095, pas entre 0 et 65535 --> a priori SharpCap a normalisé les valeurs sur 16bits en enregistrant le fichier fit (personnellement je n'aime pas les softs qui trafiquent les données à mon insu). Mais bon passons sur ce détail (note: je viens de vérifier dans les options de SharpCap, c'est un comportement par défaut, mais il y a une option pour qu'il garde les valeurs d'origine) Si on regarde canal par canal (rouge/vert bleu) pour vérifier si ce gradient est uniforme pour toutes les couleurs ou bien plus prononcé pour une couleur A gauche Le rouge est sur-représenté ! A droite Cela se confirme, il n'y a pas de gradient bleu, mais un peu dans le vert et beaucoup dans le rouge A noter que cette camera à une sensibilité étrange, les pixels vert (ceux qui ont un filtre vert sur la matrice de bayer sont en fait aussi sensible aux longueurs d'onde dans le rouge) La courbe de sensibilité de la camera (source ZWO) Une piste: ta camera est annoncée comme étant sensible dans l'infrarouge. Le hublot devant le capteur est traité anti-reflets mais n'agit pas comme un filtre UV-IR-cut, et il est préconisé d'utiliser ce type de filtre avec cette camera. Tu dis avoir réalisé les dark avec le bouchon de la camera, hors le plastique qui constitue ces bouchons laisse souvent passer pas mal d'infrarouge, ce qui pourrait expliquer la dominante rouge (le gradient pouvant provenir de l'orientation de la camera par rapport à la source infrarouge, comme un radiateur, ou une fenêtre (éclairage du soleil) Comme je le disait, rien avoir avec la dominante bleue en diagonale, je voulais juste montrer 2 choses: 1) tous les détails ont leur importance, et on peut avoir une fuite de lumière même avec le bouchon fermé, si tu utilises ces darks tu va dégrader le résultat 2) disposer des fichiers "raw" en format fit, le plus proche possible de ce qui a été lu sur le capteur permet de faire une analyse quantitative (basée sur la mesure, sur les chiffres) et pas seulement une analyse qualitative (basée sur l'observation ou la description, qui peut être biaisée par exemple par des choix d'affichage ou de calibration d'écran) Désolé, c'était un peu long, et avec tout cela on a pas avancé sur le problème initial As tu un fichier raw (en fit donc) d'une image brute ? (les png ne nous servirons pas). Si c'est le cas merci d'en poster un. Un fichier unitaire, pas un empilement, comme cela on pourra aussi l'utiliser pour faire une analyse quantitative Cordialement

Bonjour, Je souhaite voir un dark unitaire (en fichier fit) pas un empilement, c'est parce que je veux les données issues du capteur, pas celles issues d'un calcul à postériori. De plus un dark cela se fait sans dématricage (un dématricage cela fait des calculs pour fournir les valeurs manquantes pour 2 canaux sur 3 pour chaque pixels) Pareil pour une image "light", pas d'empilement, il faut une brute unitaire. Pour les PNG c'est trop tard, cela a enregistré des fichiers en 8 bits, la perte d'information est irréversible Dans siril il faut passer par l'onglet "alignement" pour faire cette étape avant de passer à l'étape "empilement" Dans l'onglet "conversion" tu convertit des raw en fit avec création de séquence (si les fichiers sont déjà en fit cela créé juste la séquence) Ensuite pour les "bias" et "dark" tu passe directement à l'empilement, il n'y a pas de calibration ni d'alignement (vu qu'il n'y a pas d'étoiles), et l'empilement se fait sans normalisation Pour les "light", étapes conversion, puis calibration (avec le master dark) (le calibrage se fait sur les images non dématricées, cocher l'option dématricage avant la sauvegarde , puis alignement, puis empilement (normalisation additive) Tu noteras que l'on utilise pas les fichiers bias, utiles seulement si il y a des flats. Enlever les bias aux light et aux dark c'est inutile Arithmétiquement: (light - bias) - (dark -bias) = light - dark Si on a des flats cela fait: ((light - bias) - (dark -bias)) / (flat -bias) = (light - dark) / (flat - bias) Donc seuls les flats sont calibrés avec les bias

Non, celui ci je le reconnais, c'est un modèle Klingon...

Bonjour, Que cela soit des images 16 ou 32 bits, peu importe, le plus important c'est d'avoir des fichiers "fit" et pas des jpeg ou png. Il nous faudrait un light et un dark (pas forcement le master empilé) En terme de "dark", je comprend que tu fait du liveview avec Sharpcap et qu'il est alors nécessaire d'avoir dans Sharpcap un master dark généré par lui. Néanmoins, si ensuite tu récupère les lights pour les empiler avec Siril, je te conseille alors de récupérer aussi les dark unitaires et de générer un master dark avec Siril, et de ne pas utiliser celui généré par Sharpcap lors du pré-traitement Siril. On a vu dans d'autre post que cela pouvait poser des problèmes. Cordialement

Il s'agit d'un bug connu pour la beta4 https://gitlab.com/free-astro/siril/-/issues/?sort=updated_desc&state=all&milestone_type=1.4.0&created_after=2025-09-28&not[label_name][]=Not+a+bug&first_page_size=20 Et techniquement, ce n'est pas l'empilement Oiii qui échoue, ce qui échoue c'est l'alignement des couches Ha et Oiii, l'alignement de tes fichiers results_00001.fit et results_00002.fit Cordialement

Bonjour, Ton tube est un flextube, utilises tu une "jupe" épaisse pour bien calfeutrer ? Il peut aussi y avoir entrée de lumière parasite par l'arrière, coté barillet qui porte le miroir principal. Le tube étant un newton, à priori pas besoin de pare buée (pas de lame de fermeture), mais un pare buée peut aussi permettre de lutter contres les entrées de lumière parasites à l'entrée du tube, surtout si le porte oculaire est placé très proche de l'extrémité du tube. Tu peux faire des test de capture sur une cible en tournant plusieurs fois de 90° ton ensemble camera/reducteur/MAP hélicoïdale, cela te permettra de voir si la trainée bleue reste au même endroit sur le capteur ou pas. --> si elle ne reste pas au même endroit sur le capteur c'est que l'entrée parasite a lieu dans le tube, ou reflet sur l'araignée ou sur un bord de miroir secondaire --> si elle reste au même endroit sur le capteur, alors c'est qu'il y a un reflet parasite lié au réducteur Cordialement

Bonjour, note: je ne sais pas ce qu'est une TZ3... On peut (et on doit) utiliser un filtre ERF de pleine ouverture avec un SCT (Schmidt-Cassegrain) ou avec un MAK (Maksutov) devant un Quark, en diaphragmant un peu l'ouverture sur un SCT. Le filtre permettra de protéger à la fois le Quark, mais aussi le miroir secondaire interne du tube. Le Quark "combo", donc sans barlow télécentrique intégrée est utilisé de manière optimum avec un instrument ayant un rapport F/D de 15 ou plus. Sur un MAK habituellement a F/D 15 l'ERF suffit. Par contre sur un SCT habituellement à F/D 10, il faut diaphragmer (réduire le diamètre de l'ouverture) pour augmenter le rapport F/D (mais on va perdre en résolution optique, qui dépend du diamètre, donc autant utiliser un instrument plus petit) source: https://www.daystarfilters.com/combo-quark/ Cordialement

M104, la galaxie du Sombrero note: plutôt que de poster dans la Noctua il vaut mieux poster dans le Forum astrophotographie edit: désolé, je n'avais pas vu que la réponse avait déjà été donnée dans l'onglet commentaire (comme quoi la Noctua n'est vraiment pas adaptée pour cela)

C'est exact, j'ai juste voulu montrer qu'un filtre n'est pas parfait, ce n'est pas du tout ou rien, style 0% ou 100%, un filtre bleu laissera passer un peu du reste aussi (et c'est comptabilisé dans l'intensité du bleu)... Pour un photosite équipé d'un filtre bleu, la valeur d'intensité est obtenue par la lecture du voltage du photosite, pour la valeur d'intensité verte et rouge qui va lui être attribuée lors du dématricage, elle sera obtenue par interpolation des valeurs des phoposites voisins équipés respectivement des filtres vert et rouge Oui, le filtre (matrice de bayer) bouffe une partie du signal. Pour simplifier le propos l'auteur parle de 30% de perte moyenne, mais la courbe fournie ci dessous pour les canaux couleur montre que cela n''est pas 30% mais que cela dépend de la longueur d'onde considérée. Mais donner un ordre de grandeur reste très valable pour ne pas noyer le lecteur dans des explications techniques (on peut vouloir faire de la photo sans connaitre les détails du fonctionnement du capteur, ou encore utilise rune voiture sans connaitre les détails d'un moteur à combustion) Des lors qu'il y a calcul d'interpolation il y a perte de définition. Je vais tenter de donner une explication plus détaillée. Sur le capteur, chaque photosite va percevoir les photons venant d'une partie du ciel, on va parler d'échantillonnage en arcseconde/pixel. Imaginons que nous ayons un couple capteur plus telescope permettant d'avoir une résolution de 1 arcsec/pixel. Sur un capteur monochrome aucun photosite n'a de filtre. Par contre sur le capteur couleur les photosites auront des filtres RVB en alternance, imaginons que nous ayons un groupe de pixels contigus RVBRVBRVB (dans les faits ils ne sont pas dans cet ordre sur un capteur, on a plutôt des blocs de RVVB disposés en carré, mais peu importe, je met 3 groupes RVB sur la même ligne pour faciliter la démo) Sur le capteur monochrome, prenons aussi 9 pixels qui se suivent Si je fais une image avec un filtre vert, j'obtiens bien pour chacun des 9 photosites l'intensité de lumière verte qui sera reçue de la partie du ciel qu'il représente (1 arc seconde de hauteur et 1 arc seconde de largeur pour chaque pixel dans notre exemple) Puis si je fais pareil avec un filtre bleu et rouge, j'obtiens bien pour chacun des photosites (et donc de la portion de ciel) la bonne indication sur l'intensité reçue de chaque couleur pour la portion de ciel considérée Donc sur le capteur monochrome, j'ai bien pour les 9 photosites les "vraie" intensité de chacune des 3 couleurs, et ces informations reflètent vraiment la proportion de lumière verte, bleue ou rouge reçue de ces parties du ciel . Avec le capteur couleur, sur le 1er photosite rouge je vais obtenir la "vraie" info du rouge, mais pour ses valeurs bleues et vertes je vais INVENTER une valeur en calculant une moyenne par rapport aux autres pixels vert ou bleus les plus proches. Mais ces pixels verts ou bleus proches ne représentent pa la même portion de 1 arc seconde sur le ciel. Si il y a un peu de gaz qui rayonne en Oiii (bleu vert) très localisée dans cette partie du ciel, mais pas sur les pixels voisins, alors mon interpolation va calculer une valeur proche de 0 pour le bleu et vert de ce pixel parce que les voisins sont presque à zéro, mais cela ne reflétera pas la "vraie" valeur que l'on devrait obtenir si on était capable de capter le bleu/vert réellement émis pas cette partie du ciel. C'est en ce sens que l'on perd en définition. Il y a un lissage dû aux calculs de moyenne, pour chaque pixel on a une valeur de couleur (bleu ou vert ou rouge) et on "invente" les 2 autre valeur manquantes en faisant une moyenne des valeur obtenue à coté, et à coté cela veut à la fois dire les photosites d'à coté, mais aussi les parties du ciel qui sont à coté, c'est en cela que cela dégrade la qualité de l'image Et ici aussi les 45% annoncés correspondent à une moyenne, on perd moins sur le vert que sur le bleu et le rouge. C'est du au fait que 50% des photosites du capteur sont pour le vert, 25% rouge et 25% bleus. Ce choix (mettre plus de photosites avec filtre vert que rouge ou bleu) n'est pas anodin, il est liée au fait que l'oeil humain est plus sensible dans le vert (et ce n'est pas par hasard non plus, c'est là que notre Soleil à son pic d'émission dû à sa température de surface...) En résumé, après dématricage, 100% des pixels de l'image ont bien une valeur pour le vert, une pour le rouge et une pour le bleu, mais pour chaque pixel 2 des 3 valeurs ont été calculées par moyenne et c'est ce calcul qui génère la perte de résolution Oui, je pense qu'il y a du vrai la aussi, il n'y a certainement pas seulement de la logique commerciale, les chaines de fabrications ne sont peut être pas les mêmes et les lots produits, certainement plus petits pour le monochrome ne permettent pas la même répartition des coûts De mon coté - une PlayerOne Poseidon-C (IMX571 pour faire du ciel profond en "one shot", et un peu de SHO avec des filtres dual-band, en 2 prises de vue) - une ASI290mm, monochrome dédiée guidage, parce que la sensibilité est meilleure pour les poses courtes du guidage - une ASI178mm, monochrome, utilisée pour la spectro (avec un Sol'ex) et l'imagerie lune et soleil, parce qu'avec une monochrome la résolution est meilleure et que capter la couleur n'est pas indispensable sur ces cibles (à part la lune et le soleil je ne fais pas de planétaire) Voila. Garde à l'esprit que mes réponses reflètent mon expérience et les éléments que j'ai pu lire de ci et de là, éléments que j'ai pu mal comprendre ou interpréter de manière erronée, donc je ne prétend pas que ce que j'écris ne soit pas entaché d'inexactitudes. Je te fais confiance pour recouper ces infos avec d'autres sources Cordialement, Stéphane

Bonjour, En cas d'utilisation du correcteur de coma, tu vissera les filtres devant le correcteur, donc ils ne modifierons pas le backfocus (le rajout de 1/3 de l'épaisseur du filtre c'est seulement si il est intercalé entre le correcteur et le capteur) La contrainte pour les flats tu l'aura dans tout les cas, on les fait pour chaque filtre, et c'est vrai aussi avec un tiroir (ou avec des filtres clip aussi), même si le tiroir n'oblige pas à un démontage du chemin optique, car chaque filtre peut générer un vignettage différent. Cordialement