On Thu, Apr 18, 2024 at 6:15 AM Jochen Keil <jochen.k...@gmail.com> wrote:
> 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. > darktable.gui.action() was added to the API allowing manipulation of the darkroom modules among other things > > 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 > My reference to extrapolation and interpolation was regarding decoding the XMP :) > > >> * 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). > Confession Time I said 100 lines of code and 30 minutes. It took 45 minutes, but I only had to write ~60 lines of code and steal another 100 from other scripts. :D I know almost nothing about timelapse photography or processing. I googled what settings to use and then shot a 99 image timelapse so I would have a dataset to test with. I used 17 keyframes to adjust the exposure. With another script running that generates a new thumbnail for each processed image I processed the 99 image timelapse in 90 seconds. Without the background thumbnail script the time dropped to 80 seconds. My timelapse included ground and sky and a storm was coming. The sky exposure stayed fairly constant, but the ground exposure changed a lot as the clouds moved. Processing the timelapse with the script, I could have an exposure module with a mask for just the ground portion and process just that. The full power of darktable is available to use. So at this point I have a working proof of concept. It's ugly, fragile, etc, etc, etc... We're approximately 30 days from feature freeze for darktable so I won't have much time to play with this until darktable 4.8 is out. I will try and get it to a point where it's not so fragile (causing darktable to hang) and then throw it out for people to play with. Bill > > 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
