I didnāt read the whole thread, but I have a more or less working open source timelapse workflow. Darktableās exposure module does already do a great job for deflickering and equalizing the exposure. Then itās just a question of tuning filmic (filmicRGB now). A good starting point is the picture with highest dynamic range of the whole sequence. Then edit as usual (I like local contrast & tone curves) and copy the history stack. Be careful with masks, however, parametric masks can be helpful to keep the highlights in check. The whole process is a bit more involved and I mean to write an Howto, essentially documenting my whole workflow, but Iām drowning in work atm.
The final piece (actually this should be done before all of the editing) is smoothing out the white balance if you shoot your timelapse in AWB (*), like I do. Iāve written a Python script which reads the WB coefficients from the RAW files, applies a smoothing filter (google Savitzky-Golay) and writes it to the XMP files. The params in the XMP file are HEX-packed binary structs, for WB thatās only 4 doubles. Pretty easy to interface with Python once youāve figured it out. However, my script is CLI only and not very polished but Iām satisfied with the results.
Iāve recently extended the script to allow interpolation (not smoothing!) of exposure and graduatend based on keyframes. That means, pick some files of your sequence, tune exposure (very rarely necessary) and / or graduatend and automatically interpolate all files in between. I still to hacky for a release though.
Here are some Videos I processed roughly following my workflow & using the script:
Depends on the subject. Astro ususally with 30s intervals, so I can expose long enough when itās dark. But itās also subject to the 500 rule for astro shots
For clouds I find ~4s good, depending if I want a sunrise or sunset transition that needs to be longer.
Day-to-Night and Night-to-Day is difficult, hence the term āholy grailā. At the moment Iām experimenting with fixed 4s intervals (Shutter speed mode and a variable ND filter) and 2s pauses. Deflickering can be done in SW, so I donāt care about my aperture changing. The upside is that I can use f/16 for a nice sunstar and once the sun has set the aperture will open automatically. The downside is (potential) flickering and that itās getting to dark for the VND later at night, so youād have to remove it, which means touching the camera, which is dangerous
Btw I also found that you want to be careful about the lens correction module. Different apertures mean different vignetting correction. I now only do distortion & TCA, which seems to work fine.
Looks really nice!
Would you mind to put you python script on GitHub, even itās Ā«too hacky for a releaseĀ»? It could be a useful starting point for me anyway, Iām looking for something since a while and didnāt have an idea where to start.
Iād really love to see this integrated into dt. @anon41087856 any change you will have a look into doing this, or would it be faster if I would start learning c now?
Not going to discourage you, but darktable is a vast C++ code base which is more or less a framework around modules. Even if youāre going to learn C++ now itāll take you some time until you understand darktableās code base which is (afaik) pretty undocumented. In addition, this is not a standard module in the sense of take pixels from the pipeline, modify pixels and write them back, but rather read information from a group of images and apply it to a group of images, a process darktable was never designed for. So prepare for some hacky solutions here. I wouldāve loved to this in LUA though but the API isnāt there, thatās why I āreverse-engineeredā the XMP interface.
Iāve seen the script and all it does is calculating and applying smoothed out WB across set of images (sorry for trivializing actually great piece of work). Technically it can be either an operation in DT in āselected filesā module (so youād have to learn C) or LUA script that would do the same So you can either learn C or LUA. I think lua script can also call Python script that @jchnkl done (lua scripts can call external binaries to do processing). So ultimatelly options are - introduce this as an op in C, introduce it as an op using LUA (total rewrite in lua) or intruduce it as an op in lua dependent on python script.
My stack of tasks is pretty much full for at least the 2 next months, so if you are able to learn C in less than 2-3 months, chances are you will be faster than I am.
Well, you could do a āmoduleā for the lighttable (src/libs/copy_history.c is close to what you do here), code a SQL request to fetch exposures/WB for the selected list of pictures, unroll your interpolation of parameters, save the SQL in database and refresh XMP files.
Now that darktable has arbitrary module ordering, making a toolchain of module invocations in lua would be a powerful way to process multiple images.
I recently completed a batch capability for my own software, and it has surpassed my expectations for improving the efficiency of my workflow. For instance, after Iāve produced my proof JPEGs after a dayās shooting, if I find something like a white balance correction that applies to a series of images, I can open one of them (which opens the raw file and re-applies the toolchain to make the JPEG), change the white balance, then I delete the other proofs i want to apply the change to and kick of the batch dialog, which will process new JPEGs with the modified processing. Itās not lua, but the concept is the same: have a scripting language that exposes the same image processing API as the GUI program uses.
No, the modules that you can reorder are the pixel pipe ones (where āmoduleā means a GUI widget and an image operation filter, located in src/iop). Those are not accessible from Lua. Lua let you play only with pipeline I/O and the lighttable modules (where āmoduleā means only a GUI widget to do arbitrary stuff not affecting pixels, those are located in src/libs)
Okay, some of what Iām getting at is already in darktable-cli. From my initial read of the doc, one needs a previously-saved XMP with the desired history stack. Iām not a large fan of history stacks, Iād rather just have a ātoolchain stackā of the parameters I finally settled on, not all the less-than-desirable iterations it took me to get there. Okay, further reading reveals ācompress history stackā, which gets rid of all but the essential information needed to process the image with the final editing decisions. That gets me thereā¦
I appreciate the conversation here, which I followed silently.
Also I kept back off for the purpose of letting dt-3.0.0 come to earth and getting calm.
Now I would like to go back a little to my initial intention. Hence I have just now opened a Feature Request on github and seriously hope for any helpful supportā¦
With the upcoming darktable 3.2, we will get the new introspection mode , which @dterrahe has been implemented. I am very very grateful for this work and happy that I have had a little minor role of being part of the testing team.
It think there is still a long way to go and patience is needed
@jchnkl meanwhile has realeased dtlapse, which I still need to try, but looks very promising.
Some of you may want to merely use FOSS, then dtlapse probably is the long awaited diamond
those looking forward to the very mature LRTimelapse, dtlapse might be the tool, makes the required patience a bit easier to accept.
