FalCT60

Pour conclure et passer ce sujet en Résolu : un traitement sur la séquence dure plus longtemps que sur une seule image, en plus de générer un flux bien visible dans la console (lorsqu'elle n'est pas masquée par la boîte de dialogue).

Aïe ! aïe ! aïe ! tout est donc à mettre au cabinet, comme le disait ce cher Alceste. Le pire - cela m'est revenu dans la matinée - c'est que j'avais déjà lu cette page, et qu'à l'époque je me suis assuré que les deux valeurs en question correspondaient, n'ayant rien trouvé indiquant le contraire. Et d'ailleurs, si je clique sur le bouton Default, ce sont bien ces valeurs-là qui sont rétablies. Par curiosité, j'ai calculé WB_B x median G / median B ainsi que WB_R x median G / median R, et j'obtiens deux valeurs très proches de 50 : 50,059 et 50,079. Donc, oui, 50 pour les deux, ainsi que tu me l'indiquais. N'en demeure pas moins que le fait que les calculs donnent des valeurs différentes de 64 me perturbe toujours autant. L'une des raisons pour lesquelles je souhaite m'affranchir de l'obligation de faire les bias, ce sont des latences inexpliquées qui font planter mon système au bout de quelques images pour des poses inférieures à la seconde. Encore merci pour tout cet accompagnement.

Je ne suis décidément pas doué pour les recherches. Mais cela signifie que ce ne sont pas que les bias et dark qui sont affectés, contrairement à ce que j'avais cru comprendre, mais aussi les light, non ? Donc le résultat final du prétraitement devrait être cohérent et bien rattrapé par la balance effectuée lors de l'étalonnage des couleurs, non ?

Merci. Mais encore faudrait-il pour cela que le problème du pilote fût réglé. Sinon, je vais toujours me retrouver avec des valeurs faussées.😭

Alors, là, heureusement que je suis assis, sinon j'en serais tombé de cul par terre ! Je pensais que @lock042 déconnait, avec son histoire de balance, tant il était impensable pour moi que quelque chose pût être fait dans ce sens. Quant à m'en rendre compte par moi-même, j'aurais pu relire des millions de fois ce passage la doc que ça ne m'aurait même pas effleuré - pour la même raison que précédemment. Et, de toute façon, chaque fois je me suis arrêté à la vue de la série d'équations, sans même chercher à la déchiffrer ni aller au-delà. Trop complexe pour moi. Puis-je la jouer optimiste - j'ai juste à refaire les dark et je pourrai sauver les quelques sessions que j'ai effectuées depuis quelques temps - ou bien tout « est simplement bon à mettre au cabinet » ? J'ai évoqué EKOS, mais si j'ai bien compris c'est INDI qui se charge du pilotage au niveau profond, et EKOS gère la couche superficielle. Je vais donc devoir effectuer un signalement auprès des développeurs - ils vont être contents : ce n'est pas le premier dysfonctionnement que je leur signale. À croire que je n'utilise pas de la même manière que les autres. 😇 Pour le reste, je vais opter pour un offset de 15 au lieu de 13, toujours au gain 120, et utiliser 1024 en tant que valeur de calibration. Merci pour ton aide précieuse.

Bonjour, Dans ma quête de compréhension, j'ai voulu voir ce que ça donne avec un autre logiciel, dans un autre environnement. Petite rectification, tout d'abord : ce sont 9 bias que j'ai faits hier, de 10 à 50 et gain 120, mais je n'ai pas utilisé le premier pour les statistiques. Il y est à présent inclus. J'ai fait de même avec NINA, sous w10. Un peu galère, car je ne connais pas du tout ce logiciel. J'ai donc dû modifier l'offset entre chaque prise et déconnecter / reconnecter la caméra pour que ce soit pris en compte. Siril m'a analysé tout ce petit monde et m'a sorti les données qui m'ont totalement désarçonné tant elles sont différentes de celles obtenues précédemment.😱 Toujours aussi incohérentes, apparemment, mais néanmoins différentes. Je donne ici le lien wetransfer vers les fichiers issus d'EKOS et de NINA, en plus de la feuille de calcul jointe à la publication. Pour ma part, je n'y comprends plus rien du tout. Je me suis lancé dans quelque chose qui me dépasse totalement.😭 -=-=-=-=-=-=-=-= Edit =-=-=-=-=-=-=-=- Rectificatif : après avoir généré le graphe, les valeurs retournées par NINA semblent au contraire très cohérentes et montrent une progression quasi-linéaire de +320 entre chaque pallier, en plus de se situer à mi-chemin entre le min et le max.. offset.ods

Désolé @jDef, j'avais totalement raté ton intervention. Et j'aurais mieux fait de ne pas m'en rendre compte. J'ai déjà eu mal à la tête avec les explications de @Cissou8, mais les tiennes furent le coup de grâce.

Je sais qu'il m'arrive d'être distrait, et lorsque quelque chose ne va pas je considère que c'est forcément l'ICC qui déraille. Mes fichiers ont été générés avec la 183 fixée sur un objectif bouché que j'ai eu la flemme de sortir du sac. J'ai juste légèrement entrouvert la fermeture pour connecter le câble USB. Le logiciel de prise de vues est Stellarmate OS 2.6.60 qui fait tourner Kstars-Ekos 3.6.6 sur un rPI 4B/8Go. J'ai programmé dix séquences à 0,000032s au gain 120 en variant l'offset - et lui seul - de 5 à 50. J'ai transféré les images pour analyser sous Siril et, au vu des résultats, me suis longtemps demandé : «Mais c'est quoi ce binz ?» J'ai refait 8 bias ce soir, de 15 à 50, en utilisant la version tablette de Stellarmate, et j'obtiens rigoureusement les mêmes valeurs sorties de Siril. Je ne pense pas qu'un quelconque réglage inopportun soit venu mettre le souk, et je suis un peu moins inquiet quant à mes aptitudes. Mais toujours aussi perplexe quant aux résultats.

Merci @Cissou8 pour tes explications détaillées. J'avoue que j'ai toujours un peu de mal à comprendre certaines choses, ce qui peut parfois me conduire à faire totalement l'opposé de ce qu'il faudrait. J'espère toutefois n'avoir pas été con au point de rater les bias !

Effectivement, si ça doit tout déglinguer, mieux vaut éviter. Merci pour la précision.

Bonjour, Petit retour sur ce sujet que je croyais avoir parfaitement compris, mais là d'un coup je suis pris de sérieux doutes. Utilisateur d'une ASI183MC classique, j'ai pris l'habitude de renseigner la valeur ADU utilisée lors de l’acquisition en tant que master offset. Et, comme j'aime bien me compliquer l'existence, j'ai voulu couper un peu plus les cheveux en quatre. On ne se refait pas. J'ai repotassé le tuto sur le sujet, puis j'ai pris dix bias de 5 à 50. J'ai déjà dit que je suis un CCQ. Un convert offset suivi d'un seqstat offset offset.csv basic plus tard, j'ai mon tableau. Petite parenthèse rapide : ne serait-il pas possible de faire en sorte que Siril tienne compte des paramètres régionaux ? Il me sauvegarde les données avec des points au lieu de virgules. Fin de la parenthèse. J'ai donc mon tableau de valeurs dans lequel, après remplacement des points par des virgules, seule la colonne median m'intéresse ; et comme il s'agit d'entiers inutile de se compliquer (tiens, c'est moi qui écris cela ?) avec les median16. Cette courbe montre une progression apparemment linéaire, et si j'effectue le rapport median/offset j'obtiens des valeurs groupées entre 67 et 74 - exception faite de la première valeur à 83 qui se singularise. Pour pousser un peu plus la curiosité, la colonne Progrès indique le pas entre deux paliers avec, là aussi, des valeurs quasi-homogènes. Le capteur est censé être 12 bits (sauf erreur de ma part) pour lequel le tuto stipule qu'il faut utiliser un facteur 16. Au gain 120 que j'utilise, l'offset déterminé de façon empirique avec Sharpcap est 13. Et 120 est actuellement la valeur que j'indique en tant que master offset. Néanmoins, si à présent j'utilise 64*$OFFSET, je vais me retrouver avec une valeur de 832 et non plus de 120. Valeur qui, par ailleurs, serait bien cohérente avec les mesures effectuées, et en tout cas bien à sa place entre 736 et 1064, resp. offset 10 et 15. J'ai voulu voir si cela induisait un quelconque changement entre un prétraitement avec 120 ou 64x$OFFSET et n'ai rien remarqué qui semble anormal ni flagrant. Soit je ne sais pas regarder, soit ce ne sera visible que dans certaines conditions, par exemple de forts écarts thermiques, étant donné que ma caméra n'est pas refroidie. Quoi qu'il en soit, si je me suis planté, merci de me dire où, et pourquoi. Et j'espère que ça permettra d'éviter à d'autres de commettre les mêmes erreurs. ASI183MCnc.ods

Mauvaise nouvelle : il m'est à présent (depuis hier, en fait) impossible de reproduire ce comportement.😨 J'ai d'abord fait comme suggéré sans que cela ne se produise. Du coup, j'ai tout effacé et suis reparti du début : même chose. 🤔 Nouvelle purge des fichiers, redémarrage de Siril... rebelote : aucun problème lors de la sauvegarde. M'énerve ! 😠 Purge, fermeture de Siril, redémarrage du système : toujours aucun problème. Se moque vraiment de moi ! 🤬 Puis je me suis rappelé qu'entre mon dernier passage ici et mes nouveaux tests une màj du système a eu lieu. N'ayant pas plus que quiconque par ici ni le don de clairvoyance ni boule de cristal, je crains que ce mystère n'en demeure à jamais un.

Testé à l'instant depuis le site d'origine : aucun problème. C'est donc ton AV qui délire. Par contre, si tu l'as téléchargé à partir d'une autre source, de celles qui rajoutent leurs adwares aux paquets, c'est une autre histoire. Toujours préférer le site de l'éditeur - et se méfier des contrefaçons.

Bonsoir, Pas très sûr que mon approche soit très pertinente, mais de manière empirique j'ai opté pour 0,5 et ça ne semble pas trop mal. Mais c'est vrai que j'aimerais bien pouvoir déterminer la valeur à appliquer en fonction des cas.

Bonsoir, Non, strictement rien. Je me rends compte que ça part en vrille lorsque je tente de sauvegarder le résultat après le starnet. Je n'ai aucune raison de sauvegarder avant d'avoir joué avec les curseurs. Si je repartais du stade avant le starnet et, une fois celui-ci terminé, avant d'effectuer quoi que ce soit d'autre, ouvrais l'explorateur de fichiers et voir si c'est le starnet lui-même ou les ajustements sur le résultat qui causent ce comportement ?

Bonjour, Je viens de refaire une session afin de sortir le log. Une fois le traitement starnet exécuté, chaque tentative de Sauvegarder sous... échoue pour un problème apparemment lié au jeu de caractères. Je vous laisse examiner tout ce verbiage, en espérant qu'il mène à quelque chose. Bonne fin de week-end, output.log

Très bien, je referai le traitement dans sa totalité en le démarrant depuis la console afin d'avoir un maximum de données à vous fournir.

Sur mon D4s j'avais 769 et sur mon D700 quelque chose autour de 3. Ces valeurs n'ont jamais semblé poser de problème - pour le D700 j'ai même utilisé 0 sans noter aucune différence avec les offset. Il existe un tuto par ici qui indique la manière de déterminer cette valeur, je pensais avoir mis le lien en favoris, mais je ne le trouve plus. Ah ! çà y est, j'ai remis le pointeur dessus.

Bonsoir @m27trognondepomme D'après ce que j'ai pu lire, le retrait sur le gradient sur la séquence s'effectue avec une fonction polynomiale de degré 1. D'ailleurs, de mémoire, si tu te trompes et tentes de saisir une autre valeur, Siril te le fait savoir de manière péremptoire. Inutile de chercher à le contrarier. 😂

Effectivement, j'aurais déjà pu préciser que j'utilise la 1.2.0 du dépôt sous Ubuntu 22.04 et starnet++ pour la réduction. Workflow complet ? Pour les logs, à la limite je peux repartir de l'étape du traitement des étoiles, juste après l'étalonnage des couleurs, puisque c'est à partir de là que ça dégénère.

Bonsoir, Cela ne m'arrive pas souvent, mais parfois j'ose me laisser aller à une réduction d'étoiles. Une fois le résultat pas trop moche, je souhaite l'enregistrer, mais aussitôt que s'ouvre la boîte de dialogue j'obtiens ce qui apparaît sur la capture d'écran jointe. Et, avant de pouvoir saisir un nom cohérent, il me faut valider trois (ou quatre - plus très sûr) fois. Mais, à supposer que je veuille l'enregistrer sous un nouveau format (.tif, .jpeg, ...), c'est reparti comme en quatorze. Seule solution pour ne plus avoir ces hiéroglyphes à chaque demande d'enregistrement : quitter Siril. Une idée de la cause de ce comportement incongru ?

Bonsoir, j'arrive toujours après la bataille, mais j'espère que mon expérience va pouvoir servir. Je me suis rendu compte après plus d'une heure à batailler pour équilibrer les dentelles du cygne que les deux raisons majeures à l'échec de la résolution astrométrique sont : le fait de ne pas correctement recadrer l'image - càd de laisser des résidus de décalage à l'alignement - et de ne pas suffisamment recadrer l'image. Cette seconde notion me semble assez perturbante, car c'est ce qui m'a fait perdre pas mal de temps ce jour. Car, ayant dans un premier temps proprement recadré mon image de manière à éliminer tout résidu comme indiqué en 1, je me suis heurté à l'obstination de Siril à ne pas vouloir coopérer. Comme l'auteur j'ai alors tenté toutes les focales sans succès, jusqu'à ce que je me décide à effectuer un recadrage très sévère de ma photo - un bon tiers de ce qu'il restait après le premier recadrage. Et, là, c'est passé comme une lettre à la poste. Pourquoi ce comportement inopportun ? Mystère. Précision : je ne recadre pas n'importe comment, je conserve les proportion d'origine.

Bonsoir, Il me semblait que le plus simple est de renseigner dans le champ du master offset la valeur ADU utilisée pour la capture. C'est en tout cas ce sur quoi j'en étais resté après mes échanges par ici, et que j'applique ; et cela semble pas trop mauvais.

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.

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