Student Projects

The Laboratory for AudioVisual Communications works on a number of topics related to signal processing for communications. These range from wavelet theory and applications, to image and video processing, joint source-channel coding and computer vision. Each winter and summer semester a number of projects are offered as term projects for undergraduate students, as doctoral school projects, or as master’s projects.
For a list of currently available projects, please click here.

You can find descriptions of past or ongoing projects here.

For your convenience, here is a list of reminders, requirements and pointers that you should be aware of when applying for a project

Requirements

Doctoral School Projects

It is required that the documentation and presentations of these projects are carried out in English. The grading is determined approximately with the following weights:

  • 50% Effort spent on project, creativity, and achieved results.
  • 25% Quality of the report (maximum 8 pages, excluding appendices).
  • 25% Quality of the presentations, usually semester project presentations are 15 minutes long with additionally 5 minutes for questions.

In contrast to semester projects, it is required that these projects consider the existing state-of-the art (review in presentation and report, reference list).

Please see the EDIC project course regulations page for additional information.

Master’s Projects

It is required that the documentation and presentations of these projects are carried out in English. The grading is determined approximately with the following weights:

  • 50% Effort spent on project, creativity, and achieved results.
  • 25% Quality of the report (at least 30 pages without code and excessively large printed data).
  • 25% Quality of the presentations.

In contrast to semester projects, it is required that these projects consider the existing state-of-the art (review in presentation and report, reference list).

Please see the I&C Master Project web page for additional information.

Semester Projects

It is highly recommended that the documentation and presentations of these projects are carried out in English. This year, we introduced a different form of project management, which is based on a plan completed at the beginning of the project. The students should spend the first 2 weeks of work to understand precisely the goal of the project and acquire the needed background knowledge. At the end of this preparation, a precise plan for the rest of the work should be submitted by filling in the a planning document (available from your supervisor).

The submission is done by sending the document by e-mail to adam.scholefield@epfl.ch.

The grading is based on a weigthed average of different elements of the work. These elements include both the quantity and quality of work, and the presentation (written report, mideterm and final presentation).

Please see the I&C Semester Project web page for additional information.

Guidelines for Presentations

An excellent presentation on how to make presentations can be found on Prof. Markus Püschel’s page (8,25Mb). It contains detailed guidelines for beginners and even useful tips for seasoned veterans. If you are a beginner, some main points to keep in mind are:

  • Length: Fewer slides and more talking is the way to go. Have fewer slides than the length of your talk in minutes or say around 2/3rd of the total length in minutes.
  • It is not possible to explain all aspects of your work in a short talk. Try to use your time to clearly explain the main parts of your work.
  • Stick to the time limit. Practise and time your talk before the actual presentation.
  • Try to have a dry run of your talk and incorporate suggestions from your audience.
  • Tips on slide presentation and content can be found on this link.
  • For presenting comfort, try to use a laser pointer and a remote slide changer.
  • Try to arrive before the talk and test your laptop with the projector to make sure that the display settings are matched to that of the projector. This way you can avoid wasting valuable talking time.

C++ Guidelines

This section is meant for students working with us on projects and writing code in C++. The guidelines are far from exhaustive. While some guidelines are common sense C++ programming tips, some others on this page are purely personal preferences.

Why C when you can C++?
  • If you can write a program in C++, prefer it to C.
  • Programming is even more about debugging, testing, and refactoring.
  • C++ offers a lot of advantages over C and should be an obvious choice, particularly in the light of the previous statement.

Keep it simple silly…
  • Programming has a lot to do with debugging and refactoring. So a well written program should be such that it is easy to debug, and easy to understand, so that it can be refactored whenever needed, by anyone, including yourself 🙂
  • A piece of code can be complex (to understand) only if it offers greater speed in return. But remember, greater speed is needed only in time critical inner loops, not in functions that are called only a couple of times in the whole run.
  • A key to simplicity is understanding the fact that each function your write offers an opportunity to delegate understanding. So try writing programs in such a way that they heirarchially delegate understanding from coarser levels to finer levels.

Programming choices
  • Make each of the functions small, digestible, tasty morsels of code.
  • If one such tasty morsel is called too often in an inner loop, make it an inline function.
  • As far as possible, limit the scope of variables. For instance, if a variable required inside a loop, is reassigned on each iteration, declare it inside the loop.
  • Avoid global variables. Fewer global variables make everyone’s life easier.
  • The idea behind using classes is that they encapsulate data and functions. Said otherwise, each instance of a class holds a certain state, that is stored in the data. So make those variables of code class members, that hold the state in a program. Others can be made local. Though, any number of member variables can be used, they are still global in nature; I still prefer passing variables across function as arguments, to clearly understand which function changes which variable and when.

Comments in code
  • Be generous with comments in your code. I can not emphasize this enough. If you are like me, you will realize how quickly your forget how and why you have written some code. Comments are indispensible for anyone who wants to read your code. Personally, it works better than documentation for me. In addition if you make them doxygen compatible (one way is to just type /// in front of comments that you think should be part of your documentation), you can even have ‘real’ documentation for free.

Code-wise…
  • Avoid goto statements. Usual advice in most C++ programming books. There is always another way to write the program if you have used them.
  • Use the reference operator, &, to pass arguments, avoid using pointers for this purpose.
  • If an argument that is passed to a function does not change within the scope of the function, pass it as a const value. Such little details make it easier to understand code, apart from making it less error-prone
  • Use STL (standard template library) vector class instead of dynamically allocated arrays wherever possible. They are easy to use, are as fast as arrays, can be dynamically allocated, and yet do not need to be deleted after use.
  • Avoid using ?: operators, use if-else instead. Oh by the way, I hear it is faster in execution too besides being easier to understand.
  • Use CamelBack notation to name variables, function and classes. Start the names of variables with small letters and those of classes and function with capitals.
  • Use nice, understandable, short, but descriptive names for variables, functions and classes
  • In general, things seem nice if one uses nouns for names of classes and verbs for names of functions.
  • Note the code below. Try using the same order of spaces as the code below. Start the curly braces on the next line after the for statement, and close them promptly after the last line.
  • for( int x = 0; x < 100; x++ )
    {

    ........
    ........

    }

  • Do not be shy to rewrite one line code of the following form:
  • int x = 100;
    if( somethingIsTrue ) while( x > 0 ) {x--;y++;z++;}

    as:

    int x = 100;
    if( somethingIsTrue )
    {

    while( x > 0 )
    {

    x--;
    y++;
    z++;

    }

    }

  • When in doubt about operator precedence, or even otherwise for easier reading, use parenthesis in mathematical expressions.
  • The statement if( 10 == x ){…} is better than if( x == 10 ){…} because it prevents the common coding error where if( x == 10) can be written as if( x = 10 ), which assigns x with 10 (and returns true) rather than checking if its value is 10.
  • Use m_memberVariableName for member variables, and g_memberVariableName, if you do end up using global variables

Code self checking
  • Use plenty of _ASSERT( value == shouldbethis ) statements in code. Such statements verify the values as expected in say, inner loops where one does not want to be checking values manually.

Of course, every suggestion here can be ignored. The emphasis is mainly on producing code that is more readable, and that helps delegate understanding better