Installation de la version de développement de Siril sous Windows10 ou W7 64 bit

[lock042]

Tu n'as pas la bonne version. C'est 0.99.1

[Stéphiou]

Par hasard il faudrait pas essayer à chaque fois de faire la maj de MSYS2 par un pacman -Syu suivi d'un pacman -Su avant de faire une maj de SIRIL dev ?

 

[Stéphiou]

Le 21/03/2020 à 10:01, m27trognondepomme a dit :

Pour ma part, la compilation 'Windows 10' de la master s'est passée correctement.

Trognon, du coup tu as installé la 0.99.1 ?

[m27trognondepomme]

oui mais je ne l'ai pas encore testée car je suis sur un bug de Sirilic suite à l'évolution sur le nombre d'image affichée dans l'arbre du projet.

J'ai un premier correctif , mais il faut que je mettes à plat la fonction de rafraichissement des infos.

[vinvin]

Stéphiou : c'est probablement utile oui pour avoir les dernières versions des bibliothèques partagées msys2 que siril utilise. -Syu ça suffit normalement.

[Stéphiou]

Bon ben pas moyen, SIRIL démarre en version 0.99 mais j'ai ça à la fin d'une tentative de maj :

 

[m27trognondepomme]

j'ai eu ce problème la semaine dernière (mais pas aujourd'hui )

as-tu bien fait :

git submodule update --init --recursive

 

Sinon j'avais contourné le  problème la semaine dernière en faisant ceci :

• ( cd deps/librtprocess/build ; make )
• make

[Stéphiou]

il y a 38 minutes, m27trognondepomme a dit :

git submodule update --init --recursive

oui j'avais lancé cette commande avec git submodule sync --recursive  comme mentionné par Cissou.

 

il y a 39 minutes, m27trognondepomme a dit :

• ( cd deps/librtprocess/build ; make )
• make

Je viens de faire, ds le répertoire SIRIL, ça ne change rien, j'attends de voir à la proch maj, sinon je ré-installe tout, no pb !

[vinvin]

Stéphiou, cette erreur vient du fait que librtprocess ne gère pas la target install (dans notre intégration), il faut faire make all install à la place, ou make d'abord et make install ensuite.

[m27trognondepomme]

Le 21/03/2020 à 09:28, lock042 a dit :

Pour toi, tu as une branche siril-cli a tester ;). Elle produit un deuxième binaire qui gère les lignes de commande sans démarrer de server X normalement.

 

Maintenant sans serveur X sur Linux (par exemple: via ssh), la commande "siril-cli -s monscript.ssf" fonctionne  correctement.

à la fin, j'ai quelques warnings mais sans conséquence : log.txt

 

Le seul problème rencontré était au sujet de la variable d'environnement LANG qui valait fr_FR.UTF-8. j'ai du la  mettre à zéro ( export LANG=  ) car Siril-cli semblait bloquer avec le point décimal.

[lock042]

Ah oui il faut LC_NUMERIC=C. Ça devrai être le cas. Faut vérifier ça. 

Pour les warnings on jetera un œil. 

[Stéphiou]

il y a 45 minutes, vinvin a dit :

il faut faire make all install à la place

alors là, chapeau ! ça a marché en 2-2 ! 👌

[Stéphiou]

est-ce que par hasard, il faudrait pas remplacer le make install par make all install ds cette ligne de commande : ./autogen.sh && make clean && make install

???

[lock042]

Il y a 1 heure, m27trognondepomme a dit :

Le seul problème rencontré était au sujet de la variable d'environnement LANG qui valait fr_FR.UTF-8. j'ai du la  mettre à zéro ( export LANG=  ) car Siril-cli semblait bloquer avec le point décimal.

Dans le main-cli tu as :

    g_setenv("LC_NUMERIC", "C", TRUE); // avoid possible bugs using french separator ","

Donc tu ne devrais pas avoir de problème.

Modifié 22 mars 2020 par lock042

[Cissou8]

Salut, 

j'ai eu le temps de faire des tests aujourd'hui sur la 0.99.1.

L'interface intégrée est vraiment impeccable, fini les fenêtres qui se baladent partout. J'ai juste les 2 boutons pour le menu de traitement d'image et des scripts qui se rescalent un peu trop quand le path du folder de travail est long, jusqu’à quasiment se faire oublier.

 

Mais sinon, c'est plus réactif partout. L'histogramme est devenu lisse et plus réactif. J'arrive presque à comprendre ce que je fais, c'est pour dire 😉!

L'outil d'extraction de fond du ciel aussi. Quand je fais des clics pour enlever ou supprimer des points, c'est instantané ou quasi instantané. Alors qu'avant je cliquais en salve, et ils apparaissaient./disparaissaient..après.

Au final, toutes les fenêtres qui ont été passées en liveview exécutent plus rapidement leur traitement.

 

Par contre, j'ai des soucis de performance (?) pendant le pre-processing. J'ai fait passer 2 scripts pour essayer (un avec 45 lights et un masterdark, et un plus complet avec 208 lights avec 20 biases/flats et un masterdark), le constat est le meme. C'est pareil voire un plus lent qu'avec v0.9.12. J'ai regardé les temps passés à chaque étape, il semblerait que ce soit à chaque fois qu'il faut lire tous les fichiers de la séquence.

Ci-dessous les temps pour celui avec le traitement complet. J'ai décomposé la commande stack en 2,la normalisation puis le stacking. Le stacking va bien 2 fois plus vite, mais le bénéfice se perd avec les autres étapes.

Au final, 0.9.12 est plus rapide de 2min sur une trentaine. C'est pas un drame hein, c'est juste que je pensais que ca devait aller plus vite. Apres, comme dit plus haut, mon ordi est pas une machine de guerre, j'ai 8G de RAM et je suis en SSD. Mais c'est peut-etre pas suffisant pour voir le bénéfice...ou alors je fais quelquechose de travers? Je peux partager les scripts et les logs pour les 2 versions si besoin.

 

En tout cas, merci pour tout ce travail, c'est juste énorme,

C.

[lock042]

Sur ma machine, cette version est au moins 2 fois plus rapide que la 0.9.12.

[m27trognondepomme]

Je confirme que sur ma machine vieillissante ( XEON W3550@3HGhz +12G RAM) sous W10, la version Float est moins rapide que la version 0.9.12.

Modifié 22 mars 2020 par m27trognondepomme

[lock042]

Sous windows ?

Car moi pour vous donner un exemple, l'execution d'un script qui me prenait 2min45 sous 0.9.12, prend 1min15 en version master (et 55sec dans une autre branche)

[m27trognondepomme]

Oui, sous windows 10.

La semaine dernière quand j'ai fait l'essai avec la branche float, mon script prenait environ 4min en 0.9.12 et sur la version float 5 min.

 

je viens de refaire sur le même script:

• 0.9.12 : 3min47s
• 0.99.1 :5min17s

 

C'est peut-être normal mon proc ne fait pas d'AVX.

 

Je vais faire l'essai sur Linux

** edit **

sur Linux avec un autre script que windows, j'ai l'inverse:

• 0.9.12 : 1min47s
• 0.99.1 : 1min13s

 

Je ferai un test demain avec les mêmes images

 

Modifié 22 mars 2020 par m27trognondepomme

[Cissou8]

Vous êtes en train de dire que mon PC est une vielle chose, c'est ca🤣? Bon, ben vous avez raison!

J'avais pas réalisé, mais il date de....2010! Je lui ai donné un bon coup de frais l'an dernier en lui mettant un SSD et 4G de RAM en plus, mais le constat est sans appel, il est vintage. Le passage sous W10 lui a mis un p'tit coup de moins bien aussi...Mais bon, pour faire bouger la monture et imager, il tourne comme une horloge. 

J'ai refait un test, si je traite plus que 12 lights, 0.99.1 donne mieux que 0.9.12, mais c'est tellement dans un mouchoir de poche, qu'on peut pas dire que c'est significatif. 

Je vais faire d'autres tests ce soir, j'ai vraiment l'impression que c'est la lecture des fichiers en 32b qui lui donne du fil à retordre.

Si ça vous dit, je peux partager mes 12 lights, mon dark et un script, histoire qu'on benche sur la même chose. 

C.

 

[lock042]

il y a 6 minutes, Cissou8 a dit :

J'ai refait un test, si je traite plus que 12 lights, 0.99.1 donne mieux que 0.9.12, mais c'est tellement dans un mouchoir de poche, qu'on peut pas dire que c'est significatif. 

Ce la veut dire que c'est les I/O qui limitent la vitesse de traitement. Tout simplement.

[vinvin]

Je me demande pourquoi avec windows c'est si lent cette nouvelle version. C'est marrant que l'interface graphique aille plus vite par contre, pour moi avec linux c'est l'inverse

Je n'ai pas d'AVX non plus (je crois) et ça va plus vite qu'avant malgré mes I/O lentes.

[lock042]

il y a 27 minutes, vinvin a dit :

Je me demande pourquoi avec windows c'est si lent cette nouvelle version.

Y'a effectivement peu de raisons. J'espère que personne ne compile avec le flag -g ou le --enable-debug?

[Cissou8]

1 hour ago, lock042 said:

Y'a effectivement peu de raisons. J'espère que personne ne compile avec le flag -g ou le --enable-debug?

Risque pas! J'ai deja eu du mal à compiler tout court...je me suis pas amusée à rajouter des flags exotiques 🤣

 

1 hour ago, vinvin said:

C'est marrant que l'interface graphique aille plus vite par contre, pour moi avec linux c'est l'inverse

Pour le coup, chez moi, l'amélioration est carrément bien notable!

 

[vinvin]

J'ai mis à jour le tutoriel de compilation pour windows ici https://free-astro.org/index.php?title=Siril:install/fr#Installation_sous_Windows.

@Argonothetu peux peut-être mettre à jour le premier post aussi ?

[m27trognondepomme]

J'ai poursuivi mes tests avec le même script

Rappel: XEON W3550@3HGhz +12G RAM

 

Linux + SSD 🥇

• 0.9.12 : 2min39s
• 0.99.1 :1min55s 👍

WINDOWS 10 + SSD

•  0.9.12 : 3min50s
• 0.99.1 :3min10s 👍

 WINDOWS 10 + HD

•  0.9.12 : 3min47s 👍
• 0.99.1 :5min17s
   

J'ai 2 conclusions pour ma configuration (attention à ne pas généraliser):

1. la version 0.99.1 est à la ramasse sur mon disque dur mécanique tandis que la version 0.9.12 a une performance  identique entre SSD/HD
2. Sous linux, le traitement est plus rapide que sur Windows 10. ( différence de perf entre les 2 ssd ?? ou OS ?? )

 

Modifié 23 mars 2020 par m27trognondepomme

[vinvin]

C'est dingue. Merci. Je ne sais pas expliquer la différence entre les deux OS. Peut-être qu'il y a moins de mémoire libre avec windows au démarrage du traitement tout simplement...

J'en profite pour dire que si on a beaucoup de mémoire disponible par rapport à ce dont on a besoin, on peut changer les paramètres de la mémoire virtuelle de linux pour garder les fichiers en mémoire plus longtemps et éviter les écritures sur le disque trop souvent, ou à un moment où on voudrait plutôt lire. Avec windows c'est 5s et inchangeable, après quoi il écrit. Avec linux, on peut avoir tous les fichiers en RAM si on veut, mais il en faut beaucoup :)

Pour le disque rotatif, il est possible que vu que la nouvelle version consomme moins de mémoire dans certain cas, elle puisse paralléliser plus les opérations, et donc avoir plus besoin du disque (et donc contribuer à le détruire un peu plus rapidement...), ce qui pourrait expliquer que ça va moins vite.

[m27trognondepomme]

il y a 2 minutes, vinvin a dit :

(et donc contribuer à le détruire un peu plus rapidement...),

Chouette, je vais pouvoir changer mon vieux disque dur

[Stéphiou]

@vinvin

 

Les commandes ci-dessous ne sont plus indispensables ? en particulier EXIV2, LIBHEIF et NSIS si on en a pas besoin ?

pacman -S git

pacman -S libgnutls-devel

pacman -S mingw-w64-x86_64-exiv2
pacman -S mingw-w64-x86_64-libheif
pacman -S mingw-w64-x86_64-cmake
pacman -S mingw-w64-x86_64-nsis

 

 

[vinvin]

Ah oui j'avais pas vu qu'il manquait exiv2... J'ajoute, merci. gnutls et nsis je ne sais pas pourquoi c'est là. libheif est optionnelle.

Edit : c'est fait. Je suis pas trop sûr de quels paquets ont des noms normaux et les autres ont le préfixe mingw-w64-x86_64-... J'ai mis le cmake comme tu as dit du coup. J'ai mis deux paquets par ligne aussi pour faire moins de ligne sans que ça sorte de l'écran.