CS448f: Project

Your task

Project Proposal

Due: Thursday Oct 30

In the project proposal you'll briefly describe what you intend to do. You should list your group members (if you're working in a group), what each group member will aim to accomplish, and what ImageStack operations will be created. If the technique you want to implement is simple, you can also consider performing a thorough evaluation, improving the technique, or adapting the technique to a new application. If you want to try something completely new, that's OK too. Here's a sample proposal:

We plan to implement most of the PatchMatch paper from SIGGRAPH 2009. We'll add a -patchmatch operator to ImageStack, which computes the nearest neighbour field between the top two images on the stack. We will both work on this part together. We'll then use this operator to implement the retargeting and inpainting applications described in the paper. This will add a -retarget operator to ImageStack, which has the same interface as -resample but performs content-sensitive retargeting instead. Jen will do this aspect of the project. We will also add an -inpaint operator, which takes an image and a binary mask, and replaces areas in the image where the mask is zero with plausible content using the algorithm described in the paper. Andrew will do this aspect of the project. If we have extra time, we may also implement a GUI for specifying the geometric constraints as described in the paper. This GUI would use ImageStack as a library.

Submit your project proposal by emailing it to us at cs448f-aut0910-staff@lists.stanford.edu. We'll get back to you as soon as we can. A list of suggested project topics can be found here. Ideally, all project implementations will be unique, so if multiple people want to work on one paper implementation, we would suggest forming a group.

Paper Presentation

You'll use half of one class to present your selected paper to the class. After your presentation everyone should have a fair idea of how to go about implementing that technique and what it's useful for. If the paper has a video, you might like to show that as part of your presentation. You should aim for 20 minutes worth of slides (which usually means 20-30 slides). We'll then discuss the paper for 15 minutes or so before moving on to the next one.

The presentation has two goals. It should be educational for all of us, and it should serve as a milestone in your project, so you're not tempted to put it off until the last minute. Therefore, we'll judge your presentation according to both how well you explain the paper, and also by how far along you are relative to the date of the presentation. If you give a presentation in a later slot, we'd like to see some preliminary results. If you give a presentation in an early slot it's fine to just describe the paper. Whoever takes the first two presentation slots will be graded quite leniently.

Final Demo and Submission

In the last week of class, each group will give a quick (10 minute) demonstration of their results and findings. Ideally your chosen technique will do all sorts of cool things that you can demo for us. However, if you find that it's is not useful at all, because it has key flaws, then that's also a useful result for the rest of us to know. Negative results are rarely published, but they are often just as useful as positive results. In a case like that you should submit both your code and an analysis of the technique demonstrating its flaws.

You should email your final codebase to us at the usual address before midnight on the Sunday at the end of quarter (December 6 11:59pm). This will give you a few days after the presentation to clean up your code for submission.

Grading Criteria

The class project is worth 40% of your final grade. 10% is for your paper presentation, and 30% is for your final demo and submitted materials. Your submitted materials will be evaluated by Jen and I according to how much you did (taking into account the difficulty), how robust it is, and how useful your code will be to others in the future. Usefulness is determined by writing clean, well-commented code, and also by adding operations which are as general as possible, so that they're useful for a variety of applications. Everyone's project will be different, so we don't intend to break down this 30% into sub-categories.

Presentation Schedule

Remember, no late days can be used on the project, since you must present on your scheduled presentation day.

Tue Nov 3: Either presentations or a lecture, depending on how many groups there are

Thu Nov 5: Presentations by ...

Tue Nov 10: Presentations by ...

Thu Nov 12: Presentations by ...

Tue Nov 17: Presentations by ...

Thu Nov 19: Either presentations or a lecture

THANKSGIVING

Tue Dec 1: Final Demos by ...

Thu Dec 3: Final Demos by ...

Sun Dec 6: Code and any analysis due by 11:59pm