The project

COMS4036A — Honours
Brief released Week 3 · proposals due Week 5 · presentations Week 14

The project is 20% of the course and the only piece of work in it that is yours to define. You pick a problem, build something that addresses it, measure whether it worked, and defend the result in a short live session in Week 14.

Groups of up to three, as in the labs. One submission per group, and every member must be able to explain every part of it. The Week 14 Q&A is where that gets checked, and it carries part of the mark individually.

What counts as a project

Something that takes a computer-vision method to a problem and finds out what happens. The method does not have to be new. The finding does not have to be positive. What it has to be is measured: a claim, an experiment that tests it, and a number you are prepared to defend.

Three shapes work well:

Build. A working system for a specific task: a detector for something nobody has a detector for, a segmentation model on data you collected, a pipeline that runs end to end on a phone photograph. Marked on whether it works and on what you measured to establish that.

Compare. Two or three approaches on the same problem, under one fair protocol. The value is in the fairness: same data, same split, same budget, same metric, and an honest account of what you had to hold constant.

Probe. Take a model somebody else trained and find out something its authors did not report: where it fails, what it is really keying on, how it degrades under a shift you construct. The cheapest of the three in compute and the most demanding in thinking.

What does not work: a re-run of a lab with a different dataset; a survey with no experiment; anything whose success condition you cannot state in one sentence before you start.

Scope

Eight weeks, part-time, three people, a free Colab GPU. That is the budget, and it is smaller than it sounds once data collection is in it.

The most common failure is a project that is too big to finish and therefore has nothing measured by Week 14. Design it so that a reduced version is still a result. If your plan is “annotate 2,000 images and train a detector”, the reduced version is “annotate 300 images, train the detector, and report how accuracy moved between 100 and 300”. That is a better project anyway, because it has a curve in it.

The second most common failure is having no baseline. Whatever you build, something simpler should be sitting next to it: a classical method from Chapter 1, a pretrained model used off the shelf, or the majority-class predictor. A number with nothing to compare it to is not a result.

Deliverables and marks

Deliverable	Due	Weight
Proposal (one page)	Tue 18 Aug (Week 5)	2%
Scope check-in (five minutes, no document)	Tue 22 Sep (Week 9)	—
Code repository	Week 14	4%
Report (six pages maximum)	Week 14	8%
Presentation and live Q&A	Week 14 session	6%

The proposal is one page and answers four questions: what problem, what data, what you will measure, and what the baseline is. If you cannot fill a page, the project is not defined yet; if you need three, it is too big.

The check-in is not marked. It exists because Week 9 is the last week in which a project can change shape and still finish. Bring what you have, including the parts that are not working.

The repository is marked on whether somebody else can run it: a README with the setup, the data, and the commands; seeds set; results reproducible from a clean checkout. The habits are the ones the labs have been drilling since Lab 2.

The report is six pages, and shorter is fine. Problem, method, experiment, results, what you would do next. Figures with labelled axes and stated units. Every number in it traceable to something in the repository.

The presentation is short, and the Q&A after it carries part of the mark individually. That is the reason for the “every member can explain every part” rule.

Dates

Week	Date	What happens
3	Tue 4 Aug	Brief and topic lists released
5	Tue 18 Aug	Proposal due
9	Tue 22 Sep	Scope-refinement check-in
14	Tue 27 Oct	Presentations, in an additional session; time to be confirmed

Test 1 is Friday 4 September and Test 2 Friday 9 October, both in the lab slot; the mid-term break is 7–13 September. Nothing here is due in those weeks; the project’s own deadlines are placed around them.

Topics

A starting list, organised by the week that gives you the tools. Anything here can be narrowed, widened, or ignored in favour of your own idea. Weeks are when the method arrives; you can start collecting data before that.

From Weeks 1–3: classical methods, transfer learning

What does a pretrained backbone actually buy on your problem? Take a small dataset you collect yourself, and put a fine-tuned ResNet against Chapter 1’s hand-built pipeline of Gabor or MR8 features into a linear classifier. Report the crossing point in dataset size, as Chapter 3 does for its two recipes.
Fine-grained classification on something local. Indigenous plant species, local bird species, currency, road signs. The interesting part is that the classes look alike, which is where augmentation and probe-depth choices start to matter.
How far can you push a frozen backbone? One backbone, five datasets of increasing distance from ImageNet, linear probes throughout. Chapter 3’s figure does this for two; you would be extending it.

From Weeks 4–5: detection

Count something. Vehicles at an intersection, livestock in a drone frame, cells in a micrograph, stock on a shelf. Counting is a detection problem with an unusually honest metric, because you can check the answer by hand.
A detector for a class no pretrained model has. Annotate it yourself (Lab 5’s skill) and measure how accuracy moves with the number of annotated images. That curve is the project.
What does annotation quality cost? Two people annotate the same images, you measure their disagreement, then train on each set and on their intersection. Lab 5 measures the disagreement; this measures what it does downstream.

From Week 6: segmentation

Segmentation on data with a real user. Medical, agricultural, satellite, or industrial. Talk to somebody who has the problem, and let their definition of “good enough” be your metric.
How little labelled data do you need? Train a U-Net at 10, 30, 100 and 300 masks, with heavy augmentation. U-Net’s original paper claims 30 images was enough for its task; find out what that number is for yours.
The same network, a different target. Chapter 6 ends on the point that a U-Net is a function from image to image. Pick a target that is not segmentation, such as colourisation, super-resolution, or depth from a single view, and build the pairs yourself.

From Weeks 7–8: transformers, and the models that came after

Where does a ViT look? Attention maps on a domain the model was not trained for, against what a human says is relevant.
Prompt-driven segmentation on a hard domain. How much does a promptable segmenter’s mask depend on where you click, and does that dependence get worse on images unlike its training data?

From Weeks 9–11: self-supervision, CLIP, vision–language

Pretrain on unlabelled local data. You almost certainly have more unlabelled images than labelled ones. Does self-supervised pretraining on the unlabelled pile beat ImageNet transfer on the labelled few?
Zero-shot classification, and the prompt. How much of a zero-shot model’s accuracy on your domain moves with the wording of the prompt alone? Report the spread, not the best.
Find a bias and measure it. Not “does the model have biases” but a specific, measurable disparity on a dataset you may lawfully use, with a confidence interval. Read the data-ethics note below first.
Do vision–language models describe your domain correctly? Collect captions for domain images, score them against what a domain expert says, and characterise the failures.

From Week 14: 3D, and the self-study video chapter

The 3D lecture lands in the presentation week itself, and video is a self-study chapter that is never lectured. Both suit groups willing to read ahead and to start collecting data early.

Reconstruct something with your phone. Capture a scene, reconstruct it, and measure the reconstruction against a real dimension you tape-measured.
Video is not a stack of frames. Take a per-frame model, run it on video, and measure how much its predictions flicker. Then fix the flicker and measure that.

Ethics-forward projects

The course carries an ethics thread through every chapter, and a project can sit on it directly: an audit of a deployed system, a provenance study of a dataset in common use, a measurement of who a model fails. These are marked by the same rubric as any other project: a claim, an experiment, a number.

Rules

Data you collect. If your data has people in it, you need their consent, and the consent has to cover what you will do with the images. If it has a third party’s data in it, check the licence before you download it and record what you found in the report. Chapter 1’s provenance discussion is the standard.

Compute. Free Colab. If your plan needs more, raise it at the proposal stage.

AI tools. The course policy in the outline applies. For the project specifically: you remain accountable for every line and every claim, and the Week 14 Q&A is where that is tested. Declare how you used AI tools in the report.

Reusing your own work. A project may build on something you did elsewhere provided you say so and the new work is separable and stated. Submitting the same work for two courses is misconduct.

If you are unsure whether an idea is a project, bring it to a lab session. The answer takes two minutes and is nearly always “yes, but narrower”.

# The project {.unnumbered} **COMS4036A — Honours**\ Brief released Week 3 · proposals due Week 5 · presentations Week 14 The project is 20% of the course and the only piece of work in it that is yours to define. You pick a problem, build something that addresses it, measure whether it worked, and defend the result in a short live session in Week 14. Groups of up to three, as in the labs. One submission per group, and every member must be able to explain every part of it. The Week 14 Q&A is where that gets checked, and it carries part of the mark individually. ## What counts as a project Something that takes a computer-vision method to a problem and finds out what happens. The method does not have to be new. The finding does not have to be positive. What it has to be is *measured*: a claim, an experiment that tests it, and a number you are prepared to defend. Three shapes work well: **Build.** A working system for a specific task: a detector for something nobody has a detector for, a segmentation model on data you collected, a pipeline that runs end to end on a phone photograph. Marked on whether it works and on what you measured to establish that. **Compare.** Two or three approaches on the same problem, under one fair protocol. The value is in the fairness: same data, same split, same budget, same metric, and an honest account of what you had to hold constant. **Probe.** Take a model somebody else trained and find out something its authors did not report: where it fails, what it is really keying on, how it degrades under a shift you construct. The cheapest of the three in compute and the most demanding in thinking. What does not work: a re-run of a lab with a different dataset; a survey with no experiment; anything whose success condition you cannot state in one sentence before you start. ## Scope Eight weeks, part-time, three people, a free Colab GPU. That is the budget, and it is smaller than it sounds once data collection is in it. The most common failure is a project that is too big to finish and therefore has nothing measured by Week 14. Design it so that a reduced version is still a result. If your plan is "annotate 2,000 images and train a detector", the reduced version is "annotate 300 images, train the detector, and report how accuracy moved between 100 and 300". That is a better project anyway, because it has a curve in it. The second most common failure is having no baseline. Whatever you build, something simpler should be sitting next to it: a classical method from Chapter 1, a pretrained model used off the shelf, or the majority-class predictor. A number with nothing to compare it to is not a result. ## Deliverables and marks | Deliverable | Due | Weight | |---|---|---| | Proposal (one page) | Tue 18 Aug (Week 5) | 2% | | Scope check-in (five minutes, no document) | Tue 22 Sep (Week 9) | — | | Code repository | Week 14 | 4% | | Report (six pages maximum) | Week 14 | 8% | | Presentation and live Q&A | Week 14 session | 6% | : {tbl-colwidths="[46,30,24]"} **The proposal** is one page and answers four questions: what problem, what data, what you will measure, and what the baseline is. If you cannot fill a page, the project is not defined yet; if you need three, it is too big. **The check-in** is not marked. It exists because Week 9 is the last week in which a project can change shape and still finish. Bring what you have, including the parts that are not working. **The repository** is marked on whether somebody else can run it: a README with the setup, the data, and the commands; seeds set; results reproducible from a clean checkout. The habits are the ones the labs have been drilling since Lab 2. **The report** is six pages, and shorter is fine. Problem, method, experiment, results, what you would do next. Figures with labelled axes and stated units. Every number in it traceable to something in the repository. **The presentation** is short, and the Q&A after it carries part of the mark individually. That is the reason for the "every member can explain every part" rule. ## Dates | Week | Date | What happens | |---|---|---| | 3 | Tue 4 Aug | Brief and topic lists released | | 5 | Tue 18 Aug | **Proposal due** | | 9 | Tue 22 Sep | Scope-refinement check-in | | 14 | Tue 27 Oct | **Presentations**, in an additional session; time to be confirmed | : {tbl-colwidths="[10,22,68]"} Test 1 is Friday 4 September and Test 2 Friday 9 October, both in the lab slot; the mid-term break is 7–13 September. Nothing here is due in those weeks; the project's own deadlines are placed around them. ## Topics A starting list, organised by the week that gives you the tools. Anything here can be narrowed, widened, or ignored in favour of your own idea. Weeks are when the *method* arrives; you can start collecting data before that. ### From Weeks 1–3: classical methods, transfer learning - **What does a pretrained backbone actually buy on your problem?** Take a small dataset you collect yourself, and put a fine-tuned ResNet against Chapter 1's hand-built pipeline of Gabor or MR8 features into a linear classifier. Report the crossing point in dataset size, as Chapter 3 does for its two recipes. - **Fine-grained classification on something local.** Indigenous plant species, local bird species, currency, road signs. The interesting part is that the classes look alike, which is where augmentation and probe-depth choices start to matter. - **How far can you push a frozen backbone?** One backbone, five datasets of increasing distance from ImageNet, linear probes throughout. Chapter 3's figure does this for two; you would be extending it. ### From Weeks 4–5: detection - **Count something.** Vehicles at an intersection, livestock in a drone frame, cells in a micrograph, stock on a shelf. Counting is a detection problem with an unusually honest metric, because you can check the answer by hand. - **A detector for a class no pretrained model has.** Annotate it yourself (Lab 5's skill) and measure how accuracy moves with the number of annotated images. That curve *is* the project. - **What does annotation quality cost?** Two people annotate the same images, you measure their disagreement, then train on each set and on their intersection. Lab 5 measures the disagreement; this measures what it does downstream. ### From Week 6: segmentation - **Segmentation on data with a real user.** Medical, agricultural, satellite, or industrial. Talk to somebody who has the problem, and let their definition of "good enough" be your metric. - **How little labelled data do you need?** Train a U-Net at 10, 30, 100 and 300 masks, with heavy augmentation. U-Net's original paper claims 30 images was enough for its task; find out what that number is for yours. - **The same network, a different target.** Chapter 6 ends on the point that a U-Net is a function from image to image. Pick a target that is not segmentation, such as colourisation, super-resolution, or depth from a single view, and build the pairs yourself. ### From Weeks 7–8: transformers, and the models that came after - **Where does a ViT look?** Attention maps on a domain the model was not trained for, against what a human says is relevant. - **Prompt-driven segmentation on a hard domain.** How much does a promptable segmenter's mask depend on where you click, and does that dependence get worse on images unlike its training data? ### From Weeks 9–11: self-supervision, CLIP, vision–language - **Pretrain on unlabelled local data.** You almost certainly have more unlabelled images than labelled ones. Does self-supervised pretraining on the unlabelled pile beat ImageNet transfer on the labelled few? - **Zero-shot classification, and the prompt.** How much of a zero-shot model's accuracy on your domain moves with the wording of the prompt alone? Report the spread, not the best. - **Find a bias and measure it.** Not "does the model have biases" but a specific, measurable disparity on a dataset you may lawfully use, with a confidence interval. Read the data-ethics note below first. - **Do vision–language models describe your domain correctly?** Collect captions for domain images, score them against what a domain expert says, and characterise the failures. ### From Week 14: 3D, and the self-study video chapter The 3D lecture lands in the presentation week itself, and video is a self-study chapter that is never lectured. Both suit groups willing to read ahead and to start collecting data early. - **Reconstruct something with your phone.** Capture a scene, reconstruct it, and measure the reconstruction against a real dimension you tape-measured. - **Video is not a stack of frames.** Take a per-frame model, run it on video, and measure how much its predictions flicker. Then fix the flicker and measure that. ### Ethics-forward projects The course carries an ethics thread through every chapter, and a project can sit on it directly: an audit of a deployed system, a provenance study of a dataset in common use, a measurement of who a model fails. These are marked by the same rubric as any other project: a claim, an experiment, a number. ## Rules **Data you collect.** If your data has people in it, you need their consent, and the consent has to cover what you will do with the images. If it has a third party's data in it, check the licence before you download it and record what you found in the report. Chapter 1's provenance discussion is the standard. **Compute.** Free Colab. If your plan needs more, raise it at the proposal stage. **AI tools.** The course policy in the [outline](outline.qmd) applies. For the project specifically: you remain accountable for every line and every claim, and the Week 14 Q&A is where that is tested. Declare how you used AI tools in the report. **Reusing your own work.** A project may build on something you did elsewhere provided you say so and the new work is separable and stated. Submitting the same work for two courses is misconduct. If you are unsure whether an idea is a project, bring it to a lab session. The answer takes two minutes and is nearly always "yes, but narrower".