As I said, “ideally LR compatible or clearly specified/defined xmp”. Especially the latter isn’t the case today but a prerequisite in order to modify with an external APP.
Maybe it would be good to open an issue on the DT Github repo for this so it could be more technically discussed and seen by devs.
The devs actually all have accounts here IIRC.
2 Likes
the XML is clearly specified. if you look at the top of the XMP file each namespace has its schema/DTD referenced. it is just different namespaces with different content than what lightroom uses.
and emulating lightroom behavior without clear specifications of the algorithms is impossible. that’s why the current lightroom importer only covers some very basic things.
May I call this “defined” 
but is it “specified”? What is needed, is a reliable base for a third-party software.
Maybe this post from Mai about documentation of xmp, which has had the same background meaning, helps for clarification.
I hope we do not stuck here, by discussing, whether current xmp would be suitable or not, whether base64 is usable or not. I wouldn’t have spent the efforts to write this article, if I could have succeeded with such approach at Gunther 
As I said above, once we proceeded in a way, coming closer to “yep, the idea is doable with a separate view and ‘castrated’ modules…” then @gwegner might even support in defining which elements/classes need to be specified for xmp to even have a chance darktable and LRTimelapse can be compatible one day (to prevent, every now and then things suddenly behave different and the interface wouldn’t work anymore which makes users to think bad about both softwares).
This is a bit off-topic, but I can’t avoid mentioning that the firmware add-on CHDK (and probably Magic Lantern) allow in-camera deflickering for timelapse shooting, thanks to the capability of script execution.
In CHDK, there’s this fantastic script YASS (for Yet Another Sunset Script).
2 Likes
in separate IRC chats I have discussed with you about this topic. May I kindly ask you to express your -hopefully supportive 
- thoughts and ideas about this approach?
Would be very nice, as I still hope, we can find a vivid discussion here about future abilities of darktable in an additional field of photography
Sincerely
Axel
Fully agree, this is no hope to get an XMP compatible with Lr. That’s just not hard, that is just impossible. No way around that.
@Pascal_Obry
seems my English capabilities are way to be improved
I ever said, “ideally”. Doesn’t mean I want a 100% compatible thingie. But in the same manner (more closer to the XML ideas) and reliably specified (so one could do a translation / transformation table), that would help a lot.
Just imagine, you write a separate, not implemented function and you want to control dt from outside… Actually LR’s spec cannot be THAT secret, as it already gets crontrolled from outside via LRTimelapse. But again, I am not looking for a “just alike” but something can be handled for someone, who wouldn’t have this as the top priority rather than a prerequisite.
Cheers
Axel
Maybe you can find out what information that timelapse tool is actually putting into those XMP files.
And then we can see if we can do something about the things they put in.
and the XML format is reliably specified … the module settings for each module are probably also easily documented (iirc @houz wrote a Javascript app once to show the settings in a XMP file)
I know, @houz is the key player for the xmp. But as I have linked above an attempt from May, it was not yet doable to get the specification for the xmp on hand.
That java-script anyhow would be nice to have… Do you have a link available?
Cheers
Axel
Hi there, year by year I see more people interested in timelapses, also I would love to have this feature inside DT
I had a look at GitHub - fhrtms/darktable: darktable main repository and i saw that it was ready for 2.2 so not so much versions ago!
That is very close to what I have discussed yesterday with mica[m] @paperdigits on IRC. I also got the idea already, now it needs to be split down to digestible peaces
I will come back with something like this, soon
Indeed, I think smaller steps would be much more doable.
My thinking boils down to this:
- Pick one module to start with (exposure or white balance should be both easiest and most necessary).
- Decode the part of the xmp.
- Figure out the format and how to write into that format.
- Write a CLI tool that takes a starting and ending white balance/exposure balance and interpolates the value of each file in the time lapse from begining to end.
- Write those values into the xmp.
That part is, what LRTimelapse does (and way more)
Basically I see it the same way.
Why you guys say like this?
When I open such xmp, I find the specification reference in the third line: http://www.w3.org/1999/02/22-rdf-syntax-ns#
Confused…
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