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