Refer to the build instructions if you're interested in building the application yourself or running it in Python.
The project is setup to automatically configure VSCode witht he proper extensions and settings. Linters and formatters will be run on save.
If you use a different IDE or for some reason cannot / don't want to use the recommended extensions, you can run scripts/lint.ps1.
If you like to use pre-commit hooks, .pre-commit-config.yaml is setup for such uses.
The CI will automatically fix and commit any autofixable issue your changes may have.
If your pull request is meant to address an open issue, please link it as part of your Pull Request description. If it would close said issue, please use a closing keyword.
Try not to Force Push once your Pull Request is open, unless absolutely necessary. It is easier for reviewers to keep track of reviewed and new changes if you don't. The Pull Request should be squashed-merged anyway.
Your Pull Request has to pass all checks ot be accepted. If it is still a work-in-progress, please mark it as draft.
Most coding standards will be enforced by automated tooling. As time goes on, project-specific standards and "gotchas" in the frameworks we use will be listed here.
Please avoid using magic numbers and prefer constants and enums that have a meaningful name when possible.
If a constant is shared throughout the app, it should live in src/utils.py. Unless it is very-specific to a module.
For image shape and channels, please use utils.ImageShape and utils.ColorChannel.
To avoid image shape mismatch issues, and to keep code simpler, we standardize the image color format to BGRA. This should always be done early in the pipeline, so whatever functionality takes care of obtaining an image should also ensure its color format. You can do so with cv2.cvtColor (ie: cv2.cvtColor(image, cv2.COLOR_RGBA2BGRA) or cv2.cvtColor(image, cv2.COLOR_BGR2BGRA)).
None 😦 Please help us create test suites, we lack the time, but we really want (need!) them. #216