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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> >> 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 < >>> [email protected]>: >>> >>> >>> 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 >>> [email protected] >>> = >>> >>> >> ____________________________________________________________________________ >> darktable user mailing list to unsubscribe send a mail to >> [email protected] >> > > ____________________________________________________________________________ > darktable user mailing list to unsubscribe send a mail to > [email protected] > ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]
