You are not logged in. Please login or register.
Kinovea - Forums → Posts by joan
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.
Some times the camera is not well placed and it is not 100% horitzontal.
The grid coordinate system should be well suited for this, as it's one of its main purposes. Add a perspective grid and right-click one of the corner and enter the calibrate dialog.
Another thing is to calculate inclinations or an angle between to segments that are not intercontected by an axis of movement. Then an angulus of "four" points would be the point. Digitization is then from distal to proximal in both arms.
Yes, that would be a nice tool to have. It might be doable as a custom tool.
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.
I just thought of the fact that you are filming underwater!
The lens distortion is going to be different due to the refractive index of water vs air. Ideally you should perform the lens distortion calibration underwater as well, not reuse the coefficients computed in air. I don't know exactly how much of a difference it will make but it's worth a test I think.
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.
There is a filtering pass on the raw coordinates to remove the high frequency noise produced by the digitization. There is more information about the exact process and the cutoff frequency selected in the about tab of the data analysis dialog.
The approach comes from sport science literature, I don't know its relevance to burst swim of fishes. But I think it should still be better than the raw coordinates.
The spreadsheet export from the main menu does not have the filtering, it's just the raw data. The shift by 4 frames is strange. Maybe one of those files where the first image has a time coordinate different than zero and cause some issues.
Export through spreadsheet from main menu or export through data analysis dialog from trajectory context menu?
Please try the bug related to zooming in 0.8.24, there were important changes regarding precision since 0.8.15, the coordinates are now stored in subpixel precision. I'm interested to know if you can reproduce it.
The bug where an angle drawing would vanish out of thin air has been fixed for 0.8.25. To avoid the problem in 0.8.24 you should keep the mouse down until the second leg of the angle is placed. 1. mouse down to add the angle, 2. stay mouse down and move away a bit, 3. mouse up.
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.
Hmm. I was going to write that there was an options in the preferences but I just realized this is still only in the unpublished version. I really need to get it out.
Hmm, I hadn't realized they updated to Pylon 5.
I should have posted a follow-up in this thread anyway, back in November a color Basler camera was lent to me for a few weeks so I could fix the issues. I rewrote the Basler interop layer and we did some testing with Pieter and it worked fine for both of us. This was on the dev version of 0.8.25 which exists for x64 in addition to x86.
I've had trouble to get this version out of the way due to other commitments unfortunately. I see now that they made some major changes and it won't work anymore with Pylon 4, ouch.
The capture system is more or less organized in a plug-in manner, so maybe later we could have a capture module working with Pylon 5 that can be dropped in the install directory so that there is a solution for everyone. For now I think 0.8.25 will ship with Pylon 4 support only, and I'll look into v5 later.
Super. Thanks for the follow-up.
For the record we continued the discussion off-line and I sent coachmattb a preversion of 0.8.25 with a bug-fix for testing purposes.
For others with this issue (any network camera should have the issue really), a workaround in 0.8.24 should be possible, by going to the global capture preferences in Options > Preferences > Capture, and in "Display synchronization strategy", select "Camera frame signal" instead of "Forced framerate".
In Kinovea you should use the direct URL to the MJPEG stream, something like http://192.168.0.45:8080/video for IP Webcam app.
There seems to be an issue with the display though, I also can't get a stable stream. Something must be broken…
If you install both using the installer they will share the application data directory and it could create conflicts as the preferences format is not the same.
The usual way to do this is to use the "portable" version for 0.8.24. This way it is completely self-contained and does not interfere.
No, Bluetooth is not involved. Wi-Fi should be turned on on both though.
Use the "Manual connection" button under the camera list and configure from there. The URL information should be found in the mobile app settings or documentation.
A web browser should also be able to connect to the stream, so you might want to test there to pinpoint the origin of the problem.
Kinovea - Forums → Posts by joan