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!

[Udayscode]

Hii @niksirbi ,

I’m interested in tackling issue #422 regarding automatic file format inference for pose estimation data in the movement library. I understand the goal is to enhance user experience by reducing friction in data loading.

I propose implementing a system that inspects file extensions and structures to determine the source_format. Renaming source_software to source_format makes sense to accurately represent what can be inferred.

I’d love to discuss this further and get started on a solution. Please let me know your thoughts!

Thanks

[niksirbi]

I propose implementing a system that inspects file extensions and structures to determine the source_format. Renaming source_software to source_format makes sense to accurately represent what can be inferred.

@Udayscode yeah, that's what we had in mind, though we'd have to first openly discuss how the new interface would look like. Since the new loading function will likely become the main entrypoint into movement, we have to make sure it's intuitive and easy to use.

In the interest of working in small steps, which we generally prefer, I'd suggest the following plan:

• First work on a PR to change the existing uses of source_software to source_format (including in tests and docs)
• After we review and merge that, write your proposal (it can be a mockup) for the new loading function here as a comment to this issue, so we can give you early feedback.
• Then open another PR to implement the loading function itself.

Let me know if that sounds like a good plan to you.

[Udayscode]

Hi @niksirbi ,

I’m working on renaming source_software to source_format as per issue #422 and have made the changes in the code, tests, and docs. However, I’m facing some issues while running the full test suite (pytest --cov=movement) locally due to dependency problems.

Here’s what I’ve tried so far:

• Installed dependencies like numpy, pandas, xarray, h5py, attrs, pyyaml, pooch, sleap-io, matplotlib, napari, and tables.
• Got errors like Failed building wheel for vispy and DLL load failed for numexpr with Python 3.13.
• Tried setting up a virtual env and installing Visual C++ Build Tools, but still stuck with build issues.

Could you please guide me on:

1. The minimal setup needed to run the tests locally on Windows?
2. Any specific Python version or tool (like Conda) you recommend to avoid these dependency issues?

I’d really appreciate your help to get past this and submit the PR soon! Let me know if you need more details about the errors I’m seeing.

Thanks,
@Udayscode

[adamltyson]

You could try installing movement with conda including all dependencies:

conda create -n movement-env -c conda-forge movement napari pyqt

Then installing an editable version of movement "on top. This is what I typically do and it works across OSs. More details are here:
https://movement.neuroinformatics.dev/user_guide/installation.html

[niksirbi]

Hi @Udayscode, just to confirm, have you followed these instructions for creating a development environment?

That normally works well for our contributors, including on Windows. If that doesn't work for you, I'd try Adam's suggestion above.