46

(9 replies, posted in General)

Hi,  I will look into the dual replay sync issues. Could you describe the image size and frame rate of each camera, I'll emulate the same to investigate. They are both 720 x 540 @520 fps?

For color, when you are using a Bayer stream format (telltale is the little grid pattern on top of the black and white frames) you have two options:

1. Debayering on the fly: in the camera parameters check the "Enable software demosaicing". This will add a little overhead so if it makes things even worse regarding dropped frames try the second option.

2. Debayering during playback: in Preferences > Capture > General > Record uncompressed video. This ensures the raw frames are saved as-is to the file which is necessary for this to work as we need pixel perfect precision to retain the Bayer grid data all the way. Then when loading videos in the player: Image > Demosaicing and selecting the Bayer format. Note that these raw uncompressed files are not supported by many media players and those that support it might not have the option to rebuild color during playback.

For the first approach I realize that since you are using "retroactive" mode there could be a third way where the debayering is done at the end during the saving process. This is not implemented at the moment.

(color cameras always start with these patterned B&W images but they do the debayering on the hardware, which is not necessarily faster and requires 3 times the bandwidth, that's why the only way to get the top frame rate advertised by the vendor is to go with the bayer format. Also don't bother with the higher bit depth formats like 10 bit or 12 bit, Kinovea doesn't use them, they get converted the same and just eat bandwidth for no additional benefit).

Debes hacer una calibración del espacio con una linea o una cuadrícula. Haz clic derecho y "Calibrar".
https://www.kinovea.org/help/en/measure … ation.html

48

(1 replies, posted in Bug reports)

Hi, that definitely sounds like a bug.
Could you connect to one of the machine and go to the log folder (via help menu) and then collect the files whose name start with "Unhandled exception"? These contain the last things the program was doing before the issue and will help me identify exactly where the problem is. Send them to joan at kinovea dot org or create an issue on github and attach them there.
If possible also collect the log.txt and log.txt.1 files, send these ones via mail only as they can sometimes contain personal data like file paths.
Thank you.

49

(2 replies, posted in General)

Currently there is no option to default the trigger to "armed" but it can be added, I'll write it down.

50

(2 replies, posted in General)

Hi, sorry for the late response.

In general users don't see or use the image based coordinates. The pixel coordinates (when there is no calibration) is aligned to the bottom-left of the pixels, not to their centers.
There are several confounding factors, in particular the way the image is painted on screen with pixel offset and bilinear interpolation. But arithmetic between pixel locations should work the same. Several functions return fractional pixel positions (zooming in, tracking, calibration).

It's hard to describe without making things even more confusing, so I'll post an image. This is a 4x4 image magnified, with the 4 center pixels colored in. I disabled pixel offset and bilinear interpolation (this could be an option if you need this for research). In yellow is Kinovea default coordinate system.

https://www.kinovea.org/screencaps/2024.1/pixel-grid-coordinates.png

So if your image coordinates start at the top-left of the top-left pixel, then the center is at 2, 2. This is what the KVA file will store in the calibration node. If your image coordinates start at the center of the top-left pixel, then the center is at 1.5, 1.5, which is maybe what you expected.

But as mentioned this is confounded by the rendering options, pixel offset mode will make it so everything is pre-offset by half a pixel, this is relevant when the user selects locations in the image. I'm not saying this is bug-free, but the tracking work done last autumn makes me think there is no issue that would be as large as a half pixel, let me know if you find something problematic.

I think the only moment where this would be relevant is if you have an external system giving you pixel-based coordinates.

Are you talking about having a video that you review and you want to share your feedback in live with the student while you both look at the video? I consider this outside the scope of the program, mainly because there are many external software that let you do this easily.

For this you can use anything that let you share your screen or a specific window. Video conferencing applications typically have this, probably the most natural solution in a remote training scenario since you would already be using this to communicate. So Zoom, Google Meet, Teams, etc. should all work, look for their screen sharing feature. Instant messaging apps like Whatsapp or Discord also have this.

Or are you talking about getting the live feed of the student while they are doing an exercise, and you receive their video stream as fast as possible so you can give them feedback in near real time? Where it's the student that's doing the broadcasting? Maybe by saving the files on an online drive.

No, right now there is no way to snap the time of the cells to match key images.

53

(2 replies, posted in General)

There is not really any mechanism to load CSV files at the moment but it could be done. What does the data contain?

Hi,
Unfortunately there is a bug with dual recording commands in the released version. The ones for single capture screen should work, can you confirm that? This script seems massively useful.

I fixed the issue in the source code a while back but haven't made progress on the other things I wanted to include in the next release.

This is great, thanks!

56

(1 replies, posted in General)

Yes, the program still doesn't support sound at the moment.

When opening a new file it limits the number of thumbnails created to a small number to avoid it taking too long and only creates the thumbnails later when navigating to them.

Hi, yes it's possible. You need version 2024.1 and then you use ALT key + scroll backward or forward with the mouse wheel while hovering above the cell. This will change the time reference of the cell.

I added some documentation here: https://www.kinovea.org/en/forum/viewtopic.php?id=1973

It won't automatically import the key images you have previously selected. It's an independent process, you'll have to configure the kinogram for say, 5x1 cells first, and then move each cell in time to find the right spot.

Sorry about the crash. I think it's likely related to the thumbnails that are created for each key frame, both in the bottom area and the side area. Not sure what the best solution is to address this.

60

(18 replies, posted in Cameras and hardware)

alkaman wrote:
joan wrote:

It appears the issue with FLIR cameras is that when you have two of them of the same model connected at the same time, the identifier we use doesn't differentiate between them and this causes a crash. Single camera should work.

Is there a possibility that this will be enhanced/fixed in the future to allow for 2 of the same FLIR cameras to work? Or is this just a permanent shortcoming of the driver(s)?

Yes it should be fixable.