Aller au contenu

Messages recommandés

Posté (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.

ALS logo 2.png

Modifié par Nikooo34
  • J'aime 1
Posté

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é.

nodark.png

1dark.png

1Master.png

  • J'aime 1
Posté

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 ?

Posté

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'

Posté

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.

 

Posté

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 ?

Posté

(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

 

Posté

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

 

Posté

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

Posté

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}"
                                                                                    ^

 

Posté

Bo,, j'ai installé anaconda, refait toute la démarche d'installation d'ALS et tout semble fonctionner maintenant.

  • J'aime 1
Posté

Peut-être faut-il conseiller à ceux qui ont le même souci que le mien de suivre cette procédure qui consiste à installer Anaconda.

Posté
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 !

 

 

Posté

@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 :

 

image.thumb.png.73e9a4ce8508ffc2eba8746056ffbf53.png

  • Merci / Quelle qualité! 3
Posté
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

Posté (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é par deufrai
Posté
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

Posté

De rien :) .

Oui je pense que l'option dark reste intéressante (et pas seulement car je l'ai codée :D ). 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

  • J'aime 1
Posté (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é par deufrai
Posté
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 :)

Posté

Donc, vraie question pour tous : il serait souhaitable d'avoir les 2 pre-traitements ? Suppression des pixels vraiment chauds + soustraction de dark ?

Posté

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.

 

Posté

Huuum, je m'aperçois que je me suis mal exprimé :p .

 

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

Posté

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

  • En ligne récemment   0 membre est en ligne

    • Aucun utilisateur enregistré regarde cette page.
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.