Automatically infer file format without requiring source_software

[niksirbi]

Mentioned by @sfmig while reviewing #393.

The drag-and-drop functionality is So Nice - and without realising I was trying to do it all the time with the pose files 😅

Is it worth opening an issue for supporting drag and drop for the data files (for the future)?

I imagine someone using the movement plugin to proofread predictions, and it would be super useful if they can do that as "mechanically" as possible. For example, in an ideal world, the pose file has some link to the video it refers to (maybe simply they share filename), and by dropping the pose file and providing a path where to look for videos, the data can be visualised.

The format of the file would need to be inferred, but maybe we can implement some heuristics for this (for example, if the extension is csv, check the header, and try DLC etc.). I'm sure you have thought about this before, maybe (very probably) there are more pain points than what I am seeing now.

I agree this would be very nice and would reduce friction by a lot!

To do this we need 2 components:

1. The "backend": a general loader function that doesn't require the user to supply source_software but instead infers it by looking at the file extension and structure. Several software share file extensions, but this could be easily resolved by inspecting the file structure (in the case of .h5) and or header (in the case of .csv). Some software share the exact same file format, e.g. DeepLabCut and LightningPose, which is a problem because we currently store source_software as a dataset attribute. If the user doesn't supply that, we cannot disambiguate between such cases. But perhaps we could circumvent the problem by renaming the attribute to source_format instead of source_software. This is much more truthful anyways, because we can only makes assertions about the file format, not about the pose estimation software used (e.g. a user may generate predictions with SLEAP and convert them to DLC format before loading them into movement). This "new generic loader function" is somewhat related to Expose loading functions from main module interface #361, requested by @vigji, and can be tackled together with that.
2. The "frontend": this would be a simple reader napari plugin, which should be trivial to do once the "backend" is in place.

[vigji]

Oh yessss this would be super nice!

[luiztauffer]

+1 to that!