search

mooch443 / trex

TRex, a fast multi-animal tracking system with markerless identification, and 2D estimation of posture and visual fields.
https://trex.run
GNU General Public License v3.0
82 stars 8 forks source link

frame_rate doesn't seem to map predictably across parameters #190

Closed aperkes closed 8 months ago

aperkes commented 1 year ago

I have videos recorded at 1 fps, but played back at 25 fps, and I noticed that setting the frame_rate to 1 fps does not seem to be mapped throughout the various speed calculations. So the speed values end up being a little silly (In my case, 100 cm/s, when the fish is only moving a few cm's), and makes finding the right speed range less intuitive. I'm guessing the speed either keeps using default value, or is using the meta info from the video

This also seems to be the case for "track_max_reassign_time", which seems to go off the meta fps rather than the set fps.

It seems like it would make more sense for the set frame rate to be used in the calculation of speed/time.

Alternatively (or really regardless), it would be great to have additional info in the documentation that makes it clear which parameters are impacted by the set frame rate.

mooch443 commented 1 year ago

Sorry for the silly speed values :-) I presume that in your case it is using meta data from the video, which is likely set to 1fps from the .mp4 file or whatever. You should be able to overwrite this by setting frame_rate manually during the conversion.

Are you saying this does not work, or did you try entering it in TRex? Setting frame_rate in TGrabs manipulates how timestamps are generated for each frame. These are then saved to the .pv video format and used for important calculations - frame_rate was included in TRex from the beginning, but read-only. Just FYI, basically. Atm it can be changed on startup, but basically mostly affects GUI functionality and calculation of some tracking properties. You are correct in that this should probably be more consistent. I have updated the documentation, but haven't uploaded it yet since that would also change other unrelated things.

Currently, I suggest changing this when you're converting the video - also because it makes sense to set this meta data only once and then have it be part of your video file (in my opinion).

aperkes commented 1 year ago

I only tried setting it in Trex, I'll be less sloppy and just set it in Tgrabs or during ffmpeg conversion (In my defense, I do actually want the video to play back at 25 fps, because watching them at 1 fps is a drag, so Tgrabs is probably the place i'll set it.)

Thanks!

On Mon, Feb 6, 2023 at 2:45 PM Tristan Walter @.***> wrote:

Sorry for the silly speed values :-) I presume that in your case it is using meta data from the video, which is likely set to 1fps from the .mp4 file or whatever. You should be able to overwrite this by setting frame_rate manually during the conversion.

Are you saying this does not work, or did you try entering it in TRex? Setting frame_rate in TGrabs manipulates how timestamps are generated for each frame. These are then saved to the .pv video format and used for important calculations - frame_rate was included in TRex from the beginning, but read-only. Just FYI, basically. Atm it can be changed on startup, but basically mostly affects GUI functionality and calculation of some tracking properties. You are correct in that this should probably be more consistent. I have updated the documentation, but haven't uploaded it yet since that would also change other unrelated things.

Currently, I suggest changing this when you're converting the video - also because it makes sense to set this meta data only once and then have it be part of your video file (in my opinion).

— Reply to this email directly, view it on GitHub https://github.com/mooch443/trex/issues/190#issuecomment-1419885757, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRNK6RYAGECVMTI5M62I6DWWF5H5ANCNFSM6AAAAAAUPMB5TY . You are receiving this because you authored the thread.Message ID: @.***>

mooch443 commented 8 months ago

For future reference. track_enforce_frame_rate specifically addresses the disconnect between frame_rate and output data in 2.0. This means finally the frame_rate can be changed dynamically:

Enforce the frame_rate and override the frame_rate provided by the video file for calculating kinematic properties and probabilities. If this is not enabled, frame_rate is only a cosmetic property that influences the GUI and not exported data (for example).