Aller au contenu

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


Argonothe

Messages recommandés

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.

  • Merci / Quelle qualité! 1
Lien vers le commentaire
Partager sur d’autres sites

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 !

Lien vers le commentaire
Partager sur d’autres sites

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.

  • J'aime 1
  • Merci / Quelle qualité! 1
Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

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é par lock042
Lien vers le commentaire
Partager sur d’autres sites

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.

image.png.141c6b8a9a6fb8ba6192ee80015578d6.png

 

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.

image.png.93432bf16a14342e3238fa5968761ae3.png

Lien vers le commentaire
Partager sur d’autres sites

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é par m27trognondepomme
Lien vers le commentaire
Partager sur d’autres sites

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.

 

Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

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?

Lien vers le commentaire
Partager sur d’autres sites

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!

 

Lien vers le commentaire
Partager sur d’autres sites

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é par m27trognondepomme
Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

@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

 

 

Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

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