GSoC qualifying projects

We will not accept applications from students who have not submitted a patch.

We only consider GSoC applications from students who have already submitted a patch for review. It can be entirely trivial -- a one-line bug fix, or making a cryptic error message more understandable, adding a small unit test for one of our utility classes, whatever. But you have to prove you have the interest and ability to check out the code, build it, use it enough to discover something that can be fixed, modify code, and submit a code review to the group. (You ALSO need a compelling project proposal and qualifications, but those are not enough by themselves.)

Submitting a patch will qualify you to have your application reviewed. But of course, submitting a useful patch that survives code review and is merged into OIIO makes your application a whole lot more likely to be accepted!

Don't worry if you're reading this and have not yet submitted a patch. There's plenty of time before the deadline. You just need to have done so by the time the admins and mentors are voting on which students to accept. Lots of students submitted patches to qualify in previous years. If you think it's too much trouble or you can't be bothered to do it, OpenImageIO is not the project for you.

If you aren't sure quite what to do, here are some ideas:

• Check out our issues list: http://github.com/OpenImageIO/oiio/issues But note that it's not always easy to tell from the issue reporting whether the fix is a one-liner, or a year-long project. Ask about an issue if you aren't sure.

• Throughout the code there are comments containing the strings "FIXME" and "TODO", which often reveal small things we'd like fixed but haven't had the time to get to.

• If you run into trouble building the project (especially on Windows), perhaps you will be inspired to make some improvement to the build system itself: making it more robust in some circumstance we hadn't foreseen, making an error message give a more clear indication to beginning developers how to fix a broken build, etc.

• Use the software a bit. Maybe you'll find some bit of confusing, inconsistent, or incorrect behavior and try to track it down and fix it.

• Improve our testing:

• Many of our existing unit tests that do not fully test their classes: In the distribution's src/libOpenImageIO directory, you'll see a number of foo_test.cpp, each of which purports to be a unit test of some class (generally found in src/include/foo.h and src/libutil/foo.cpp). Most of these don't come anywhere close to testing every method or feature of the libraries -- generally they were set up to test one particularly tricky thing, with an intent to return to fill in the rest of the tests, but it was never high priority for the senior developers to do so. Among the incomplete are strutil_test.cpp, filesystem_test.cpp, fmath_test.cpp, imagespec_test.cpp, ustring_test.cpp. The easiest thing to do is look in the corresponding header, find some method or function that doesn't appear to be tested, and add the tests.
• In the testsuite directory, you'll see format-related tests for many of our formats such as tiff, openexr, jpeg2000, bmp, etc. But some of our formats don't have any tests: cineon, dds, hdr, iff, png, pnm, softimage, and zfile. It would be great to have even some basic tests for these. See the existing ones for examples. Basically, they are scripts that read an image in that format, write it back out, then compare the input and output to make sure they match. That's all it takes for simple formats; complex formats may require a bunch of individual tests for different "features" of the format (tiled versus scanline, different data depths, etc.).
• Very little oiiotool functionality is tested in the oiiotool test, that really should be considered a higher priority.
• We have Python bindings, but I don't believe that anything in the testsuite exercises them.

Those are just a few ideas to get you started.