Aller au contenu

Messages recommandés

Posté

J'ai fait une première traduction de la documentation d'Ekos du site Indilib.org rubrique About; celle du tutorial pour les débutants de la rubrique Support et du manuel de iAstroHub3.

 

Où dois-je les mettre à disposition SVP ?

  • Réponses 217
  • Créé
  • Dernière réponse

Les pipelettes du sujet

Les pipelettes du sujet

Posté
Bonjour,

Pour ceux que ça intéresse, je me prépare à diffuser une image disque SD iAstroHub 3 modifiée comme suit :

- Contrôle direct de la monture en EQMod depuis Skysafari sans la raquette

- Géolocalisation depuis le GPS d'un smartphone

- Alignement d'EQmod depuis le résultat de la réduction astrométrique

- Possibilité de commander le reflex par le GPIO (Mirror Lock Up)

En gros, le matériel se limite à un smartphone et à un Raspberry. Le but est de faire simple et efficace tout en disposant d'un outil complet et de qualité.

La notice Française est en cours de rédaction. La version Anglaise sera faite dans un second temps.

Etant du Nord les possibilités de test du produit sont relativement limitées...

Il y a t-il des personnes sur ce forum qui seraient disposées à le tester ?

Cordialement,

 

Je veux bien te donner un coup de main pour tester, contacte moi en MP ;)

Posté

Bonjour,

 

Voici ici les premiers résultats du travail de traduction et de mise en forme la documentation Kstars Ekos Indi

 

Je n'ai pas encore intégré tout ce que m'ont transmis patdut et rmor51, mais c'est en cours :)

 

Bon ciel,

Posté

Bonjour,

 

Recevez mes compliments pour la doc Française d'INDI.

 

Je suis certain que cela contribuera à démocratiser cette solution en France.

 

Le site me permets également de découvrir le potentiel de SIRIL.

 

Je suivrai votre projet avec attention.

 

Encore bravo,

Posté
Je suis certain que cela contribuera à démocratiser cette solution en France.

 

Il faut. Si les gens se rendaient compte qu'on peut piloter son matériel (observatoire + instru) avec une suite de logiciel libre et gratuite (que même des pros utilisent) peut-être que plus de gens auraient un petit linux installé sur un ordi.

Je trouve déjà que cette communauté grandit. A mon inscription sur WA ce genre de sujet n'existait pas ou étaient très peu actif.

Maintenant, que cela soit ici ou sur Facebook je vois de plus en plus de gens utiliser des solutions libres pour produire leurs images astro.

 

Le site me permets également de découvrir le potentiel de SIRIL.

Bien :). En espérant également que ce potentiel te plaise.

  • 2 semaines plus tard...
Posté

Attention:

Pour les utilisateurs d'INDI et de logiciel client PHD2 ou CCDCiel et qui mettraient à jour INDI aujourd'hui. La version 1.4.1 d'INDI est incompatible avec ces clients. Cette situation ne devrait pas durer. PHD2 devrait rapidement être mis à jour. Pour CCDCiel ???

Posté

Ta remarque est valable pour ceux qui ont la version master de PHD2 ? Ou une version stable package ?

Je récupère les sources sur le git et je compile.

Posté

C'est aussi ce que je fais. Je viens de recompiler et tout fonctionne normalement. La correction a donc été faite mais je ne peux rien dire pour l'instant sur la version packagée.

Posté

Une bonne nouvelle pour les accros de la fenêtre. Il existe une version de Kstars pour windows qui intègre Ekos. C'est disponible ici.

Vous pourrez donc le tester à loisir.

  • 1 mois plus tard...
Posté (modifié)

Bonjour à tous,

 

Sur un PC portable équipé de Debian Testing (pour le moment, il s'agit donc encore de Stretch), j'ai installé une série de programmes pour l'astronomie pratique : Kstars, Stellarium, Siril (qui fait son apparition sous Debian, j'ai l'impression : je crois qu'il n'était pas encore sur les dépôts de Jessie, actuelle version Stable), Skychart (c'est-à-dire Cartes du ciel) et Oacapture.

 

Aucun problème pour tous ces programmes, sauf pour Oacapture. Dans un premier temps, j'ai essayé de le compiler à partir de ses sources, comme j'avais fait sur le PC de bureau qui tourne sous Debian Stable, donc pour le moment Jessie. Mais l'étape de configuration, avec la ligne de commande « $ ./configure », échoue en raison de librairies Qt requises mais non installées. Pourtant, je n'ai pas l'impression d'avoir dû installer des librairies Qt « ésotériques », genre librairies de développement *-dev, etc., pour compiler Oacapture sous Debian Jessie.

 

Après quelques tentatives infructueuses pour installer les librairies Qt qu'il demande (le message de ./configure n'est pas très explicite, pour une fois, et je suis donc un peu dans le cirage), j'ai essayé d'installer Oacapture via l'archive préparée par l'auteur pour Ubuntu 16.04. Pour mémoire, l'exécution de Oacapture sous Ubuntu nécessite les librairies suivantes pour fonctionner :

 

. libqtcore4,

. libqtgui4,

. libv4l-0,

. libv4lconvert0,

. fxload,

. libcfitsio3.

 

À nouveau, aucun problème pour toutes ces librairies, sauf pour la dernière, libcfitsio3. C'est une librairie partagée pour l'entrée/sortie avec des fichiers de données au format FITS (Flexible Image Transport System). Debian Stretch ne la propose plus que sous la forme du paquet libcfitsio5. L'installation de ce paquet copie la librairie elle-même (libcfitsio.so.5.3.41) et son lien symbolique (libcfitsio.so.5) dans /usr/lib/x86_64-linux-gnu/ (dans le cas de l'architecture amd64). Aucun lien vers elle sous le nom libcfitsio.so.2 attendu par Oacapture.

 

Je me suis dit que le moment était venu pour une installation en mode brutal. En root, j'ai donc ajouté un nouveau lien symbolique semblable à celui du paquet Debian :

 

# cd /usr/lib/x86_64-linux-gnu/

# ln -s libcfitsio.so.5.3.41 libcfitsio.so.2

 

Oacapture compilé par l'auteur pour Ubuntu 16.04 se lance alors sans aucun problème sous Debian Stretch. Il reconnaît sans problème ma caméra, une ZWO ASI290MM, et j'ai pu lui faire produire un fichier .ser d'une capture d'une trentaine de secondes en full frame (58 frames par seconde vers un HDD conventionnel, avec la caméra connectée en USB 3.0). Malheureusement, il ne s'agissait pas de Jupiter, mais de ma bouille émerveillée par le miracle de la vie (informatique).

 

À propos de mon échec de compilation à partir des sources, je me demande s'il n'y a pas un souci avec les versions 4 et 5 de Qt, mais je ne sais pas.

 

Voilà, ce n'est pas propre du tout, de faire comme ça, mais peut-être que ça intéressera un autre utilisateur de Oacapture qui fera peut-être bientôt l'installation de Debian Stretch quand elle sera devenue la future version Stable (version 9).

Modifié par ChristianHJ
Posté

Merci de ta réponse, Cyril. ;) Je n'imaginais pas que Planetary Imager était déjà arrivé à une telle maturité..! En plus, étant sous Jessie pour le PC de boulot, je n'avais pas encore pu l'y installer (sans compil des sources, en tout cas). Planetary Imager sera de sortie dès que la météo le permettra à nouveau, merci encore !

Posté

Disons que je suis en contact régulier avec le développeur et que je lui sers de beta-testeur.

Du coup ... Je fais pas mal "mes courses" ;).

 

Sinon sans blague c'est un super logiciel pour lequel il va privilégier la simplicité et les performances.

Posté (modifié)

Voilà, Planetary Imager installé sur Debian Testing (Stretch). Mais pas sans quelques soucis ; je me suis dit que la suite peut intéresser d'autres utilisateurs.

 

La version de Planetary Imager (PI) en phase de développement actuellement est la 0.7.0-beta2 (en fait 0.6.96). Elle est proposée sous une forme binaire pour Windows, Ubuntu (16.04 et 16.10), Fedora 25 et Debian Testing. J'ai donc récupéré le .deb pour Debian Testing, mais une dépendance d'exécution de PI ne peut pas être remplie sous Debian Testing pour le moment. Il s'agit de libopencv-highgui2.4v5, puisque Stretch ne la propose que sous le nom libopencv-highgui2.4-deb0. Bon, on peut quand même forcer l'installation du .deb de PI, et ça me semble fonctionner sans problème, mais on se retrouve alors avec un paquet cassé (beurk), et dpkg, apt-get, aptitude et al. n'aiment pas ça.

 

Du coup, j'ai récupéré les sources afin de compiler PI. Il suffit de disposer de git et de lancer la commande suivante (comme utilisateur normal) :

 

$ git clone --recursive https://github.com/GuLinux/PlanetaryImager.git

 

puis de se déplacer dans le répertoire de PI, de créer le répertoire de travail et de s'y rendre :

 

$ cd PlanetaryImager/
$ mkdir build/
$ cd build/

 

Enfin, on configure, et puis on compile une fois que la configuration est OK :

 

$ cmake .. -DCMAKE_INSTALL_PREFIX=/usr
$ make all

 

Les messages d'erreur de la ligne de commande cmake sont très clairs et explicites. En les lisant, on sait immédiatement quelles sont les librairies qu'il faut installer afin de respecter les différentes dépendances de compilation. Bien sûr, on procède étape par étape, et puis après quelques installations de librairies (des *-dev pour la plupart) la compilation indique que tout s'est bien passé. On peut alors exécuter la seconde commande ci-dessus ($ make all), celle de compilation.

 

Dernière étape, l'installation proprement dite, la seule qu'il faut effectuer sous le compte d'administration :

 

# make install

 

L'application fonctionne vraiment très bien et une caméra ZWO ASI290MM (non refroidie) est reconnue sans problème. Il y a des outils d'aide à la mise au point que je n'ai jamais essayés (des algorithmes de détection de bord, Canny ou Sobel). Le seul hic que j'ai remarqué, c'est que quand l'ASI290MM est ouverte ou connectée et qu'on la déconnecte (Camera > Disconnect), ça interrompt l'exécution du programme PI. Avec la webcam du PC portable, reconnue elle aussi, la déconnexion de la caméra laisse en revanche l'application PI intacte. Pas bien grave...

 

Merci encore de ton conseil, Cyril. (Bien sûr, pendant la configuration et la compilation, le ciel s'est d'autant plus couvert qu'on approchait du but, mais c'est une autre histoire. :eheh:)

Modifié par ChristianHJ
Posté

La compilation est toujours un truc intéressant. :)

Dommage que je ne fasse pas d'imagerie, mais je suis à 100% sous Linux depuis des années, ma copine qui n'y connaît rien utilise Fedora ou Mageia sans souci.

 

Attention avec la terminologie : library en anglais signifie bibliothèque, et on parle bien de bibliothèques ou de dépendances en info. ;)

Posté
L'application fonctionne vraiment très bien et une caméra ZWO ASI290MM (non refroidie) est reconnue sans problème. Il y a des outils d'aide à la mise au point que je n'ai jamais essayés (des algorithmes de détection de bord, Canny ou Sobel). Le seul hic que j'ai remarqué, c'est que quand l'ASI290MM est ouverte ou connectée et qu'on la déconnecte (Camera > Disconnect), ça interrompt l'exécution du programme PI.

 

Ah. Tu devrais signaler ce bug dans l'onglet "Issues" du github. Moi je n'ai pas ce soucis avec ma zwo ASI224MC.

 

Merci encore de ton conseil, Cyril.

 

Je t'en prie, c'est avec plaisir.

Posté
Attention avec la terminologie : library en anglais signifie bibliothèque, et on parle bien de bibliothèques ou de dépendances en info. ;)

Ok, je crois que j'ai utilisé la terminologie de façon cavalière... Ce que je voulais dire, c'est que le paquet .deb suivant :

 

PlanetaryImager-0.6.96-20170411-beta2-Linux-x86_64_debian-testing.deb

 

(la version binaire en développement de PI pour Debian Testing sous l'architecture amd64) impose une dépendance d'exécution, via son champ « Depends: », vis-à-vis de la librairie libopencv-highgui2.4v5... qui n'existe pas sous Debian Testing. (Debian Testing propose à la place libopencv-highgui2.4-deb0.) Du coup, la dépendance en question ne peut pas être satisfaite par les dépôts de Debian Testing. On peut forcer l'installation quand même, et le programme fonctionne bien (pour autant que je sache), mais on se retrouve avec un paquet cassé (celui de PI) et des gestionnaires de paquets qui le font savoir à tout bout de champ. Ça m'a semblé préférable de compiler à partir des sources.

 

Ah. Tu devrais signaler ce bug dans l'onglet "Issues" du github. Moi je n'ai pas ce soucis avec ma zwo ASI224MC.

D'accord, je vais voir comment je dois m'y prendre. Peut-être que ce serait utile si je relevais aussi le petit souci au niveau du champ « Depends: » pour le paquet binaire de PI (0.7.0-beta2) pour Debian Testing ? Merci à toi en tout cas !

Posté

A propos de Planetary Imager, la QHY5LII-C n'est pas reconnue. Signalé dans la doc, mais bon ...

Posté (modifié)

Les problèmes avec la QHY sont connus et détaillés sur le github. Ça vient du SDK de qhy qui est bien pourri pour linux malheureusement.

Modifié par lock042
Posté
A signaler la disponibilité de la version pour Androïd de Kstars-Lite.

 

Merci pour l'information :p

Posté (modifié)

Un petit up pour signaler que la toute récente version 0.7.0-beta3 (0.6.97) de Planetary Imager, mise en ligne par l'auteur le 21/4/2017, ne pose plus le moindre problème avec une ZWO ASI290MM (non refroidie), et qu'on peut désormais aussi l'installer sur une Debian Testing (Stretch, future version 9) via un paquet binaire .deb :

 

. avec cette version 0.7.0-beta3 (0.6.97), on peut connecter et déconnecter une ASI290MM à volonté, sans risquer un crash du programme Planetary Imager (ce n'était qu'un souci mineur, mais c'est réglé) ;

 

. le nouveau paquet .deb pour cette version comporte une dépendance d'exécution vis-à-vis du nom et de la version corrects de la librairie libopencv-highgui2.4-deb0. Du coup, son installation par dpkg ne pose plus aucun problème.

 

Entre parenthèses, Debian Stretch comportera un Pure Blend pour l'astronomie, avec des métapaquets proposés qui dépendent de paquets pour l'astronomie et des dispositifs qui en facilitent l'installation et la configuration. Vous savez sans doute déjà tout ça, mais voici le lien pour Debian Astro Pure Blend :

 

https://blends.debian.org/astro/

 

et celui pour la liste de métapaquets correspondante :

 

https://blends.debian.org/astro/tasks/

 

Mais il faut attendre la stabilisation de Stretch (ou passer en Testing)...

Modifié par ChristianHJ
Posté

J'ai un souci avec une SPC900 N&B LX qui est reconnue. Mais à la connexion ça plante le soft. Et je dois manuellement arrêter le processus dans la moniteur. Pas de souci avec la caméra intégré du portable.

 

Cette SPC900 est très bien géré dans EKOS avec le driver INDI V4L2 CCD: flux vidéo et longue pose.

Posté

Je refais la demande suivante: Ne pourrait-on pas disposer d'une rubrique Linux spécifique dans le forum SVP?

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