AlSvartr

Hello Christian Merci pour ton retour, qui semble indiquer que c'est mort: dans mon cas j'ai tellement de cibles que ça veut dire creer des dizaines voir centaines de filtres sur le long terme... donc en gros c'est infaisable. Donc retour probable à Genika avec l'ASI290. En effet il suffirait peut-être de le suggérer à Torsten, ça doit pas être très long à implémenter. On peut écrire un e-mail commun si tu veux. a+ Simon

en effet les caractères hindi ne sont pas pris en charge sur astrosurf (j’ai essayé ) c’est rigolo ces posts qui partent en cacahuète systématiquement lorsque ça démarre pas en français.

Salut, Suite à mes déboires avec un SSD externe m'ayant "perdu" 400 Go de données, je me pose la question de trouver un ou plusieurs HDD pour stockage...et pourquoi pas traitement. Bien sûr ce qui suit ne concerne pas la phase d'acquisition! Mon raisonnement est le suivant: 1) Un HDD externe de base coute (suivant sa capacité, la marque) 5x à 10x moins cher au byte qu'un SSD 2) Avec la production de .ser ayant des tailles de parfois plusieurs dizaines de Go, la limite en TBW pour les SSD peut-être atteinte assez rapidement suivant le modèle, la marque,...Dans ce cas la durée de vie du SSD peut être plus faible que celle du HDD 3) Indépendemment de la durée de vie du SSD, le risque de perte de donnée augmente lorsqu'on approche la limite annoncée en TBW, et cela se fait sans signes avant-coureurs Maintenant une question se pose: comment les vitesses de lecture et écriture affectent un traitement avec Autostakkert? Bien sûr un HDD est nettement moins rapide qu'un SSD, mais une fois la lecture du .ser faite et stockée dans la RAM, et si celle-ci est suffisante (32 voire 64 Go), dans quelle mesure cela est-il vraiment un problème? C'est peut-être une question débile, mais comme je ne sais pas comment AS3! utilise la RAM et les accès au HDD/SDD, je prfère la poser Bonne journée, Simon

En Suisse on a même 4 langues nationales: français, italien, (suisse-) allemand et romanche.

why not? C’est molto funny di avere un poste multi-lingue Bravo x l’acquisto di questo bello VMC260 !

Sur les HDD c'est plus souvent la mécanique de lecture qui plante : https://www.techbuyer.com/uk/blog/what-is-the-click-of-death J'ai eu le coup avec un HDD que j'avais pris à St Véran, résultat 750 Go de ser lunaire perdus. Pour la sauvegarde, de toute façon soit c'est du cloud (mais bonjour le prix pour sauver des To de données) soit un NAS avec par exemple une redondance en SHR ou SHR2 suivant les volumes et le nombre de baies dispos. Bon si tout le NAS grille suite à une surtension, c'est quand même mort... P.S. Ca n'a pas grand chose à voir avec le post initial, mais pour ceussent que ça intéresse, Synology a mis en ligne un petit calculateur de capacitéàs de stockage en fonction des modes RAID, des volumes etc... https://www.synology.com/en-au/support/RAID_calculator

Lorsque ça m’est arrivé cet été j’ai perdu 90% des acquisitions d’une nuit. Il y a avait deux répertoires qui ont simplement disparus. J’ai pu récupérer le premier (il y a des softs pour cela) mais pas le deuxième. Apparemment c’est lié à des problèmes d’adressage. Donc clairement pour des SSD d’acquisition utilisés intensivement faut pas attendre 5 ans pour les changer. D’après ce que j’ai pu lire Il y a d’autres facteurs qui peuvent « fatiguer » les SSD, par exemple la chaleur de stockage et fonctionnement. Pour du solaire ça vaut la peine de le mettre à l’ombre par exemple.

En effet, c’est pour ça qu’il faut que je refasse l’expérience avec un .ser bien plus lourd, histoire de remplir la RAM au max et de voir ce qui se passe.

Hello, Je fais remonter ce post car j'ai pu faire quelques tests de comparaison de vitesse d'execution d'autostakkert 4 sur un SSD et sur un HDD. Le résultat est intéressant: Sur un ser lunaire (donc pleine trame) de 21 Go (IMX178), la différence de durée de traitement est de moins de 3% (APsize: 72, pas d'improved tracking ou de double stack reference). Le PC a 64 Go de RAM. En fait les temps de run sont strictement égaux à partir de l'Alignment, ce qui veut probablement dire que tout est stocké dans la RAM à partir de cette étape. La différence vient donc des 3 premières étapes, donnant une légère avance au SSD. Il faut que je refasse le test avec un ser dont la taille est proche de la mémoire vive. Simon

J’ai du mal à voir les mouvements dans la grande tache rouge, le bruit résiduel peut jouer des tours. Mais les mouvements latéraux des bandes sont parfaitement évidents, c’est très impressionnant, bravo !

https://www.cloudynights.com/topic/387046-1967-celestron-16-inch-sct/

Oui c’est cela. Je ne l’ai pas encore essayé mais l’auteur en parle dans un vieux tuto basé sur AS4 alors encore en gestation.

As tu cliqué sur la petite coche à côté du logo de Jupiter sur la fenêtre principale ?

Merci pour ces précisions !!!

doublon.

Merci pour l’info. Ce sursaut n’apparaît pas encore sur http://www.aerith.net/comet/catalog/0012P/2024.html , mais d’après ce que je peux interpreter c’est plutôt un sursaut de 2 magnitudes non? Ce qui est intéressant c’est qu’après le premier sursaut la magnitude n’est pas retombée, donc si on suit cette logique pour ce deuxième saut la comète pourrait atteindre une magnitude autour de 2 ou 3 au printemps 2024 ?

Ah il fallait aller la chercher celle-là, un beau challenge parfaitement réussi! On a une idée de la taille du noyau ?

Je viens de faire le test sur un .ser lunaire, le gain en temps reste excellent . * .ser de 27 Go * Windows 10 * 64 Go RAM * SSD *AP size=72 AS3 -> un peu plus de 3 minutes AS4-> 1 minute !!! A priori rien à signaler en terme des résultats qui semblent identiques au premier abord.

Très joli résultat: résolution, traitement nickel,… bravo!

C’est étrange la disparition de la spire en haut à droite, ça ne pourrait pas venir du flat ?

Ahaaaa super !!! Je vais tester cette beta, d’après ce que j’avais compris la v4 allait plus performante pour les gros .ser. Donc Mes .ser lunaires de 56 Go vont être plus rapide à traiter, c’est top!

Jolie planche cher Alain et oui la météo de cet automne est pour le moins ignoblissime. Nos instruments dorment d’un repos mérité après un bel été et les plantes et les nappes phréatiques sont contentes, c’est le principal. Vive la pluie !

M94 est une galaxie très difficile à gérer au traitement, mais qu’elle est belle! Tu mets ici parfaitement en valeur ses portions les plus ténues, et à côté de cela le fourmillement de galaxies plusieurs dizaines de fois plus lointaines qui parsème(nt)* le fond de ciel ! Donc bref: bravo! * j’hésite à accorder parsème avec fourmillement et galaxies 😂

il me semble bien que tu as raison. Sauf erreur il avait été installé par le regretté Manuel Forestini, qui était quelques années auparavant moniteur aux stages astro (en Belgique) que je fréquentais quand j’étais ado.

Tu peux y mettre un bel instrument solaire, qui par définition n’ira jamais taper dans la fourche.