The RDF is just for the XML elements, not their values or the tools that read and interpret those values.
And what this can bring? Reading XMP is fine, easy even trivial. But what does that bring? Nothing in terms of image processing. Or maybe I completely missed your point?
Just for the record Iām the author of the Lr import in darktable and I can tell you that this is no trivial task and even the simplest module is very difficult (read impossible) to map one to one to have a look alike final image.
I would be curious about a few things
- what does LRtimelapse actually do? How does it work?
- if it writes those XMP files itself. what kind of informations are stored in it?
- if it writes those XMP files itself ā¦ could we get it to write informations for DT as well?
2 Likes
In my initial article (1st post), I explained quite in detail, what LRTimelapse does and why some changes in darktable are necessary, in order have a chance, that LRTimelapse (one day) could be compatible to darktable and those two software can co-operate.
So, yes Pascal, I do think you missed my point a bit.
Abstract
- LRT reads values from the xmp (integer, decimal)
mainly exposure and WB, (e.g. from pic 1/100, 50/100 and 100/100) - calculates the necessary interpolation
to get the wanted transitions and balance exposure steps due to automated camera re-setting (exp, aperture, ISO) during day/night transition-shots - writes the interpolated values (e.g. for exp and WB) into the xmp-files
of all the other (97) pics, except the keyframes (1/100, 50/100 and 100/100 in my example). - from here user opens DT, accept the newly written xmp as the actual values and imports that
- after the user exports the pics to what ever jpg, tiff or ā¦ he can render the movie to get the final result.
@darix your Point #3 that is exactly, my aim or final goal.
Why I think something need to happen?
The author of LRT would merely think to invest time into a (today) limited user (customer) base, when it can be handled by him.
What can be handled?
- Integer and decimal values, with a clear descriptor
(and specified, to avoid unexpected failures or surprises). - Not necessarily like Lightroom, but the closer to that, we come (only for those modules we would like to start with) , the easier for him to have an interface
Indeed it would be a nice beginning, if we can create two āspecial modulesā like LRT-exposure and LRT-WhiteBalance and give them a new parameter definition (integer, decimall) in the xmp. From here I thought a bit further already and put it into my initial post under Concept (separate view)
There are more headaches than the most obvious, but I donāt wanna flush the baby with the bath, as we have a kind of saying.
For those who loves details, here is an LR-example.xmp, what LRT can handle today <?xpacket begin="ļ»æ" id="W5M0MpCehiHzreSzNTczkc9d"?><x:xmpmeta xmlns:x="adobe:n - Pastebin.com
2 Likes
Is the interpolation linear or something else?
Not linear, quite complex, to compensate several even overlaying effects
I think the idea of editing the xmp externally becomes less trivial with the new features of the 3.0 release. Especially reordering of modules may cause some trouble. Therefore an internal solution similar to what was prototyped already may be the better way to go. Of course that needs a dev willing to have a long term relationship with the project.
Adding extra modules just to interface to some commercial, closed source software sounds odd to me. If the software producer implements this interface in the external software, of course thatās fine. That would mean reading and understanding darktable xmp files, which for 3.0 may not be trivial, but not impossible I think.
We have the same thing for TurboPrint 
1 Like
Hm, did not know about that. I have no issues with Gunther selling his software, I understand that he has to make his living from that. For me, trying to live a free software life, itās just something that goes not well together. Itās not about money, itās about being able to look into things, learn and understand, and itās about technical topics, and about keeping my data accessible. That we have that for turboprint feels now odd as well. And the question is, why do we need it, as turboprint integrates into the printing system kind of seamless?
Chris,
nobody try to sell something here, except ideas.
Me and hopefully others, we want to have a professional software to create the timeplapse. The level Gunther achieved wont be available any time soon, as you also already guessed.
From that perspective, I donāt mind commercial software and I donāt want to learn, I donāt need to worry about my data. The only thing I want is, being able to use LRTimelapse, without need to say goodbye to darktable.
In case the motivation is still unclear, please see my initial post. Any constructive support is highly appreciated.
Sincerely
Axel
2 Likes
I did not think so. IMHO the way to go should anyway be that lrtimelapse learns darktable xmp instead of adapting darktable. The information is in the xmp files, just coded in a different way. I am pretty sure that adobe did not change lightroom to make it compatible with lrtimelapse. At least not when the project was fresh. Maybe you can pay Gunther to do the changes?
If this is the case, then maybe lightroom is the better tool for you?! I do not mean that offending, I just think working with free software gives the users some responsibilities as well.
I might be mistaken, but I have the feeling, you did not get, what I said before starting from initial post.
Crossing the arms in front of chest is counterproductive.
1 Like
I agree that this will be nice to have. Iām still not sure how feasible it is. but it will require a team to step-in to start designing that I suppose. This requires people having some experiences on time-laps 
1 Like
Maybe I am too stupid but I do not get it. The beginning of your post is all fine, but the proposed solution is not described such that I exactly get what you want. As far as I understand, itās about writing xmps that are easier to parse. But I do not get why the current xmp format is a real blocker.
However, I am still in favour of a native and free software solution (darktable internal or external) such that we all can benefit from it not only by using it but by learning from it in many dimensions. Why not pick up the implementation prototype thatās already there instead of interfacing with proprietary software?
Thatās a beginning, we are on the same page 
I ever hoped, there is one or some devs, which are in timelapse as well and would support it, or those devs who are the main acts for Eposure, Whitebalance and xmp-definition would accept to go step by step and we tryā¦
It seems to me like the functionality here would be better implemented as a separate toolā¦
A Python script could interpolate the desired parameters between keyframes and generate outputs to potentially command any RAW processor. Additionally, analysis could be done on frame content to determine parameters for the next frame.
A while ago there was a Python script that implemented key aspects of LRTimelapse functionality (such as dynamically adjusting camera exposure settings during the capture process by analyzing each image and performing āfilteredā exposure adjustment similar to what Sonyās in-camera timelapse tool does), Iāll see if I can find it when I get back.
Hello guys,
let me try again an approach and keep being a PITA
Today we find something like this in dtās xmp:
darktable:operation="temperature"
darktable:enabled="1"
darktable:modversion="3"
darktable:params="046c32400000803f8c4dd63f0000807f"
It is understandable for me, that behind ādarktable:paramsā is all the power of dt, like:
- masks (with all their unlimited power)
- blend modes
- core values of module
- etc., etc.
So indeed I would also be very very careful, if I wanna touch a running system.
But just one question:
Is it imaginable, to extract the values, which are interesting for TL and have just those two (temp and tint) available in an editable, additional field? The rest in params should be untouched, just not representing temp/tint anymore.
Here is an simplified example, what I mean:
darktable:operation="temperature"
darktable:enabled="1"
darktable:modversion="3"
darktable:params="046c32400000803f8c4dd63f0000807f" (example !)
darktable:temperature="5748"
darktable:tint="1.012"
Something like this for exposure likewiseā¦
To avoid we damage something, which just runs well today, I propose:
- to have two new modules: exposure-TL and whitebalance-TL and
- pack them in a separate view.
- Only those two modules have that abilitiesā¦
Like this, someone could change this values from outside, theoretically with an simple editor (which at the end is, what LRT does when it exports its work).
Practically I have manually edited WB-temp with an RT .pp3 file tonight and it worked (after changing the temp and open the pic with RT again, RT interpreted that new value correctly and calculated the effects to RGB automatically).
Yes, definitely, thatās actually done in darktable already (when we read those params). I even think that if you didnāt enable the XMP compression in preferences, they are already stored in clear.
Reading your whole post, I wonder actually how much work it would be to just re-implement the feature from scratch in dt. Matching white balance and average brightness is not rocket science.
2 Likes
I just tried with switched off compression, the values are still not really stored in clear but (assumed) bases64
Thanks for your supportive attitude.
I do admit, backwards compatibility could be a pain. Another good reason, to pack such things in fresh modules only, to not hurt, what we have already.
There was some communication on github about how to decode the xmps, maybe have a look there (donāt remember which issue or pr). I still donāt think special modules are needed to interface to lrtimelapse, itās all there.
1 Like