Search options (Page 54 of 135)

This operation is not currently possible but that's a very good idea!

A slight generalization of this would be "alignment by coordinate systems" or "by calibration", as the approach could also work with the line-based calibration / coordinate system (just origin + scale, axes stay aligned with image axes). Even if less accurate it's often the only calibration available.

Lens distortion correction might also comes into play.

The original goal with superposition was actually to compute this transform matrix automatically, refining it using the video sequence to ignore the foreground layer. I very much like the idea of being able to do something manually before implementing an automation of it.

We need the full homography matrix by the way, not just affine, as it will map arbitrary quad to arbitrary quad. I've been thinking about how to finally build a platform to experiment with these ideas more easily. I also need to revisit and homogenize the matrix maths in some places. No ETA.

Yeah, this is the color model, unfortunately I hadn't been able to test it at the time and 0.8.24 won't work with any of the color models.

The issue should have been fixed for 0.8.25 but the code is still based on Basler Pylon API v4 which was the then-current version when I worked on this last fall. Since then Balser updated their software stack to v5 which will break compatibility. I will have to revisit this for 0.8.26.

Well, the circle tool is more designed as an annotation tool rather than a measurement tool. As such it's not exported in spreadsheet export. The center and radius are saved (in pixels) in the KVA file.

The marker tool is going to be the preferred option to export individual coordinates of things.

Yes the frame shift most likely depends on the format. Or even the encoder in the camera. If you want you can send me a file with the problem so that I can see if it's a bug that could be fixed somehow. Less than 5MB send to joan at kinovea dot org, if more than that host it somewhere else and send me the link.

Regarding filtering, if it's possible, I would still suggest to test a digitization of a file for which you have ground truth available if possible. Ideally coming from a physical measurement system, not from another optical based system. The filtering helps smoothing the minuscule noise introduced by the manual or automated tracking process, where even subpixel placement at 600% zoom might not be enough to get the correct coordinates. I would assume this to be universally beneficial for precision/repeatability.

Note that the radial distortion calibration will also not be perfect, and usually less accurate at the periphery. The tracking works only in 2D so deviation from the the plane of motion is also going to add errors. If you are computing derivatives the noise is going to increase the error. If you compute or save acceleration data for example, I would definitely try to evaluate the accuracy first, to know where you are standing.

Export through spreadsheet from main menu or export through data analysis dialog from trajectory context menu?

A priori non, pas directement compatible. Les flux de type H.264 ne sont pas supportés en capture (Uniquement MJPEG est supporté pour les caméras IP). Il y a des montages possibles avec un soft intermédiaire qui republie le flux localement en MJPEG mais c'est pas forcément génial (latence et recompression à prévoir).

Concernant l'USB il y a possiblité de passer par des adaptateurs USB<->Ethernet. Le flux est capturé à la sortie de la caméra, passe dans le réseau local (cable éthernet ou cablage mural ou CPL), ressort pas loin du PC et revient dans de l'USB avant d'entrer dans le PC. C'est normalement transparent pour les données.

Les ports USB sont effectivement souvent en déficit et il n'y a souvent qu'un seul "root hub" ce qui fait que les appareils sont en compétition pour la bande passante.