You are not logged in. Please login or register.
Kinovea - Forums → Posts by joan
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:
.
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.
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.
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?
Yeah, after thinking about it I came to the conclusion that this was your use case, replaying a high-speed video at its real time speed.
Currently there is no satisfying way to do it. Tweaking the reference video framerate in order to increase the range of the speed slider is a workaround based on a side effect, I don't think it's a good solution to overload this option with a completely different role than what it was intended for.
The issue is that if you want to replay a say, 1000fps video to real time with the current player, it will need to decode and display these 1000 frames per second, it will most likely fail, which to me means that this use-case requires a different playback approach altogether.
I very much like the idea of being able to go way higher in speed. If we can do 10x we should be able to do 100x because at that point it wouldn't be related to computer perfs.
This would be very useful to quickly parse a long video, and it would provide timelapse out of the box which I think have unexplored applications in sports, to analyze cyclic motions or long term trends in posture.
So, I would say: 1. a new playback approach for very high framerates, most likely by seeking forward in the file instead of decoding frame by frame. 2. a logarithmic speed slider so you have fine control for slow motion but can still go to 100x speed at the other end, 3. an increased size of the speed slider (this is limited by the size of the screen in dual playback configuration at the minimal monitor resolution supported).
The first few times I used the program, I adjusted the video framerate and couldn't figure out why certain things were happening on my playback window
Hmm, changing the video reference framerate should be a very rare action, only when the video file is broken by having an incorrect information written into it which makes it playback faster/slower than expected. Maybe there is another use-case but that's the original reason for adding this option. In particular it should not be used to emulate slow/fast motion. It's a pretty recent addition.
So this is something the user would do once, usually right after opening the video and discovering it's not playing at real-time speed on 100%. At that point the video is considered broken, all bets are off. If we let the capture speed stay at the previous value it would be wrong for the primary use-case of that option (a non-high speed video with incorrect information in it).
For a high speed video the reference framerate written in the file is already not corresponding to real time so I'm not sure why it would ever have to be changed. The scenario would be when a high speed camera is not capturing at the advertised framerate, but even then you would just change the capture framerate, not the reference video framerate.
My feeling is that this video framerate option is too easy to tamper with compared to its role. Maybe the menu should be "Advanced video timing options" or something.
Kinovea - Forums → Posts by joan