Adding option for output directory in litpose predict

[ElTinmar]

Hi !

Would it be possible to add an argument to the cli to specify an output folder for the predictions? I am running the same model in parallel on several datasets on a computing clusters, and all the predictions end up in the same folder.

Something along the lines of:

    predict_parser.add_argument(
        "--prediction_dir",
        type=Path,
        help="directory where predictions will be saved\n"
    )

    def handle(args):
    """Handle the predict command."""
    # Delay this import because it's slow.
    from lightning_pose.api.model import Model

    model = Model.from_dir2(args.model_dir, hydra_overrides=args.overrides)
    
    # monkey-patching model to store prediction in a specific folder
    if args.prediction_dir is not None:
        model.video_preds_dir = lambda: Path(args.prediction_dir)
        model.labeled_videos_dir = lambda: Path(args.prediction_dir) / 'labeled_videos'
    
    input_paths = [Path(p) for p in args.input_path]

    if model.config.is_multi_view():
        _predict_multi_type_multi_view(
            model, input_paths, args.skip_viz, not args.overwrite, progress_file=args.progress_file
        )
    else:
        for p in input_paths:
            _predict_multi_type(
                model, p, args.skip_viz, not args.overwrite, progress_file=args.progress_file
            )

Thanks a lot for this great piece of software!

[ksikka]

Thanks for the request and glad you're finding the tool useful!

It's possible, but not sure how much value it would provide over simply running predict and then copying the prediction yourself using cp MODEL_DIR/video_preds/<video filename>/* OUTPUT_DIR

any reason that doesn't meet your need?

[ElTinmar]

Hi @ksikka

Thanks a lot for your response!

I have several datasets, and I am encoding experimental parameters in the directory structure:

experiment_videos/
├── control/
│ ├── fish01_session1.mp4
│ ├── fish01_session2.mp4
│ ├── fish02_session1.mp4
│ ├── fish03_session1.mp4
├── treatment_low/
│ ├── fish01_session1.mp4
│ ├── fish01_session2.mp4
│ ├── fish02_session1.mp4
├── treatment_high/
│ ├── fish01_session1.mp4
│ ├── fish02_session1.mp4
│ ├── fish03_session1.mp4
├── sham/
│ ├── fish01_session1.mp4
│ ├── fish02_session1.mp4

The inconvenience I'm facing is that videos from different projects which might have very similar names are mixed up in the same folder (this happens on the cluster because I'm able to run several instances of the model at once on multiple GPUs, one for each folder).

Right now I am implementing your solution by changing the names of the videos (basically flattening the directory structure) and using a regexp to sort them out, but having an extra argument for the output would greatly improve my workflow :)

I would love to see that feature integrated, as it would make the tool more flexible for my use case!

[ksikka]

What you're doing with naming is absolutely the right direction for lightning pose usage, and I suspect it will help you out in general. We recently added this doc about this very topic:
https://lightning-pose.readthedocs.io/en/latest/source/naming_videofiles.html

I can see potential use-case for manually specifying output directory, but in your scenario, your fix seems like much better direction honestly.

[ksikka]

I think I need to make that doc more clear that video filenames should contain all information needed to uniquely identify that video. Video filename should be globally unique across all video files you have.

[ElTinmar]

Thanks a lot for the link to the doc, I had missed that one!

I get your point, even though in my case the project is a bit more complex than the example I've shared, and I find having a nested directory structure slightly easier to manage (backing up or adding / removing a specific condition is a bit easier with directories, as is navigating the project)
I guess that's a philosophical question in the end, and I'll stick to your advice for the time being since I don't really have a very strong argument for the change besides flexibility and convenience for the data structure I already have at hand :)

Thanks again for your help and for the great tool you guys are making !

[ksikka]

It is indeed a philosophical question. Some factors forced our filename-leaning orientation:

• the cloud gui supports uploading video files. Due to browser limitations, we don't get access to the path, just the filename.
• the choice to use the filesystem instead of a database
• related to that, the choice to use user-provided names as references/identifiers for derived or related data. E.g. model prediction storage path, extracted frame path, multi view camera calibration files, bounding box files, etc.
• supporting multi view and in the future multi animal - there are a lot of related files that need to be stored. I.e. bounding boxes for animalN in sessionN in viewN.
• the preference to not make users create CSV files relating all entities and their paths