Bringing current darktable to OS X

darktable has been software of my choice for raw photo development for quite some time now, I’ve occasionally submitted bug reports and patches and kept an eye on current development by using git master version. My main operating system is Linux, which is the priority target of darktable support, but recently I bought MacBook Air to take with me on trips and such. Also my current project at work consists of porting a library to OS X, so this presented to me as a great opportunity to contribute to one of my favorite open-source projects and make darktable work reliably on Macs. Some work has already been done in the past, there’s even a package of an old darktable version for OS X, but of course I was interested in bringing the latest darktable experience to OS X.

How things were at the beginning of my work

Since OS X support was present in some way in current codebase, compiling darktable wasn’t a problem. All I had to do is install dependencies via macports, checkout git repository and run cmake and make. darktable even successfully started, at least sometimes :) That was a good start actually.

Killed bugs

First problem I noticed was reproducible crash when switching to darkroom mode. Using gdb I traced it back to text rendering in bauhaus code. On Linux fontconfig considers “sans”, “sans serif” and “sans-serif” as aliases to default font from Sans family, but OS X isn’t so accepting and chokes on “sans-serif” spelling, which was used in bauhaus. Changing it to “sans” solved this problem.

Second reproducible crash was triggered by attaching/detaching any USB devices. This time it wasn’t anything darktable code did wrong, but libgphoto’s fault. It was dynamically loading and unloading libusb-0.1, which left usb event handling threads running even after library with thread’s main function code was unloaded from the memory. Workaround I used to circumvent this issue is to link darktable itself against libusb, thus making sure it stays in the memory. Hopefully gphoto will soon finally migrate to libusb-1 backend (it’s already there, but needs more work and isn’t a default choice yet) which has a proper exit function for stopping such threads before unloading.

Third crash was more tricky since it was happening almost randomly and in different functions. All of them though were in sqlite3 library. When I tried to build and install sqlite3 with debugging symbols to better understand what was happening, I realized that darktable was using system libsqlite3 instead of macports version. Forcing build system to link against libsqlite3 in /opt/local/lib directory helped (OS X dynamic linker/loader works differently than Linux one, it allows to prefer one library from /opt/local/lib and another from default system path). So OS X ships an old/buggy version of libsqlite3, something to watch out for if you’re writing for Mac platform.

Next improvement was enabling OpenCL support on OS X. Apple began including it since Snow Leopard, so it would be a shame not to take advantage of that fact. OpenCL library is installed as a “framework” on OS X, this concept was new to me, and first I thought that there was no way to load it dynamically how it’s done on Linux. I rewrote code so that darktable would link against OpenCL framework on OS X, but after some discussion and help on IRC, I’ve managed to find where exactly dynamic library resided – /System/Library/Frameworks/OpenCL.framework/Versions/Current/OpenCL. Now OpenCL library successfully loads, but I can’t do any further testing, since my laptop doesn’t have discrete GPU.

Next issue was that function keys weren’t recognized by darktable and so most common shortcuts didn’t work. This turned out to be a bug in GTK, that was already fixed and just updating GTK from outdated macports version helped (use at least 2.24.11).

All other fixes were about GUI appearance. Font subsystem on OS X has different idea about what font size numbers mean, “Sans 8” on Linux looks something like “Sans 13” on Mac. So font sizes had to be changed for OS X in several places. This fact though exposed an issue with bauhaus widgets (they are quite new after all) that wasn’t specific to OS X – code made assumption that ratio between font size and its height in pixels is constant. This isn’t true even for Linux systems with different DPI settings, but since cairo by default doesn’t pay attention to monitor’s DPI, everything looked fine. This all has been fixed, now bauhaus is correctly rendered on Linux and OS X systems with any DPI setting.

Lastly there was a mismatch in GUI colors, which made darktable look somewhat ugly. It was probably the most hard problem to debug and fix. It turned out to be caused by use of different functions to set color space in cairo and gtk quartz backends. Apple documentation wrongly stated though that both variants are actually equivalent, so it took some time for me and GTK+ developers to figure out what was happening. Details and patch can be found in GNOME bugzilla.

To be done

OpenMP is still disabled on OS X. System compiler is too old to support it and I’m still to experiment with other options.

Creating application bundle is obviously the final target of this process, there’s a script for that already in git repository, but it needs to be tested and most likely adjusted.

Feedback required

Though darktable appears to run stably on my system, I haven’t actually processed any considerable number of photos with it on OS X yet. Also I use Mountain Lion, and obviously other OS X versions differ, which can expose more bugs. So you are welcome to try darktable on your Mac and report any crashes or bugs using our bug tracker. OS X saves backtraces of all segfaults, you can find them in Console application (Diagnostic And Usage Information/User Diagnostic Reports), so please attach them to your bug reports.

To build darktable on OS X follow these steps:

  1. Install MacPorts (instructions and prerequisites can be found on official website), please use default installation path (/opt/local)
  2. Add +no_gnome +no_x11 +quartz -x11 -gnome to /opt/local/etc/macports/variants.conf
  3. Install required dependencies: sudo port install git exiv2 libgphoto2 gtk-engines2 gtk-osx-application-gtk2 lensfun librsvg libsoup openexr json-glib flickcurl GraphicsMagick openjpeg15 lua webp libsecret
  4. Clone darktable git repository: git clone git://
  5. Finally build and install darktable: cd darktable ; mkdir build ; cd build ; cmake .. ; make ; sudo make install

After this darktable will be installed in /usr/local directory and can be started by typing “darktable” in terminal.


There’s an issue with gphoto on OS X, which prevents a plugged-in camera from appearing in darktable – OS X starts PTPCamera daemon when it detects a camera, which blocks the access to the device from any other application. To fix it simply run killall PTPCamera command after connecting the camera. An automated solution also exists (I haven’t tried it myself, so no warranties): (scroll to the bottom).

darktable on OS X

Filed under: blog development bugfixes darktable git macports os x
These are comments from the old website, archived as static HTML
  1. Hooray! I'm really glad that darktable development on OSX is alive.
    However I'm yet unable to make a working build yet. Hope you could help me with it:

    Thanks for you work!
  2. Yahoo!
    I'm not willing to build, but willing to test binaries! :)
  3. Pity you're using macports. I'd really like to give the program a go, but I don't want to have to get rid of all the goodness in /usr/local just to install it.
  4. You can use whatever way you want to install dependencies, I just provided a tested way to do it. Make sure you install gtk+-2.24.11 with that patch from GNOME bugzilla if you want everything to work and look right. Ah, and sqlite problem should be paid attention to, change /opt/local in cmake/modules/FindSqlite3.cmake file to /usr/local (or other path you installed libsqlite3 to) before you run cmake.
  5. I've enabled OpenMP support in git master, seems to work for me. You will need to install and use gcc-4.6 to get it (dragonegg-3.1 works too, clang-3.1 doesn't):
    sudo port install gcc46
    Configure darktable with this command instead of "cmake ..":
    CC=gcc-mp-4.6 CXX=g++-mp-4.6 cmake ..
  6. Building with gcc from macports turned out to be a bad idea - it links against its own version of libstdc++ and because system frameworks are using system libstdc++ it results in both of them being loaded. That causes bad things like crashes. So no OpenMP for OS X for now.
  7. I am so happy this is happening! :]
  8. Works. Great job. First tried on Lion, now on Mountain Lion.
  9. hey guys,

    it is a very promising project, but needs a lot of polishing on the handling, like extensive shortcuts for modules, panels, actions, everything. if you can make it fully customisable which enables me to set it in a way lightroom works, and make the handling easy as lightroom, i'm very-very happy and would consider to switch from mac to linux, seriously, lightroom and ps is the only thing that holds me back, and gimp is really getting there as i could understand from other people. maybe it would be interesting for darktable to work closely with gimp and unify some terminology and stuff, if that didn't happen yet... of course i'm lame in the topic, and only used the os x version, so just sharing my initial ideas.

    keep up your awesome work,
  10. Jonathan Knights on Mon Sep 10 10:43:28 2012:
    Very happy with the new version on Mac.

    I do hate the fact there is no forum where we can post topics and questions, enhancement requests, etc.

    Some niggles, like it would be good to show the image file name under the thumbnail in LightTable view. A file browser would be better rather than having to import images but I understand you dont like this but ...... some user do!
  11. What about retina support on the mac? Already supported?
  12. Depends on what do you mean by support. The key has been added to Info.plist of application bundle which allows darktable to run in native resolution mode (with no upscaling). It has been reported to work, I can't test myself since my notebook display isn't of retina type.
  13. Crashing on Snow Leopard while in Darkroom mode, seemingly like the first bug you noticed.

    I'm really excited about using this soon. Is anyone else having difficulty using non-Lion or Mountain Lion OS versions?
  14. Can you please report it as a bug (development > bug tracker)? It would be very helpful.
  15. Crashes with Snow Leopard 10.6.8. iMac, quad-core i5, 12gb RAM. Crashes as soon as you launch and won't stay open. Tried multiple time and then gave up.
  16. This probably has already been reported:
    Feel free to join there and help out with finding the cause.
  17. If you could help updating the MacPorts darktable port to the current version, it would be greatly appreciated. These tickets are a good place to start:
  18. Until our next release (or at least release candidate) there's IMHO nothing I can do. As far as I can see, macports doesn't have anything like live ebuilds in gentoo (though it does support fetching sources from git). So I will look into it when it will become possible.
  19. I have a retina macbook pro. Ping me to remind me to test this, this weekend. I can show Google Chrome (which is supports retina, beside CyberDuck which is upsampled, vs Darktable)

    Where should bugs be reported?
  20. Here:
  21. Euan Stace on Wed Dec 19 09:28:13 2012:
    I've been looking at tutorials for Darktable. I use Mac OS but I note from looking at tutorials that other OS have more controls (and they are configured differently) from MC OS. For instance Linux OS modules have sliders and number fields that can be changed. In Linux the exposure module seems to have an extra field (gain).
  22. What you are seeing isn't caused by the OS but the version of darktable. Most tutorials are likely to be based on the old GUI design which has changed recently.

    You can still enter values by right clicking a slider and just typing.
  23. Gunnlaugur Þór Briem on Tue Jan 8 01:43:50 2013:
    I found that I needed:

    export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig:$PKG

    on OS X 10.8.2 (Mountain Lion), to force the use of the MacPorts glib (and gtk) in preference to those in /Library/Frameworks/. Else the build would try to use /Library/Frameworks/GLib - even after - and give up because it's version 2.18.1, which is too old.
  24. That's very strange, that commit helped with similar issue with GTK. And actually it sounds more like there's something wrong with your pkg-configs (why would there exist pkgconfig file for framework?). Anyway, if you want to have this fixed on darktable's side, file a bug report, then we can discuss.