781

(44 replies, posted in General)

Please go to Help > Open log folder and collect the log.txt file and sent it over at joan at kinovea dot org. So I can better understand what is happening. Thanks.

782

(44 replies, posted in General)

Hi dangthuhuongvn,
It could be linked to the Windows locale used for non-Unicode programs causing an issue when loading the video decoding library. There is an open bug submitted a while ago of a similar thing. Most people don't have the issue but on some systems it causes this problem.

Is your Windows in Vietnamese? Can you see thumbnails for images (.gif, .png, .jpg, etc.) they use a different decoder, it would confirm the origin of the problem.

Please check the following setting in Windows: Control panel > Region > Administrative > Language for non-Unicode programs. What is the value of this?

Try to change this to match the language of your system if it's set to English. This is mostly to test the hypothesis, this may have side-effects on the functionality in other programs so keep that in mind if this fixes the issue but you see bugs arising in other programs.

punkduck2064 wrote:

You can see the camera thumbnail, but when you try to capture the video is when you get the error.

What is the error exactly ? Error message saying to try a different format? Black screen? Can you open the camera settings dialog? Can you change the stream format? What is the list of stream formats? Can you paste what the header bar is displaying above the camera screen?

TL;DR: at the end.

This is on the road to being able to export tracked angles and other tracked data.

Persistence is the thing that makes a drawing fade in/out around the frame it was added on.

Currently there are 3 visibility levels:
1. The drawing is shown only on the frame (persistence off).
2. The drawing is shown for a customizable amount of time before/after the frame.
3. The drawing is shown for the entire video ("Always visible").

These options can be customized for each drawing. It's also possible to set defaults in Preferences > Drawings > Persistence. And there is also a checkbox in Preferences > Drawings > General to hide drawings altogether when the video is playing.

Now drawings can also be tracked individually, to review position, length or angle variation over time. When you track a drawing it is always visible as long as it is tracked, and when you stop tracking it reverts back to its original visibility. So if you track a drawing for a while and then turn off tracking, it will usually disappear because its visibility option is to fade out a few frames after the frame it was added on, which is way before. The tracking data is not lost.

Requirement: I want to be able to start/stop tracking the same drawing multiple times. With the current way it works, I have to first set the drawing to "always visible" which is cumbersome: Right click drawing > Persistence > uncheck "Use default value" > check "Always visible".

I started adding an option specific to trackable drawings to let them "show the drawing even if not tracking", but it is redundant with the option of "Always visible" persistence.

Also, I'm not convinced that having fade in/out values customizable "per-drawing" is that useful. It seems to make the whole "persistence" thing unnecessary complicated for most people.

I'm considering the following:
- Drawings are created using the default fading option from the preferences just as it is now.
- The persistence dialog at the drawing level is removed.
- At the drawing level, we can only toggle between "Always visible" or not.
- When "Always visible" is off, the drawing uses the global option from preferences.
- The "Always visible" toggle menu is directly in the drawing's context menu, not in a dialog box as it was with persistence.
- In preferences, merge the whole "Persistence" tab into "General".

TL;DR:
I'm considering simplifying the user interface for "persistence" of drawings, leaving just "Always visible" as a per-drawing toggle. When off it would use a global fade in/out option from preferences.

Q: Is it reasonable to remove per-drawing fading options?

I feel it would make things more straightforward and would allow the most useful toggle to be directly accessible in one click.

Thanks.

The way these exporters work makes it complicated to distinguish these cases. The data is first exported to a Kinovea XML dialect and then converted "declaratively" directly between the XML formats to a target format like ODF, XHTML or Excel XML. It has proved rather burdensome to maintain.

If this is for trajectories, please consider using the "Data analysis" menu on the trajectory itself (in 0.8.25). This will bring a time series plot and can export the data to CSV, either clipboard or file. In this dialog the time coordinates are always numeric.

I'm currently expanding the data analysis dialog and it's possible that at some point it will replace the spreadsheet exporters altogether.

Mail sent.

It's not 100% clear to me, what are you trying to do? If you want to compare two videos, one being 210 fps and the other 240 fps it should be possible.

First, go to Options > Preferences > Playback > General and uncheck "Link speed sliders when comparing videos".

Next you need to find the slow motion factor you will have to apply to one of the video so that their ratios to real time match. This depends on the playback framerate marked in the file (e.g: 30 fps).

Example:
- Video A has a capture framerate of 240 fps, and a playback framerate of 30 fps.
- Video B has a capture framerate of 420 fps, and a playback framerate of 24 fps.
- Let Ra be the ratio to real time of A : 30 / 240 = 0.125.
- Let Rb be the ratio to real time of B : 24 / 420 = 0.0571.
- Let S be the slow down factor to apply to A so that it matches the ratio to real time of B : Rb / Ra = 0.45714.
- By setting video A speed to ~46% of video B speed, you should be able to compare them on equal grounds.
- This speed should be set via the main speed slider.

The formula can be summarized like this:
- slowdown for A = (Ac * Bp)/(Ap * Bc).
- Where Ac and Bc are the capture framerate of A and B, and Ap and Bp are the playback framerate of A and B.

You can read the playback framerate by going to Video > Configure video timing…. In the "Video" section, read the "Framerate read in the file" value.

Please plug your numbers into this and let me know if it works.
I realize this is not trivial, should probably detect this comparison case and offer a way to set this up automatically.

Which version of Kinovea? Can you try with 0.8.25? Do you see the camera thumbnail?

OK, I think I have a fix for the initial black screen on DirectShow cameras, and it could possibly fix the issue for this camera.

Can you help testing this? Let me know if I can use the email address you registered with on the forum or send me a mail at joan at kinovea dot org.

Hum. I should log more context when it fails, as it is there not much information to work with.

It appears that getting one frame on the default stream format is OK but the problem is that we can't get the details of this format. Kinovea needs these details to compute buffer sizes. There is a mechanism to cover for this case in the IP camera module.

I've set the camera at 1280x720 30fps, as the only settings available on the UVC camera on Kinovea

Are you saying the list of stream formats is empty? I'm interested in this list:

http://www.kinovea.org/screencaps/0.8.25/0825-cameraconfig.jpg

.

On the top I see the data for the signal: 29-30 fps and 79 MB/s

Ah, (1280*720*3*30)/(1024*1024) = 79.10 MB/s. So the camera is sending uncompressed RGB24.
I will review the issue that the first time we open the camera we get a black image and need to change the configuration. For cameras that have only one possible configuration it may cause a problem.

That's pretty cool! Thanks for posting this.

I didn't know about the Palette Gear, this is super interesting, I love the modularity of it!

I missed your previous message. It is interesting to know that the thumbnail works but not the video feed. The thumbnail uses a slightly simpler way to capture the image but it means it should be possible to make it work natively in Kinovea.

Could you send me the log file corresponding to trying to open the camera directly in Kinovea?

Hi,
Which version of Kinovea? Can you try on 0.8.25?
When you go in the camera parameters from inside the capture screen, can you list the various image formats and pick a different one. I've noticed that sometimes the default parameter read doesn't correspond to a meaningful combination and black screen results. Picking a configuration among the exposed options usually fixes the issue.

794

(6 replies, posted in Cameras and hardware)

I don't have any experience with this camera. The global shutter + 1224x1024 @ 145 fps definitely sounds interesting on paper if it delivers. They mention "DirectShow" compatibility so yes, it should work with Kinovea.

I didn't know about this vendor, they have several other interesting listings. It's always hard to know if they are the actual manufacturer or just rebranding. They seem to be present on the usual Shenzhen online markets like Aliexpress to get an idea of princing, but this specific model is not listed yet.

I think these guys have the same unit under a different brand. Too bad none of them list the actual imaging sensor, we could have reviewed the claims.

795

(6 replies, posted in Cameras and hardware)

In my experience the camera actually delivers 100fps when set to 120fps. That's the rate at which Kinovea receives the frames anyway.

I'll have to check but I think it's possible amcap is assuming the camera is faithful and writes the requested option in the file descriptor even if it's inaccurate.

Can you film a stopwatch with amcap and verify that the video time keeping is correct compared to the physical stopwatch?