On Thu, Apr 18, 2024 at 6:39 AM Jochen Keil <[email protected]> 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 <[email protected]> > 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 <[email protected]>: >> >> >> 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] >> = >> >> >> ____________________________________________________________________________ >> 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]
