Timelapse photography and darktable

Hi darktable users and timelapse geeks,

I would like to create (semi) professional timelapse videos. But I would also like to stay in RAW format as long as possible, and use darktable as the raw editor. Presently, there are some limitations in that respect. With this article I would like to discuss this and hope that one day, darktable will become a suitable tool for this branch of photography as well. You may call this an extended “feature request” (referring to ‘github’)…


Later in this article, I will refer to commercial software. My intention is not to promote any commercial software - I am not paid to do so, I am just personally convinced. There is no relationship involved with those programmers, except that we know each other via Internet. My aim, my motivation, is purely to try to bring two worlds together in order to overcome certain limitations.

Adobe Lightroom is a trademark of Adobe Inc. Later in this article referred as Lightroom or LR.

LRTimelapse is a trademark of Gunther Wegner, lrtimelapse.com.

What is timelapse photography all about?

Timelapse videos are made of a series of still shots of a scene, which moves (too) slow, one can (almost) not see any movement with the bare eyes. The movement of the stars, due to the rotation of the earth, is one typical case. But there are also many other examples, as well as pure aesthetic approaches. One example could be: https://youtu.be/Od-p10d_llU

Timelapse photography simply is a branch of photography, where invisible things can be made visible…

With the gear (like sliders, a bunch of tripods and cameras), you collect a huge number of photos, which later generate a breathtaking scene, e.g. of astro photography, like NOX ATACAMA from Martin Heck https://youtu.be/x2D7jHfitzk

What can be done with darktable and what can not

With darktable’s exposure module, you can already de-flicker, once you are in “automatic” mode. That part already works quite nicely.

What you cannot do, is to handle transitions of lightness, like from sunset to night (which is The Holy Grail of timelapse). Particularly in such situations, you may even want to have a transition for the white balance. This is something which is impossible in today’s darktable. Today, you can have one WB setting and copy it to some or to all shots in your picture set, but a smooth transition (e.g. via a set of keyframes) is impossible.

Those are the two most prominent examples where transitions might be wanted. Indeed, once you are editing a timelapse sequence, you might find a lot of other settings, which you would like to have a transition between the first and the last part of a sequence or even for some keyframes in between.

For all transitional tasks, there is a market leading software available. It is not FOSS but a commercial one (see Disclaimer above). I am talking about LRTimelapse. Apart from the commercial version, there is also a FREE VERSION which works with a series of up to 400 images. That is meant for testing purposes, but it also gives the private users with smaller projects the opportunity to use it for free without any timely restrictions.

What this software does, (simplified explanation)

  • it imports Adobe Lightroom’s .xmp files,
  • does the modifications and
  • writes them back into the .xmp files.
  • It also triggers a “Visual Preview” generation (image+xmp development of a preview via batch call) analyzes the result and uses that for deflickering purposes, displaying the preview etc.
  • It offers a powerful video renderer to assemble the developed images to a video clip in different formats like h.264, h.265, prores, motion jpg etc.

Currently the manipulated .xmp files get imported back into Lightroom for development and then exported and rendered.

A possible way forward, in my opinion

Now we are approaching the intention of this article.

For me, as a Linux freak, it was clear from the beginning that I wanted to have native linux software for my photo workflow. And, from the very start, I am a very big fan of darktable.

Many users seem to be annoyed by the license model of Adobe and are searching for alternatives. They might switch to darktable…

Now, as we are in darktable and some of us want to manage timelapse sequences, we figure out that darktable and LRTimelapse are not compatible with each other. LRTimelapse is designed to be compatible with Lightroom and its incarnation of .xmp. Darktable uses its own .xmp structure, which for the developers might be very clear, but at the moment, this clearly is an obstacle. Another “hurdle” is the enormous power of darktable, especially since its extremely flexible masks and blend modes are implemented per module.

Since years I am a PITA to Gunther Wegner, the author of LRTimelapse. I kept telling him, darktable is not that bad, here and there even way more powerful than Lightroom. When we discussed about usability and handling concepts, it took me quite some time to convince him. After all, I could notice that at least some of the ideas seem to have rooted. :slight_smile:

BTW: quite some time ago, there was a darktable timelapse fork, but it did not survive, as far as I know.

Back to the main topic…

What has happened so far?

I was telling Gunther about my dreams and also about different philosophies of usability and the developers’ quite academic approach of darktable. During those conversations I had to admit that it would be quite something to bring the two worlds of commercial software and FOSS closer together.

While one has to make its living, the other might have many other motivations, be it reputation, just for pure fun or fame or whatsoever. The first has to calculate affords and gain from beginning, where the latter perhaps is more motivated by a personal interest.

We are lucky, because from his heart, Gunther likes FOSS quite a lot and supports this in many ways, like his first version of a dedicated timer. So, unlike big organisations, he is willing to open mindedly listen to this issue and even may offer some support (e.g. writing specifications).

Technical Issues

The aforementioned transitions are called “animation” in the LRTimelapse environment. In order to be able to animate modules, the adjustable values of the modules need to be accessible.

The way to access is editing/modifying the .xmp files, which come along with the photos. In order to do so, the .xmp file ideally keeps as close as possible to what Lightroom provides, alternatively it maintains a quite reliable, well defined specification according to the XML standard or scheme.

Darktable is extremely powerful and, due to the nature of FOSS, it is also extremely agile (e.g. the filmic and tone equalizer modules). Especially the masks, they are IMHO far ahead of LR and maybe one of the reasons why at least some entries in today’s .xmp files are base64 coded.

internal corrections in LRTimelapse (like the deflickering) are currently performed on hidden tools in Lightoom. As darktable already can handle several instances of one module, I consider this to be possible to adapt for darktable.

The Concept

Anything I describe here, is spun from my own thoughts, with my limited know-how or understanding of coding software. Advice for different approaches, which strive at the same goal, is very welcome.

Let me outline my concept:

First of all, there might be a need for a separate “view” besides PRINT, SLIDESHOW and TEATHERING, called TIMELAPSE.

Inside that view, the modules that need to be animated in order to generate transitions, should be grouped together (not newly developed, just maybe restricted/locked in a certain manner), like but not ultimately limited to:

  • exposure
  • white balance
  • shadows and highlights (to be replaced by tone equalizer in the future)
  • color zones
  • levels (critical, I know)
  • equalizer (at least tricky)

Animation can only happen on linear tools with a predefined set of parameters. A tonecurve with n-points for example wouldn’t be possible to animate easily, a parametric tonecurve with blacks, shadows, mids, hightlights and whited (5 discrete parameters) would work.

We should work with Gunther to define a subset of tools that make sense for timelapse editing to be implemented in the first step.

If the user uses any other tools in Darktable, LRTimelapse could make sure that those changes get populated to all images of the sequence (but not animated). With the separate “Timelapse” view, it becomes clear to the user, that only the tools that are on that view, will be animated.

Inside that view, one can now edit the images designated as keyframes. Those keyframes need to be identified, either by tags or any other (automatic) technology. Currently LRTimelapse simply uses Star-Ratings to mark the keyframes. In Lightroom a simple filter for starred images then can be used to identify the keyframes.

The idea is that, in such a dedicated view, the user can expect that edits of the keyframe pictures could be animated by LRTimelapse (which means that interpolations/transitions will be calculated and written into the .xmp files).

Now over to the very essential part: Those modules, that are embraced in that dedicated view, need to be exported into the .xmp file ideally(!) identically to what Lightroom provides. Alternatively in a quite reliable, well defined, specified manner, according to the XML standard or scheme.

For the beginning, it would be sufficient to migrate the tools on the Timelapse-View into a readable XMP format. The other tools could stay in the current base64 format.

For the next step, we probably need a locking of the pixle pipe of the timelapse-view modues

As soon we gain more experience, we can add more modules to the view “TIMELAPSE”.

The Challenges

I have read houz’ article about why there is no darktable for windows in the past, which finally ended up in this new situation. Similar reasons/situations might apply here as well. Hopefully we are all open minded and will find a suitable way to make it happen…

My Contribution

These new functions will be a pain for debugging and testing. I want to contribute on this, as well to become the interface between the two “worlds” of FOSS and commercial SW, by means of working on the compromises necessary (I guess that can be a hard job already).


With this article, I hope I can convince the related devs or devs, who are also eager for timelapse photography, to support this project and whenever their time allows, to implement the needed steps gradually.

The intention is to make darktable compatible with LRTimelapse. In order to do so, a separate view is to be implemented and provide a limited set of modules there with limited “power” (e.g. masks/blend modes restricted). And last but not least, this timelapse dedicated modules should generate a clean or specified XML-alike or LR-compatible .xmp-files.

All other modules might get used by users for timelapses but without animations for the timelapse video sequence.


I seriously hope that one day this becomes a reality and that we see it being merged in the official tree.

@gwegner: thanks for listening and very helpful advices
@Claes: thanks for proof reading


I think the hopes of providing lightroom-compatible xmp files is far fetched. The tools are not the same between the two applications, and they never will be.

You seem to imply that darktable’s xmp files are not valid XML, but they are valid so far as I can tell. XMP supports custom XML namespaces, which is what darktable uses to store its edits.

So far as the base64 encoding… You’d just decode it, wouldn’t you?

1 Like

As I said, “ideally LR compatible or clearly specified/defined xmp”. Especially the latter isn’t the case today but a prerequisite in order to modify with an external APP.

Maybe it would be good to open an issue on the DT Github repo for this so it could be more technically discussed and seen by devs.

The devs actually all have accounts here IIRC.


the XML is clearly specified. if you look at the top of the XMP file each namespace has its schema/DTD referenced. it is just different namespaces with different content than what lightroom uses.

and emulating lightroom behavior without clear specifications of the algorithms is impossible. that’s why the current lightroom importer only covers some very basic things.

would be absolutely amazing if @gwegner supports darktable!

1 Like

May I call this “defined” :slight_smile: but is it “specified”? What is needed, is a reliable base for a third-party software.

Maybe this post from Mai about documentation of xmp, which has had the same background meaning, helps for clarification.

I hope we do not stuck here, by discussing, whether current xmp would be suitable or not, whether base64 is usable or not. I wouldn’t have spent the efforts to write this article, if I could have succeeded with such approach at Gunther :smile:

As I said above, once we proceeded in a way, coming closer to “yep, the idea is doable with a separate view and ‘castrated’ modules…” then @gwegner might even support in defining which elements/classes need to be specified for xmp to even have a chance darktable and LRTimelapse can be compatible one day (to prevent, every now and then things suddenly behave different and the interface wouldn’t work anymore which makes users to think bad about both softwares).

This is a bit off-topic, but I can’t avoid mentioning that the firmware add-on CHDK (and probably Magic Lantern) allow in-camera deflickering for timelapse shooting, thanks to the capability of script execution.
In CHDK, there’s this fantastic script YASS (for Yet Another Sunset Script).

1 Like

@aurelienpierre @hanatos @houz,

in separate IRC chats I have discussed with you about this topic. May I kindly ask you to express your -hopefully supportive :slight_smile: - thoughts and ideas about this approach?

Would be very nice, as I still hope, we can find a vivid discussion here about future abilities of darktable in an additional field of photography :slight_smile:


Fully agree, this is no hope to get an XMP compatible with Lr. That’s just not hard, that is just impossible. No way around that.

seems my English capabilities are way to be improved :slight_smile:

I ever said, “ideally”. Doesn’t mean I want a 100% compatible thingie. But in the same manner (more closer to the XML ideas) and reliably specified (so one could do a translation / transformation table), that would help a lot.

Just imagine, you write a separate, not implemented function and you want to control dt from outside… Actually LR’s spec cannot be THAT secret, as it already gets crontrolled from outside via LRTimelapse. But again, I am not looking for a “just alike” but something can be handled for someone, who wouldn’t have this as the top priority rather than a prerequisite.


Maybe you can find out what information that timelapse tool is actually putting into those XMP files.
And then we can see if we can do something about the things they put in.

and the XML format is reliably specified … the module settings for each module are probably also easily documented (iirc @houz wrote a Javascript app once to show the settings in a XMP file)

I know, @houz is the key player for the xmp. But as I have linked above an attempt from May, it was not yet doable to get the specification for the xmp on hand.

That java-script anyhow would be nice to have… Do you have a link available?


Hi there, year by year I see more people interested in timelapses, also I would love to have this feature inside DT
I had a look at https://github.com/fhrtms/darktable and i saw that it was ready for 2.2 so not so much versions ago!

That is very close to what I have discussed yesterday with mica[m] @paperdigits on IRC. I also got the idea already, now it needs to be split down to digestible peaces
I will come back with something like this, soon

Indeed, I think smaller steps would be much more doable.

My thinking boils down to this:

  1. Pick one module to start with (exposure or white balance should be both easiest and most necessary).
  2. Decode the part of the xmp.
  3. Figure out the format and how to write into that format.
  4. Write a CLI tool that takes a starting and ending white balance/exposure balance and interpolates the value of each file in the time lapse from begining to end.
  5. Write those values into the xmp.

That part is, what LRTimelapse does (and way more) :slight_smile:

Basically I see it the same way.

Why you guys say like this?
When I open such xmp, I find the specification reference in the third line: http://www.w3.org/1999/02/22-rdf-syntax-ns#