search

Noblis / INVSC-janus

IARPA Janus Program API
Other
9 stars 16 forks source link

Fix for 2 unrelated issues for video processing #42

Closed JordanCheney closed 7 years ago

JordanCheney commented 7 years ago

  1. In the 1N video protocol the video filename wasn't being set properly. This fixes that by forcing the media filename to mirror VIDEO_FILENAME if that header is found in the protocol csv.

  2. In the 1N video protocol ground truth location information is provided for the first frame in which a subject of interest appears to inform implementors who they should be tracking. In the current API this information is passed as const list of janus_associations. This change makes that list non-const so that additional any bounding boxes inferred by a tracking algorithm can be added to the track and made available to the calling application.

@nxwhite-str @carlosdcastillo @stephenrawls could you all review at your convenience?

nxwhite-str commented 7 years ago

@JordanCheney These changes look good to me and I would support them as-is. I have a few minor comments and questions that may or may not be worthy of updates to the code comments (not all new to this update):

1) The field janus_attributes.frame_number is a zero-based index in the current CS protocols. This might be useful to note in the comments as a contractual statement.

2) My interpretation of the comments for the new janus_create_template is that the returned vector, for videos with a single 'seed' annotation, is the provided ground truth box should be the first element of the vector for frame N, and any tracked detections for subsequent frames should be appended to that. Is that correct, or should the ground truth annotation be removed and replaced with the first tracked detection?

3) My assumption also is that the vector of janus_attributes returned for tracked detections in video frames can be sparse (e.g., in the case of missed detections or downsampling frames), and the janus_attributes.frame_number field just needs to be populated correctly. Is that correct?

JordanCheney commented 7 years ago

@nxwhite-str Thanks for the input. The latest push should hopefully address these issues. I'll enumerate my changes below-

  1. Documentation has been updated to indicate the proper use of the frame_number field. I would like to change it to a uint32_t type instead of double but our use of NaN prevents that.

  2. Your interpretation is correct. I tried to highlight that in this line of the documentation-

    If tracking is done, the single frame ground truth track should be extended with any additional information so that the calling function can make use of it.

Please let me know if you think it needs to be more clear.

  1. Again your interpretation is correct. I added another sentence to the documentation to make this more explicit.
nxwhite-str commented 7 years ago

@JordanCheney Thanks for the clarifications, looks good to me.