Please take a moment to review this document in order to make the contribution
process easy and effective for everyone involved.
Following these guidelines helps to communicate that you respect the time of
the developers managing and developing this open source project. In return,
they should reciprocate that respect in addressing your issue or assessing
patches and features.
1 - Development environment
Installing a development environment for different operating systems.
Note that the .txt files in the cvat/requirements directory
have pinned dependencies intended for the main target OS/Python version
(the one used in the main Dockerfile).
If you’re unable to install those dependency versions,
you can substitute the corresponding .in files instead.
That way, you’re more likely to be able to install the dependencies,
but their versions might not correspond to those used in production.
Note for Mac users
If you have any problems with installing dependencies from
cvat/requirements/*.txt, you may need to reinstall your system python
In some cases after system update it can be configured incorrectly and cannot compile
some native modules
Make sure Homebrew lib path is in DYLD_LIBRARY_PATH.
For Apple Silicon: export DYLD_LIBRARY_PATH=/opt/homebrew/lib:$DYLD_LIBRARY_PATH
Homebrew will install FFMpeg 5.0 by default, which does not work, so you should install 4.X.
You can install older 4.X FFMpeg using Homebrew like that:
On Mac with Apple Silicon (M1) in order to install TensorFlow you will have
to edit cvat/requirements/base.txt.
Change tensorflow to tensorflow-macos
May need to downgrade version Python to 3.9.* or upgrade version tensorflow-macos
Note for Arch Linux users:
Because PyAV as of version 10.0.0 already works
with FFMPEG5, you may consider changing the av version requirement
in /cvat/cvat/requirements/base.txt to 10.0.0 or higher.
Perform this action before installing cvat requirements from the list mentioned above.
Note: use docker start/stop cvat_db_debug commands to start and stop the container.
If it is removed, data will be removed together with the container.
Apply migrations and create a super user for CVAT:
Start npm UI debug server (run the following command from CVAT root directory):
If you want to run CVAT in localhost:
yarn run start:cvat-ui
If you want to access CVAT from outside of your host:
CVAT_UI_HOST='<YOUR_HOST_IP>' yarn run start:cvat-ui
Open a new terminal window.
Run VScode from the virtual environment (run the following command from CVAT root directory):
source .env/bin/activate && code
Inside VScode, Open CVAT root dir
Select server: debug configuration and run it (F5) to run REST server and its workers
Make sure that Uncaught Exceptions option under breakpoints section is unchecked
If you choose to run CVAT in localhost: Select server: chrome configuration and run it (F5) to open CVAT in Chrome
Alternative: If you changed CVAT_UI_HOST just enter <YOUR_HOST_IP>:3000 in your browser.
You have done! Now it is possible to insert breakpoints and debug server and client of the tool.
Instructions for running tests locally are available here.
Note for Windows users
You develop CVAT under WSL (Windows subsystem for Linux) following next steps.
Following this guide install Ubuntu 18.04 Linux distribution for WSL.
Run Ubuntu using start menu link or execute next command
wsl -d Ubuntu-18.04
Run all commands from this installation guide in WSL Ubuntu shell.
You might have to manually start the redis server in wsl before you can start the configuration inside
Visual Studio Code. You can do this with sudo service redis-server start. Alternatively you can also
use a redis docker image instead of using the redis-server locally.
Note for Mac users
You might have to manually start the redis server. You can do this with redis-server.
Alternatively you can also use a redis docker image instead of using the redis-server locally.
Note for Arch Linux users
You need to start redis and docker services manually in order to begin debugging/running tests:
You have to install nuctl command line tool to build and deploy serverless
functions.
The simplest way to explore Nuclio is to run its graphical user interface (GUI)
of the Nuclio dashboard. All you need in order to run the dashboard is Docker. See
nuclio documentation
for more details.
Deploy a couple of functions.
This will automatically create a cvat Nuclio project to contain the functions.
Information about coding style that is used in CVAT development.
We use the Airbnb JavaScript Style Guide
for JavaScript/TypeScript code with a little exception - we prefer 4 spaces
for indentation of nested blocks and statements.
For Python, we use Black and
isort to enforce the coding style and autoformat files.
Currently, not all components implement formatting, the actual information about the enabled
components is available in the CI checks here
and in the formatting script at dev/format_python_code.sh.
4 - Branching model
Information about the branching model that is used in the project.
origin/master to be the main branch where the source code of
HEAD always reflects a production-ready state
origin/develop to be the main branch where the source code of
HEAD always reflects a state with the latest delivered development
changes for the next release. Some would call this the “integration branch”.
5 - Using the issue tracker
Information and rules for using the issue tracker.
Please do not use the issue tracker for personal support requests (use
Stack Overflow).
Please do not derail or troll issues. Keep the discussion on topic and
respect the opinions of others.
6 - Bug reports
Guidelines and an example of how to report a bug.
A bug is a demonstrable problem that is caused by the code in the repository.
Good bug reports are extremely helpful - thank you!
Guidelines for bug reports:
Use the GitHub issue search — check if the issue has already been
reported.
Check if the issue has been fixed — try to reproduce it using the
latest develop branch in the repository.
Isolate the problem — ideally create a reduced test case.
A good bug report shouldn’t leave others needing to chase you up for more
information. Please try to be as detailed as possible in your report. What is
your environment? What steps will reproduce the issue? What browser(s) and OS
experience the problem? What would you expect to be the outcome? All these
details will help people to fix any potential bugs.
Example:
Short and descriptive example bug report title
A summary of the issue and the browser/OS environment in which it occurs. If
suitable, include the steps required to reproduce the bug.
This is the first step
This is the second step
Further steps, etc.
Any other information you want to share that is relevant to the issue being
reported. This might include the lines of code that you have identified as
causing the bug, and potential solutions (and your opinions on their
merits).
7 - Feature requests
Information on requesting new features.
Feature requests are welcome. But take a moment to find out whether your idea
fits with the scope and aims of the project. It’s up to you to make a strong
case to convince the project’s developers of the merits of this feature. Please
provide as much detail and context as possible.
8 - Pull requests
Instructions on how to create a pull request.
Good pull requests - patches, improvements, new features - are a fantastic
help. They should remain focused in scope and avoid containing unrelated
commits.
Please ask first before embarking on any significant pull request (e.g.
implementing features, refactoring code, porting to a different language),
otherwise you risk spending a lot of time working on something that the
project’s developers might not want to merge into the project.
Please adhere to the coding conventions used throughout a project (indentation,
accurate comments, etc.) and any other requirements (such as test coverage).
Follow this process if you’d like your work considered for inclusion in the
project:
Fork the project, clone your fork,
and configure the remotes:
# Clone your fork of the repo into the current directorygit clone https://github.com/<your-username>/<repo-name># Navigate to the newly cloned directorycd<repo-name># Assign the original repo to a remote called "upstream"git remote add upstream https://github.com/<upstream-owner>/<repo-name>
If you cloned a while ago, get the latest changes from upstream:
Create a new topic branch (off the main project development branch) to
contain your feature, change, or fix:
git checkout -b <topic-branch-name>
Commit your changes in logical chunks. Please adhere to these git commit
message guidelines
or your code is unlikely be merged into the main project. Use Git’s
interactive rebase
feature to tidy up your commits before making them public.
Locally merge (or rebase) the upstream development branch into your topic branch:
file extension. For the importer it can be a comma-separated list.
These parameters are combined to produce a visible name. It can be
set explicitly by the display_name argument.
Importer arguments:
file_object - a file with annotations or dataset
task_data - an instance of TaskData class.
Exporter arguments:
file_object - a file for annotations or dataset
task_data - an instance of TaskData class.
options - format-specific options. save_images is the option to
distinguish if dataset or just annotations are requested.
TaskData provides
many task properties and interfaces to add and read task annotations.
TaskData. shapes - property, an iterator over LabeledShape objects
TaskData. tracks - property, an iterator over Track objects
TaskData. tags - property, an iterator over Tag objects
TaskData. meta - property, a dictionary with task information
TaskData. group_by_frame() - method, returns
an iterator over Frame objects, which groups annotation objects by frame.
Note that TrackedShape s will be represented as LabeledShape s.
TaskData. add_tag(tag) - method,
tag should be an instance of the Tag class
TaskData. add_shape(shape) - method,
shape should be an instance of the Shape class
TaskData. add_track(track) - method,
track should be an instance of the Track class
Sample exporter code:
...# dump meta info if necessary...# iterate over all framesfor frame_annotation in task_data.group_by_frame():# get frame info
image_name = frame_annotation.name
image_width = frame_annotation.width
image_height = frame_annotation.height
# iterate over all shapes on the framefor shape in frame_annotation.labeled_shapes:
label = shape.label
xtl = shape.points[0]
ytl = shape.points[1]
xbr = shape.points[2]
ybr = shape.points[3]# iterate over shape attributesfor attr in shape.attributes:
attr_name = attr.name
attr_value = attr.value
...# dump annotation code
file_object.write(...)...
Silk is a live profiling and inspection tool for the Django framework.
Silk intercepts and stores HTTP requests and database queries before
presenting them in a user interface for further inspection: