Final Project

Overview

In teams of 3–4, you will ask an empirical question about a computer vision model and answer it with evidence. You'll start from open-source code, working with a real repository is part of the skill.

Your project should focus on asking and answering a measurable question, rather than on building an application. For example, if interested in self-driving cars, you won't set up a problem of "Build a self-driving car", but instead ask whether a detector may fail more on nighttime or rain images. Proposals phrased as a build will be guided towards design of a question.

The final project counts for 35% of your course grade. It is the course's final-week activity, and there is no final exam. Due dates for every milestone are on the Schedule.

Milestones

Percentages are shares of the final project grade, which will be calculated per team. The project seed and team roster sign-up are conducted individually and count toward your participation grade.

Project Lab 1 and project seed (participation)

In the first lab you'll watch several modern models succeed and fail, predicting what happens before each demo. You leave with a project seed: a domain you care about, five images you could get from it, and a prediction of where a model would work and where it would fail.

Project Lab 2 and team roster (participation)

Pitch your seed in 60 seconds to rotating small groups, then form teams of 3–4 (the exact size is set in week 1, once enrollment settles). Anyone still without a team when the roster is due goes on the unmatched list, and the TA places them on teams.

Proposal (15%)

You will be given a template that asks you to answer questions such as:

The question
Your archetype (below)
The repository you'll start from
A data plan
A baseline plan
A fallback, if you chose archetype 6

Check-in (20%)

Check-in will ask each team to answer a series of questions asked in a provided template. As part of your check-in you will be asked to provide a baseline number. A baseline is a simple method with a measured result: random guessing, nearest neighbour, zero-shot CLIP, or the repository's off-the-shelf output. It guarantees you have something to report even if the ambitious part doesn't work. It is also the only way a later result means anything: 87% accuracy is uninterpretable until you know guessing gets 70%. You will also include information such as your revised scope and what's blocking you.

Presentation (25%)

Presentations are in class during the last week. The format (full talks, lightning talks, or a mix) will be announced once enrollment is finalized.

Video + code (40%)

Submit all of the following:

A 3 minute video in a fixed defined order such as: question, baseline, what you did, result, limitation.
A GitHub fork of the repository you started from, submitted as a URL.
A CONTRIBUTION.md file listing every file your team wrote or changed, with one line on why.
Your results.

Six Project Archetypes

Pick one of these shapes. Follow the shape and you will have results by the end of the quarter. Archetypes 1–5 rely mostly on running existing models rather than training new ones, which is what makes them work on limited compute.

Project archetypes, what each produces, and its risk
Archetype	What you produce	Risk
1. Reproduce and stress-test	Reproduce one reported number from an open-source model, then break it on out-of-distribution data you collect. You produce the reproduction plus a robustness curve.	Lowest
2. Head-to-head under a fixed budget	Compare 2–3 open-source models on the same task, data, and compute. You produce a comparison table and a recommendation you defend.	Low
3. Domain transfer	Apply a model trained for one domain to a domain you care about, measure the drop, then try to close it. You produce before/after results and a gap analysis.	Low
4. Ablation / mechanism probe	Systematically remove or change parts of one model to find what matters. You produce an ablation table and an explanation.	Low
5. Failure taxonomy	Collect inputs where a model fails, sort the failures into categories, and test hypotheses about their causes. You produce the taxonomy with evidence for each category. No training needed.	Low
6. Build something new	Build a working system, plus its evaluation.	High: your proposal must name a fallback from archetypes 1–5 using the same repository and data

The course this term does not cover multi-view geometry (homographies, calibration, stereo, structure from motion). You may still propose a project on it, but you'll be learning that material on your own.

Choosing a Starting Repository

The project idea document lists some strong starting repositories that you can work with. Feel free to select your own repository to start from, just use the list below as a check-list to determine if it is a good candidate starter repository:

The README has a working install and a runnable demo or evaluation command.
It had a commit in the last ~2 years, or it's a maintained library such as torchvision, timm, or Hugging Face.
It's an official implementation, or it has a few hundred or more stars.
Pretrained weights are downloadable. Avoid anything that says "train for 8 GPU-days".
It runs on one GPU, meaning free Colab.

Grading Rubric

One rubric covers every project, so an ambitious topic is never graded as "harder" than a modest one. The rubric grades the evidence you show. Each dimension is scored 0, 1, or 2:

There is a question, stated precisely enough to be answerable.
There is a baseline with a number, and it's the right baseline.
There is a comparison or a curve, not a single number.
The evaluation is honest: held-out data, no tuning on test data, limitations stated.
The conclusion follows from the evidence shown, and goes no further.
Your contribution is clearly separated from what the repository already did. This is checked against your fork's diff and your CONTRIBUTION.md.
It's reproducible: someone could re-run it from what you submitted.