For our June, Staff Pick, Project of the Month we have selected darktable, a virtual light table and darkroom for photographers, which manages your photos in a database and lets you view them through a zoomable light table. It also enables you to develop raw images and enhance them. One of the project’s lead coders, Johannes Hanika, tells us about the project’s history, purpose, and direction.
SourceForge (SF): Tell me about the darktable project.
JH: darktable is a workflow tool that helps photographers quickly work through (potentially thousands of) pictures after a shoot and enables them to get the most out of each individual shot. On the technical side, we employ many recently developed algorithms from research in the field and implement them as efficiently as we can, using SIMD on the cpu and opencl on the gpu. We target raw or high-dynamic range images as input format but others (jpg) work too, within limits.
SF: What made you start this?
JH: At the time (just over 5 years ago) there was no open source raw developer/workflow tool (RawTherapee was still closed-source) and all the un-free programs wouldn’t link against my custom compiled glibc.
SF: Has the original vision been achieved?
JH: We would say it has been surpassed quite a bit. Nowadays darktable has features we never imagined would be possible. It’s translated into languages we will never be able to understand and reached a level of complexity that is only manageable by a larger community, not a single developer.
SF: Who can benefit the most from your project?
JH: To be honest we don’t care too much. It’s been a fun ride and a great pleasure to get to know all the great contributors, who have helped to shape darktable and who are still working on it now. In that sense, we think it’s a community project and everybody who takes an active part in it benefits the most because they can shape it by their own ideas and needs.
SF: What is the need for this particular photography program?
JH: The answer to that is obvious once you try to sort thousands of raw images and select the best out of groups of similar images, with a workflow based on Gimp and UFRaw. You really need a streamlined solution to make that process efficient. As an additional bonus, we have always done all our computation in floating point pixel formats so we don’t lose any of the bit depth provided by the raw input files, which are typically 12 bits, not just 8 bits as regular jpg files.
SF: What’s the best way to get the most out of using darktable?
JH: There is excellent documentation in form of a user manual on our webpage. It might also pay off to browse through the blog to get more detailed information about particular tricks. There are quite a few screencasts to explain basic usage and we also recommend Robert Hutton’s tutorials on YouTube.
SF: What has your project team done to help build and nurture your community?
JH: It’s mainly a question of getting new contributors in. We get them in and then see if they stick around. In particular, we want to answer pull requests fast and try to get an approval or rejection of ideas for feature requests early. We also try to make non-coder contributors feel important. A non-coder contributor is actively taking non-coding tasks away from a coder and that’s always a good thing. For example:
- Documentation–especially external tutorials, videos, etc. are done by the community, while the user manual is done by the core developers.
- Community Management–the main developers don’t answer most questions on the mailing list anymore since the community is mature enough to answer.
- Web Administration
- Bug Triaging
At this point the community is self-sustaining and more or less self-policing, which is a real relief for the coders!
SF: Have you all found that more frequent releases helps build up your community of users?
JH: We think the vast majority of people in our community would be using either git master or PPA for Pascal de Bruijn for Ubuntu or similar nightly builds for other distros. Most of our releases are older stable branch releases.
SF: What was the first big thing that happened for your project?
JH: Around 2010, Alexandre Prokoudine gave a talk about it at the Libre Graphics meeting, which really helped to round up our little group of developers. He was also the one to do some networking, which we believe is the reason why Henrik Andersson joined the project early on and contributed large parts, such as the gphoto import feature and tethered shooting.
SF: What is the next big thing for darktable?
JH: We have a couple of ideas to restructure the pipeline to make it better suited for even higher quality image processing (dual-iso, video workflow, etc.) but these things are in an early stage, so we don’t really want to advertise or promise any of this yet.
SF: How long do you think that will take?
JH: darktable is an open-end project. Maintenance and polishing, even of well-established features, is not something we consider finished at any point. In fact, that’s one thing we look out for when assessing whether or not to merge a larger feature: whether the original contributor will stick around and maintain his code after the merge.
SF: Do you have the resources you need to make that happen?
JH: Well, we’re all pretty busy with our real lives but we can’t complain. Our community is healthy, new people are popping up and doing great work, old veterans disappear for a while (some having children and such), every so often one of them comes back and does something great for darktable again. Of course, there could always be more. In their scarce time, coders efficiently tackle some tasks because they know our source well. Probably the bottleneck here is the time it takes us to review all the pull requests (sorry for that @all you guys waiting for a review).
SF: If you had it to do over again, what would you do differently for darktable?
JH: We don’t have real regrets. We would have kept it a lot smaller and with only one tenth of the features but that is a trade off. Having more features makes more people happy because it enables them to fit darktable to their individual workflows better. This in turn helps to grow the community. Of course, accepting patches is always more motivating than rejecting the hard work of a contributor.