If a user carefully sets the original_videos field in an ndx-pose PoseEstimation container to match the relative path of their source video files, dandi organize will break them.
dandi organize --update-external-file-paths renames the ImageSeries.external_file paths but leaves PoseEstimation.original_videos untouched, silently breaking the connection between pose estimation data and its source video. Currently, _get_image_series() only scans for pynwb.image.ImageSeries objects in the VIDEO_FILE_MODULES and rename_nwb_external_files() only rewrites container.external_file, with no awareness of ndx-pose's PoseEstimation.original_videos field.
A possible fix: rename_nwb_external_files() already builds a mapping of old paths to new paths for each video file it renames. It could also scan for PoseEstimation containers in the NWB file and apply that same mapping to any original_videos entries that match an old path.
Would this make sense?
If a user carefully sets the
original_videosfield in an ndx-posePoseEstimationcontainer to match the relative path of their source video files,dandi organizewill break them.dandi organize --update-external-file-pathsrenames theImageSeries.external_filepaths but leavesPoseEstimation.original_videosuntouched, silently breaking the connection between pose estimation data and its source video. Currently,_get_image_series()only scans forpynwb.image.ImageSeriesobjects in theVIDEO_FILE_MODULESandrename_nwb_external_files()only rewritescontainer.external_file, with no awareness of ndx-pose'sPoseEstimation.original_videosfield.A possible fix:
rename_nwb_external_files()already builds a mapping of old paths to new paths for each video file it renames. It could also scan forPoseEstimationcontainers in the NWB file and apply that same mapping to anyoriginal_videosentries that match an old path.Would this make sense?