Hello all, I agree with william, automatic exposure could do the job for exposure, but the goal of timelapse processing is also to set some keyframes with specific parameters and also to interpolate darktable module parameters (such as exposure, but also crop, color tone, and so on...). A notion of maths also is necessary to treat flickering or also large variation of exposure smoothly.
one upon a time (in 2014), i did a tool in java, but it was too much work to update the definition of each module of darktable, and also due to various changes in the <xml format> of .xmp text files. https://github.com/3v1n0/timelapse-darktable/tree/master/DTTimelapse with a video example here: https://www.youtube.com/watch?v=C-0bCAIJR0c If it's possible to do it with lua script, I would be happy to help somebody. I would like some examples to 'jump' in this new type of language for me... Cheers, Le jeu. 18 avr. 2024 à 18:43, William Ferguson <wpfergu...@gmail.com> a écrit : > > > On Thu, Apr 18, 2024 at 6:39 AM Jochen Keil <jochen.k...@gmail.com> wrote: > >> Hi Martin, >> >> The exposure module offers an "automatic" mode which works reasonably >> well but in my experience there are outliers that need manual correction. >> Apart from exposure flicker I've also noticed what I call "White Balance >> Flicker". That usually happens with changing light situations (sunrise / >> sunset) when the camera tries to adjust the white balance automatically. Of >> course one could set the white balance to a fixed value but there's no WB >> that fits daylight and night, which means you need WB ramping. >> > > You could use color calibration and set a keyframe with the correct color > calibration for day and then another for night then just read them, compute > the difference and apply them. > > I tried the auto exposure and thought it provided a good starting point > (at least better than I could achieve with my extremely limited timelapse > processing skills. Apply the auto exposure and then add another exposure > module above that could be adjusted for fine tuning. > >> >> The color calibration tool offers a functionality that's a bit in the >> right direction: You can set a target from another image and use it to >> adjust other pictures based on it. Works well, but there's no automation. I >> helped myself with xdotool (a program for key macros) but that's clunky. >> >> As you suggest, it's possible, just not very streamlined and >> straightforward. >> >> Cheers! >> >> >> >> On Wed, Apr 17, 2024 at 9:35 PM Martin Straeten < >> martin.strae...@gmail.com> wrote: >> >>> with recent darktable there can be a further approach: using exposure >>> and color mapping. >>> These functions might support setting of smooth transitions for exposure >>> as well as color calibration based on keyframes >>> >>> Am 17.04.2024 um 19:08 schrieb William Ferguson <wpfergu...@gmail.com>: >>> >>> >>> The issue here is that we are trying to solve a darktable problem with a >>> lightroom solution. If we approach it from a darktable perspective, then >>> we are looking at (probably) less than 100 lines of lua code and 30 minutes >>> worth of work. >>> >>> Using lua I can load an image into darkroom and read or modify the >>> exposure setting. >>> >>> So, if I go through and pick my "key frames", adjust the exposure, then >>> assign a keyframe tag I can run a script that: >>> * selects the images that are keyframes, loads each one sequentially, >>> and reads and stores the exposure information >>> * loads each image in the collection and >>> -- determines the limiting keyframes >>> -- computes the exposure difference >>> -- applies the exposure difference >>> -- loads the next image after the pixelpipe completes. >>> >>> Advantages of this approach >>> * No decoding, extrapolating, interpolating, guessing, etc of XMP files >>> * Don't have to scan for updated XMP files when starting darktable >>> * No worries about XMP file corruption >>> * No worries about database corruption from loading a bad XMP >>> * Don't have to worry about XMP format changes >>> * If the collection gets messed up, you simply select all, discard the >>> history stacks and you've recovered. >>> * You're not limited to just modifying exposure >>> >>> Disadvantages: >>> * It's slower. It has to load each image into darktable and process >>> it. >>> I tested loading images and changing the exposure and IIRC darktable >>> processed roughly 2 images/sec. The images were on an SSD. >>> >>> Bill >>> >>> On Wed, Apr 17, 2024 at 11:04 AM Jochen Keil <jochen.k...@gmail.com> >>> wrote: >>> >>>> Hi Sébastien, >>>> >>>> I wrote dtlapse back then and I'm happy to see that there's still >>>> interest in it. Unfortunately, due to time constraints I cannot put much >>>> work into it. Therefore, in its current state it's pretty unusable, since >>>> darktable evolves faster than I can keep up. >>>> >>>> The basic functionality is very close to what you describe. Pick some >>>> keyframes, adjust them as desired and interpolate the values in between. >>>> This can be done by using the XMP files as interface, once you get around >>>> decoding the module parameters. That's all in dtlapse and worked pretty >>>> well for its rather hackish state. >>>> >>>> However, the biggest problem is that modules tend to change regularly, >>>> which means that you have to manually adapt the interface description for >>>> every new darktable release while keeping old versions for compatibility. >>>> I've made it somewhat easy to update XMP interface descriptions by moving >>>> them to JSON files separately from the code. Still, for every new release >>>> you have to reengineer the XMP file because they're not documented, at >>>> least last time I looked. Given the amount of modules (and even if you >>>> would limit yourself to the most interesting ones) it's tedious and by the >>>> time you're done a new release comes around the corner. >>>> >>>> I've had the idea to generate the interface description directly from >>>> the source code, but you'd need to use a C/C++ parser to get it. I've just >>>> checked the code and the XMP interface is STILL hardcoded in the modules. >>>> >>>> So, to sum it up, it can be done, but it's quite hard. It'd be much >>>> easier if the darktable developers would separate the XMP interface >>>> definition for each module from the code which would greatly increase >>>> interoperability and is good practice anyway (separate data from code). >>>> However, I think there's not much incentive for them to do it, it'd even be >>>> a rather elaborate redesign. >>>> >>>> Best, >>>> >>>> Jochen >>>> >>>> On Wed, Apr 17, 2024 at 2:23 PM Sébastien Chaurin < >>>> sebastien.chau...@gmail.com> wrote: >>>> >>>>> omg thanks for that ! I knew somehow that I couldn't be the only one >>>>> thinking that it'd be great to have... >>>>> >>>>> I'll have a closer look at that repo. >>>>> >>>>> Thanks again. >>>>> >>>>> On Tue, 16 Apr 2024 at 13:48, Martin Straeten < >>>>> martin.strae...@gmail.com> wrote: >>>>> >>>>>> Have a look at >>>>>> https://discuss.pixls.us/t/annoucement-of-dtlapse/19522 >>>>>> >>>>>> Am 16.04.2024 um 09:59 schrieb Sébastien Chaurin < >>>>>> sebastien.chau...@gmail.com>: >>>>>> >>>>>> >>>>>> Hello all, >>>>>> >>>>>> Have any one of you guys wondered about how hard it'd be to implement >>>>>> something similar to LRTimelapse ? >>>>>> For those of you not aware of what this is, it's an additional app >>>>>> that looks at xmp files from LR. It looks first within a folder with >>>>>> hundreds of pics for a timelapse (in real life), at those images with >>>>>> only >>>>>> 5 stars. In this exemple let's say we only have 5 images for our >>>>>> timelapse. >>>>>> Let's imagine that we only have 2 of those, the first and the last, >>>>>> rated 5 stars. and let's also assume there is only one module with one >>>>>> parameter that has changed : exposure. >>>>>> This app would look at the first 5 stars rated image and see the >>>>>> exposure value of +0.5, and the second with a value of +0.9 >>>>>> hypothetically. >>>>>> It would then look at how many images there are in between in the >>>>>> folder (those not rated 5 stars) and divide the difference of the current >>>>>> setting by the number of pics that sit in between these. 5 pics total >>>>>> minus >>>>>> the 2 rated 5 stars leaves us with 3. >>>>>> So in this toy example we only have 3 photos in between the key >>>>>> images (5 stars), then we have >>>>>> - difference in exposure : 0.9 - 0.5 = 0.4 >>>>>> - 4 pics to arrive at that 0.9 value if we start from the first one : >>>>>> 0.4 / 4 = 0.1 incremental step of exposure to be applied. >>>>>> it would build xmp files for the 3 non 5 star rated pic with exposure >>>>>> values respectively of 0.6, 0.7 and 0.8. The first one being 0.5, and the >>>>>> last 0.9. >>>>>> This is assuming we have a linear progression, but I'm sure you can >>>>>> imagine other types than linear. >>>>>> >>>>>> The idea is to adjust every parameter for the pics in between key >>>>>> images (5 stars pics) so that in the end for the timelapse, there are >>>>>> smooth transitions for every setting, exposure is usually one. >>>>>> >>>>>> Hopefully this little example makes sense ? The concept is I think >>>>>> easy to understand : avoid editing possibly thousands of pictures with >>>>>> varying needs in editing. You would only edit key images, and then it >>>>>> would >>>>>> ensure smooth transitioning for all the in-between images, working out >>>>>> the >>>>>> incremental steps it needs to put for every single setting to ensure >>>>>> that. >>>>>> >>>>>> I've used that a lot during my time with LR, and I've been thinking >>>>>> about bringing this capability into DT. >>>>>> >>>>>> Food for thoughts at this stage, and of course happy to discuss this >>>>>> further. I'm sure there will be many obstacles in making that a feature, >>>>>> but isn't it also the challenge ? :) >>>>>> >>>>>> PS: LRtimelapse goes a little bit beyond this, but let's start >>>>>> "simple". >>>>>> >>>>>> Cheers, >>>>>> Sébastien >>>>>> >>>>>> ____________________________________________________________________________ >>>>>> darktable user mailing list to unsubscribe send a mail to >>>>>> darktable-user+unsubscr...@lists.darktable.org >>>>>> = >>>>>> >>>>>> >>>>> ____________________________________________________________________________ >>>>> darktable user mailing list to unsubscribe send a mail to >>>>> darktable-user+unsubscr...@lists.darktable.org >>>>> >>>> >>>> ____________________________________________________________________________ >>>> darktable user mailing list to unsubscribe send a mail to >>>> darktable-user+unsubscr...@lists.darktable.org >>>> >>> >>> ____________________________________________________________________________ >>> darktable user mailing list to unsubscribe send a mail to >>> darktable-user+unsubscr...@lists.darktable.org >>> = >>> >>> >>> ____________________________________________________________________________ >>> darktable user mailing list to unsubscribe send a mail to >>> darktable-user+unsubscr...@lists.darktable.org >>> >> >> ____________________________________________________________________________ >> darktable user mailing list to unsubscribe send a mail to >> darktable-user+unsubscr...@lists.darktable.org >> > > ____________________________________________________________________________ > darktable user mailing list to unsubscribe send a mail to > darktable-user+unsubscr...@lists.darktable.org > ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
