vinvin

En effet ça doit être du 24 TPI, je n'avais pas calculé combien ça faisait. La pièce que j'essaie de mettre dessus est pourtant documentée comme étant du Schmidt-Cassegrain femelle (2''x24FPP UNC). Désolé pour le 0.75mm je me suis trompé avec le M42. Donc c'est le bon pas mais pas le bon diamètre, il y a juste 0.3mm de trop, dommage. C'est un filetage mâle, la pièce est démontable mais c'est aussi la plaque arrière du télescope d'environ 160 de diamètre. Merci norma, on en reparlera alors !

Bonjour, j'ai un peu peur que ce que je cherche n'existe pas, pour avoir cherché et rien trouvé déjà, mais peut-être que des experts des filetages sauront ici : j'ai un vieux maksutov chinois sans marque que TS vendait il y a 20 ans environ, en sortie de tube on dirait une bague SCT 2" normale, alors j'en ai acheté une pour fixer une caméra dessus, mais non... Le 2" normal fait 50.8mm, là c'est 51.1mm de diamètre extérieur (mâle), et le pas est de 1.0667 mm à ce que je peux mesurer, donc plus que le 0.75mm du SCT normal (edit: 0.75 est une erreur ici, c'est bien le filetage normal, 24 TPI). Ca a l'air complètement aléatoire comme ça, même en convertissant en pouces... Est-ce que quelqu'un a déjà vu ça et sait si on trouve des adaptateurs dans le commerce ? La bague d'origine a beaucoup de jeu latéral, j'aimerais la changer. Question bonus : au bout du tube qui est sur ce filetage, là où on met un oculaire 1.25", il y a un filetage mâle de 35mm avec un pas de 1mm, j'ai pas l'impression que ça existe dans l'astronomie habituellement non plus ? Je ne vois rien sur pierro-astro par exemple de cette taille... Merci d'avance !

Merci !! Ca va être super pour la photométrie, pour éviter de choisir une étoile variable comme étoile de référence !

Si jamais quelqu'un était motivé pour faire un catalogue d'étoiles variables, ça serait bien utile pour la photométrie Peut-être qu'on va devoir créer une page sur le wiki pour partager les catalogues des utilisateurs, comme pour les scripts des utilisateurs ?

Une solution alternative serait de mettre un écran tactile sur le raspberry pi, comme ça pas besoin d'un autre ordi pour quelque opération que ce soit. Le plus dur est de bricoler un boitier pour fixer le rpi et son radiateur, un disque dur et l'écran. C'est la solution que j'ai choisi.

L'outil montré utilise l'astrométrie, donc la position des étoiles, pas les objets du système solaire, qui bougent dans le ciel.

tu veux dire quoi par "impossible de nommer l'objet" ?

pour la voie lactée oui, pour la comète, si elle a une trajectoire rectiligne je ne vois pas pourquoi ça ne serait pas possible Si ça ne fonctionne pas, il faut probablement faire des réglages, voir la FAQ à ce sujet : Pourquoi l’alignement ne trouve-t-il pas d’étoiles dans mes images ?

Au niveau ISO et même du temps d'exposition. En général les flats sont courts alors si on fait un offset au plus court temps ça ne posera pas de problème, mais pour des flats faits avec des filtres à bande fine pour lesquels il faut plusieurs secondes, c'est une bonne chose à faire. On appelle ça des dark-flats maintenant au lieu des offsets dans siril, parce que les vrais offsets, faits au plus court temps d'exposition, servent normalement à calibrer les darks, chose qu'on ne fait plus avec les capteurs CMOS.

Oui, ça va plus vite, c'est marqué dans les nouveautés de la version et j'en profite pour encourager tout le monde à les lire, c'est très instructif.

Si tu utilises les scripts de siril, les offsets sont utilisés pour calibrer les flats, donc il faut que les flats et les offsets soient pris avec les mêmes paramètres, mais pour les darks c'est bien avec les mêmes paramètres que les lights. Et en fait dans le doute y'a même pas besoin de faire d'offsets, on peut juste indiquer le niveau médian dans siril comme expliqué dans ce tutoriel sur les offsets synthétiques.

En effet vu comme ça, ça ressemble plutôt à des reflets défocalisés. Je n'arrive pas à voir ça dans l'image que tu as partagé par contre. Je l'ai ouverte dans gimp et j'ai augmenté la luminosité et le contraste et j'ai trouvé ça en bas au milieu par contre : Il y a clairement un truc pas net dans une des images. Il y a probablement un problème de flat aussi vu les grandes tâches mentionnées par Batbihirulau.

Bonjour, je ne vois pas de corrélation entre les zones oranges et les étoiles, pour moi c'est juste un fond de ciel trop coloré, et donc du bruit avec une trop grande saturation de couleurs. L'outil de saturation des couleurs permet de faire l'inverse, préserver le fond pas trop coloré quand on ajoute la couleur, là il faudrait en mettre moins dans le fond et garder les parties lumineuses colorées. Je ne vois qu'une façon de faire ça simplement : ne pas étirer autant l'histogramme des images R, G, B, ou leur donner un fond de ciel moins lumineux au moins.

Bonjour, pour ceux qui ne l'ont pas encore lu et qui voudraient en savoir plus sur ce sujet, il y a le tutoriel de composition RVB qui est un bon point de départ. Mais il ne répond pas à ces questions en effet. 1) je ne m'étais jamais posé la question, je suppose que si on le fait sur la L aussi ça permettra d'avoir une meilleure relation entre luminosité et chromatisme, mais ça ne me parait pas obligatoire. 2) utiliser la luminance sans avoir ajouté d'image de luminance n'a aucun effet. Mais oui l'alignement sur une étoile fonctionne comme ça, peu importe la couche choisie. 3) la résolution astrométrique doit être faite sur une image linéaire, avant étirage de l'histogramme donc. Si ça ne fonctionne pas et que les paramètres de taille de pixel et focale sont assez proches de la réalité, merci de partager une image pour que l'on vérifie ce qui se passe. 4) suppression du bruit vert ? normalement c'est inutile, mais des fois ça enlève une dominante verte restante, ça ne coûte pas grand chose d'essayer. Bonne chance !

La commande n'est pas la bonne, c'est soit seulement le chemin complet soit ./le_nom_du_fichier.appimage à partir du répertoire.

Tu as l'air d'oublier que j'ai un système 32 bits...

On ne distribue pas de version 32 bits mais on en développe Il faut juste le compiler soi-même.

Siril peut faire une registration sur des images de taille différente, mais pas l'empilement. Pour une composition RGB ça ira donc.

Quelle est l'erreur ?

Un raspberry pi c'est quand même un peu plus qu'un boulier Mais si on a de grosses images en couleurs, il vaut mieux avoir beaucoup de boules (= disque SSD pour le traitement et beaucoup de RAM).

Bonjour, je suppose que c'est arrivé plus d'une fois, et c'est pas forcément simple de trouver de quoi réparer ça, alors voici une petite description de l'aventure. La pièce qui pose problème est le support de connecteur des moteurs de suivi de l'EQ5, qu'on trouve dans les kits skywatcher et probablement d'autres. Le circuit est assez fin et comporte un connecteur RJ11 et est fixé par deux vis à la structure du moteur. Si on se prend les pieds dans les fils ou qu'on tape dessus sans faire exprès, ça casse facilement, comme on voit ici : Je mets la référence pour google : FZ06.PCB 98.03.23. C'est pas dur à réparer à condition d'avoir les pièces... Le circuit imprimé ou l'assemblage sont introuvables seuls. Le connecteur est facilement trouvable, par exemple sur reichelt sous le nom Fiche intégrée modulaire 6/4. Il y a la place pour 6 contacts mais il n'y en a que 4 utilisés, comme pour le RJ11. Le problème avec ce genre de connecteur est qu'il a deux rangées de pattes ; elles sont bien au pas standard 2.54 mais les rangées sont décalées d'un demi-pas, donc on ne peut pas mettre le connecteur sur les cartes habituelles... Heureusement d'autres connecteurs utilisent ce décalage, les ports série par exemple. J'ai trouvé un break-out board DB9 (un circuit imprimé qui peut recevoir ces connecteurs) en Angleterre ici, le vendeur a été sympa et m'en a envoyé plusieurs, donc si vous en voulez dites-moi. Et après un peu d'adaptation pour pouvoir remettre les deux vis et après avoir remis le connecteur et le câble au bon endroit, on obtient ça : Oui j'aurais pu mettre le connecteur de l'autre coté de la carte, mais ça passe juste et je pense que ça sera plus protégé comme ça. Voilà c'est tout, pourvu que ça tienne...

Ce que je voulais dire avec mon histoire de repisse, c'est que les capteurs sont sensibles à l'infrarouge souvent, et que pour les capteurs couleur, donc avec des filtres devant les photosites, l'infrarouge passe généralement à travers les 3 filtres. Le résultat c'est que sans filtre L c'est comme si on ajoutait du signal gris dans l'image, ce qui diminue le contraste des couleurs, et qui rend la tâche plus difficile à l'opération de dématriçage pour retrouver les couleurs aussi. Je ne trouve pas la courbe de réponse de la QHY10L, mais pour une ZWO 533 par exemple ça donne ce genre de truc : Pour trouver le bon réglage de matrice dans siril, le plus simple sera de prendre une photo de jour. Si le logiciel de capture est à jour ce n'est normalement pas la peine de le changer, mais pour des photos de 2015 ça vaut le coup de faire des essais. Le problème de points noirs avec l'A7S est peut-être dû à la différence de température du capteur entre les darks et les lights. Pour une CCD ça vaudrait le coup d'activer l'optimisation des darks, qui remet les darks au bon niveau, mais avec l'A7S je ne suis pas sûr que ça fonctionne.

Aucune idée, je ne me suis pas renseigné sur le sujet depuis 20 ans environ... Et j'ai eu des cours à la fac aussi. Le C++ te servira probablement plus, c'est plus moderne dans le sens où au moins c'est un langage orienté objet, ce qu'on retrouve dans tous les langages récents. Le C c'est souvent uniquement utilisé pour faire du code de bas niveau genre noyau, drivers, embarqué, c'est performant en exécution mais souvent le C++ l'est au moins autant, c'est pas rapide à programmer comme des langages plus récents comme python ou C#.

Oui, ça a été dit : let's encrypt a changé sa façon de signer les certificats des sites il y a quelques mois, probablement que ça ne plait pas aux vieilles versions de windows/navigateur/antivirus.

Bonjour, il faut bien vérifier qu'il n'y a pas d'images autres que les images d'entrée dans les répertoires sources, sinon elles seront prises pour le traitement avec les scripts. Je ne comprends à quel stade l'empilement pose problème si les résultats de chaque filtre sont bien obtenus.