Aller au contenu

Messages recommandés

Posté

Bonjour, et merci pour ce super soft! :)

J'ai un PC plutôt correct (i7-4800MQ, Nvidia Quadro K1100M et 8 Go de ram, pas de SSD par contre) et je rencontre très fréquemment d'énormes ralentissements quand Siril tourne, le PC étant parfois inutilisable pendant ce temps. Et lorsque je traite un grand nombre d'images, disons à partir de 200 ou 300, ca a tendance à faire freezer l'ordinateur, avec redémarrage forcé à la clé, souvent après plusieurs heures de calcul. J'utilise typiquement le script traitement APN+correction cosmétique.

 

Merci!

Posté

Bonjour, il faut probablement régler la mémoire allouée à siril dans les préférences à moins de 90% de la quantité libre, si c'est bien la 0.9.12. Si ça freeze c'est que ça dépasse ce qui était disponible, donc soit que c'est réglé trop haut, soit que quelque chose d'autre a pris de la mémoire depuis le début du traitement, ce qui est souvent le cas avec windows.

 

La carte graphique ne sert à rien à siril ni à la plupart des logiciels.

Posté
16 minutes ago, vinvin said:

Bonjour, il faut probablement régler la mémoire allouée à siril dans les préférences à moins de 90% de la quantité libre, si c'est bien la 0.9.12. Si ça freeze c'est que ça dépasse ce qui était disponible, donc soit que c'est réglé trop haut, soit que quelque chose d'autre a pris de la mémoire depuis le début du traitement, ce qui est souvent le cas avec windows.

 

La carte graphique ne sert à rien à siril ni à la plupart des logiciels.

 

Merci, j'essaye en mettant par exemple 60%.

Question complémentaire, mon traitement plante à l'empilement mais j'ai tout de même le fichier r_pp_cc_pp_brute. Est-ce que c'est bien cette séquence où tous les DOF ont été pris en compte? Puis-je directement aller à l'onglet empilement avec, pour éviter de relancer le script depuis le début? Merci!

Posté

L'interface graphique n'a pas d'influence sur les scripts. Pour ne pas tout refaire, il faut enlever, ou mettre en commentaire avec un # devant la ligne, les opérations qu'on ne veut pas effectuer avec le script.

En général les séquences pp_ sont celles pré-traitées DOF oui, et celles r_pp_ sont celles qui ont été alignées ensuite. C'est inhabituel d'avoir deux fois pp, ce qui voudrait dire qu'il y a eu deux pré-traitements sur les mêmes fichiers.

  • Merci / Quelle qualité! 1
Posté (modifié)
Il y a 3 heures, vinvin a dit :

C'est inhabituel d'avoir deux fois pp, ce qui voudrait dire qu'il y a eu deux pré-traitements sur les mêmes fichiers.

Non, c'est une particularité du script avec correction cosmétique supplémentaire.

J'ai envie de les virer des scripts de base eux d'ailleurs :).

Modifié par lock042
Posté
Il y a 8 heures, lock042 a dit :

J'ai envie de les virer des scripts de base eux d'ailleurs :).

 

JOR

Posté
il y a 30 minutes, lock042 a dit :

En français ????

 

T'as jamais entendu cette expression "Jor" ? :D 

Posté
il y a 22 minutes, Colmic a dit :

T'as jamais entendu cette expression "Jor" ? :D 

non 😕

 

Du coup tu voulais dire quoi ? :)

Posté

Ben virer les deux scripts avec correction cosmétique. Ca génère plus de soucis qu'autre chose. 

La correction cosmétique c'est pas dur à faire en manuel et ça permet de mieux voir. 

Posté
il y a 29 minutes, lock042 a dit :

Ben virer les deux scripts avec correction cosmétique. Ca génère plus de soucis qu'autre chose. 

 

Non mais j'avais compris :)

JOR, c'était de l'humour. "Genre, vas-y te gêne pas" :D

Mais si effectivement ça génère plus de soucis, faut les virer.

D'ailleurs est-ce que la différence avec et sans correction cosmétique est si évidente à voir ?

Tasson m'en fous moi, je suis en caméra maintenant, j'utilise plus les scripts :)

Posté
il y a une heure, Colmic a dit :

D'ailleurs est-ce que la différence avec et sans correction cosmétique est si évidente à voir ?

Jamais fait de comparatifs très précis, mais je pense que en auto ca a tendance a faire plus de mal que de bien.

 

  • 2 semaines plus tard...
Posté
On 5/7/2020 at 3:52 PM, Orion38 said:

Bonjour, et merci pour ce super soft! :)

J'ai un PC plutôt correct (i7-4800MQ, Nvidia Quadro K1100M et 8 Go de ram, pas de SSD par contre) et je rencontre très fréquemment d'énormes ralentissements quand Siril tourne, le PC étant parfois inutilisable pendant ce temps. Et lorsque je traite un grand nombre d'images, disons à partir de 200 ou 300, ca a tendance à faire freezer l'ordinateur, avec redémarrage forcé à la clé, souvent après plusieurs heures de calcul. J'utilise typiquement le script traitement APN+correction cosmétique.

 

Merci!

 

On 5/7/2020 at 4:52 PM, Orion38 said:

 

Merci, j'essaye en mettant par exemple 60%.

 

Bonjour, je m'autocite pour remettre dans le contexte.

J'ai testé en baissant l'utilisation de ressources à 50% et pourtant, j'ai toujours ce problème de lenteurs et de crash occasionnel du PC... 

Ce coup ci, avec un traitement comprenant environ 300 images...

 

Posté

Il nous faudrait plus d'infos pour comprendre : quel système d'exploitation, quelle version, surveiller les ressources du système genre mémoire libre et cores utilisés, le journal de siril...

Posté
7 minutes ago, vinvin said:

Il nous faudrait plus d'infos pour comprendre : quel système d'exploitation, quelle version, surveiller les ressources du système genre mémoire libre et cores utilisés, le journal de siril...

 

C'est sur un W10, avec Siril 0.9.11. J'avais sélectionné 6 coeurs sur le 8 que possède mon processeur et limité le ratio de RAM à 0.5.

Pour ce qui est du journal, je peux récupérer ça quelque part après avoir fermé Siril? Sinon, je vous le fournirai au prochain traitement problématique :)

Merci!

Posté
il y a 32 minutes, Orion38 a dit :

C'est sur un W10, avec Siril 0.9.11.

Ah oui donc déja il faut utiliser la dernière version stable. Car la 0.9.11 a un bug connu a ce niveau.

Posté
4 minutes ago, lock042 said:

Ah oui donc déja il faut utiliser la dernière version stable. Car la 0.9.11 a un bug connu a ce niveau.

 

Ah zut, je pense que ça me proposerait une MàJ ou quelque chose comme ça et je n'ai pas pensé à le faire manuellement. J'essaie! Merci.

Posté (modifié)

hello,

 

petit bug à signale dans la commande Stackall, que j'appelle dans un script par :

 

stackall rej 3 3 -norm=addscale -filter-fwhm=70%

 

elle enregistre toujours la même image pour tous les SER, donc au lieu d'avoir à la fin 20 images empilées pour 20 SER, il n'y en a qu'une --> 95 % perdues, c'est gênant

 

ci-dessous la sortie console de SIRIL qui le montre (limitée aux deux premiers SER) : on voit que l'image enregistrée a le même nom alors qu'on a bien chargé deux séquences SER différentes :

 

"

10:39:57: Exécution de la commande : stackall
10:39:57: Cherche les séquences dans le répertoire de travail...
10:39:57: Début de l'empilement des séquences trouvées...
10:39:57: Empile la séquence r_Capture 2020-05-21T23_49_53
10:39:57: Utilisation du filtre de FWHM (inférieure à 5.970550)

10:39:57: Traitement des images de la séquence avec une FWHM inférieure ou égale à 5.97055 (208)
10:39:57: Calcul de la normalisation...
10:39:57: Avec les limites actuelles de la mémoire et du thread (8), vous pouvez utiliser jusqu'à 8 thread(s) pour la normalisation de la séquence
10:40:12: Utilisation de 2869 Mo maximum pour l'empilement
10:40:12: Nous avons 4 blocs parallèles de taille 270 (+0) pour l'empilement.
10:40:12: Débute l'empilement...
10:40:42: Rejet des pixels dans le canal #0 : 0.181% - 0.751%
10:40:42: Intégration de 208 images :
10:40:42: Combinaison ............... moyenne
10:40:42: Normalisation ............. additive + mise à l'échelle
10:40:42: Rejet des pixels .......... Winsorized sigma clipping
10:40:42: Paramètres de rejet ....... bas=3.000 haut=3.000
10:40:42: Estimation du bruit : (canal : #0) : 20.827 (3.178e-04)
10:40:42: Fichier FITS enregistré : fichier r_Capture 2020-05-21T23_49_53_stacked.fit, 1 canal(aux), 1920x1080 pixels
10:40:42: Empile la séquence r_Capture 2020-05-21T23_54_58
10:40:42: Utilisation du filtre de FWHM (inférieure à 6.057640)

10:40:42: Traitement des images de la séquence avec une FWHM inférieure ou égale à 6.05764 (208)
10:40:42: Calcul de la normalisation...
10:40:42: Avec les limites actuelles de la mémoire et du thread (8), vous pouvez utiliser jusqu'à 8 thread(s) pour la normalisation de la séquence
10:40:55: Utilisation de 2884 Mo maximum pour l'empilement
10:40:55: Nous avons 4 blocs parallèles de taille 270 (+0) pour l'empilement.
10:40:55: Débute l'empilement...
10:41:29: Rejet des pixels dans le canal #0 : 0.161% - 1.100%
10:41:30: Intégration de 208 images :
10:41:30: Combinaison ............... moyenne
10:41:30: Normalisation ............. additive + mise à l'échelle
10:41:30: Rejet des pixels .......... Winsorized sigma clipping
10:41:30: Paramètres de rejet ....... bas=3.000 haut=3.000
10:41:30: Estimation du bruit : (canal : #0) : 23.687 (3.614e-04)
10:41:30: Fichier FITS enregistré : fichier r_Capture 2020-05-21T23_49_53_stacked.fit, 1 canal(aux), 1920x1080 pixels
10:41:30: Empile la séquence r_Capture 2020-05-22T00_00_04

"

 

merci,

😀

Modifié par Pulsar59
Posté

autre souci pour mise à jour (avec dernière version de Mysis64)

 

Moi@PCdePulsar MSYS ~
# git submodules update --init
git : 'submodules' n'est pas une commande git. Voir 'git --help'.

La commande la plus ressemblante est
        submodule

 

et plus tard (sans doute lié) :

 

Moi@PCdePulsar MSYS ~
# cd siril

Moi@PCdePulsar MSYS ~/siril
# make all install
make: *** Aucune règle pour fabriquer la cible « all ». Arrêt.

Moi@PCdePulsar MSYS ~/siril
# siril
bash: siril : commande introuvable

Moi@PCdePulsar MSYS ~/siril

 

 

merci

 

 

Posté

j'avais essayé, mais ...

 

"

Moi@PCdePulsar MINGW64 ~
$ git submodule update --init
fatal: ni ceci ni aucun de ses répertoires parents n'est un dépôt git : .git

Moi@PCdePulsar MINGW64 ~
$ cd siril

Moi@PCdePulsar MINGW64 ~/siril
$ make all install
make: *** Aucune règle pour fabriquer la cible « all ». Arrêt.

Moi@PCdePulsar MINGW64 ~/siril
$

 

"

Posté (modifié)

merci

 

il faudra rectifier le post d'Argonothe sur l'install Windows ☺️

 

mais je n'y arrive toujours pas (win 8.1), ca en devient pénible, alors que l'année dernière j'installais sans pb les versions de dev

 

Après avoir téléchargé et installé Mysis 64bits à jour, et exécuté ligne à ligne en désactivant Avast, sans erreur affichée,  les commandes :

pacman -Syu
pacman -S --needed base-devel mingw-w64-x86_64-toolchain mingw-w64-x86_64-cmake
pacman -S git automake
pacman -S mingw-w64-x86_64-fftw mingw-w64-x86_64-gsl
pacman -S mingw-w64-x86_64-cfitsio mingw-w64-x86_64-gtk3
pacman -S mingw-w64-x86_64-libconfig mingw-w64-x86_64-opencv
pacman -S mingw-w64-x86_64-libraw mingw-w64-x86_64-ffms2
pacman -S mingw-w64-x86_64-curl mingw-w64-x86_64-exiv2

 

Après ça, la commande git clone https://gitlab.com/free-astro/siril.git retourne ça,

 

Moi@PCdePulsar MINGW64 ~
$ git clone https://gitlab.com/free-astro/siril.git
bash: git : commande introuvable

 

 

merci

 

 

 

Modifié par Pulsar59
Posté

Bon, comme il n'y a pas moyen d'installer, j'ai trouvé sur le net un "build" tout fait

 

ca lance une version 0.99 avec le nouvel interface :

0.99.0
Ceci est une version de développement instable
modification 19d143cd

 

mais le bug stackall est toujours là.

Posté
il y a 26 minutes, Pulsar59 a dit :

mais le bug stackall est toujours là.

Il a été corrigé après.

 

Et ton erreur dit que tu n'as pas installer le logiciel git.

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