Aaron/openpose tracking #47
Conversation
Co-authored-by: philipqueen <[email protected]>
|
Also something for the future is that in the subprocess call in |
…p/skellytracker into aaron/openpose_tracking
| hand_markers = OpenPoseModelInfo.hand_markers | ||
| face_markers = OpenPoseModelInfo.face_markers | ||
| # Initialize a full array of NaNs for keypoints | ||
| keypoints_array = np.full( |
There was a problem hiding this comment.
I did some work on this class to handle the optional hand + face data better. Do we want to always return the same size array for data output (potentially with nans for hand and face data), or do we want to only include the data being tracked?
There was a problem hiding this comment.
Thanks for doing that, I was gonna tackle that sometime this week so it saves me the trouble. That's a good question, and I'm not sure I have a firm opinion. If we return the same size output, will the splitting/exporting functions down the line essentially create face/hands csvs that are empty?
Oh also I just realized, if all those emptys go into skellyforge, we may get some completely hands and face data if it tries to interpolate those completely empty arrays.
There was a problem hiding this comment.
From a general perspective I support only saving the data we have. Both to reduce wasting unnecessary space, and also to avoid errors like the kind you mention with skellyforge.
However, it may make some of the checks in freemocap more difficult if it's not easy to determine the expected size of the array. We would have to add some method of checking (on the freemocap side) what flags were used to process in order to verify the array is a valid shape. That will be important for multiperson work as well.
|
I did a little cleanup work on this, and once my last 3 comments are answered I think we'll be good to merge it |
| input_video_folder / "output_data" / "raw_data" / "openpose_jsons" | ||
| ) | ||
| openpose_root_folder_path = r"C:\openpose" | ||
| output_json_path = Path(r'C:\openpose\output_json') |
There was a problem hiding this comment.
This path is wrong - the we want the output jsons to be saved within the raw_data folder of the FreeMoCap recording it's running on - not the actual OpenPose demo folder.
This does bring up a point I was thinking about though. Functionally, I realized that this particular parameter shouldn't be a parameter that users change (the openpose_jsons folder should always be in the raw_data folder).
The reason this is a little tricky is because, as far as I understand, none of the other trackers we have so far need to do file saving or management during their run time processes - we pass the data back out to the process_folder_full_of_videos function to take care of that, but for OpenPose we do need to do file I/O, both to save and load the json files. So we need want a way to do some file management specific to the OpenPose tracker. Should we take a version of this code (that's in process_folder_full_of_videos):
if output_folder_path is None:
output_folder_path = (
synchronized_video_path.parent / "output_data" / "raw_data" / file_name
)
and put it in the `openpose_tracker`, but making that `openpose_jsons` folder instead?
There was a problem hiding this comment.
I took a stab at implementing this. Let me know if it works and particularly if the path specified is correct (Path(input_video_filepath).parent.parent / "output_data" / "raw_data" / "openpose_jsons")
…m recorder initialization
|
@philipqueen I fixed up a few things to get the tracker to run properly. Let me know if all seems good. |
pulling in the openpose tracker