Building darktable on Windows 10


The startup instructions to point to an alternate database directory or maybe keep this database in memory, as I discover is possible (which is ok for a test), to avoid any conflicts with existing installations, would be interesting pieces of info to add to the guide.

If you assumed I created an installer. Not so.

I did not create an installer, and then go on to install the build in Windows as standard., in which case it would have been advisable to install in a separate directory. But this does not apply. Explanations below.


It’s right there in the instructions :

“If you are in a hurry you can now run darktable by executing the darktable.exe found in the build/bin folder, install in /opt/darktable as described earlier, or create an install image”

I ran the executable from the /opt/darktable directory - exactly as instructed, so it was not possible that I had created any mixups with my prior 3.4 version, which was installed from the binary distribution as many users on Windows, would so do.

I do also hope you can accept that, any set of instructions, like the build for Windows which I followed, might make certain assumptions of the skill level of the end user. When you follow a Google map, it does not need to tell you to move one foot in front of the other, or give you instructions on how to drive your car, it makes certain assumptions, that you have those elementary issues sorted.

There is value, as I have done, to point out to anyone, who might have wanted to follow those instructions, that there is a level of knowledge assumed, and if the experience has not been gained prior, there would be a learning curve. Especially as you are most likely addressing Windows users, who may have never seen a command line before.

Simple things like - add these statements to a user startup file, would leave some users pondering - how do I achieve this? I cannot assume any skill levels of those who read my comments, so it is fair that I pointed out these caveats. Nothing scary, better to let them know, there is a learning curve for some.

With my experience, I still had to figure out a few things, simple things like what kind of editors does linux use, when a unix typical “vi” command to edit files did not work. I never used linux professionally, only unix, but it was a relatively easy transition to google this and realise that in linux its now “vim” not “vi”.

I was also once a technology educator, who wrote teaching guides and taught a fair bit, so it’s valid to assert, the instructions can always be improved to assure their success. I hope it can become more accepted, on techie centric sites, to also see things from the point of view of non techies. When I have the time, and the mysteries of this build process are fully resolved, I’d love to enhance those build instructions, and make this available, and hopefully anyone, at any skill level, as long as they can type and move a mouse, will have ALL of the instructions, however elementary these are, to follow a set of instructions, that are a superset of what I attempted to follow, and have even more of an opportunity to succeed at the build.

I am glad that not all the instructions succeeded, I wish they had. Once I figure out why, it will be easier for the next person who follows suit.

1 Like

why don’t you simply start a new thread instead of polluting a sigmoid related thread with your learning experience building darktable on windows?

1 Like

There is some great educational documentation…its called readme

Section 7 building DT

Yes definitely yes, I have succeeded in building an installer on Windows, for a darktable version 3.5.0 xxxx which comes from the most current version of darktable on github.

I was also able to build the executable that runs from a bin directory within the MSYS installation directories. But this time around I did not bother to run this version, as I wished to test the final product - which is the full windows installer.

I went ahead to run the installer, being careful to use a startup parameter to ensure that this new version derived/created its startup configuration from a new directory, to avoid any corruption of the configuration of an existing version

Install went well and I have a “stable” i.e not crashing instance of version 3.5. As expected there are some differences and possible bugs, so regard this as an experiment. Lots of interesting features, which I will not go into here.

If one studies the document carefully, there are 4 different pathways to create this installable executable, using MSYS2, as defined in the following process.

And there are additional methods, which may be possible using a cross compile on Linux. The document points to the MSYS2 site, and this has some preliminary install instructions.

For one who is unfamiliar, with the process, it is possible to inadvertently add additional steps, by following some of the instructions on the MSYS2 site, which could be surplus to requirements, which was a possible reason why my 1st attempt did not proceed as expected.

The 4 paths using MSYS2 are :

  1. Create an installer for your own computer (which may not be installable on another computer) using “MSYS Makefiles”

  2. This was my primary intention, same as above but the installer .exe should be able to be installed on another Windows computer. I attempted this but it did NOT succeed, so I had to go back to run option 1, above.

  3. Same as 1 above but using “Ninja” to achieve this build.

  4. Same as 2 above but using “Ninja” to achieve this build

It takes a while to do each of these compiles, so I did not bother with 3 and 4, having achieved what I needed in option 1.

When I do have the time, I’d love to compile a single set of instructions, of the specific instructions I followed, for option 1. Which should be sufficient for most “testing” purposes, ideally with some explanations, hints aimed at anyone who has never played around with a command line, to assure their success.

Next steps, from this success, will be learning how to creating a Windows build of custom sources, like the Sigmoid module, which is what initiated this opportunity to build Windows executables/installers, in the 1st place.

I’ll ask the developer of sigmoid, for assistance, with this build - Things I need to know are :

  1. How to obtain a copy of the source of the “fork” which includes the sigmoid module code.

  2. Any changes which I may need to introduce to the process, in my attempt to build for Windows.

So a working sigmoid compile is the next step.

When I succeed at this, the next step will be learning enough code development to create a Filmulator module so I can have options for raw development in the same instance of daktable (Base Curve, LUTS, Filmic, Sigmoid, and Filmulator).

A huge thanks to all contributors to my success. Thank you from a deep place in my heart.

Thanks ever so much. I was able to, thanks to the encouragement and guidance of those on the forum, to learn and build a Windows installer or executable, from the most current dev version of darktable on github.

At the appropriate time, I will still delve into Linux on a virtual machine, to make it easier to share and obtain knowledge from other contributors who are, in my estimation, developing or building on Linux, as their primary target platform.


1 Like

Ask your build questions here. References from the previous thread.

1 Like

I’m glad you got to a useable endpoint…

Pretty pleased.

I was able to compile and build a Windows executable and also create an installer.exe, which installed ok. So I now have an instance of dt, which has the sigmoid module.

At first I gitted (if there is such a word) or rather cloned the entire repository/branch from the author of sigmoid, but compiling and building that did not yield an install which included sigmoid.

Then I found this :

And if synced with the windows build instructions I had succeeded with earlier, it was a relatively painless process.

Next frontier to conquer would be a much more involved one which is “building a filmulator module or might be modules, cos of the architecture of dt’s processing, which may require the various aspects of filmulator to be split up”

It makes sense to start the discussion on this “project”, in its own thread. My initial thoughts are , for compiled apps, this must be such a pain, to have to always compile before they could test anything.

1 Like

Funnily enough I didn’t see this discussion until now.
I built a dt-trunk + sigmoid build under Win10 for the first time yesterday.
To be honest, i was surprised how easy it was. Well done DT devs for the process and documentation!

1 Like

The approach I followed, provided me with a “build” of DT, which includes sigmoid, but the version of DT in this, is not in sync with the latest DT dev version. So I end up having three versons of DT.

  1. One with sigmoid, but out of sync (I think) with the current development code on github.

  2. One without sigmoid, but is based on the current development version on github.

  3. And the stable release, which I simply downloaded and installed, and did not build, unlike the two above.

I wish I knew how to, every month, build a version based on the current dev code on github, and combine this with sigmoid. So I can reduce the number of instances/versions I keep on my computer, from 3 to 2. If anyone knows how to do this, kindly share.

I did the steps in the DT windows build doc:

git clone git://
cd darktable
git submodule init
git submodule update

(from darktable/ at master · darktable-org/darktable · GitHub)

Then i did:

git remote add jandren
git fetch jandren
git merge jandren/sigmoid_tone_mapping

(from: [WIP] sigmoid tone mapping module by jandren · Pull Request #7820 · darktable-org/darktable · GitHub)

The merge fails for 3 or 4 files.
I then edited those files and fixed the merge issues.
This was very straightforward if you know a little C/C++ coding.

I then built it as per the DT windows build doc.

So the normal way to dealwith that would be to create a local branch containing the sigmoid code, and merge onto it changes from the official darktable master branch. As long as there are no merge conflicts, it is easy. If there are merge conflicts, you may need some coding skills to resolve them. I would suggest just avoiding the sigmoid module altogether though, unless it somehow finds its way into the official master branch.


This will corrupt your database so be prepared as updates don’t recognize the sigmoid module…I would keep a separate version with sigmoid if you want to use it…

This is more complicated than necessary. Just do git fetch pull/7820/head:sigmoid_tone_mapping
This will create a new local branch that you can checkout to: hit checkout sigmoid_tone_mapping.
You can then do git merge master to incorporate newer changes from the main branch. But as Matt said, this could lead to merge conflicts that you need to resolve manually. These are sometimes unavoidable, so this procedure is not recommended to the uninitiated.

Been a while since I studied or wrote/edited any C/C++. It would be interesting.

But - see below, why I’ll hold on this.

Until sigmoid gets included in the official dt roadmap, if periodically Jandren refreshes the sigmoid branch, (one or two months behind the bleeding edge version, is ok for me), then I can build from this revised branch, using the same process I followed earlier, and use this as my “dev” dt edition.

And yes, all warnings noted, installed in its own “dev” directory and own database/config directory, which I already adhere to, as directed by all the kind folks on pixls, with much thanks.

Why would you suggest that? I’m finding it much better to use than filmic.
I really hope it does make its way in.

The PR is flagged as “controversial”, and until that is settled, I think it is premature to be establishing work processes that depend on it.

1 Like

I think its only forthright that I add here, I have eventually figured out filmic, and it now works for me.

Between the base curve(for those who like working the old way - habits may not be easy to let go off for some), and filmic, I have enough options, for tone mapping.

One thing I read about the development process, for darktable, is that anyone with new development ideas, ideally has to collaborate with the rest of the darktable inner caucus, in a very specific way, and also has to be able to demonstrate that they will be around to maintain the code. So its not just a case of - oh here is a new idea, put it into darktable.

There is a lot more work that any new idea in darktable has to live up to, including the contributor demonstrating their commitment to being around to maintain their code. On hindsight, these protocols and controls in the darktable roadmap, are really important, to ensure that darktable remains stable, for a long time to come.

I have enjoyed the new ideas, like sigmoid, but in fairness, maybe what we need is more education about filmic, more marketing of how to use filmic.

Not that an effort has not been made, with the education on filmic, but more information could always help, cos its a bit of a special tool, very different from what most of us have used in the past.

Its easy to use - filmic, when you know how, but it needs some time to learn it, and a bit of practice, to become consistently successful with it.

It has taken me months (over 6 months) to figure it out, but now, I am eventually quite comfortable with it, and it fulfills most of what I need. And any additional tweaks can be done in a few other modules, like the tone-equaliser and the “new” colour-balance rgb.

One major hurdle, with filmic, was learning to always enable the middle-grey-luminance slider, so its always there should I need it. So I have this enabled this slider to be displayed by default, via an auto-apply preset in filmic.

You don’t need middle-grey. Use the exposure module. You can even set up a keyboard shortcut so you can change it while you’re in filmic.