Home

Welcome to the darktable wiki! It's currently in construction.

Building darktable

For now, see : Building darktable (migrated from redmine, needs to be updated).

See also : Building darktable using SCBI

Before testing the development version, remember to keep frequent backups of the following files in your ~/.config/darktable directory:

• darktablerc
• data.db
• library.db

Errors during building are usually related to missing dependencies. If the compilation fails, take a look at the error message, and if it reports a missing dependency, search which package provides it in your distribution and install it. Then, build again and repeat until you have all your dependencies installed.

Distribution-specific build instructions

See also: Building darktable

• Ubuntu
• Fedora
• Manjaro
• Mint

Reporting bugs

When you report a bug, please remember developers are not magicians and are not in front of your desktop. The same error can have multiple causes, and dropping backtraces is usually not enough. To help us understand your problem remotely, please provide as many details as possible, like:

1. the backtrace generated, if possible,
2. the OS used, its version, any non-standard tweaks you might have done,
3. the hardware used: GPU, CPU, RAM
4. does your issue arise with or without OpenCL enabled, or both?
5. what were you doing when the issue arisen?
6. if you backup and delete the ~./config/darktable directory (meaning you reset it to default post-install state), does the issue reproduce?
7. if issue happens with specific combination of modules/masks etc - attach the XMP file that produces the bug
8. if issue happens with specific RAW file and XMP combination - attach both

If you compile darktable from the git sources, ensure you recursively removed all the build local directory and the /opt/darktable install directory before building, because many bugs can come from merging or leftovers issues.

How to produce a backtrace:

Pascal recorded a detailed screencast describing the procedure. For convenience here are the minimal steps:

$ cmake ..
$ make && sudo make install
$ gdb darktable
... crash dt here ...
(gdb) set pagination off
(gdb) set logging file gdb.txt
(gdb) set logging on
(gdb) thread apply all bt full

Post the backtrace written to gdb.txt along with your bugreport. Or even better: Try a few prints and figure out what seems to be the problem. Best: Fix it and supply a patch!

Contributing

Easy

Try building pull requests (in sandboxes, or backup your config files first — see above), and give feedback on them or report bugs. Build the master and report bugs or performance dropdowns.

Another easy task is to maintain the translation for your language, see Translate your language

Medium

There are lots of rough corners in darktable regarding UI glitches (GTK, Cairo) and many bugs affect them. Also, usability and ergonomics could be improved. The darktable project can count on several scientists for the image processing parts, but lacks graphists and UI designers to help building clear interfaces.

Hard

There is duplicated code in the software that could be factorized and put into libraries. Also, bugs are piling up faster than we can fix them, so any help is always welcome.

New

See the developer's guide to begin hacking in darktable.

Finding bug causes

Sometimes it's possible to trace when a bug was introduced via git bisect. Most git bisect tutorials make it more complicated that it has to be, so here's simplest git bisect tutorial:

1. Let's assume that current git commit you're on exhibits a problem, and you remember for certain that there was no problem on earlier commit. You even checked and know for certain that git commit hash XXX worked (eg. you've switched to it, compiled and there was no bug)
2. start bisect process wit git bisect start
3. mark current commit that exhibits problem as 'bad' with git bisect bad
4. mark known good commit as good with git bisect good XXX
5. now we're doing git bisecting! do a clean compile and check if bug's present
6. if the bug is present still - mark current iteration as bad with git bisect bad, if there's no bug - git bisect good
7. repeat steps 5 and 6 till git spews first known bad commit - that's the cause of the bug! Now you can report that!
8. to return git to normal mode do git bisect reset

After getting accustomed with git bisect you can try advanced tutorials in case there are some uncompilable commits (so need to be skipped) and so on.

Proposing features

While proposing new features, keep in mind that darktable:

• tries to stay compatible with its earlier versions,
• does not have a full-time team of software engineers,
• tries to stay fairly usable on limited hardware.

Consequently, new features that require the latest GPU monster to give usable performance are not likely to make it inside the core. That applies to most ground-breaking machine-learning features.

Camera support

See camera support guide