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
