Philippe Bernhard

Merci à tous !!! Merci Olivier, je n'y manquerai pas.

merci beaucoup Samedi avec l’AAV on a eu une trouée d’un peu plus de 4h. j’ai donc une mosaïque de 2x 2h (enfin, 55 poses de 2 min pour M45 et 70 poses de 2min sur ngc1499 jusqu’à l’arrivée des nuages). Donc peu de poses mais effectivement un traitement spécifique pour le bruit (peut-être un peu trop) et pour sortir les nuages de poussières et les structures Ha. Mes nouvelles techniques de traitement me permettent de mieux booster mes images mais il ne faut pas oublier l’APN rle sigma fp) et le 135 ouvert à 1.8 qui permettent aussi de récupérer du signal. Alors oui, il reste des artefacts et le traitement a été poussé à son maximum pour sortir tout ce que je pouvais ! Et effectivement en 2x 2h je suis assez surpris du résultat Merci à tous pour vos commentaires !

Petit update : un nouveau moteur AI v2 beta est sorti et proposé pour test. https://pixinsight.com/forum/index.php?threads/blurxterminator-ai2-beta.20019/

peut-etre pas à ce point, hein ? 🤣 non, c’est appliqué sur les brutes d’empilement mais la compression jpeg ne permet pas une vraie analyse ici. Et la version finale de l’image n’a d’ailleurs pas eu les mêmes réglages de blurx Pour l’AI, oui, loin de moi l’idée de lui faire une confiance aveugle. J’ai souvent été assez déçu par les outils classiques de déconvolution (d’abord par leur temps de calcul, ensuite par le résultat) que j’ai été emballé par blux. Je l’ai testé sur plusieurs images pour voir la limite des curseurs et dans l’équipe (ciel austral) on regarde toujours avec un blink l’avant et après. Par contre, pour mes images nomades à l’APN en courte focale, là je m’en fous complètement. je mets des paramètres spécifiques pour la courte focale et ça répare même certains défauts (étoiles en bord de champ… ou pas très rondes)

les anti-PIX sont encore plus marrants perso, j’utilise un panel de logiciels (gratuits et payants) selon le niveau de traitement à faire. après, pour en revenir au sujet de blurX, on peut comparer des jpeg compressés et dessiner plein de traits dessus. il faudrait avoir les tif 16 voire les brutes 32 bits pour voir réellement. Et effectivement aussi voir les réglages (limites des curseurs) car il faut plutôt les laisser assez bas (après l’euphorie de la sortie du plugin)

je ne parlais que pour ma part. j’utilise starx et starnett2 et je compare. Et le plus souvent je garde celles de starx. Quant-aux prix des logiciels et autres plugins, je te laisse maître de ton portefeuille. Pixinsight je l’ai acheté dès le début (donc il y a très longtemps) et c’est amorti depuis longtemps, alors remettre 50 ou 100 par ci par là, pas de problème.

T'inquiètes, ça va bien se passer ce passage sous ce merveilleux logiciel !!! bon, trève de plaisanterie, tous les derniers process de Russell Croman sont adoptés : NoiseXterminator, StarXterminator (meilleur que starnett 2) et BlurXterminator. Je ne sais pas ce que ce mot "IA" cache mais je n'y vois pas que de mauvaises choses. Tout n'est pas parfait et probablement qu'une mise a jour de l'IA donnera de meilleurs résultats mais je suis émerveillé de voir (enfin) des nouveautés en traitement. N'en déplaise aux vieux de la vieille.

j’utilise ce process depuis quelques jours un crop 100% sur une de nos images de notre CDK600 au Chili (juste l’assemblage SHO pour les crop du haut) Alors, oui, c’est puissant et c’est pas du topaz sharpen. Je n’ai aucun doute que son IA va évoluer comme c’est le cas pour noiseX et StarXterminator.

Merci ! En fait, dans nos images, nous faisons des acquisitions en RGB et SHO Le RGB sert essentiellement pour les étoiles (couleurs naturelles calibrées photométriquement) Le SHO ou HOO sert pour la couleur et aussi pour la luminance Mais il nous arrive aussi de mixer les couches SHO avec les RGB afin d'avoir un rendu un peu différent (luminance ou couleur). Le script que nous avons écrit sous Pixinsight permet de faire tout cela facilement. En fait, nos traitements passent parfois par des versions vraiment différentes faites par chaque membre de l'équipe et ensuite on converge vers les points positifs de chacune des versions. Philippe

Ok je vais tenter d’expliquer le capteur a 51ke- de puits de potentiel pour 3.5 e- de bruit rms. la dynamique est donc de 51000/3.5 = 14500 environ soit un tout petit peu moins que 14bits (16384) On met sur ces 51000 e- un ADC 16bits qui va convertir 51000 e- en 65535 niveaux moins un offset. On va donc le régler avec un gain de 0.8 e-/adu On passe maintenant en adu. tu satures (à gain 0) à 65535 adu et ton bruit de lecture va etre proche de 4.4 adu (3.5 / 0.8). Le bruit est donc quantifié par 4 adu (2 bits) ce qui ne sert absolument à rien. Bien pire, tu montes en gain, par exemple le gain du switch de l’ampli bas bruit : gain 100, tu satures à 18ke- et tu as un bruit de 1.5e- . Ta dynamique est alors de 12000:1 (18k/1.5) et donc un peu plus de 13 bits (disons 13.5). Tu vas les convertir sur 16 bits avec un gain de 0.25 e-/adu, soit 4 adu pour coder un électron !!! Alors bien sur le FITS sorti du logiciel ne peut etre qu’en 8, 16 ou 32 bits. Tant qu’à faire, autant utiliser les 16 bits Prenons maintenant la 2400mc, elle a un puits de potentiel plus élevé mais un bruit de lecture aussi plus élevé à gain 0. Sa dynamique est aussi de 14 bits. l’ADC sur le capteur est de 14 bits mais ZWO a choisi de convertir en post acquisition en 16 bits pour remplir les 16 bits d’un fichier FITS. Ils auraient pu laisser à 14 bits comme pour les APN par exemple. Voilà je pense que tu confonds la dynamique réelle du capteur (calculé sur des électrons) avec le convertisseur e- vers ADU qui est codé sur 12, 14 ou 16 bits selon les compsants.

Déjà, il faut oublier la dynamique du convertisseur (16 bits) mais regarder la dynamique réelle du capteur. Typiquement 14 bits grand max (voir courbe zwo). Lorsque tu fais un binning 2x2 software interne ( FPGA ou dans le driver), tu augmentes ta dynamique réelle d’un facteur 2 maximum donc tu as 15 bits de dynamique réelle. Ca tient toujours sur un FITS 16 bits. il faut pas croire que ton asi6200 a 16 bits de dynamique (je sais que ça a été un de tes principaux arguments pour promouvoir l’asi6200 sur les forums). L’asi2400 a un ADC 14 bits ajusté à sa dynamique réelle et j’ai toujours préféré ce capteur pour sa meilleure qualité de distribution du bruit (et banding) et sa sensibilité (pour avoir eu les 2 caméras). D’ailleurs les données de l’asi2400 sortent sur 16 bits du driver. Aussi, la QHY461 mono permet un binning 2x2 hardware. C’est un des seuls capteurs (avec son grand frère le 411) permettant de le faire. Je dois vérifier ça lorsque j’aurai le temps avec les caméras d’un de nos membres de Ciel Austral. Il l’utilise en bin 2x2 sur ses CDK1000 et CDK700

Merci à tous pour vos messages ce n’est pas notre première image au CDK24 et nous en avons encore 6 en attente de traitement !!! La galerie est sur notre site : http://www.cielaustral.com @FranckiM06 je ne suis pas trop d’accord avec toi. on gagne toujours à poser plus longtemps, ne serait-ce déjà pour avoir le maximum de qualité (certaines nuits sont moins bonnes que d’autres) et on gagne toujours dans les extensions. Ici on gagne dans le modelé du bleu+OIII. je crois même que nous avons oublié de passer un filtre de réduction de bruit sur ces images ! Aussi, on était au mois de mai lors des acquisitions et le télescope est entièrement automatisé par MaxPilote. Comme on ne devait pas etre tous dispo, on laisse aussi parfois le setup se débrouiller tout seul pendant plusieurs jours. Alors certes, on aurait pu faire M20, M17, M16 dans ces 80h et après ? Est-ce qu’on fait la course aux objets ou alors est-ce qu’on fait comme ces sites de vente de pile d’images (souvent restreintes) ou location de temps de télescope où le temps est compté ? non, on a le temps, c’est notre setup. On shoote 300 nuits par an (moins les périodes de 2-3 jours avant et après la pleine lune) donc on a le temps. On avait fait pas mal de tests à l’époque de la TEC160 et l’ODK20 sur le nombre de poses à faire. C’était simple, il suffisait d’empiler 25, 50, 75, 100 poses par exemple et comparer le S/B sur certaine zones et la FWHM des étoiles. philippe

Bonjour à tous L'équipe CIEL AUTRAL vient de recevoir sa nouvelle caméra MORAVIAN instruments C4-16000EC équipée du CMOS Gpixel GENSE4040 (FSI) Nous avons donc fait un 1er test en France, sur notre RC360 f/8 custom. Nous avons comparé, la même nuit, une de nos G4-16000 (KAF16803) et le résultat correspond à ce que nous attendions. Nous vous montrons 1 brute (calibrée par un masterDark) de chaque. 600s en Ha 3nm. D'autres tests sont en cours ou à venir, mais la caméra est validée et partira bientôt pour le Chili avec notre nouveau télescope. Une nouvelle caméra Moravian avec un autre capteur CMOS arrivera aussi dans quelques semaines... Elle sera aussi envoyée au Chili. Les infos générales sur la caméra C4 sont ici : https://www.gxccd.com/art?id=607&lang=409 Amicalement Ciel Austral

Oui dans ce cas on acquière uniquement des dark qui constitueront 2 MasterDark Hi & Low (quoi que je ne fais pas de median, mais un empilement avec réjection)

On peut utiliser soit des dark de flat soit des bias. Du fait des 4 quadrants distincts, il est fortement conseillé d'utiliser au minimum de vrais bias. Jerome, il faudra que tu étudies la structure de ce capteur très spécial. Nous avons d'ailleurs écrit un script sous Pixinsight pour la calibration des brutes car c'est plus compliqué qu'habituellement...

sur les 4 modes de lecture, on en utilise 3. 1 pour les light et 2 pour les bias dark flat

Pour les master, on a une 50aine de dark et bias de chaque ampli. Les flat c’est généralement une 30aine Attention, en cmos, on ne calibre pas les dark et surtout on ne coche pas « optimiser le drak » car le dark n’est pas tout à fait linéaire en fonction du temps de pose

Le bruit télégraphique est présent sur tous les CMOS. La structure des bruits (lecture, thermique...) est différente des CCD comme les KAF. Mais comme je t'ai dit, tout se corrige avec le prétraitement. L'image finale est clean sans aucun pixel chaud. On travaille à -15 (ou -12 car il peut faire assez chaud la nuit) Donc oui, en narrowband on a un gain direct en rapport signal sur bruit sur les brutes et sur l'image empilée. Mais surtout on pose moins longtemps, ce qui a certains avantages.

Mike a reçu son DeltaRho et aussi 2 caméras QHY-461. Il attend aussi une C5 qui ira sur le deltarho. La QHY-461 est installée sur son CDK1000. L'autre doit aller dur le CDK700. Je regarde avec lui les modes optimaux pour le T1m. Et j'attends que le DeltaRho soit finalisé pour "jouer" avec Il travaille sur le T1m en binning hardware avec la QHY. Il semblerait que le capteur ait la possibilité d'un binning hard 2x2. A voir ce que ça donne.

oui, surtout en narrowband 3nm sous un ciel comme le Chili On a même choisi de ne poser que 900s au lieu de 1200s avec le KAF après différents essais.

Ces images sont anciennes (nos 1ers tests en janvier 2021). On a en réel un facteur 4 à 5 en rapport signal sur bruit grace à 2 paramètres : Le QE en Ha est de 70% contre 50% pour le KAF16803 et aussi le bruit de lecture qui est de 3.6 e- contre 11-12 e- pour le KAF. Le courant d'obscurité reste négligeable car différent sur les CMOS que sur les CCD KAF. On a aussi pu vérifier ces différences par une autre méthode. La caméra tourne depuis quelques mois, toutes les nuits sur notre CDK24 après avoir fait un rapide tour sur le CDK1000.

La FLI a (ou a eu) beaucoup de problèmes (surtout de calibration des 4 quadrants). Après, je crois qu'il y a eu des MAJ de drivers mais les retours sur Cloudynights sont vraiment pas encourageants. De plus, un des membres de notre team a une FLI 4040... voilà... je n'en dirais pas plus sur cette marque. Pour la C4-16000, les pixels chauds sont automatiquement éliminés par le prétraitement, que ça soit Pixinsight ou plus facilement APP. Un autre membre de notre team a remplacé sa C4-16000 par une C5 avec le 461 (je vais voir ou ça en est cette histoire) car les derniers capteurs livrés pas Gpixel avant l'été semblaient un peu plus hard à corriger (les 4 quadrants).

la C4-16000 tourne au chili sans problème et on accumule des images sur le CDK24 (on est en panne de traitement à cause des vacances mais ça repart doucement car on a 4 ou 5 nouvelles images à traiter ) La calibration doit être méthodique mais on a maintenant l’habitude et on a créé un script pixinsight pour faciliter la tâche. la C3-61000 attend toujours le Ti45 en cours d’upgrade chez les italiens. Oui, le 4040 est plus sensible que le 16803 et les pixels chauds disparaissent complètement au pretraitement. le courant d’obscurité n’est pas un problème. on pose 150s en LRGB et 900s en SHO.

Bonjour à tous Je réfléchissais (entre autre) à une configuration nomade rapide à base d'un Sigma Art 135mm f/1.8 (canon ou nikon) et une caméra ASI2400MC (24x36 couleur 24Mp) et roue à filtres (j'ai déjà la caméra, RaF, série de filtres IDAS) Le problème des objectifs modernes est l'absence de bague manuelle de réglage de diaphragme. Existe-t-il une solution "électrique" pour régler l'ouverture voire si possible piloter le moteur de mise au point. Au pire, il existe des systèmes à courroie avec un ZWO EAF par exemple (mais c'est juste la MAP) Au lieu de la RAF, je peux revenir aussi à une solution de filtre à tiroir. Je sais qu'il existait une boite russe (Astromechanics) qui faisait l'adaptateur EOS vers T2 entièrement motorisé mais il est hors de question d'acheter en russie vue la situation actuelle et leur site est de toute façon down. Merci d'avance a+ Philippe

le Lacerta Mgen3 est relié au PC par USB (le même qui te sert à l'alimenter) L'appli Mgen.app bypass le driver ASCOM de la caméra CMOS et synchronise le Lacerta avec les poses et le dithering.