Format de fichiers ZWO ASI183MC

[FalCT60]

Bonjour,

Grosse hésitation quant à l'endroit sur lequel poser ma question, mais ici me semble le plus approprié.

Possesseur d'une ZWO ASI183MC depuis quelques semaines qui me fait tourner en bourrique depuis aussi longtemps.

J'ai choisi de la piloter depuis un PI4B 8Go hébergeant la triplette indi-ekos-kstars.

Aucune difficulté majeure, sauf que depuis le début je me retrouve avec des latences de 1,7s qui s'ajoutent systématiquement à mes temps d'acquisition.

Pas trop gênant pour des poses de 30s, mais rédhibitoire à partir de 5s et en-dessous, le temps total s'en trouvant proportionnellement accru - 1h de poses unitaires de 5s dure effectivement ~1h40.

Pire encore, lorsque je descends en temps d'exposition, cela finit par engorger le système qui, à son tour, finit par planter.

25 flat à 0,035s qui devraient ne durer qu'une fraction de seconde durent effectivement ~45s et, si la fantaisie me prend d'en demander 60, je finis par obtenir un fort ralentissement à partir de 35~45, suivi d'un joli plantage dès 50~53. Et, à partir de là, outre le fait que les dernières photos sont tronquées, c'est tout mon système qui est planté - souris, clavier, ne répondent quasiment plus - et ma seule issue est un reboot du PI.

J'ai fini par m'apercevoir que c'est l'encodage en fits qui cause ce problème : si au lieu de fits je choisis un encodage natif, tout roule sans aucun problème - hormis que, du coup, je ne peux plus traiter mes fichiers qui sont des .bin que Siril ne sait reconnaître et pour lesquels je n'ai trouvé aucun convertisseur fonctionnant nativement sous Linux. Parce que Wine me saoule et que je n'ai pas envie de polluer ma machine avec. Et en cherchant des moyens de convertir du .bin ZWO en .fit, l'ami Google m'a sorti tout un tas de pages traitant du binning, mais rien qui soit de nature à m'aider.

Une autre option serait de baisser la résolution lors de l'acquisition : la ZWO crache du 5496x3672 à 40 Mo le fichier. Néanmoins, je n'ai noté d'amélioration perceptible qu'à partir de 1920x1080, et cela me pose problème : à quoi bon acheter une coûteuse caméra avec une forte résolution si c'est pour en jeter les 3/4 ?

Du coup, je suis ouvert à toute suggestion de nature à m'aider.

Avec mes remerciements anticipés,

Modifié 17 septembre 2023 par FalCT60
Oubli

[Tyler]

Salut,

 

 

déjà, les flats, la camera peut envoyer 19fps en pleine résolution, soit  des temps de 0.052 secondes mini pour que ça "rentre" dans une seule seconde.

 

Pour ce qui est de la latence, j'ai pas tout compris, tes poses de 30 secondes font en réalité 31.7 secondes?

Sinon, suivant ton disque dur, ton cable USB, et les reglages de la cam, ça peut prendre du temps en transfert, c'est normal.

j'ai une 183c aussi, une altair mais bon, les fichiers sont les mêmes, et sous nina / windows je n'ai aucun soucis de transfert, de latence, ou de ralentissements.

Je ne comprends pas bien ton histoire de bin, les fichiers sont en fit, les softs utilisent des fit, pourquoi vouloir utiliser autre chose?
le probleme de latence, vitesse de transfert ne vient pas de là, sinon il y a longtemps qu'on aurait eu des retours.

Ton Pi4B est-il à la hauteur de la cam niveau vitesse, transfert...?

et ta carte SD?
Si elle peut ecrire disons 100Mo / seconde, ça fait environ 2.5 images par secondes.
 

[FalCT60]

J'ai d'abord cru que ça venait de la SD, remplacée par un SSD 970 EVO plus, sans aucune amélioration.

Et, oui : une pose de 30s est rallongée de 1,7s, une pose de 0,035 fait 1,735s.

Pour l'histoire du .bin : si je capture en .fits, j'ai cette latence ; si je capture en Native, ça utilise le format .bin, sans aucune latence.

D'où je déduis que c'est la conversion .bin / .fit qui me ruine.

Du coup, si je peux utiliser ce format natif quitte à devoir convertir après-coup, ça m'arrangerait plutôt.

La carte SD était à la hauteur, et d'ailleurs le SSD qui l'a remplacée n'a rien amélioré. Je précise : je n'utilise plus de carte SD, tout passe en SSD.

40 Mo à la vitesse de transfert de l'USB3 ne devraient pas mettre plus de quelques millisecondes, ce qui est bien le cas lorsque je change l'encodage de FITS en Native sous indi.

Sur un PI, tu imagines bien que ce n'est pas windaube qui tourne.

OK, tu utilises le même capteur, mais à quelle résolution ? Ainsi qu'on peut le voir sur ma capture, c'est plein pot chez moi. Mais cela ne justifie en rien cette latence inexplicable.

Un peu comme si un tampon ne se vidait pas et s'engorgeait jusqu'à tout ralentir.

Modifié 17 septembre 2023 par FalCT60

[Tyler]

Il y a 1 heure, FalCT60 a dit :

Sur un PI, tu imagines bien que ce n'est pas windaube qui tourne.

Oui je me doute, mais d'un autre coté, avec "windaube" ça marche nickel
 

Il y a 1 heure, FalCT60 a dit :

OK, tu utilises le même capteur, mais à quelle résolution ?

pleine résolution, bin x1, 12bit converti en 16 dans nina.
 

si ça passe en format natif et pas en fit, c'est le soft d'encodage qui est en cause, c'est là qu'il faut investiguer.

 

[schizophrene]

Teste avec NINA ou autre depuis un autre PC. Au moins ça permettra de vérifier si c'est la caméra ou autre qui pose problème.

[rmor51]

J'ai un RPI4 avec un SSD et une 183. Je n'ai pas de problème particulier de transfert. Je sauve sur le SSD. Il est normal pour écrire 40 Mo que ça prenne un certain temps. 

Ben oui, proportionnellement le temps d'écriture sera plus important avec des poses courtes.

J'ai un Mele à disposition avec Stellarmate Je vais regarder si on a un gain significatif.

 

[FalCT60]

@Tyler Disons que mon premier réflexe en pareil cas est de remettre en cause l'ICC. Même si je suis quasi-certain de faire tout correctement.

@schizophrene J'ai eu l'avis de quelqu'un utilisant la même caméra (enfin, non : la pro...) sur ASIAIR : pour lui, aucun problème mais si j'ai bien compris c'est en 1080.

@rmor51 Qu'il faille un certain temps pour transférer 40Mo ne me paraît pas anormal - encore que USB3 et SSD cumulés, ça ne devrait pas prendre plus que quelques centièmes de seconde.

Là où ça me pose problème, c'est lorsque le temps diffère selon que les 40Mo s'appellent .fit ou .bin.

Je vais tâcher de trouver le moyen d'effectuer des tests fiables.

[schizophrene]

Il y a 7 heures, FalCT60 a dit :

J'ai eu l'avis de quelqu'un utilisant la même caméra (enfin, non : la pro...) sur ASIAIR : pour lui, aucun problème mais si j'ai bien compris c'est en 1080.

 

L'avis de quelqu'un qui n'a pas TON matériel (pas les mêmes modèles ni même OS - ou du moins le même état de la stack logicielle. Et si ces points étaient égaux, pas le même matériel physique).

 

Il y a 7 heures, FalCT60 a dit :

Là où ça me pose problème, c'est lorsque le temps diffère selon que les 40Mo s'appellent .fit ou .bin.

 

Entre en jeu ce qu'on appelle la conversion, c'est-à-dire l'agencement des données selon un formatage et un ordre précis. Et entre un fichier brut et un fichier dans un format X ou Y, il peut y avoir de nombreuses opérations.

La conversion pouvant s'effectuer dans la caméra, ma proposition de la tester sur un PC n'est pas innocente : soit c'est la caméra, et point de salut, sur c'est autre chose, et il faudra solutionner son le résultat.

 

Donc, on teste sur un PC : sous Windows avec NINA ou autre, avec un résultat positif, on saura que la caméra n'est pas en cause. Toujours sur Windows mais avec la même stack logicielle que sur le Pi, avec un résultat positif, on saura que ni caméra ni stack logicielle ne sont en cause. Ensuite, toujours sur le PC mais sous Linux, même essais.

Si à la fin tous les résultats sont positifs sauf sur (ton) Pi, on pourra conclure que soir le matériel est défectueux, soit que l'ensemble caméra/matériel/stack logicielle pose problème.

Modifié 19 septembre 2023 par schizophrene

[FalCT60]

Bien, du coup hier installation de NINA, qui au passage me paraît extrêmement complet et puissant, et apparemment pas plus compliqué qu'un autre.

Comme je veux tester le transfert de ma caméra, ce sont des flat que je choisis de générer : 77 à 0,02 s., gain 120 et offset 13.

Sur le terrain, je tiens l'écran à flat devant l'objectif le temps que dure la séquence. Là, pour le coup, j'ai posé l'écran au sol sous l'objectif.

Démarrage de la séquence : il s'est écoulé 6 min 30 s. entre le début et la fin, soit 5 s. entre chaque capture. D'où j'en ai conclu que le test n'est pas concluant.

La méthodologie que tu donnes est la plus évidente, encore faut-il pouvoir l'appliquer.

Mon PC est une machine de 2012, avec un pentium quad-core Q9650 et une carte graphique Radeon, qui serait en terme de performances équivalent à un i3 G4.

Il ne me sert que pour des tâches basiques, j'y installe le moins de choses possibles pour conserver un tant soit peu de fluidité sous w10 - exception faite d'un logiciel dont je ne suis toujours pas parvenu à trouver l'équivalent sous Linux.

Ma machine Linux est quant à elle un portable de 2017 équipé d'un i3 G4, qui ne me sert qu'au traitement des mes photos. Et c'est loin d'être un foudre de guerre.

Les tests que je serais en mesure d'effectuer devraient donc l'être sur deux machines différentes, les résultats n'auraient pas grande valeur non plus.

De la même manière qu'entre une 183 et une 183 pro ou entre Stellarmate et Aisair sur un pi4.

Il va me falloir trouver un autre moyen de comprendre.

Quoi qu'il en soit, il n'est pas acceptable que l'acquisition prenne autant de temps.

Je suis 100% nomade, je veux être le plus léger et mobile possible car le trajet du point où je laisse mon véhicule à celui d'observation n'est ni proche, ni plat.

Avec mon apn, 63 flat ne duraient que 16 s., je pouvais donc me permettre de tenir l'écran devant l'objectif. Ce n'est pas envisageable avec des temps de 6 min.

Je ne compte pas m'arrêter avant d'avoir vraiment compris de quoi il retourne.

[schizophrene]

Ça tendrait à montrer un problème avec la caméra. Mais il faudra d'autres essais.

 

Nul besoin de puissance pour la capture. Je tiurne avec un Celeron.