Previous email doesn't seem to have come through... Here it is, screenshot available on wetransfer for 7 days : So I've made a quick and dirty script that reads all of the modules file, and since they are structured similarly, it grabs the parameters for each and puts it in a master table.
It looks like this : download the attachment from wetransfer (I couldn't attach it even though it's not too big ...) . https://we.tl/t-HpEiv4WsBP Link will be broken in 7 days. I think from that dataset it should be relatively easy to build the json files, or update them if we can map the args type to what's needed on the json side. Would that be useful to anyone ? On Mon, 20 May 2024 at 12:59, Sébastien Chaurin <sebastien.chau...@gmail.com> wrote: > Hey, > > Sorry I've been sorta afk for a bit, and seeing all this good stuff just > now. I'm glad I'm not the only one pursuing this ! It's actually very nice > to see that multiple attempts already happened in that space, meaning we'll > probably not start from scratch... > Flickering is exactly what I had in mind when I wrote "PS: LRtimelapse > goes a little bit beyond this, but let's start "simple". " > > I guess in terms of software development the 2 choices we have are : > - develop the feature inside DT, possibly with lua scripting, allowing the > pros and cons we've seen prior this email, and probably leading to some > (reasonable) processing time > - develop it outside DT which means processing the XMP files and updating > their definition regularly. The main cons for that option from my > perspective is probably speed, I'm guessing much faster than the above > (making multiple iteration with some slight adjustments an option too). > > I'm not familiar with lua, but as a data scientist I'm at ease with maths > and some other programming languages. I'm not quite sure yet how I can > help, but at least let's keep this discussion going :) > > Cheers > > > On Sun, 28 Apr 2024 at 20:10, Alexandre Jullien <alex.jull...@gmail.com> > wrote: > >> Hello all, >> >> I agree with william, automatic exposure could do the job for exposure, >> but the goal of timelapse processing is also to set some keyframes with >> specific parameters and also to interpolate darktable module >> parameters (such as exposure, but also crop, color tone, and so on...). A >> notion of maths also is necessary to treat flickering or also large >> variation of exposure smoothly. >> >> one upon a time (in 2014), i did a tool in java, but it was too much work >> to update the definition of each module of darktable, and also due to >> various changes in the <xml format> of .xmp text files. >> https://github.com/3v1n0/timelapse-darktable/tree/master/DTTimelapse >> with a video example here: https://www.youtube.com/watch?v=C-0bCAIJR0c >> >> If it's possible to do it with lua script, I would be happy to help >> somebody. I would like some examples to 'jump' in this new type of language >> for me... >> >> Cheers, >> >> >> >> >> >> Le jeu. 18 avr. 2024 à 18:43, William Ferguson <wpfergu...@gmail.com> a >> écrit : >> >>> >>> >>> On Thu, Apr 18, 2024 at 6:39 AM Jochen Keil <jochen.k...@gmail.com> >>> 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 < >>>> martin.strae...@gmail.com> 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 <wpfergu...@gmail.com >>>>> >: >>>>> >>>>> >>>>> 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 <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 >>>>> >>>> >>>> ____________________________________________________________________________ >>>> 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
