Hi Bill, when I started to work on dtlapse it was not possible to modify module parameters through the LUA interface, that might have changed.
On Wed, Apr 17, 2024 at 7:08 PM William Ferguson <wpfergu...@gmail.com> wrote: > 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 > You'll still need an extrapolation or interpolation algorithm to generate the values between the keyframes. That's simple though, at least with Python. LUA probably offers similar libraries > * Don't have to scan for updated XMP files when starting darktable > * No worries about XMP file corruption > That's why I've made the recommendation to not work with dtlapse and darktable in parallel :) > * No worries about database corruption from loading a bad XMP > Another recommendation would to use darktable's `--library :memory:` option, bypassing the DB (which makes sense in another way: hundreds of timelapse photos will a) clutter your library b) hinder performance) > * 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. > That's actually reasonable. 1000 images in less than 10 minutes. That's just a fraction of the time necessary for a complete and proper timelapse workflow if you add in some video post production (music, zooming, panning, etc). Cheers! > > 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
