Nikooo34 Posté 13 avril 2020 Posté 13 avril 2020 (modifié) Salut a tous, mes compétences en matière de programmation ne me permettent malheureusement pas de vous aider, j'ai malgré tout réussi à récupérer le logo que je me suis amusé a triturer un peu... Je voulais savoir si ça vous plait. Modifié 13 avril 2020 par Nikooo34 1
Nikooo34 Posté 14 avril 2020 Posté 14 avril 2020 Bonsoir, je reviens vers vous après avoir réalisé quelques tests à partir des modif évoquées par Davy si avant: Masterdark et nombre d'étoiles Ca semble bien fonctionner meme si pour le nombre d'étoiles nous attendrons d'etre en situation réelle et d'echec de l'alignement pour etre sur. Pour le master Dark je vous mets une série de trois tests: La première sans dark, la deuxième avec un dark et la troisième avec un masterDark fait a partir d'une 50aine de Dark. Aucun autre paramètre n'a été modifié. 1
patdut Posté 14 avril 2020 Posté 14 avril 2020 Petit souci d'installation d'ALS: (venv) pat@Vega ~/Projects/als $ python3 setup.py develop Traceback (most recent call last): File "setup.py", line 16, in <module> from utils import compile_ui_and_rc File "/home/pat/Projects/als/utils/compile_ui_and_rc.py", line 8 src_folder_path: Path = Path(__file__).parent.parent / "src" Une idée ?
deufrai Posté 14 avril 2020 Posté 14 avril 2020 hello pourquoi invoquer python3 explicitement quand tu es dans ton venv ? Si tu as vu ça dans une doc, signale-le nous, c'est une coquille. Réessaye avec : $ python setup.py develop A tout'
patdut Posté 14 avril 2020 Posté 14 avril 2020 J'ai aussi essayé avec python tout court, sans succès. Je suis sur une distrib Mint 18.03 mais ce n'est semble-t-il pas le problème qui semble être un problème de synthaxe.
deufrai Posté 14 avril 2020 Posté 14 avril 2020 Etrange... Es-tu certain d'avoir copié / collé l'intégralité du message d'erreur ? Avant cette étape, l'installation des dépendances avec $ pip install -r requirements.txt n'a remonté aucune erreur ?
patdut Posté 14 avril 2020 Posté 14 avril 2020 (venv) pat@Vega ~/Projects/als $ python setup.py develop Traceback (most recent call last): File "setup.py", line 16, in <module> from utils import compile_ui_and_rc File "/home/pat/Projects/als/utils/compile_ui_and_rc.py", line 8 src_folder_path: Path = Path(__file__).parent.parent / "src" ^ SyntaxError: invalid syntax
deufrai Posté 14 avril 2020 Posté 14 avril 2020 OK, je vois C'est un problème lié aux type hints Quelle version de python as-tu dans ton venv ? $ python --version Je soupçonne une version inférieure à 3.5
patdut Posté 14 avril 2020 Posté 14 avril 2020 (venv) pat@Vega ~/Projects/als $ python --version Python 3.5.2
deufrai Posté 14 avril 2020 Posté 14 avril 2020 As-tu accès à une machine avec python 3.6 ? Sinon, tu peux remplacer les lignes 8 et 9 de ce fichier par src_folder_path = Path(__file__).parent.parent / "src" generated_src_path = src_folder_path / "generated" Mais tu auras sans doute d'autres problèmes de ce genre par la suite... Je vérifie de mon côté le niveau de version minimum obligatoire pour exécuter le code tel quel et ajouterai cette info à la documentation
patdut Posté 14 avril 2020 Posté 14 avril 2020 Je n'ai hélas pas accès à d'autre machine avec une version plus récente de python. Font chier chez python de modifier si fort les versions et de ne pas assurer la compatibilité ascendante. Problème suivant: (venv) pat@Vega ~/Projects/als $ python setup.py develop Traceback (most recent call last): File "setup.py", line 16, in <module> from utils import compile_ui_and_rc File "/home/pat/Projects/als/utils/compile_ui_and_rc.py", line 19 args = f"{ui_file} -o {target_file_path} --import-from={generated_src_path.stem}" ^
deufrai Posté 14 avril 2020 Posté 14 avril 2020 ici ce sont les F-string qui ne sont dispo que depuis python 3.6 Il semble qu'installer python 3.6 sur une Mint 18.3 soit assez facile avec un PPA https://www.linuxhelp.com/how-to-install-python-v-3-6-5-on-linux-mint-18-03
deufrai Posté 14 avril 2020 Posté 14 avril 2020 Ou mieux et moins risqué pour ton système : https://www.reddit.com/r/linuxmint/comments/7w5u7s/how_to_update_python3_to_python364_in_linux_mint/
patdut Posté 14 avril 2020 Posté 14 avril 2020 Bo,, j'ai installé anaconda, refait toute la démarche d'installation d'ALS et tout semble fonctionner maintenant. 1
patdut Posté 15 avril 2020 Posté 15 avril 2020 Peut-être faut-il conseiller à ceux qui ont le même souci que le mien de suivre cette procédure qui consiste à installer Anaconda.
Nikooo34 Posté 15 avril 2020 Posté 15 avril 2020 Je vous poste le petit lien vers le live AstroNhomme / ALBE d'hier soir. Nous avons testé ALS avec les deux modifications apportées par Davy et les concepteurs d'ALS. https://youtu.be/SXWVpFj_c1g
gehelem Posté 15 avril 2020 Auteur Posté 15 avril 2020 Il y a 12 heures, Nikooo34 a dit : Je vous poste le petit lien vers le live AstroNhomme / ALBE d'hier soir. Nous avons testé ALS avec les deux modifications apportées par Davy et les concepteurs d'ALS. https://youtu.be/SXWVpFj_c1g Super cette vidéo ! Merci !
deufrai Posté 17 avril 2020 Posté 17 avril 2020 @Nikooo34 Je suis sur une piste très prometteuse qui permet de supprimer les affreux pixels chauds sans obliger l'utilisateur à faire de darks à gauche, le résultat de la suppression : 3
boulabytes Posté 17 avril 2020 Posté 17 avril 2020 Il y a 9 heures, deufrai a dit : Je suis sur une piste très prometteuse qui permet de supprimer les affreux pixels chauds sans obliger l'utilisateur à faire de darks Salut, Ah oui ça l'air de vraiment bien fonctionner ! Bravo ! Davy
deufrai Posté 17 avril 2020 Posté 17 avril 2020 (modifié) il y a 3 minutes, boulabytes a dit : Salut, Ah oui ça l'air de vraiment bien fonctionner ! Bravo ! Davy Du coup, si vous voulez tester cette partie, c'est sur la branche https://github.com/gehelem/als/tree/feature/hot_pixel_remover Et désolé Davy, tu as peut-être bossé (vite et bien) pour rien sur cette soustraction de darks. Je suis preneur de vos retours de tests sur cette branche HotPixelRemover. Si c'est concluant, je pense qu'on finira pas se passer des darks. Ca simplifiera la vie des utilisateurs et des programmeurs En encore merci et bravo @boulabytes pour ta réactivité et la qualité du boulot. Même si je te fais faire bcp d'allez-retour. Comprends-nous, on cherche à avoir qqchose de très robuste + rapide et facile à utiliser. Modifié 17 avril 2020 par deufrai
gehelem Posté 17 avril 2020 Auteur Posté 17 avril 2020 il y a 4 minutes, deufrai a dit : Et désolé Davy, tu as peut-être bossé (vite et bien) pour rien sur cette soustraction de darks. Tututuuuut ! Moi la soustraction de dark je garde !! Merci encore @boulabytes
boulabytes Posté 17 avril 2020 Posté 17 avril 2020 De rien . Oui je pense que l'option dark reste intéressante (et pas seulement car je l'ai codée ). En fait, si on compare ça a un traitement standard (disons avec pix) le retrait de dark retire une grosse partie des pixels chauds, le reste est retiré avec une correction cosmétique. On enchaîne donc les deux process. Mais, utiliser un fichier de dark peut apporter une autre plus value. Disons que je fais 50 darks et que je les empile directement. En soustrayant le master a une image je retire les pixels chauds (mis en évidence par le dark) mais également le bias. Une correction cosmétique ne retirera pas le signal d'offset. Bon, cela dit, sur du live stacking c'est du peut-être du pinaillage 🤣 En tout les cas, le soft est vraiment bon, il donne de très bons résultats et nous comptons bien l'utiliser lors de soirées publiques . Davy 1
deufrai Posté 17 avril 2020 Posté 17 avril 2020 (modifié) il y a 2 minutes, boulabytes a dit : Mais, utiliser un fichier de dark peut apporter une autre plus value. Disons que je fais 50 darks et que je les empile directement. En soustrayant le master a une image je retire les pixels chauds (mis en évidence par le dark) mais également le bias. Une correction cosmétique ne retirera pas le signal d'offset. Bon, cela dit, sur du live stacking c'est du peut-être du pinaillage 🤣 Zaktement ! Le but reste quand-même et avant tout le live : efficacité + simplicité Pour la soustraction de dark : reste le problème de la dérive de la balance des couleurs (que vous avez notée lors de votre dernier live) et les "problèmes" d'adaptation en T° A approfondir... Modifié 17 avril 2020 par deufrai
boulabytes Posté 17 avril 2020 Posté 17 avril 2020 il y a 2 minutes, deufrai a dit : Le but reste quand-même et avant tout le live : efficacité + simplicité Oui, mais quand on commence à atteindre les limites du matériel sur un objet, ça peut faire la différence
deufrai Posté 17 avril 2020 Posté 17 avril 2020 Donc, vraie question pour tous : il serait souhaitable d'avoir les 2 pre-traitements ? Suppression des pixels vraiment chauds + soustraction de dark ?
boulabytes Posté 17 avril 2020 Posté 17 avril 2020 En fait, comme l'utilisation du dark est optionnelle, est-ce gênant ? Je veux dire, c'est comme le nombre de match pour l'alignement, dans 90% des cas 25 est un bon chiffre, mais sur certaines cibles on n'a pas assez d'étoiles sur l'image et dans ce cas pouvoir modifier l'option est un plus.
boulabytes Posté 17 avril 2020 Posté 17 avril 2020 Huuum, je m'aperçois que je me suis mal exprimé . Je ne suis pas en train de dire qu'il faut conserver coûte que coûte la soustraction des darks. Finalement, ce qui me semble intéressant c'est de déterminer si avoir les deux process peut s'avérer utile dans certains cas. Pour cela il faut être en mesure de tester les différentes configurations : retrait des pixels chauds par ta méthode seulement ; soustraction d'un master dark seulement ; utilisation des deux process combinés. S'il s'avère que les deux derniers tests n'apportent rien, je suis pour que l'on élimine le retrait des darks tout simplement. Je dis ça car sur des objets ténus ou des images obtenues avec des filtres à bande étroite, le rapport signal sur bruit est tellement défavorable que l'alignement échoue. Mais quand on fait un pré-traitement le gain est alors suffisant pour permettre l'alignement puis le stacking. Je pense qu'il serait dommage de se priver d'une telle option. Mais, encore une fois, si les tests montrent qu'une option (ou sa combinaison avec une autre) n'apporte rien de plus alors il faut la supprimer Voila, désolé si j'ai été mal compris, c'est pas toujours évident à l'écrit Davy
gehelem Posté 18 avril 2020 Auteur Posté 18 avril 2020 Moi j'ai pas d'argument béton, je voudrais juste donner une chance aux darks Je me voyais bien avec ma petite bibliothèque de masters à différentes températures / gains pour choisir lequel j'utiliserai ce soir Et avec une cadence pas trop élevée le temps de traitement on s'en fiche Sur les petites configs effectivement ça va ramer : et bin là on décoche et on fait autrement Tiens un argument : sur les petites CMOS qui sont truffées d'ampglow le dark est le seul moyen de s'en débarrasser, surtout avec des gros gains
deufrai Posté 18 avril 2020 Posté 18 avril 2020 Donc ampglow et narrowband à poses super longues sont des bons arguments, ANÉFÉ
Messages recommandés