Aller au contenu

keymlinux

Membre
  • Compteur de contenus

    933
  • Inscription

  • Dernière visite

  • Jours gagnés

    4

Tout ce qui a été posté par keymlinux

  1. 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
  2. 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
  3. 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.
  4. 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
  5. 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
      • 2
      • J'aime
  6. 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
  7. 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...
  8. 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 ?
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. Non, celui ci je le reconnais, c'est un modèle Klingon...
  16. 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
  17. 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
  18. 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
  19. 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
  20. keymlinux

    identification galaxie

    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)
  21. 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
  22. 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
  23. Donc plutôt que panchromatique il serai préférable d'utiliser polychromatique Pan --> tous (comme dans Pangée, Panthéon) poly --> plusieurs (comme dans Polytechnique) Un photosite ets sensible a une large gamme de longueur d'ondes mais pas toutes , polychromatique EDIT: oui. La première courbe présentée (la sensibilité du capteur monochrome) est une courbe "absolue", la seconde pour la camera couleur est "relative", elle s'applique relativement à la courbe du capteur mono Par exemple: Imaginons de la lumière verte à 530nm de longueur d'onde. Sur le capteur monochrome on a statistiquement 91% (1ere courbe mono) des photons incidents qui vont générer le piégeage d'un électron Sur le capteur couleur à cette longueur d'onde 100% des photons (2eme courbe) vont passer à travers le filtre VERT et 91% (1ere courbe) de ceux qui sont passés vont générer le piégeage d'un électron dans le photosite (ici on est dans le cas de la seule longueur d'onde où on à la même sensibilité entre le capteur mono et celui couleur, parce qu'a cette longueur d'onde le filtre vert laisse passer 100%. Par contre sur le même capteur couleur et à la même longueur d'onde, si le photosite est équipé d'un filtre BLEU, alors seulement 10 à 15% (2eme courbe) des photons vont passer le filtre bleu, et parmis ceux qui sont passés, seuls 91% vont générer le piégeage d'un électron --> 0.1x0.9=0.09 --> 9%du signal Si maintenant on veut voir la sensibilité dans le bleu(différence entre les 2 capteurs) Imaginons de la lumière bleue à 450 nm Sur le capteur mono, on aura statistiquement environ 77% des photons incidents qui vont générer le piégeage d'un electron (1ere courbe) Sur le capteur couleur, pour la même longueur d'onde, le filtre BLEU va statistiquement laisser passer 77% (courbe 2) des photons, et pour ceux qui sont passés seulement 77% (courbe 1) vont générer le piégeage d'un electron, donc au final on a statistiquement 59% (0.77*0.77=0.592) des pixels incidents à l'entrée du filtre BLEU qui vont générer le piégeage d'un électron dans le photosite. Ici on voit bien la différence de sensibilité pour une même longueur d'onde entre les 2 capteurs Donc oui, le filtre (la matrice de bayer) absorbe du flux, donc au final le capteur (avec filtre) d'une camera couleur est moins sensible que la même version monochrome Tu notera au passage qu'un capteur couleur c'est un capteur monochrome auquel on a ajouté une matrice de bayer, donc le prix du capteur couleur devrait être supérieur a celui du capteur mono. Mais comme au final le capteur mono est "meilleur" (au sens plus sensible) que le couleur, la logique en grande partie commerciale impose de le vendre plus cher... J'ai écrit "meilleur" entre guillemet car tout le monde n'a pas les même critère pour définir ce qui est meilleur. Par exemple, pour mon cas personnel, bien que la sensibilité du capteur couleur (avec matrice de bayer) soit inférieure, le fait de ne pas avoir à faire 3 lots de prise de vue différents (avec des filtres R, V et mais une seule fait que je préfère utiliser un capteur couleur (ont dit souvent OSC pour one shot color) Cordialement
  24. Bonjour, On va faire la différence entre les photosites (sur le capteur) et les pixels (dans le fichier image, restituant une information lue ou calculée) 1) Sur une camera dite monochrome, un photosite n'est pas monochrome, il "réagit" (effet photo-électrique) aux photons (ondes électromagnétiques) ayant de nombreuses longueurs d'onde différentes (c'est peut être ce que tu entends par "panchromatique"), mais avec une efficacité différente pour chaque longueur d'onde Ci dessous la courbe d'efficacité (quantique) d'un capteur IMX571 (source P.O.) La lecture du capteur d'une camera monochrome permettra donc d'obtenir une valeur de voltage (qui va dépendre du nombre l'électrons piégés, ces électrons résistant de l'effet photo-électrique) pour chaque photosite, que l'on transcrira en valeur d'intensité lumineuse pour chaque pixel normalisée sur 8, 10, 12, 14 ou 16 bits en fonction de la camera. Pour une IMX571 c'est 16 bits donc on obtiens des valeurs d'intensité entre 0 et 65535 (2 puissance 16 valeurs) L'image obtenue est donc bien monochrome dans le sens où elle n'est constitué que d'un seul canal d'information (on peut parler 'une image en niveau de gris) Si on emploie des filtres (LRGBSHO) sur cette camera on ne fera que réduire la plage de longueur d'onde qui va interagir avec les photosites, et dans tous les cas l'image obtenue est monochrome, restera ensuite à attribuer à chaque couche une couleur arbitraire si l'on veut obtenir une image couleur par combinaison de plusieurs canaux note: les photosites étant aussi sensibles dans l'UV et l'IR, il faut utiliser un filtre 'UV/IR cut' si la camera n'en dispose pas (sur certaines la vitre devant le capteur est traitée pour faire office de filtre UV/IR) 2) Dans le cas d'une camera couleur, les photosites sont eux aussi sensibles à une très large plage de longueur d'onde. On (le constructeur) va ajouter devant le capteur une matrice de Bayer qui va agir comme des filtres rouge/vert/bleu devant respectivement un quart, la moitié et un quart des photosites. Ceci étant cela n'en fait pas des récepteurs monochromatiques, chaque filtre laisse passer une large game de longueur d'onde (donc ici aussi ton appellation panchromatique es peut être valable selon le sens que tu lui donne) Ci dessous la courbe d'efficacité quantique relative pour chaque filtre (même capteur IXM571) On peut noter que par exemple que les photosite recouverts d'un filtre bleu et ceux recouverts d'un filtre vert sont sensible de la même manière à la longueur d'onde à 580nm. La frontière de sensibilité d'un photosite ne s'arrête pas là où démarre celle de son voisin. Et ici aussi malgré la matrice de bayer les photosites restent sensibles dans l'UV et l'IR, donc usage d'un filtre pour les couper si la camera n'en est pas équipée en standard. Et ici aussi la lecture des voltage des photosites va permettre de construire un fichier image mono couche (1 valeur d'intensité lumineuse par pixel). Pour les DARK, FLAT et BIAS, on les utilise sans les debayeriser (dé-matricer), donc on les utilise en tant qu'image RAW qui est monochrome (même si obtenue avec une camera dite couleur) Par contre pour les images 'Light" qui doivent nous servir à montrer les couleurs de l'objet photographié, on va debayériser le RAW pour générer une image comprenant 3 couches. Lors de la débayerisation, pour chaque pixel de l'image on va attribuer la valeur d'intensité lue dans le raw à la couche correspondant à son filtre (de la matrice de bayer), et pour les autres couches on fera un calcul de moyenne (une interpolation) en prenant les valeurs de pixels voisins. C'est le résultat de la débayerisation qui génère une image couleur. https://fr.wikipedia.org/wiki/Dématriçage En résumé, que cela soit une camera couleur ou monochrome, aucun de leur photosite n'est monochrome, ils captent tous une plus ou moins large de longueur d'onde. C'est le fichier image résultant qui est monochrome ou couleur selon qu'il est constitué d'une couche unique ou pas, Cordialement, Stéphane
  25. Bonjour, Ta camera est une camera couleur, donc elle produit des images en couleur si tu les ouvre en les debayerisant. Un "dark" sera utilisé lors du pré-traitement en mode non-débayerisé, donc si tu l'ouvre dans ce mode tu verra les pixels non pas en couleur mais en niveau de gris (si tu les ouvre avec le logiciel Siril par exemple, tu as une option à cocher pour choisir si tu debayerise ou pas à l'ouverture) Un "dark" n'est pas intégralement et totalement noir (ci c'est le cas c'est que tu as la camera parfaite...et donc faire des darks serait inutile...). Il y a un peu de signal, qui dépend de la camera, entre autre si elle produit de l'amglow Cordialement
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.