Unified '/project/name' results saving

[glenn-jocher]

This PR attempts to consolidate and simplify saving and logging directory structures with the following arguments for all 3 main files (train.py, detect.py, test.py):

    parser.add_argument('--project', default='runs/train', help='save to project/name')
    parser.add_argument('--name', default='exp', help='save to project/name')
    parser.add_argument('--exist-ok', action='store_true', help='existing project/name ok, do not increment')

Results are first saved to i.e. runs/train/exp, then incremented as runs/train/exp2, runs/train/exp3, etc, unless --exist-ok.

🛠️ PR Summary

_{Made with ❤️ by Ultralytics Actions}

🌟 Summary

Updated directory incrementation and result saving logic in YOLOv5.

📊 Key Changes

• Workflow Update: CI testing pathways for saved weights and detections are simplified.
• Directory Management: Introduced increment_path, replacing increment_dir for clarity in managing run directories.
• Simplified Directories: Removed the creation of default path runs/detect or runs/test, and updated to generate directories dynamically based on project/name format.
• Documentation: Adjusted the tutorial notebook paths to reflect changes in the run directories naming scheme (e.g., exp0 to exp).

🎯 Purpose & Impact

• Ensure consistency in naming run directories across different commands and reduce errors related to hardcoded paths.
• Provide a clearer interface for users to locate and manage their training, testing, and detection outputs.
• Changes make YOLOv5 easier to use and integrate into different workflows due to a more predictable and manageable file structure.
• Overall, this should enhance the user experience and help avoid confusion when navigating between runs.

[glenn-jocher]

@AyushExel I think this works. This essentially replaces --save-dir with --project, and introduces a new --exist-ok argument to prevent incrementing of --name. save_dir is now defined internally as save_dir = increment(opt.project / opt.name)

I'm not really sure if I've helped simplify things or just made them more complicated now. I'll think about this some more.

[glenn-jocher]

/rebase

[glenn-jocher]

/rebase

[glenn-jocher]

@AyushExel one failure mode here maybe be is if the user specifies an empty --project '' or --name ''.

This works locally under all the combinations I tested, but do you know what happens if these are passed to wandb.init()?

[AyushExel]

@glenn-jocher the path separator is not supported in project name in wandb.init() . But as you mentioned it's an edge case. If someone files an error regarding this we can handle it there. I'll run this myself to see where it breaks. But I guess it's safe to merge now

[glenn-jocher]

WARNING: Breaking Changes to Workflows

This PR will modify the logging/saving structure of train.py, test.py, detect.py to bring standardization and industry best practices into YOLOv5 naming conventions. All 3 main files will share a set of common naming arguments below, with results saved to save_dir, defined internally as save_dir = increment(opt.project / opt.name, opt.exist_ok)

    parser.add_argument('--project', default='runs/train', help='save to project/name')
    parser.add_argument('--name', default='exp', help='save to project/name')
    parser.add_argument('--exist-ok', action='store_true', help='existing project/name ok, do not increment')

For train.py with the default arguments, runs are first saved to i.e. runs/train/exp, then incremented as runs/train/exp2, runs/train/exp3, etc, unless --exist-ok, in which case contents will be overwritten and run names will not increment.

You can specify custom projects and run name as:

$ python train.py --project coco --name yolov5s

which will produce coco/yolov5s, then incremented as coco/yolov5s2, coco/yolov5s3, etc, unless --exist-ok.

One new benefit is that W&B logging will be saved to the same project / name in the cloud dashboard as you see locally, helping with commonality.