euldulle

C'est une question d'ordre de grandeur. On peut prendre quelques hypothèses simples et faire des calculs simples et on aboutira sans doute à la conclusion que l'impact négatif sur la viabilité de la biosphère de 10 Fukushima par an n'atteint toujours pas le millionième de ce que font à cette biosphère les émissions de carbone (chiffres pifométriques donnés à titre illustratifs, juste pour expliquer le raisonnement).

Le traitement est un peu violent quand même, non ?

Ouch ! 't1 ça chôme pas Respect !

Le résultat est superbe. Quasi parfait... Si tu trouves le moyen de faire disparaître le liséré parasite à gauche de jupiter, j'enlève le quasi

c'est le pilote indi-eqmod qui doit gérer ça. Regarder les options dans l'onglet "alignement" du pilote, accessible depuis le panneau de contrôle indi, lui-même accessible dans l'onglet "telescope" de cartes du ciel.

Faut pas tout confondre : les systèmes de positionnement par satellite (GNSS = GPS ou GALILEO ou GLONASS ou BEIDOU) c'est des systèmes passifs, seul le récepteur sait où il se trouve, les satellites des différentes constellations utilisées n'ont aucune idée de qui utilisent les signaux qu'ils émettent pour se positionner. Donc non, ces satellites-là ne savent pas où est qui, ni s'il y a de la place pour se garer entre 2 voitures. Cette information-là elle ne peut être connue que si un autre système au sol collecte les informations des différents récepteurs et les corrèle pour en déduire les positions relatives de 2 véhicules. Typiquement, quasiment tous les smartphones du marché collectent et transfèrent ça plus ou moins à l'insu de leurs propriétaires en permanence vers des agrégateurs de données qui en font ce qu'ils veulent. Donc les 2 ensembles, (récepteurs GNSS des smartphones + les bigs brothers de la data), forment une solution technologique permettant de savoir ça en direct. Mais c'est pas le satellite qui sait, c'est les bigs brothers. Ça c'est pour une solution valable globalement partout. Une autre solution où là c'est le satellite (ou plutôt son opérateur, généralement une TLA) qui obtient l'information, ce serait des satellites espions qui observent dans le domaine optique, mais là on est dans le domaine du renseignement, militaire ou assimilé, je doute que ces gens-là se soucient de la distance entre les voitures et le trottoir, sauf si c'est la voiture de Jason Bourne. Et c'est limité spatialement, tributaire d'un satellite disponible sur la zone visée et de la couverture nuageuse.

Les sources sont indépendantes de la platerforme. Par contre si tu veux compiler pour arm sur amd, c'est un peu plus velu que compiler directement sur arm.

Ça confirme que le capteur a sans doute morflé.... pfff. Dégouté. Pas par la "qualité" du défiltrage (je fais partie des gens qui ont 4 pieds, donc je pourrais très bien massacrer le travail dans ce genre-là) mais par le culot du mec qui ose revendre ça sans prévenir. Bref. Pour les solutions, je pense que tu te doutes qu'il n'y aura pas de miracle, tous les signaux faibles dans les zones abîmées vont être perdus. Ça se voit sur la zone la plus altérée, le fond de ciel a disparu, dissous dans le signal "noir". Peut-être une stratégie cosmétique pourrait être d'extraire le fond de ciel sur le reste de l'image et de le "reporter" sur cette zone. C'est peut-être un truc à tester, si des experts des traitements peuvent détailler les étapes concrètement...

Ça ressemble effectivement à qq chose comme un spectro :

ah bin là vu le dark, c'est pas un point chaud c'est une fuite de lumière comac quelque part. Tu as fait le dark vraiment dans le noir ou juste avec le bouchon d'objectif ? edit: ou un défiltrage fait au pied de biche peut-être.

apparemment il n'y a que le câble qui est "EQMOD", il utilise GSS. J'avais pensé à une possible situation où GSS considère que le scope est hors limite donc refuserait de bouger, mais ça n'explique pas pourquoi il ferait quand même le pointage. Bizarre. La première étape est de tester avec la raquette, pour être sûr que c'est pas la monture mais le pilote qui bégaie.

Attention, c'est un phénomène inévitable : il n'y a pas de mécanique parfaite ; donc ça cause un souci si la mécanique du PO n'est pas capable d'assurer une mise au point dans de bonnes conditions. Ça n'empêche pas qu'une excellente mécanique souffrira aussi du défaut mais il sera sans impact parce que d'une amplitude minime. Donc ça doit pas être a priori rédhibitoire, il faut juste bien choisir

Ça dépend du contexte mais a priori c'est le basculement du tube du porte-oculaire au moment du changement de direction, plus ou moins important selon le design et la qualité de la mécanique. Ça fait basculer l'oculaire par rapport à l'axe optique, donc ça décale l'image. Peut être particulièrement gênant pour faire une màp fine puisqu'on va faire des allers-retours autour de la meilleure position, donc beaucoup de changement de directions. En visuel, pas dramatique, en imagerie, ça peut être vraiment gênant dans des setups à longue focale.

Je connais pas grand chose en spectro, mais pour faire de la spectro il faut du signal, j'ai des doutes quant à la possibilité pour un amateur de faire de la spectro sur des nébuleuse étendues. Mais il faut consulter des spécialistes pour être sûr. Si c'est possible, les meilleures candidats sont je pense les nébuleuses planétaires. Contacter Christian Buil. http://www.astrosurf.com/buil/index.html christian.buil chez wanadoo.fr, et peut-être sur les forums en face chez astrosurf.

À mon avis sur une brute, aucune chance de distinguer si un halo de cette nature est présent ou pas. EDIT: bon bin autant pour moi, après histogramme, on le voit.

Ooops , exact. Dans ce cas, la solution lien symbolique peut quand même régler le problème (je sais pas comment fonctionne appimage).

Solution quick and dirty (ça crée /usr/bin/gnuplot comme lien symbolique vers /usr/local/bin/gnuplot, donc si le système trouve siril dans /usr/bin, il y trouvera aussi gnuplot) : sudo ln -s /usr/local/bin/gnuplot /usr/bin La solution plus propre c'est d'ajouter /usr/local/bin dans le PATH : pour la session en cours : export PATH=$PATH:/usr/local/bin (ça met dans la variable $PATH ce qu'il y a déjà dans $PATH et ça y ajoute /usr/local/bin) mais ce sera perdu à la fin de la session. Et pour régler définitivement, on met cette même commande soit dans ton home $HOME/.bash_profile, soit globalement dans /etc/profile (sous sudo dans ce cas-là). Il y a sans doute déjà une commande de ce style dans l'un ou l'autre de ces fichiers, pas la peine d'en rajouter une, tu ajouts simplement :/usr/local/bin/ à la fine de la commande existante.

@Colmic grillé au cosmique

C'est des cosmiques.

which gnuplot doit retourner le chemin où gnuplot se trouve. which siril idem pour siril. En fonction des sorties des commandes, on devrait pouvoir suggérer une solution.

J'ai jeté un oeil. La raison pour laquelle c'est pas simple, c'est que tu dois traiter différemment les cas où : 1. tu enregistres un fit que siril a modifié ; ça c'est le cas simple. 2. tu enregistres un fit après avoir ouvert un png ou autre ; là il faut créer le header 3. tu enregistres un fit qui est par exemple un empilement de fits avec chacun son header : là à l'évidence tout garder n'a aucun sens, à supposer que ce soit même possible. Et ça c'est vrai dans tous les cas où tu as plusieurs fichiers en entrée, et typiquement au prétraitement ; tu as 1 light, n offsets, ndarks, n flats, chacun avec son header. Dans ta tête, tu sais parfaitement ce que tu veux garder dans ce cas-là ; mais traduire cette intention dans le code n'est pas trivial.

Je vais voir, juste pour voir si je peux voir. Si je vois que je peux voir, je followup sur le lien de Vinvin ?

Ok, si siril est l'"utilisateur" final, mais il peut n'être qu'un maillon d'une chaîne de traitement/stockage/archivage/j'en passe et des meilleures. En tant que tel, on pourrait vouloir qu'il ne jette rien de ce qu'on lui donne en entrée, pas même ce qui lui est inutile. Genre "si je comprends pas, je recrache tel quel en sortie" ; pour le "primary header", ça ne me semble pas si lourd, mais bon les conseilleurs ne sont pas les codeurs

C'est parce qu'une photo c'est une image fixe et une vidéo c'est une succession d'images (Lapalisse, au tableau !). Donc à la base, il y a beaucoup plus d'informations dans la vidéo que dans chacune des images. C'est ton cerveau qui construit la différence de perception en intégrant tous les détails qui apparaissent fugiftivement dans les images successives de la video ou de la vue en live, détails qui sont (majoritairement) absents de chacune des images fixes extraites de la vidéo. C'est ce qu'a dit @tyler plus haut : Donc il faut absolument que tu abandonnes l'objectif d'extraire d'une vidéo une image qui te paraîtra aussi nette que la vidéo ou le flux live, parce que c'est impossible (sauf si t'as plus d'atmosphère ). Règle ton setup pas à pas en éliminant toutes les causes possibles de dégradation (map, flexion, bougé), mais pour faire ça, compare des vidéos avec des vidéos et des images avec des images, pas des images fixes et une vidéo.

Faut se méfier des titres, et d'où ils viennent. Ça sort de chez blogauto (msn est juste l'aggrégateur). Allez faire un tour sur la page d'accueil ça situe bien le biotope de la source. L'étude citée dans l'article de blogauto est titrée "Climate consequences of hydrogen emissions", elle sort de EDF, qui est pas notre edf mais l'Environmental Defense Fund, une ONG qui a l'air crédible, si on en croit les sources de financements affichés. L'étude en question est là : https://acp.copernicus.org/articles/22/9349/2022/ C'est dense, pas lu en détail, mais comme d'hab', il y a un très grand écart entre le titre racoleur de blogauto et la conclusion de l'étude en question. L"étude remet l'église au milieu du village par rapport à l'enthousiasme "hydrogéniste" en évaluant les forçages négatifs liés au cycle hydrogène, dont personne ne doute de l'existence. Mais c'est le genre d'étude sur lesquels les fossiliens se jettent pour distiller (ou plutôt asperger) du doute sur toutes les solutions alternatives. Personnellement, ce que j'en retiens, c'est une led rouge/orange sur la sincérité de ce qui sort de blogauto (ce qui ne m'empêche pas d'être très sceptique sur le potentiel de la filière hydrogène pour faire quoi que ce soit de significativement positif pour le climat). Ci-dessous la traduction google de l'article original de EDF (l'article qui présente l'étude, pas celle de l'étude elle-même) :