ZeMrHyde

en dec : ça corrige, ça dévie toujours, jusqu'à lâcher à un moment donné apres, ça a l'air de passer d'un coté à l'autre ... possible backlash important qui n'aide pas au schmilblick

Je ne suis pas un expert, mais a priori : - bin2 ou pas, i.e. peut importe l'échantillonnage, si il est bien renseigné dans phd2, une mouvement de x arsec sera toujours un mouvement de x arsec ... apres si l'EP est un peu grande par rapport aux specs, voir la tension entre la vsf et la roue n'est pas trop forte ... peut-etre vérifier la tension de la courroie en AD - d'après les courbes, notamment en DEC, il y aurait un problème de friction mécanique : a voir les mouvements sont bien fluide, si y'a pas un truc de trop serré, et revoir l'équilibrage (qui doit être au poil chez les Ioptron, d'après ce qu'on peut lire dans les forums). Voir aussi de faire un "guiding assistant" pour avoir une mesure de backlash: si le backlash est important en DEC, voir le réglage de la tension de la courroie ..

L'orientation de la cam de guidage vis à vis des axes de la monture : osef C'est juste plus pratique pour l'interface chaise-raquette mais PHD2 s'en fou totalement : cam presque alignée ou pas, dans tous les cas un calcul de changement de repère est fait par PHD2 pour envoyer les bonnes commandes dans le bon axe (AD ou DEC) en fonction de comment ça bouge sur le capteur de la cam de guidage. Pour la calibration, le mieux reste de la faire dans une zone +-10° de part et d'autre du méridien SUD, et sur l'équateur céleste. un talk à voir et écouter à propos de PHD2 et ses réglages :

Dans NINA, le refroidissement/réchauffement suit certains paliers mais c'est assez rapide; bien plus rapide que ce qui a l'air d'être préconisé ici ... Si c'est vraiment critique, pourquoi les softs de contrôle n'utilisent pas, par défaut, une pente lente pour le refroidissement/réchauffement ?

ça ? http://astronomy.tools/calculators/ccd_suitability

Alors d'après les formules énoncées dans le tuto de JLD : Echantillonnage à viser : E = lambda / 10 D, avec lambda=400 car ton newton devrait être pas mal dans le bleu E = 400 / (10x200) = 0.2"/px Cet échantillonnage étant une base de travail, on peut sans douter aller un peu plus loin (suivant les conditions, qualités optiques du tube...) Pour avoir un tel échantillonnage, quelle focale faut-il, et ainsi quelle barlow privilégier ? : F = 206 x px / E ASi224 : F = 206 x 3.75 / 0.2 = 3862,5 mm Pour avoir une telle focale avec ton 200 à F/d 6 : barlow = 3862.5 / (200 x 6) = x3.21 ASI290mm : F = 206 x 2.9 / 0.2 = 2987mm barlow = 2987 / 1200 = x2.48 ASi174mm : F = 206 x 5.86 / 0.2 = 6025.8mm barlow = 6035.8/1200 = x5.02 Sachant que si tu utilises un adc et suivant le montage de ton train optique cela risque d'induire du tirage et donc d'augmenter l'effet de la barlow ... à prendre en considération Pour les powermate, c'est un peu different

le L-pro va etre plus restrictif qu'un simple UV/IR cut : donc, ça va dépendre la pollution lumineuse de ton ciel si bortle > 4: L-pro si bortle < 4 : UV/IR cut après si tu veux faire de la courte-pose, à ce moment là ce qui compte c'est le flux : du coup UV/IR cut et masse intégration en gros, amha (corrigez moi si je dis du caca )

la seule version 64bits que j'ai trouvé de ICE : https://www.afterdawn.com/software/desktop/image_editing/microsoft-image-composite-editor-64-bit.cfm

c'est pas mal ça ! en complement de parser les exifs, il n''y aurait pas moyen de récup l'heure de prise de vue dans l'en-tête des fichiers .fit / .fits / .ser ? on a pas tous des apn

N'empêche, mécaniquement ta monture tient la route parceque accrocher 1" de rms en guidage avec 0.35" de résolution, je ne voudrai pas dire de connerie mais ça me parait à la limite de ce qu'il serait possible de faire donc si tu arrives à réduire, y'a des chances que ça soit tip top

avec un 400 pas/tour en remplacement standard du moteur actuel : 0.35/2 = 0.175"/pas ça serait mieux, mais pas "ouf" non plus ... avec en sus une réduction 1:5, tu retomberais sur de la résolution d'Eq8 le montage de départ avec une réduction par courroie était pas mal

si tu reprends le calcul donné avec ton nombre de dents : 3600 x 360 / ( 287 x 200 x 64 ) = 0.35"/pas en d'autres termes, quand le moteur va tourner d'un pas, ça va correspondre à un déplacement de 0.35" sur le ciel amha, c'est un peu leger, une eqm35 par expl, c'est 0.14"/pas edit: et une Eq8 c'est 0.03"/pas

c'est pas le sujet d'ici mais il me semble que les px de 4.63um etaient deja du binning software... justement il y a eu débloquage (soft) pour avoir accès à la résolution native du capteur avec les px de 2.3um mais oui, ajuster aux perfs de guidage son échantillonnage via le binning peut aider à récupérer une certaine rondeur des étoiles

c'est pas mal dutout là l'idée c'est que - si il envoit des commandes et que il en faut plein pour commencer à arriver à corriger = agr trop faible - si il envoit une commande et que ça jete de l'autre coté et que donc ça balance d'un coté et de l'autre : agr beaucoup trop forte à trouver le bon compromis mais là, clairement, il manque un peu d'agr en AD, amha

ah oui ! au temps pour moi, je viens de percuter

dans la description de la video de l'auteur sur youtube : Topaz a encore frappé !

avec le système à miroir que tu proposes ?

y'a même des travaux récents à base de Deep Learning (qui devraient plaire à JLD ) https://www.biorxiv.org/content/10.1101/2020.04.05.026567v1.full.pdf c'est dans le domaine de la microscopie, mais ils ont un peu les mêmes problèmes que "nous"

c'est un peu le sens des recherches que j'ai pu voir vite fait : au delà de chercher une psf unique, les gens cherchent à estimer la psf correspondante à une zone particulière de l'image pour corriger les déformations locales. A la fin, ils n'ont donc pas une seul psf mais un champ de psf pour corriger l'image de façon plus précise sur tout le champ. Ce genre de truc on le retrouve en astro mais aussi en imagerie medicale, genre imagerie par fluorescence.... Mais l'estimation des psf repose sur des d'étoiles présentent dans l'image ou bien à partir d'une mire de sources ponctuelles (dans le cas d'imagerie médicale), du moins dans les papiers que j'ai vu voir rapidement. Estimer la psf à partir d'une image quelconque n'a pas l'air trivial. Pourtant, le soft SmartDeblur genère une psf non ? il fait comment ? C'est sans doute pas pertinent mais est ce qu'on pourrait imaginer une méthode itérative pour estimer la psf ? genre : - on part d'une psf théorique à partir des paramètres du train optique : diamètre du scope, échantillonnage (si c'est possible ? ) - deconvo avec cette psf théorique - et ensuite on mesure une(des) métrique(s) entre l'image originale et l'image deconvo qu'on va chercher à minimiser/maximiser en modifiant la psf theorique de départ, itérativement ? c'est sans doute bien naïf, j'avoue ne pas être du domaine, et les maths derriere tout ça me sont totalement hors de portée je réfléchis un peu à voix haute mais le projet est super intéressant !

ça ? https://www.astromatic.net/2010/11/08/psfex-release

un peu un truc dans ce style ? https://core.ac.uk/download/pdf/15493988.pdf

Salut, Grosse lune, poussières dans l'atmosphere, mais c'est pas grave, de toutes façons depuis le balcon le ciel est pourri test de la technique sur NGC3242, the ghost of Jupiter, nébuleuse planétaire située dans la constellation de l'Hydre. ASI533 + L-Pro au foyer d'un C8 (nouveau tube ) enregistré en fits avec NINA, raw16 (j'ai oublié de passer en 8bits), bin2x2 (0.77"/px d'echantillonnage), gain 450, 1s de pose, -15°C moulinette avec SIRILsur les 1590 images, j'ai gardé 1202x1s via une selection pas trop méchante en FWHM et rondeur 101 darks, 101 flats, 101 darkflats autoguidage avec dithering toutes les 30 images j'ai mis un petit peu d'ondelettes à trous et de déconvo crop 100% Pas totalement certain du focus fait à l'oeil sur une étoile; j'ai pas encore de bathinov/hartmann ou autre masque Pas totalement convaincu de la collimation, meme si à l'oeil sur une étoile délocalisée ça avait l'air bien concentrique Pas totalement confiant dans les choix des paramètres de prise de vue... (il y a une relation entre echantillonnage et temps de pose ? ) Avant de refaire ça proprement avec 10-20-30k images, suis-je dans la bonne direction ?

intéressant ça ! bien curieux de voir ce que ça donnerait en précision de guidage, HEQ5-Rowan vs GEM28

je ne voudrai pas passer pour le lourd de service mais : - comparer les perfs avec 5min d'un coté et 15min de l'autre, c'est pas très fairplay ... déjà avoir les mêmes conditions, ça aiderait à y voir un peu plus clair - vue le screenshot de PHD2 il y a plusieurs choses qui ne vont pas : * l'étoile guide est saturée : profil plat, et c'est pas bon. Le mieux est de laisser PHD2 se choisir l'étoile qui va bien (bouton avec l'a loupe et l'étoile) * vue le comportement en AD/DEC, soit le temps de pose était trop court pour le seeing à ce moment là, soit les paramètres sont beaucoup trop agressif ce qui envoie la monture d'un coté et de l'autre * <200ms de backlash en DEC, tu peux largement mettre le guidage DEC en "auto" avec une compensation de backlash proposée par le guide assistant. On guide en DEC que dans un seul sens si on a du backlash tres tres important, genre plusieurs secondes. -pour l'histoire des CEM60EC et autoguidage : cela a fait coulé beaucoup d'encre mais en fait il semblerait que c'est tout à fait possible de guider avec les encodeurs ON, il suffit juste d'avoir les bons paramètres de PHD2 (faible fréquence de guidage, 5-10s, notamment). Si ça oscille, faut d'abord voir du coté des paramètres de PHD2... Au dela de ça, certains modeles EC peuvent exhiber des oscillations d'assez hautes fréquences, sans autoguidage: cela est du à l'erreur SDE, qui devait être partiellement résolue avec un update du firmware ... mais c'est pas clair. Comme ton test sans autoguidage a l'air plutôt net, ta monture ne doit pas trop être impactée par ce phénomène. Pour moi c'est possible de guider une monture avec EC, mais faut bien régler PHD2 En outre, install la version béta de PHD2 et active le multistar : le gain en guidage est dingue ! Cela rend le systeme plus résilient au seeing. sinon, +1 avec christian_d, 15min à 0.5"/px, c'est tendax !

Simplement parce que NINA gère bien le dithering, et que j'en ai l'habitude En outre, l'autostretch du preview est bien pratique pour voir si on est là où il faut, et avec le platesolving c'est assez simple de pointer les petits trucs. Mais oui, le .SER est mieux c'est sûr. Il faut que je me penche voir si on peut faire du dithering avec FC Merci pour les conseils