Re: Re: [darktable-user] Feature idea : DTtimelapse ? (similar to LRtimelapse in essence)

[1-grid Support]

Hello Sébastien Chaurin  Thank you for taking the time to contact 1-Grid 
Support We are not finding an account in our system under your email.   
   Please re-submit this request from an authorized email address on file for 
your 1-grid account in order to receive support.      To help prevent confusion 
regarding the correct email, we recommend logging in to your 1-grid Customer 
Zone to submit your ticket.  1-grid Customer Zone: 
https://1-grid.com/client/clientarea.php  Please make sure that you use an 
authorized email address for login.  Also, if you forgot the password to 
1-grid Customer Zone, you can reset it: 
https://1-grid.com/knowledge/customer-zone-how-to-recover-a-lost-1-grid-password/
 Alternatively, you can ask the main account holder to add you as a contact 
in the client zone and give permissions to access and make changes on the 
account.  How to add a contact to your account? 
https://support.1-grid.com/support/solutions/articles/33000240398-how-to-add-a-contact-to-your-account-
Kind Regards  Yibanathi Tibisana  1-grid support team  You can now 
make quick payments on our 1-grid mobile app. Don’t have it yet? Download the 
app on Android or iOS  We have step-by-step guides that can assist you through 
any issues you may be experiencing, view our knowledge-base here.
   
On
Thu, 30 May at 11:14 AM
,  Sébastien Chaurin   
wrote:
 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  
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  
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  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  a écrit 
: 
 
 
 
   
  
 On Thu, Apr 18, 2024 at 6:39 AM Jochen Keil  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 aut

Re: [darktable-user] Feature idea : DTtimelapse ? (similar to LRtimelapse in essence)

[Sébastien Chaurin]

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 
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 
> 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  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  a
>> écrit :
>>
>>>
>>>
>>> On Thu, Apr 18, 2024 at 6:39 AM Jochen Keil 
>>> 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  >:
>
> 
> The issue here is that we

Re: [darktable-user] Feature idea : DTtimelapse ? (similar to LRtimelapse in essence)

[Sébastien Chaurin]

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 
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  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  a
> écrit :
>
>>
>>
>> On Thu, Apr 18, 2024 at 6:39 AM Jochen Keil 
>> 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 :

 
 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 approa

Re: [darktable-user] Feature idea : DTtimelapse ? (similar to LRtimelapse in essence)

[Alexandre Jullien]

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  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  a
écrit :

>
>
> On Thu, Apr 18, 2024 at 6:39 AM Jochen Keil  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 :
>>>
>>> 
>>> 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 
>>> 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 file

Re: [darktable-user] Feature idea : DTtimelapse ? (similar to LRtimelapse in essence)

[William Ferguson]

On Thu, Apr 18, 2024 at 6:39 AM Jochen Keil  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 
> 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 :
>>
>> 
>> 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 
>> 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 i

Re: [darktable-user] Feature idea : DTtimelapse ? (similar to LRtimelapse in essence)

[William Ferguson]

On Thu, Apr 18, 2024 at 6:15 AM Jochen Keil  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 
> 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 
>> 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 descri

Re: [darktable-user] Feature idea : DTtimelapse ? (similar to LRtimelapse in essence)

[Jochen Keil]

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.

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 
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 :
>
> 
> 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 
> 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...

Re: [darktable-user] Feature idea : DTtimelapse ? (similar to LRtimelapse in essence)

[Jochen Keil]

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 
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 
> 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 
>>> 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 <

Re: [darktable-user] Feature idea : DTtimelapse ? (similar to LRtimelapse in essence)

[Martin Straeten]

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 keyframesAm 17.04.2024 um 19:08 schrieb William Ferguson :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 exposureDisadvantages:* 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.BillOn Wed, Apr 17, 2024 at 11:04 AM Jochen Keil  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,  JochenOn Wed, Apr 17, 2024 at 2:23 PM Sébastien Chaurin  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  wrote:Have a look at https://discuss.pixls.us/t/annoucement-of-dtlapse/19522Am 16.04.2024 um 09:59 schrieb Sébastien Chaurin :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 

Re: [darktable-user] Feature idea : DTtimelapse ? (similar to LRtimelapse in essence)

[William Ferguson]

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  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 
>> 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

Re: [darktable-user] Feature idea : DTtimelapse ? (similar to LRtimelapse in essence)

[Jochen Keil]

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 
> 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
>>
>> 

Re: [darktable-user] Feature idea : DTtimelapse ? (similar to LRtimelapse in essence)

[Sébastien Chaurin]

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 
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

Re: [darktable-user] Feature idea : DTtimelapse ? (similar to LRtimelapse in essence)

[Martin Straeten]

Have a look at https://discuss.pixls.us/t/annoucement-of-dtlapse/19522

> Am 16.04.2024 um 09:59 schrieb Sébastien Chaurin 
> :
> 
> 
> 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