Apply for AI Grants India

GitHub is useful for computer vision because it brings code, documentation, reviews, automation, and release history into one workflow. It is not, however, a replacement for dataset storage, experiment tracking, or a GPU platform. A reliable project separates these concerns while keeping the decisions needed to reproduce a model close to the code.

For Indian startups, student teams, and research groups, this distinction matters. Data may arrive from low-light CCTV cameras, mobile phones, agricultural fields, factories, or multilingual user interfaces. A model that performs well on a public benchmark can fail when lighting, camera angle, connectivity, or class balance changes. Your GitHub repository should therefore preserve not only the model architecture but also the data definition, evaluation protocol, and deployment assumptions.

Define the computer vision problem first

Choose the task before choosing a repository or architecture:

• Classification: assign one or more labels to an image.
• Object detection: locate and classify objects with bounding boxes.
• Segmentation: label pixels, useful for defects, roads, crops, or medical imagery.
• Pose estimation: identify key points on people, animals, or equipment.
• Tracking: maintain object identities across video frames.
• Optical character recognition: detect and read text, including Indian scripts.

Write a short problem specification in README.md. Include the input format, target classes, latency requirement, acceptable false-positive and false-negative rates, and the hardware on which inference must run. If the project involves public-facing services, document privacy, consent, retention, and anonymisation requirements before collecting data.

Teams working with local languages can also learn from the discipline used in low-resource Indic natural language processing: define representative data splits, record coverage gaps, and avoid treating a single benchmark as evidence of broad performance.

Create a repository that can be reproduced

A practical structure might look like this:

cv-project/
├── .github/workflows/       # CI and release automation
├── configs/                 # YAML or JSON experiment settings
├── data/                    # download and preparation scripts only
├── notebooks/               # exploration, not production logic
├── src/                     # training, inference, and evaluation code
├── tests/                   # preprocessing and metric tests
├── Dockerfile
├── pyproject.toml
├── README.md
└── LICENSE

Keep configuration separate from code. A training configuration should specify the dataset version, image size, augmentation policy, seed, batch size, learning rate, number of epochs, and checkpoint location. Commit the configuration used for every reported result. Pin major dependencies and record the Python and CUDA versions; a requirements.txt, uv.lock, or environment file is more useful than an unbounded list of packages.

Use a .gitignore from the beginning. Exclude raw images, generated predictions, checkpoints, secrets, cache directories, and notebook outputs unless they are deliberately curated artifacts. Add pre-commit checks for formatting, linting, and accidental secret exposure.

Version datasets and labels outside Git

GitHub repositories are poorly suited to large image collections. Store images and annotations in object storage or an approved institutional server, then version their references with DVC or a comparable system. A typical DVC workflow is:

dvc add data/images data/labels
git add data/images.dvc data/labels.dvc .gitignore
git commit -m "version annotated training data"
dvc push

The important artifact is not only the image folder. Preserve label definitions, annotation-tool exports, train-validation-test splits, class mappings, and preprocessing scripts. Prevent leakage by ensuring that frames from the same video, patient, farm, or production line do not appear across multiple splits.

For India-specific deployments, stratify evaluation by language, geography, device, lighting, weather, and network conditions when relevant. An aggregate score can hide severe failures in one region or user group.

Select a baseline before tuning

Start with a pretrained model and a small, repeatable baseline. Ultralytics models are convenient for detection, segmentation, and pose tasks; PyTorch, torchvision, and Hugging Face models provide broader choices for classification and transformer-based vision systems. The repository should explain why a model was selected rather than presenting a catalogue of architectures.

A baseline experiment should answer three questions:

• Does the data pipeline produce correct images, labels, and masks?
• Does the model beat a simple reference, such as a smaller pretrained network?
• Does performance remain acceptable on a held-out, representative test set?

Use task-appropriate metrics. Report precision, recall, F1, mAP, IoU, per-class results, calibration, and inference latency where applicable. Include a confusion matrix and examples of false positives and false negatives. For edge deployments, measure memory use and throughput on the actual target device—not only on a developer GPU.

Do not tune against the test set. Keep it locked, publish the evaluation command, and log model weights, code commit, data version, and configuration for each run. Tools such as MLflow or Weights & Biases can store experiment metadata, while GitHub remains the source of truth for code and review.

Use GitHub Actions for quality gates

CI should test the parts of the system that can fail without a GPU. A pull request workflow can run:

• Python formatting, linting, and type checks.
• Unit tests for resizing, normalisation, label conversion, and post-processing.
• A tiny CPU training or inference smoke test.
• Schema checks for configuration files and annotation manifests.
• Documentation and dependency checks.

Run full training on a self-hosted GPU runner or an external training service, not on every pull request. For important changes, trigger a fixed validation set and compare metrics against a stored baseline. Fail the workflow when accuracy, recall, or latency crosses a defined regression threshold.

Use protected branches and require review for changes to data manifests, evaluation code, and deployment workflows. Developers interested in improving public projects can follow the practical norms in how to contribute to AI GitHub repositories in India, especially around issue reports, licences, and reproducible pull requests.

Package and deploy the model

Separate training from inference. The inference service should load a versioned model, validate inputs, return structured outputs, and expose health and readiness checks. Package it with Docker and publish signed or access-controlled images through GitHub Container Registry or your chosen registry.

Export to ONNX or another runtime only after verifying numerical equivalence against the original framework. Benchmark preprocessing, model execution, and post-processing separately. For low-cost or intermittent-connectivity deployments, consider quantisation, smaller input sizes, batching limits, and local fallback behaviour. A model that is accurate but too slow, power-hungry, or difficult to update is not production-ready.

Add monitoring for confidence distributions, input failures, latency, throughput, drift, and human overrides. Never log sensitive images by default. Establish a rollback path and retain the previous model until the new release has passed production checks.

Secure the repository and respect licences

Never commit API keys, cloud credentials, private datasets, or personally identifiable information. Use GitHub Actions secrets, short-lived cloud identities, secret scanning, and least-privilege permissions. Review licences for datasets, pretrained weights, and dependencies before commercial use; attribution and redistribution conditions vary.

Document the intended use, known limitations, training-data sources, evaluation population, and prohibited uses in a model card. For surveillance, healthcare, employment, or identity-related applications, obtain legal and domain review before deployment. India-based teams should also account for contractual data controls and applicable privacy obligations rather than treating security as a final checklist.

A practical launch checklist

Before publishing a release, verify that:

• A new developer can install the environment and run a smoke test.
• The exact dataset and model versions are recorded.
• Evaluation uses a locked, representative test set.
• CI catches preprocessing and metric regressions.
• The container runs on the target hardware.
• Secrets, raw private data, and oversized binaries are excluded.
• The licence, model card, monitoring plan, and rollback process are documented.

GitHub becomes valuable when it makes a model understandable and repeatable—not merely when it contains a notebook. Build the smallest credible baseline, version every dependency that affects results, automate quality checks, and deploy only after testing the conditions your users will actually face. Teams exploring broader software opportunities can also review best machine learning projects for computer science students for ideas that translate into focused, demonstrable portfolios.