Utilisation de deux cameras ASI (120 et 1600)

[Laurent Bernasconi]

Rien a voir avec la vitesse d'écriture du DD. C'est du avant tout à la compression de l'image en temps réel, ca demande un traitement par Prism pixel par pixel. Peutetre aussi de la méthode utilisé par Prism pour écrire une image.
Il n'y a que Cyril qui pourra répondre a cette question, c'est lié directement au codage dans prism.

[Cyril Cavadore]

Le FITS c'est le plus rapide possible avec un SSD.

le CPA il y a une compression, donc du temps de CPU supplémentaire, donc une sauvegarde plus lente.

[michel_rieutord]

Bonjour,
et merci pour vos retours.

Je reviens avec mon pb de l'acquisition à haute cadence avec une Camera
ASI 183 sous Prism. Pour résumer:

J'ai fait la manip avec Sharpcap 3.1 où j'ai réaliser une acquisition avec
un débit d'env. une image/s (en fits), chaque image faisant 40 Mb.

Je préférerais faire l'acquisition sous Prism puisque c'est avec ce
logiciel que je contrôle l'instrument: c'est plus simple à gérer et les
headers sont mieux remplis.

D'où mes questions:
1/ est-il possible que prism puisse faire l'acquisition à
une vitesse similaire à SharpCap? ou bien y a-t-il un goulet
d'étranglement incontournable? d'autres logiciels comme SAOimage/ds9
lisent et écrivent ce type de fichiers en une fraction de seconde;
la vitesse d'écriture sur disque va en général au dela de 100Mb/s.

2/ Les Cameras ASI ont en général une RAM interne tampon (de 256 MB
pour la 183) qui peut permettre de lancer la pose suivante tandis qu'on
transfere la pose réalisée. Par exemple actuellement avec un temps
d'écriture de 6.4s/image, je perds 20% du temps lorsque les poses font
30s (et le temps de télescope est précieux!). Y aurait-il moyen que
Prism fasse cette écriture asynchrone si l'option 1/ s'avère impossible ?

Merci d'avance pour vos retours.

Bien cordialement,

Michel

[Cyril Cavadore]

Je pense aussi que l'ecriture du FITS n'est pas super optimisée en vitesse dans PRISM, car PRISM gère une foultitude de format FITS, et ca sera au detriment de la performance.
Deja l'écriture se fait ligne a ligne (donc des petits morceaux de données), alors qu'une écriture avec un gros bloc serait plus rapide je pense.
Ensuite il faut passer en FITS integer pour aller plus vite, par defaut PRISM ecrit des FITS en pixel float. Ca se change dans les options générales du logiciel (si tu ne trouves pas ou, je peux dire ou).
Il faudrait que je fasse des tests de mon coté aussi.

[michel_rieutord]

Bonsoir,
J'ai vérifié l'affaire de l'écriture des données en integer
et j'ai l'impression que c'est bien le cas; je joins à mon message les captures d'écran montrant
les réglages que j'utilise. Dites-moi si on peut améliorer.

Bien cordialement,

Michel

[Cyril Cavadore]

Qu'est ce qui est "bien le cas" ?

[Jean-paul GODARD]

Aucun problème pour ma part. Nous avons cette configuration sur le télescope Janus Sud et ca fonctionne très bien.
La 1600 est piloté en natif par Prism, et la 120MM est sous ascom.

Perso, j'ai des problèmes quand je met les deux en mode natif... Je les mettais donc en Ascom...
Mais si on peut mettre une seule (Guidage ou Scientifique?) en natif, alors c'est a essayer.

[Cyril Cavadore]

Je les utilise qu'en natif et je n'ai pas eu de problèmes ces temps ci.

Attention la version de ASICamera2.dll doit etre >= a 1.13.5.28
J'ai fait faire des tests par ZWO et avec Prism, et ils n'ont pas vu de problème en double natif non plus.

Ceci dit, si ASCOM aide à ce que ca marche, ben tant mieux.

[michel_rieutord]

Bonsoir,

Je disais que c'était bien le cas que j'écrivais les données en entiers (16bit), donc de la façon la plus compacte possible (sans perdre de données). C'était suite à votre remarque "Ensuite il faut passer en FITS integer pour aller plus vite, par defaut PRISM ecrit des FITS en pixel float. "

Bien cordialement,

Michel

[Cyril Cavadore]

Quelle est votre attente en termes de temps de cycle d'acquisition + sauvegarde ?