Project Requirements for Vision Course

The vision course project is a robustness study: you measure how image-processing and vision algorithms behave as image quality degrades, and how much of the lost performance you can recover. This guide lists what the project has to do, stage by stage, with the anti-patterns that most often weaken each stage, and a suggested weekly plan. How the finished project is graded is a separate question, covered in the Project Assessment Criteria for Vision Course guide.

The Study in Four Stages

Every task/dataset combination runs through the same pipeline. The project is the same experiment repeated across tasks and distortions.

Stage 1

Clean baseline

Run each method on clean images and measure performance against ground truth.

Stage 2

Distortion

Apply distortions at calibrated severities and measure the degradation vs SNR.

Stage 3

Restoration

Enhance the distorted images (denoise, de-rain, low-light) and re-measure.

Stage 4

Fine-tuning

Adapt the deep models to the distortions and compare against restoration.

Stage A. Scope & Selection

What you study and why. Fix these before writing code; document every choice, with links, in the README.

Requirement 1

A Public Dataset with Ground Truth

Select a public dataset (KITTI, Cityscapes, COCO, ADE20K, Oxford-IIIT Pet, DOTA, a medical set, and so on) that carries ground-truth annotations for at least one of your tasks. Load a fixed, seeded subset so results are reproducible.

Common anti-patterns
  • No ground truth, so degradation cannot be measured.
  • An unseeded or shifting subset that changes between runs.
  • A toy dataset too small to show real trends.
Requirement 2

Three Tasks, Low- and High-Level

Choose at least three vision tasks and deliberately span the abstraction range: a low-level classical task (edge/corner/keypoint detection, feature matching) and a high-level task (object detection, segmentation, classification, pose). This is what makes the robustness story interesting.

Common anti-patterns
  • Three variants of the same task.
  • Only deep models, with no classical low-level task.
  • Tasks with no ground-truth metric available.
Requirement 3

Three Distortion Methods

Select at least three distortions that are realistic for your domain: noise (Gaussian, speckle, salt-and-pepper), low light, motion blur, rain, haze, JPEG compression, and the like. Each must be applied at several calibrated severity levels.

Common anti-patterns
  • A single severity, so no degradation curve exists.
  • Distortions irrelevant to the chosen domain.
  • Severity that is not quantified (see Requirement 6).
Requirement 4

A Model or Algorithm per Task

Assign a concrete method to each task, and include at least one deep-learning model (for example YOLO for detection, a SegFormer/DeepLab for segmentation, a ResNet for classification). Classical methods (ORB, Canny, Lucas-Kanade) cover the low-level tasks.

Common anti-patterns
  • No deep-learning model at all.
  • A model that cannot be fine-tuned later (blocks Stage 4).
  • Undocumented model version or weights.

Stage B. Baseline & Degradation

Establish the truth on clean images, then quantify how far each method falls as quality drops.

Requirement 5

Clean-Image Baseline

Run every method on clean images and record its performance against ground truth. This baseline is the reference every later number is compared to, so it must use the correct, task-appropriate metric (IoU/mAP for detection, mIoU/Dice for segmentation, match ratio for features).

Common anti-patterns
  • Reporting a demo output instead of a measured metric.
  • A metric that does not match the task.
  • No baseline, so degradation is uninterpretable.
Requirement 6

Degradation Measured vs SNR

Map distortion severity onto a common physical axis (SNR or PSNR in dB) and report performance as a curve over that axis. This lets distortions of different kinds be compared on one scale and reveals where each method breaks.

Common anti-patterns
  • Severity reported as an arbitrary knob value.
  • A single before/after pair instead of a curve.
  • Different distortions plotted on incomparable axes.
Requirement 7

Per-Class and Per-SNR Reporting

Break performance down per class and per SNR level, not just as a single aggregate. A mean hides that small or rare classes often collapse first under distortion; the per-class view is where the real findings live.

Common anti-patterns
  • One aggregate number for the whole dataset.
  • Averaging away per-class collapse.
  • No table linking metric to class and SNR.

Stage C. Recovery

Two ways to fight degradation: fix the image, or adapt the model. Do both and compare them fairly.

Requirement 8

Image Enhancement / Restoration

For each distortion, apply a matched classical pre-processing step (non-local-means or bilateral denoising, gamma/CLAHE for low light, deblocking for JPEG, deconvolution for blur) and re-measure every task on the restored images.

Common anti-patterns
  • One generic filter applied to every distortion.
  • Judging enhancement by how the image looks, not by the downstream metric.
  • Not re-running the tasks after enhancement.
Requirement 9

Model Fine-Tuning

For the deep-learning methods, fine-tune on distorted (or clean-plus-distorted) data and measure how much performance returns. Where clean labels exist, you may generate training labels from clean images and reuse them for the distorted set.

Common anti-patterns
  • Fine-tuning and evaluating on the same images.
  • No checkpoint or config saved, so it cannot be reproduced.
  • Claiming recovery without a clean-baseline comparison.
Requirement 10

Fair Enhancement-vs-Fine-Tuning Comparison

Put restoration and fine-tuning side by side on the same tasks, distortions, and SNR levels, and state which wins where. The interesting result is usually that the answer depends on the task's level of abstraction.

Common anti-patterns
  • Only trying one recovery strategy.
  • Comparing them on different subsets or metrics.
  • Hiding the cases where recovery failed.

Stage D. Engineering & Documentation

A reader should be able to understand and reproduce the study from the repository alone.

Requirement 11

Reproducible Repository

Ship a GitHub repository with the distortion code, the model-application code, saved outputs and labels, checkpoints or configs, and a documented README recording every choice with links. See the GitHub Submission guide for the full checklist.

Common anti-patterns
  • Results in the slides that no code in the repo produces.
  • Hard-coded local paths and no environment file.
  • A README that lists steps but not decisions.
Requirement 12

Visualization: Before/After & Curves

Document the pipeline visually: images with annotations overlaid, before/after distortion and restoration grids, and measurement plots (bar charts, per-SNR curves, per-class comparisons). The visuals are how the finding is communicated, not decoration.

Common anti-patterns
  • Tables of numbers with no supporting figure.
  • Screenshots with no labels, axes, or captions.
  • No before/after to show what the distortion actually did.
Requirement 13

Slides & Final Submission

Submit the full repository plus presentation slides (PPT and PDF). The slides tell the robustness story end to end: choices, clean baseline, degradation, recovery, and conclusions.

Common anti-patterns
  • Slides that show outputs but never the measured story.
  • Numbers in the slides that disagree with the repo.
  • No conclusion on what recovers performance and when.

Suggested Weekly Plan

A workable cadence from team formation to final submission. Each week produces a concrete artifact in the repository.

WeekTaskArtifact
1Form team, open Git, registerGitHub repo opened; entry in the course project table
2Research and select dataset, distortions, tasksA decision table with links, embedded in the README
3Research and select methods and enhancementsA decision table with links, embedded in the README
4Download data; visualize images and annotationsDownload and EDA code; sample image grid with annotations in the README
5Run methods/models on clean data; save outputsFolder with outputs/labels in the repo
6Measure clean performance using ground truthTable of results; per-class visualization
7Apply distortions; save dataDistortion code; distorted-image folder; before/after visualization
8Run models; measure degradationApplication code; performance tables; annotated comparison visuals
9Apply enhancements; measure performanceSide-by-side grids; performance-comparison visuals
10Fine-tune model(s)Fine-tuning code; checkpoints / model weights
11Measure fine-tuned performanceTable of results in Git; visualization
12Review README; improve visuals, text, tablesA rich, detailed README with all decisions and visualization
13Prepare and upload slides; review repoFull repo; slides (PPT and PDF)