Spring 2020
This section outlines my tentative plan for how this course will be delivered remotely. As we all learn more about what works and doesn’t work, I may change how things are done on the fly.
Lectures will be delivered synchronously via Zoom at the scheduled time: MTWF 2:00pm–2:50pm. You will be asked to participate using Socrative (further instructions will be provided) and in break-out groups for peer instruction. Although you should attend the synchronous lectures if at all possible, there will be no penalty for missing the synchronous lectures, and recordings will be made available promptly.
I may use Socrative to conduct in-class polls. You’ll be provided with these instructions the first time we use it, but here they are for your reference:
CSCI497P in the “Room name” fieldZoom lectures will be recorded and posted such that they are viewable only by members of this class. By joining the live lectures you consent to being a part of these recordings. To avoid appearing in lecture recordings, you may take any of the following actions:
Office hours will be held over Zoom. For security, the link is only posted on the Syllabus page of Canvas.
The midterm and final exams will be open-book/open-note take-home exams.
A broad introduction to the fundamentals and applications of computer vision. Topics include basic image processing, the geometry and physics of image formation, multi-view scene reconstruction, segmentation, and detection and recognition of objects.
Note: the actual outcomes for this course may be a pared-down subset of these due to the remote instruction modality. My aim will be to emphasize quality over quantity of topics.
On completion of CSCI 497P, students will demonstrate:
On completion of CSCI 597P, students will additionally demonstrate:
Here’s a tentative schedule that will be updated to reflect reality as the quarter progresses. Lecture materials, assignment writeups, and other materials will also be posted here.
| Date (Week) | Topics | Assignments | Readings |
|---|---|---|---|
| 4/6 (1) | Intro and logistics slides |
Ch 1 | |
| 4/7 | Overview and images slides |
on the recreational use of spreadsheets (video) | |
| 4/8 | Images and filtering slides |
3.1-3.3 | |
| 4/10 | Convolution and filters slides |
3.1-3.3 | |
| 4/13 (2) | Gradients and edges slides |
4.2 | |
| 4/14 | Spatial Frequency and Resampling slides |
3.4, 3.5.2 | |
| 4/15 | Image Pyramids slides |
3.5.3 | |
| 4/17 | Upsampling; Numpy slides demo |
Filters out | numpy quickstart cs231n numpy |
| 4/20 (3) | Feature detection slides |
hw1 soft-launched | 4.1.1 |
| 4/21 | Harris corners slides |
4.1.2 | |
| 4/22 | Feature description and matching slides |
4.1.3 | |
| 4/24 | Feature matching; Transformations 1 slides |
2.1.1–2.1.2 | |
| 4/27 (4) | Transformations 2 - Affine slides |
2.1.1–2.1.2 | |
| 4/28 | Projective transformations; warping slides, demo |
P1 artifact voting open | 3.6 |
| 4/29 | Homogeneous Intuition Alignment: Translation slides |
hw1 due hw2 out |
6.1.1–6.1.3 |
| 5/1 | Alignment: Affine, Homography slides |
Filters due | |
| 5/4 (5) | RANSAC slides |
Pano out | |
| 5/5 | Planar Panoramas slides, notes |
||
| 5/6 | Pinhole Cameras and Projection slides |
||
| 5/8 | Spherical Panoramas slides, notes supplementary spherical slides better notes |
hw2 due | |
| 5/11 (6) | Intrinsics, Extrinsics Depth from Disparity slides |
2.1.5-6, 6.3 | |
| 5/12 | Stereo Reconstruction: Matching, Metrics slides |
||
| 5/13 | Stereo Rectification Plane Sweep Stereo slides, rectification notes, planesweep notes |
||
| 5/15 | Projective geometry 1 slides, live notes, notes |
Pano due midterm out |
7.2 |
| 5/18 (7) | Projective geometry 2; funamental matrix notes, live notes |
midterm due Planesweep out |
|
| 5/19 | Projective geometry 3; SfM slides, live notes, notes |
||
| 5/20 | Intro to Recognition Nearest Neighbor Classification slides, demo, vis.png |
231n: Classification/ | |
| 5/22 | Linear Classifiers Optimization and SGD slides |
231n: Linear Classifiers | |
| 5/25 (8) | No class: Memorial Day | hw3 out | |
| 5/26 | Gradient Descent Neural Networks slides, demo |
Planesweep due |
231n: Optimization 1, 2 Neural networks 1 |
| 5/27 | Neural Networks CNNs slides |
Alexnet out | 231n: Neural networks 1, 2, 3, CNNs |
| 5/29 | Regularization CNNs: interpretation slides, demo.ipynb |
||
| 6/1 (9) | CNNs: training slides |
hw3 due | |
| 6/2 | CNNs: architectures slides |
||
| 6/3 | CNNs: other problems; GANs slides |
Alexnet due | |
| 6/5 | No lecture (but I’ll be there, come by and AMA if you’d like!) | ||
| Final Exam: out 6/8, due 6/11 |
We will use the following textbook. A PDF preprint version is freely available online at http://szeliski.org/Book/.
In response to the move to online instruction, the University has temporarily implemented Pass/No Pass grading by default for Spring quarter. You have the option to request a letter grade instead. To request a letter grade, you must respond to the Canvas Quiz titled SURVEY: OPT IN for Letter Grade. The deadline for making this request is Friday, June 5th.
If you do not opt for a letter grade, the lowest passing grade for all computer science courses is a C-. This differs from the University-wide policy where a D+ is the lowest passing grade. If you don’t respond to the survey by the due date of the survey (Friday, June 5th), the Pass/No Pass grading scheme will be used for you.
Scores will be tracked as usual throughout the quarter, and your most up-to-date score will be visible on Canvas. Your choice of whether to opt-in for a letter grade only affects whether your final score is translated into a letter grade or into a P or NP grade.
Details of the University policy are here: https://provost.wwu.edu/spring-2020-covid-19-grading-policy
For graduate students, the policy is the same as above, with the following differences:
Details of the Graduate school’s policy are here: https://provost.wwu.edu/interim-graduate-grading-policy
Grades will be calculated as a weighted average of scores on the following course components:
Programming assignments will contain add-ons beyond the base project; these add-ons will be required for students in CSCI597P and provide an opportunity for extra credit for students in CSCI497P.
It is expected that everyone will promote a friendly, supportive, and respectful environment in the classroom, labs, and project groups. Everyone’s participation will be equally welcomed and valued.
One reason I am keeping lectures synchronous is to help us all maintain a routine, which is extra important when much of the structure in our lives has been upended by circumstances such as a global pandemic. The synchronous lectures will include exercises and group work that will make your learning experience significantly more interactive and, in my experience, more effective.
However, I am aware of the possiblity that you may have extra constraints imposed by family, work, technology access, or any number of other circumstances. For this reason, lecture recordings will be available and attendance will not be tracked. Participating asynchronously puts more responsibility on you as a student to make sure you’re truly absorbing the material, so if you are able to attend the lectures synchronously, I strongly encourage you to do so.
You have three five “slip days” that you may use at your discretion to submit programming assignments or homework assignments late. Slip days apply only to programming assignments and homework assignments, and can not be applied to any other deadline (e.g., exams). You may use slip days one at a time or together - for example, you might submit each of five assignments one day late, or submit one assignment three days late and another two days late. A slip day moves the deadline by exactly 24 hours from the original deadline; if you go beyond this, you will need to use a second slip day, if available. If there is a separate artifact deadline, a slip day moves both deadlines back by 24 hours.
After your slip days are exhausted, a penalty of 10% * floor(hours_late/24 + 1) - that is, 10% per day late.
To submit your work late, you must push your changes via git (as usual) then send me an email stating that you have submitted the assignment late. The timestamp of the email, which must be sent after your final changes are pushed to git, will be used as the submission time. It is your responsibility to keep track of your slip day balance - no exceptions will be made for accounting errors on your part.
Your programs will be graded on correctness, clarity, and efficiency (in that order).
A correct program is one that always produces the correct output for a given input. Also, a correct program does not produce unintended side-effects. The most effective way to ensure that your program is correct is to test, test, test. Test each component as you introduce it; once you are confident that a component works you can use it in other routines. Try to break your program in testing, and if you succeed, locate the bug and fix it. The better you test your program, the more likely it is to be correct - the more likely it is to be correct, the more likely you’ll earn a good score. Most of your grade will depend on the correctness of your code.
The easier it is to read and maintain your code, the easier it is to locate and remove bugs. Your program should be well organized, appropriately commented, and easy to maintain. To have a well-organized program, design your program thoughtfully and modularly. Think before you code: hacking away blindly leads to ugly, difficult-to-read code. If you do hack away, producing a functional but ugly wall of code, try to clean it up a bit. Make sure that your cleaning does not introduce new bugs.
As for comments, please follow these simple guidelines proposed by Emeritus Professor Osborne:
Your programs should be asymptotically efficient, e.g. checking graph reflexivity should be O(n), insertion into a balanced tree should be O(log n), etc. Do not optimize your code beyond the asymptotic level, as such tweaks are often at the expense of clarity, correctness, or both.
Individual programming assignments are to be completed independently. Students are welcome to discuss assignments with each other on a conceptual level, but each student should be writing their code independently and without direct help from fellow students. Sharing your code with others or looking at someone else’s code is an explicit violation of this collaboration policy. To make sure you are collaborating appropriately, follow these two rules:
Automated tools will be used to check your code for plagiarism at the push of a button. They are not fooled by tricks such as changing variable naming and whitespace: in fact, hiding plagiarism is harder than doing the assignment.
For pair programming assignments, the above policy applies to any collaborations with people outside your group. In addition, the following pair programming best practices must be followed:
Please review the University policies outlined at http://syllabi.wwu.edu regarding:
