Search options (Page 6 of 135)

Hi,
I looked into perfs a bit. Specifically I have some 4K @ 60 fps videos which are impossible to browse on the timeline.

Could you tell if you are seeing the same:

1. forward playback is actually decent. It's not buttery smooth but it runs without slowing down too much. I measured between 9 and 25 ms per frame to decode, and on average it can sustain about 45-50 fps so it's usable for the purpose of watching the action in real time.

2. forward frame by frame also works. For example holding the keyboard right arrow down and letting it move forward.

3. It's backward frame by frame and clicking around in the timeline that is horrendous.

Do you get the same behavior?

When you get this it's mainly related to the encoding. This particular video is encoded with key frames every 6 seconds (360 frames).

So whenever we click in the timeline, it will randomly drop in the middle of one of these segments. The way video decoding works we get to the previous key frame and then it has to decode all the frames forward until it gets to the target.

So I'm getting 2 or 3 seconds to get the requested position, just because it has to actually decode hundreds of other frames to get there.

As an experiment I exported it back using the export function (export in Kinovea uses MJPEG exactly for this reason, so every frame is a keyframe), and now I can do frame by frame and timeline browsing without issues, on the same 4K 60 fps video. (But yes the file is 10x bigger).

(edit: my computer is not particularly beefy).

Yeah 4K + H.265 is brutal for frame by frame. Pending further investigation the current strategy is to increase the memory buffers in Preferences > Playback > Memory and then reduce the working zone to have it fit in the buffer, then it should be smooth. But that's very limiting at these resolutions, required memory: width*height*3*frames, for 200 frames ~5 GB.

I'm not sure if it's me but the images are quite small and they don't match what you wrote in terms of coordinates.

I will add an option to disable bilinear filtering and pixel offset. Indeed it will be better to test if everything works as expected.

On mouse click the program first receives the mouse coordinates on the video surface, these are integer coordinate in a top-down system. This is converted to image coordinates based on the scaling, panning, rotation and mirror done in the viewport. Then this gets converted to world coordinates based on the active spatial calibration and possibly the lens distortion (+ more complications for camera tracking).

Sub-pixel precision mainly depends on the zoom level. You can go up to 10x zoom so at most you get 10 locations in each dimensions inside the pixel. These are stored as floating point.

Just so you know the code base is going through some heavy refactoring right now related to multi-instance use-case.

You are right that there is no place in the UI that would tell the user which plugins they have installed and loaded correctly or got an issue on load, that would be good to have.

The rest is probably a discussion for github as it's more development related.

For the time being you need to check the logs. Each plugin will write down at least one line when they initialize.

2698 - DEBUG - [Main] - RootKernel - Loading built-in camera managers.
2703 - INFO  - [Main] - CameraTypeManager - Initialized DirectShow camera manager.
2716 - INFO  - [Main] - CameraTypeManager - Initialized IP Camera camera manager.
2717 - INFO  - [Main] - CameraTypeManager - Initialized Camera simulator camera manager.
2717 - DEBUG - [Main] - RootKernel - Loading camera managers plugins.
2731 - DEBUG - [Main] - CameraTypeManager - Loaded camera plugins manifests.
3036 - INFO  - [Main] - CameraTypeManager - Initialized GenICam camera manager.

Regarding logs there were recent changes:
- the logs are now only at level WARN by default so they won't print any of that, you need to go to "Help > Enable debug logs" to see these messages logged.
- the logs are now inside the Logs folder rather than at the root of the application data folder.
- each instance is logging to its own log file.

Then the camera discovery runs at non-regular intervals when you are on the camera explorer tab. For the GenICam plugin you should see the whole tree of GenTL providers. Then while you are on the camera tab you should see the discovery result lines at regular intervals. The interval is adaptive.

343075 - DEBUG - [Main] - CameraTypeManager - Discovered 1 cameras in 1205 ms. (DirectShow: 0 (1 ms), IP Camera: 0 (0 ms), Camera simulator: 1 (0 ms), GenICam: 0 (1204 ms)).

I usually open the log file in BareTail so it auto-update continuously and you can highlight certain words.
https://baremetalsoft.com/baretail/

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).

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.

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.

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.