Analyse d'EP dans une cave: méthode Starlink par bibi ;)

[eroyer 567]

Bonjour gehelem,

je prend la conversation en route et même si j'ai tout lu, je ne suis pas sûr d'avoir bien compris ce que tu calcules. D'abord, ton idée d' "encodeur optique maison" est très bonne et je pense qu'elle a un beau potentiel.

Est-ce que tu peux me confirmer que ton algo consiste à :

- prendre une image I1

- attendre que la monture tourne un peu pendant une durée delta_t

- prendre une image I2

- utiliser match_template() d'openCV pour calculer le déplacement d'un motif entre I1 et I2 (si c'est le cas, quel motif ? toute l'image ou juste une portion ?

- traduire le déplacement donné par match_template en valeur angulaire de rotation du disque et calculer l'écart entre cet angle mesuré sur 'image et l'angle correspondant à la vitesse sidérale dans l'intervalle delta_t

 

Si c'est le cas, j'ai peut-être quelques idées pour améliorer les choses.

 

 

[gehelem 174]

il y a 15 minutes, eroyer a dit :

Si c'est le cas

oui en gros c'est ça, il te manque juste l'étape "subpixel" :

en gros avec le montage de base le mouvement reste très lent (environ 2 pixels par seconde)

et la méthode de matchtemplage ne détecte que des pixels entiers, entre les deux on ne voit rien

donc on ajoute une méthode supplémentaire d'approximation de la fraction de mouvement entre deux images

il y a 18 minutes, eroyer a dit :

j'ai peut-être quelques idées

zyva !

 

 

[gehelem 174]

Il y a 11 heures, Cyrille Thieullet a dit :

(...) Le subpixel  (...)

 

 

Excuse moi je vais résumer ma compréhension :

Tu indiques en gros "bah oui c'est normal on s'y attendait"

(et merci pour tous ces développements !)

 

Du coup je vais plus loin : il faut benner cette méthode de calcul du subpixel et en trouver une autre.

Moi ça ne me convient pas du tout, il me faut un truc qui passe mon test sans faire de vague.

A la limite on pourrait acter de cette réponse non linéaire, et la compenser dans l'autre sens ...

J'avais déjà mal à la tête, là ça va être l'AVC direct

 

 

[Cyrille Thieullet 100]

14 minutes ago, gehelem said:

A la limite on pourrait acter de cette réponse non linéaire, et la compenser dans l'autre sens ...

Oui, c'est l'aspect filtrage dont je parlais. Ca sera jamais une droite. Avec le bruit en amont je ne sais pas si ca servira.

De quelle précision as tu besoin ?

Là tu passe de 7arc rms à 0.44. Tu veux descendre à combien ?

 

 

47 minutes ago, eroyer said:

Si c'est le cas, j'ai peut-être quelques idées pour améliorer les choses.

@eroyer Top !

 

[eroyer 567]

Je pense que match_template n'est pas le plus adapté pour ce cas, en plus qu'il ne donne pas de précision subpixellique.

En fait dans ce montage, le mouvement de l'image est une rotation et pas une translation. Idéalement, il faudrait chercher l'angle de la rotation qui minimise la différence d'image entre I1 et R(I2). Avec une minimisation itérative dans laquelle la fonction à minimiser est la différence d'images et la variable est l'angle de la rotation, on doit avoir un résultat plus précis. Il y a des algos d'optimisation dans scipy pour faire ce genre de choses mais c'est délicat à implémenter si on ne l'a jamais fait.

Sinon en plus simple, sans faire de code et juste pour voir ce que ça donne pour savoir si ça vaut le coup de creuser l'idée, tu pourrais utiliser un logiciel de création de panorama (par exemple hugin : https://hugin.sourceforge.io/ ). Tu rentres une série d'images dans le logiciel et il va chercher des points d'intérêt communs dans les images pour calculer une homographie entre chaque paire d'images avec un recouvrement et optimiser tout ça. Et ça donne en général un résultat très précis sur les déplacements d'image à image. Bien sûr, on est pas sur une intégration temps réel mais ça permet sans code de voir si ce type d'algo peut marcher sur tes images. Si ça fonctionne, ce n'est pas très difficile de reproduire un algo équivalent avec openCV car il y a toutes les briques de base disponibles.

[gehelem 174]

il y a 41 minutes, Cyrille Thieullet a dit :

De quelle précision as tu besoin ?

 

en tout franchise j'ai hâte déjà de voir si ce 0.44" n'est pas un peu usurpé :

j'ai tellement cuisiné le truc que je suis convaincu que j'ai arnaqué quelque part

 

Mais sinon si tout es réglo, à mon avis ce n'est pas la peine de descendre beaucoup plus bas.

Dans le cadre de la compensation en live, c'est à mon avis superflu d'essayer de descendre sous les 0.1-0.2"

Donc gagner encore un facteur 4 serait idéal, mais après on tombe largement sous la turbu c'est ridicule sauf à vouloir caractériser complètement son EP, les petits rouages les trucs précis etc etc.

 

J'ai donc commencé à faire comme toi, avec un vrai montage de l'objectif de microscope qui me fait monter à 8 pixels / seconde (et donc échantillonnage de  1.9arcs) , ça se voit vraiment bien.

Sauf que j'ai tout démonté ce matin :

je repasse avec le microscope USB d'origine, pour pouvoir tester sur la petite fenêtre de ciel clair qui semble bien vouloir se présenter ...

 

 

[gehelem 174]

[eroyer 567]

S'il y a quelques étoiles ce soir, le résultat promet d'être intéressant !

[gehelem 174]

en direct de mon jardin :

soucis "annexes" avec ma monture, rien à voir avec le procédé lui même, mais mes tests sont compromis pour ce soir

 

Et sinon tout de même un enseignement, la rosée sur le CD : on valide ?

Edited Saturday at 09:32 PM by gehelem

[Cyrille Thieullet 100]

Bonjour,

 

On 12/2/2023 at 10:22 PM, gehelem said:

mes tests sont compromis pour ce soir

Ah flute ! Rien, même pas  une photo pour voir le suivi ?

 

Très bon test pour la rosée, ca rajoute des trucs aléatoires ! Top.

Le drift est en arc sec ?

 

Cyrille

[gehelem 174]

il y a 40 minutes, Cyrille Thieullet a dit :

flute ! Rien, même pas  une photo pour voir le suivi ?

Non, impossible de faire une MES même pourrie, il faut que je repasse sur une monture et un driver indi que je maîtrise, c'est chiant.

 

Unité du graphe = arcs

La rosée = non, si la goutte bouge c'est cuit :-)