Re: [pymecavideo]

[Jean-Baptiste BUTET <ashashiwa@xxxxxxxxx>]

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
>
>            * [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.

>            * [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à )

> BRANCHE csdQT5ui (qt5) :
>
>     - Copyright des icônes :
>              Le fichier icons-credits est complété (en pj car oui,  je n'ose pas encore pusher... :-)

Pff :)

>     - 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...  Quand je vois ce que ça donne avec des diagrammes binaires ou ternaires avec des 'prepa' ...  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. 
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...

Voilou merci à toi pour les tests :)

Jb