1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

I want to be one of your Google Summer of Code students, what should I do…

Here is a quick list of things to do at this time: * MOST IMPORTANT Join the irc channel (#darktable on irc.freenode.net) and talk about your project and your appilication. We will not give formal interviews, but we will clearly favor people we have learned to know during the selection process.

* VERY IMPORTANT Update the wiki page about your idea:

  • Fill the questionnaire.
  • Detail your idea as much as possible, look at other students pages, and please give timeline, milestones and studies you've done
  • Though not mandatory, it is highly advisable to go to the EasyCoding and NotSoEasyCoding pages and implement one of these ideas (or any idea of similar scope) so we have an idea how you work. Be sure to use the mail account/address also used in GSoC when submitting these patches so we know who it is coming from. You can also implement some features or fix bugs from our ticket system here in Trac. When you implement something, also list it on your own page with a reference to the patch. This should give you a good idea what the darktable sourcecode is like and will provide a good start to getting used to our coding style, too. You can also start working on your project and submit patches/prototypes related to it
  • For working on darktable you have to be able to compile trunk. To do so you should have a look at http://www.darktable.org/install/.
  • more detailed information at GSOC_intro_for_students in particular this details what we expect from our candidates

Information about our Project

The information we provided google about our project can be looked up at the site GSOC_questionnaire.

List of Ideas for the Project (Suggestions from darktable developers)

automated regression tests

This can be facilitated by introducing a commandline-interface to darktable. This should use a raw image and an xmp sidecar file as input and parameters controlling the output module to use.

This can then be used to automatically generate a large set of parameters for all modules and compare output images against ground truth images, which are asserted to be correct by the module programmer. Specific battle tests should also be easy to include into this script.

The output should then be generated as a html or pdf containing statistics about the tests, such as runtime (real and user, to be able to tell how well it scales over multiple cores, also for the OpenCL path), peak memory requirements, and a list of failed tests (best with git blame/email of the module's author) with the actual and expected output images.

If the script detects vast performance differences depending on a particular parameter for a plugin, a gnuplot graph should be generated to document memory usage/performance impact of this parameter.

important problems:

  • write a clean commandline interface
  • automate as much as possible
  • keep runtime of the test low (or else nobody will ever run it)

interoperability

  • import databases from other DAM tools.
  • provide a dbus interface and singleton support to be able to remote-control darktable from the outside world.

important problems:

  • database conversion might include some reverse-engineering
  • image processing settings will not carry over (mostly)
  • come up with a useful/minimal api for dbus

openfx interface

  • write a wrapper for our plugins which allows you to use them through the openfx api, for example from inside nuke

opencl support tuning

OpenCL support for multi-GPU systems is implemented and working, but the process_cl() callbacks are not implemented yet for all plugins, some might be hard to do (but even more important), such as a lensfun GPU replacement.

important problems:

  • non-local means denoising seems hard to get fast on the gpu
  • try to port the permutohedral lattice code from cuda to opencl
  • port more plugins to opencl
  • support the tiling codepath, where memory constraints are tight
  • the OpenCL render path currently doesn't use the pixelpipe cache, as the CPU version does. On-GPU caching mechanisms should be explored (taking into account the quite limited RAM on affordable GPUs), as well as sharing data between the CPU cache and the GPU (zerocopy?).

edge-aware image processing

  • the equalizer plugin employs edge-aware a-trous wavelets to do multi-frequency editing
  • many other plugins can profit from this notion, examples:
  • tone mapping finally without halos/gradient reversals (replace the bilateral filter with something that creates better edges)
  • shadows/highlights could use an edge-aware blur instead of a plain gaussian
  • monochrome could avoid noise artefacts by employing a blur before applying the color filter (should then be edge-aware, too)
  • just about anything that comes with a blur ..

papers to investigate wrt edge quality and speed:

computational photography

Combine multiple images in light table mode:

  • better hdr bracketing/image fusion
  • noise removal by combining images
  • focus stacking
  • image alignment/stitching/panoramas?

important problems

  • look to existing free software to analyze the needs and the libraries that can be reused
  • look at existing software to store the information in a compatible manner

your own ideas

Feel free to come up with you own ideas if none of the above suits you. Discuss them with us in IRC or on the developers list and see if there are objections.

not this year :(

just to keep track of it, but we're not able to mentor this year: