Re: [pymecavideo]

Hello,

Coucou :)

> Bonjour à tous et désolé pour la longueur du message, je vais essayer d'être organisé :-)
>
> BRANCHE MASTER (qt4) :
>
>    - Bugs en vrac :
>
>            * [IMPORTANT] joli bug (bug_redim.avi en pj) lors d'une tentative de redimensionnement
>              après avoir commencé le pointage

sûrement à cause du QApplication.instance().processEvents() dans la méthode resizeEvent

>
> * [IMPORTANT] lorsque le pointage a commencé, on ne peut plus utiliser le slider, le
> spinbox ne permet pas que d'avancer dans les images, pas de reculer

Ouaip. Pour moi c'est le comportement normal... Le soucis, c'est qu'avec le spider, on peut trop vite changer d'images. C'est pourquoi je l'avais désactivé.
Ensuite, on peut éventuellement revenir en arrière mais ça c'est plutôt du rôle de 'defaire'... Parce que dans l' idée, au niveau du workflow, je ne vois pas comment un élève peut aller, venir, revenir, refaire, de manière méthodique. C'est pourquoi j'ai implanté le 'sens unique' . Si tu penses que c'est important, on peut facilement l'enlever.

Ce qui est très sensé effectivement. Mais... pas dans le cas du fameux tp ECE !!!!!!!!!!!!!!!!!!!!!
La recherche des positions maximales se fait par tâtonnement, il faut pouvoir aller en avant et en arrière pour trouver la bonne image !

>            * [MINOR] parfois l'image ne remplit pas totalement le label_video (quelques pixels
>          d'écart), ce n'est pas grave sauf si ça joue dans la précision des positions...
> (le ratio est un float, problème d'arrondi au pixel près ?)

T'es sur ? Parce dans l'idée, à partir du moment où tu commences l'acquisition... Le ratio est constant. Donc quelque soit ce que tu cliques, l'échelle reste la même. (soit pas d'échelle, soit une échelle)

A mon avis, la précision ne change pas, les longueurs de changent pas (ce qui est le plus important). Tout est calculé à partir des positions en pixel de toutes façons, le ratio n'intervient pas.

>            * [MINOR] avec une vidéo 640x480, fenêtre au minimum donc normalement 640x480), je
>              n'obtiens des points que de -239 à 239 soit 478 pixels. Pas grave mais Incidence sur la
>              précision du pointage ?

Donc 479 pixels ? :) (il y a le 0)
Je regarderais plus précisément pourquoi. (je n'ai pas encore regardé ton patchwork, car je suis sur mon smartphone là )

Ces deux-là, c'est de la broutille, ne t'embête pas trop avec ça ! Dans toutes les cas, u_calculs <<< u_pointage_eleve :-)
Par contre, j'en ajoute un nouveau:

                 * [IMPORTANT] : on ne peut plus changer l'origine !
                    File "/home/jd/Prog/python/pymecavideo/master/pymecavideo.git/src/label_origine.py", line 57, in mouseReleaseEvent
                    self.app.ui..label_zoom.setPixmap(QPixmap(None))
                    TypeError: QPixmap(): argument 1 has unexpected type 'NoneType'

>     - Module pgraph :
>              * J'ai fait un premier mockup ( en pj, mockup_pgraph.zip) pour vérifier si ça passe avec
>              la branche pyqt5 de pyqtgraph (incluse dans le zip car elle n'est pas encore sortie
>              officiellement). J'ai ajouté l'allure des courbes (points/lignes...) et l'exportation en png.
>
>              * Il faudrait décider ce qu'on fait avec ce module :
>                - possibilité de tracer plusieurs courbes, les superposer, des onglets différents ... ???

La superposition me paraît pédagogiquement 'bof'. Mettre des graphes de grandeurs différentes, d'unités différentes sur la même abscisses...

Tout à fait d'accord, le seul avantage, ce serait d'avoir directement x(t) et y(t) tracés, sans clic supllémentaire

Quand je vois ce que ça donne avec des diagrammes binaires ou ternaires avec des 'prepa' ...

Les binaires, c'est chiant pour tout le monde :-)

Je n'ose imaginer ce que ça va nous donner avec des secondes. Par contre, l'idée des onglets est sympa.
Même si, ergonomiquement, ça nécessite un clic supplémentaire.

Un onglet avec les positions et un onglet avec les vitesses ? Faudrait essayer mais avant il faut décider de comment récupérer les points **

A décider.

>                - je n'ai pas encore regardé comment récupérer les points (self.points ?

A priori oui. Tu trouveras le code qui construit les vitesses dans 'tracer_courbe() ' (de memoire).

) dans
>                  pymecavideo.py pour les envoyer à ce module, mais on choisit bien la courbe à
>                  tracer dans pgraph et plus dans pymecavideo.py ?

A décider.

Pas d'arguments en faveur de l'un ou l' autre. A part que c'est plus facile à déboguer quand le code qui 'construit' est dans pymecavideo...

ça dépendra de ce qu'on fait avec les courbes **

merci à toi pour les tests :)

merci à toi de les fixer 😁