Tech [Résolu] Offset synthétiques - n-ième

[FalCT60]

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

Modifié 27 juillet par FalCT60

[Cissou8]

Salut,

 

 

Alors en tracant tes donnees, j'obtiens ca:

 

 

Ce que tu vois sur le min, c'est que le réglage d'offset est tellement bas, que certaines valeurs sont clippées au noir. Donc, si tu cherches a trouver le facteur multiplicateur, il faut pas se servir des valeurs a 5 et 10, leurs statistiques sont faussées.

Si SharpCap te donne un reglage a 13, j'imagine que c'est le reglage mini de mini pour pas que ca clippe. Je te dirai quand meme de le monter un peu...

 

Y a quand meme un truc tres etrange, et meme 2:

- le premier, c'est le fait que l'ecart (max-median) est bien plus grand que (median-min) et il monte avec le reglage d'offset. Alors, je suis d'accord que le max c'est pas très robuste comme estimateur. Mais j'ai regarde aussi le noise et le sigma, c'est pareil, ils augmentent. Normalement, si tu montes juste l'offset, ca change pas l'histo, ca le decale a droite (ca ajoute un offset en bon francais  ).

- le deuxieme, c'est que si je regarde tes valeurs de max, c'est pas des multiples de 16 (sur le min, c'est bien ca). Pour une camera en 12b, c'est qd meme bizarre. Une camera en 12b, quand elle ecrit ses 12b d'info dans un container 16b et qu'elle les colle a gauche (elle remplit a droite avec 4 zeros donc), c'est normal que tu te retrouves avec des tableaux remplis de multiple de 16 (2^4).

Donc voila, je sais pas te dire ce qui va pas avec tes prises de vue, mais y a des trucs qui me chiffonent avec tes stats d'images. C'etait bien a gain constant?

 

Pour me convaincre de ce que je te raconte, j'ai sorti ma 120MM (non refroidie, ADC12b) et j'ai fait 21 bias a 0.001s au gain 29 qui est l'unitaire sur ce modele. Les min et les max sont bien des multiples de 16 deja. Et si je regarde les courbes, min, median, max, j'ai ca:

A part pour les valeurs trop basses d'offset (de 0 a 5) qui font clipper, on voit que la mediane est centree entre le min et le max et que l'ecart reste constant, peu importe le reglage.

 

 

Bien, maintenant, reprenons ta courbe de mediane en enlevant tes points a 0 et 5. Si je fais passer une droite en forcant l'ordonee a l'origine a 0, j'obtiens effectivement un multiplicateur autour de 67-68. Et oui, c'est un peu suspect. Parce que normalement, une image de capteur 12b, ca n'a que des valeurs multiples de 16 (c'est ca que dit le tuto). Et si c'est un bias, ca a en plus un histo tres ressere. A part qqs pixels qui vont pas bien, la plupart des pixels doivent tomber sur une valeur multiple de 16...

Si je trace tes data, j'ai ca:

 

Si je trace pour la 120MM, j'ai ca:

 

Et je suis bien d'accord que meme en  68, c'est pas un multiple de 16, et c'est bizarre. Le 256 que j'obtiens pour la 120, oui par contre. Et porbablement que 64*offset, c'est plus proche de la verite, mais il faudrait refaire des mesures qui n'ont pas les defauts que je t'ai liste au-dessus pour en avoir le coeur net.

 

1 hour ago, FalCT60 said:

Le capteur est censé être 12 bits (sauf erreur de ma part) pour lequel le tuto stipule qu'il faut utiliser un facteur 16.

Le tuto ne stipule, il dit que c'est qd meme a priori, ce qu'on s'attend a trouver pour les raisons que je t'ai donnees au dessus.

 

1 hour ago, FalCT60 said:

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.

Je comprends pas pourquoi tu utilises 120 comme master offset... Et oui, 832, ca sera plus coherant avec les mesures que tu as faites.

 

1 hour ago, FalCT60 said:

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.

Si tu lis le reste du tuto, l'annexe sur comment les flats corrigent les lights, tu verras que ca pourrait ne pas corriger complétement. Vu que tu utilises une valeur a priori trop petite, tu te rapproches du cas L-D/F. Maintenant, c'est pas le cas le pire, et aussi, l'ampleur du "manque de correction" depend de bcp de facteurs (les gains, l'intensite de tes flats etc etc...). Mais voila, c'et eventuellement ca que tu pourrais observer. 

 

Donc pour resumer, y a qqchose qui va pas dans tes bias de test, il faut chercher par la.

 

Cecile

[lock042]

Il y a 16 heures, FalCT60 a dit :

ne serait-il pas possible de faire en sorte que Siril tienne compte des paramètres régionaux ?

Non. Ça génère des bugs un peu partout ailleurs, même si ça fait longtemps que j'ai pas réessayer. Il est plus simple de gérer les séparateur anglais.

[jDef]

Bonjour

En complément on peut remarquer (en tout cas sur ma PO Uranus-C IMX 585) que la médiane de l'offset dépend à la fois du temps de pose et du gain.

Autour du gain unitaire on retrouve bien un ratio de 64 pour une acquisition du 1 ms, par contre si j'augmente le gain, ce n'est plus exactement le même ratio.

Nota : J'ai obtenu des variations bizarres des statistiques affichées par Sharpcap en diminuant trop le temps d'acquisition, ce qui ne semble plus être le cas avec les nouveaux drivers.

 

L'influence du gain est assez patente sur la forme de l'offset si on regarde les histogrammes (fait sur une image), la bascule HCG se fait ici au gain 210 et offset de 150, 12b, soit théoriquement une valeur de 9600 ADU. on en est pas très loin, sauf lorsque que le gain augmente :

 

Donc l'évaluation 64xOffset reste théorique, par contre c'est toujours un multiple de 16 mais sur une base variable... Il faut donc caractériser la valeur en fonction du gain.

J'ai fait la statistique sur 100 images à G300 O150 et j’obtiens toujours la même valeur de médiane à 9584 ADU.

Sans ouvrir un sujet qui mériterait une discussion spécifique, ce n'est peut-être pas l'offset qui devrait être synthétique, mais le courant d'obscurité qu'il faut optimiser avec un vrai "superbiais" portant les différents défauts du capteur.

 

Cordialement

Jacques

 

 

[FalCT60]

Il y a 10 heures, lock042 a dit :

Non. Ça génère des bugs un peu partout ailleurs, même si ça fait longtemps que j'ai pas réessayer. Il est plus simple de gérer les séparateur anglais.

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

[FalCT60]

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 !

[Cissou8]

2 minutes ago, FalCT60 said:

J'espère toutefois n'avoir pas été con au point de rater les bias !

Sans être con, y a des fois des réglages automatiques un peu cachés dans certains softs qui peuvent produire des résultats inattendus

[lock042]

Il y a 2 heures, Cissou8 a dit :

Sans être con, y a des fois des réglages automatiques un peu cachés dans certains softs qui peuvent produire des résultats inattendus

Une petite balance des blancs a la con par exemple

 

[FalCT60]

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.

[FalCT60]

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.

[FalCT60]

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

Modifié 1 novembre 2023 par FalCT60
Rectificatif

[Cissou8]

Oui, les valeurs générées par NINA sont bien plus cohérentes avec ce qu'on s'attend a trouver (noise qui reste identique quand on change l'offset, valeurs de min et max multiples de 16 etc...).

Tu peux changer l'offset dans le sequenceur de NINA sans avoir a connecter/deconnecter mais c'est un detail. Je ne connais pas EKOS donc je ne peux pas te dire ce qui ne va pas.

 

[Cissou8]

J'ai charge tes images et j'ai regarde leurs tetes. Dans EKOS, tu as un problème de balance des blancs (la boutade que faisait @lock042 plus haut et de la mienne sur les resultats inattendus...), cela n'est pas visible dans tes images NINA.

En gros, c'est le driver ZWO qui, sur certaines de ses cameras couleurs, décide que ça serait une bonne idée de multiplier le rouge et le bleu par des facteurs multiplicateurs. Je crois que ce réglage caché suffit a expliquer tes statistiques peu banales avec ekos. Ça arrive tellement souvent que c'est le premier point de notre section de résolution de problème de calibration... https://siril.readthedocs.io/fr/stable/preprocessing/calibration.html#troubleshooting-calibration

 

Modifié 1 novembre 2023 par Cissou8

[FalCT60]

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.

[lock042]

Il y a 2 heures, FalCT60 a dit :

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 » ?

 

Oui. Refais un vrai dark, et tout rentrera dans l'ordre.

[FalCT60]

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

[Cissou8]

19 minutes ago, FalCT60 said:

Merci. Mais encore faudrait-il pour cela que le problème du pilote fût réglé.

Apparemment, y a deja moyen de le controler: https://www.indilib.org/individuals/devices/cameras/zwo-optics-asi-cameras.html

Regarde la derniere image sur la tab Controls. Y a les champs WB_R et WB_B. Il faut les mettre toutes les 2 a 50.

Modifié 3 novembre 2023 par Cissou8

[FalCT60]

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 ?

[Cissou8]

17 hours ago, FalCT60 said:

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 ?

Le resultat doit etre effectivement ok si tu as traite tes flats avec des bias qui ont le meme "defaut"/"reglage" (selon qu'on voit le verre a moitie vide ou a moitie plein  )

Il est pas bon si tu as applique un offset synthetique. Maintenant, l'ampleur du "pas bon" depend de pleins de facteurs (intensite de tes flats, valeur d'offset synthetique que tu as passe etc etc)

Attention toutefois, avec ce "defaut"/"reglage", on a vite fait de saturer les pixels bleus. Donc il faut que tu sois attentif sur cette couche la en particulier pour voir si ca a fait du degat ou pas

Modifié 4 novembre 2023 par Cissou8

[FalCT60]

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.

Modifié 4 novembre 2023 par FalCT60

[FalCT60]

Bonsoir,

Gros déterrage, mais d'une part j'ai de plus en plus besoin de temps pour assimiler et, d'autre part, les possibilités d'imager ont été rarissimes.

C'est à l'occasion de nouvelles sessions très récentes que j'ai dû me remettre en question. Et tout reprendre du début.

En reprenant mes résultats (obtenus avec une BdB et BdR correctes) et en divisant les valeurs median par 64, je me suis rendu compte qu'elles résultaient offset +1.

Il me semble donc évident que si je souhaite des résultats corrects il me faut renseigner dans siril 64*$offset, car avec 1024 ce n'est bon que pour un offset de 16, or j'utilise 12 lors de mes prises de vues (pour laquelle 768 conviendrait mieux).

J'ignore si l'écart peut être significatif au point d'expliquer le bruit très important que j'ai relevé sur mes traitements récents.

Ou si je me triture une fois de plus les neurones inutilement.

[vinvin]

Ca ne change pas le bruit, ça change la correction des flats.

Je n'ai pas bien compris la logique là, il faut juste diviser la médiane par la valeur d'offset (aussi appelée luminosité chez ZWO).

[180Vision]

On 10/30/2023 at 7:04 AM, lock042 said:

Non. Ça génère des bugs un peu partout ailleurs, même si ça fait longtemps que j'ai pas réessayer. Il est plus simple de gérer les séparateur anglais.

#compassiondudeveloppeur...

[FalCT60]

Passage du sujet en Résolu.