One of the most time consuming work for any photographer is probably the development process. Lot of time behind a computer screen to adjust the curves, the contrast, the colors, the sharpness… All these are application specific, that is, the development process done with Lightroom is not compatible with AfterShot Pro or darktable (to name just few raw processing softwares around). This makes it really difficult to move from one software to another.
This is a companion discussion topic for the original entry at https://www.darktable.org/2013/02/importing-lightroom-development/
On 2 February 2013 this page was created:
https://www.darktable.org/2013/02/importing-lightroom-development/
It says:
The work on this import module will continue, trying to be more accurate where it can be.
Has further work been done on this in the last 6+ years? Is it better now than it used to be?
I am not sure the full scope of the changes over a 6 year period were but version 2.6 added more metadata fields that get imported.
That is good that more metadata fields have been included. The article is about the Lightroom development settings though and their import into darktable. The article is quite old and it says further work on importing and handling development settings was going to be done. I have not been able to find any information about further improvements in this area.
Best thing to do is to try it or read the source code!
Trying it? How does that determine what, if any, further work was done in the last 6+ years?
Looking at the source code may indicate whether the code has been updated in 6+ years, or maybe not. I suppose it depends on whether it is well commented with new/changed stuff also commented as such. Of course, the best way is for someone who has worked on it to just say so. 
Since it was documented in the manual in 2013 it wouldn’t hurt to give an update on what further work was done. How could anyone object to that?
It won’t answer that question, but trying it would tell you how much of your LR edits would be preserved through the import process.
Of course it’d be great if that person remembered what they did and showed up here to tell you. That may not happen though. And since this is open source software, that means you can know for yourself without depending on anyone else. That is the best kind of knowing for me 
Here’s the deal. I have about 108k photos in my Win10 LR catalog. About half of them have been edited. I often go to a previously edited photo and tweak it a bit. I have used many, many of the various LR editing functions, but not all of them in every photo. I have, of course, tested by bringing into darktable several dozen photos (mostly raws from the multiple cameras I have used over the last 19 years, but also a few jpegs that were edited in LR). It is darn near impossible to check all the functions used in my LR editing over the many years I have used many versions of LR since the used functions are used over so many photos. Having an up to date list of what is handled would be very helpful though because I know what in LR I have used over the years. I could then target tests of those functions imported into darktable by doing test edits of photos in LR and then importing the photos and xmps into darktable. Anyway, I was just hoping to get an update on what, if anything, has been done in this area.
Since I have never gotten any source code for any open source program it would require time and effort to figure out how to do it. Then I would have to look at probably a rather large amount of totally unfamiliar code in a language or languages I may know little about.
This is sort of unrelated, but since I haven’t posted much on this forum it might be an appropriate time to ask. Is it verboten for non-software engineers to ask questions here? Someone on another forum told me this was the place to ask questions, but maybe mere darktable users are unwelcome here? I just hoped that someone who knows might be able to answer what I thought was a very simple question. If there has been more work on this LR development migration it would be great if the article was updated.
Oh, darn, I just discovered something. In LR when you use ctrl-S to save the editing instructions and metadata to an xmp file it only does it for raw files. It says that for jpegs, tiffs, etc. it saves all of that to the image file itself. I have thousands of tiff files (scans of film) that I have edited in LR and also thousands of digital camera OOC jpegs that I have edited in LR. I just tested this by editing an OOC jpeg in LR, ctrl-S, and then importing the jpeg into darktable. I then opened the jpeg in darkroom and it appears that none of the LR editing got imported. 
I think this might be a good place to start: https://github.com/darktable-org/darktable/search?q=lightroom&unscoped_q=lightroom
All the code is on github, free for you to peruse.
Questions are welcome. Any and all questions are welcome, so far as I’m concerned. You may get exactly the answer you’re looking for from exactly the person you want to hear it from… Or you may not. This is the nature of support for free software: none of the developers are paid to write code and nobody is paid to be here to provide support. I do it because I like the software and it is a way I can give back, since I can’t code.
I hope so too, but it may not happen. Looks like the code was last touched in 2016 (at least lightroom.c and .h) so someone may have to look at the commit history to figure it out.
Yes it does, but you can dump the image file metadata to an xmp file with something like exiv2 or exiftool. But, if that image has already been exported from lightroom, and you don’t have a copy of the original file, if you dump the metadata and import, you’d be applying edits to an already edited file, which probably isn’t what you want. I’ve never used lightroom, so I don’t actually know.
In LR ctrl-S is not export, it is save metadata and nondestructive editing instructions to an xmp for raw files and for tiffs and jpegs it means save all that data within the tiff or jpeg file. See this:
I skimmed through the lightroom.c code and the only comment that indicates a date says: copyright (c) 2013–2017 pascal obry.
I do not find any comments in the code that indicate what was changed/added after the initial 2013 code. I suppose some bugs were fixed, but probably no increase in support for LR non-destructive editing instructions. There are, of course, still many more LR instructions that are not supported. Currently ON1 claims to support importing all of the LR editing instructions and getting very good results with most translations to the ON1 equivalents. C1 also supports most or all, I think. ACDSee only imports the metadata though. They all import a LR catalog though, not individual xmp files for each image file. That means that they can import the non-destructive editing instructions for tiff and jpeg files too.
I realize the developer who created this darktable capability is probably not interested in suggestions from the cheap seats but I will offer an idea. Rather than require the individual xmp files use the LR sqlite catalog file like the other programs do. This has at least 2 advantages:
-
It means that xmp files for each and every one of the image files in LR do not need to be created and stored.
-
It also means that the non-destructive editing instructions for tiff and jpeg files could be imported too.
I do realize that the other programs import a LR catalog in one long operation, but in darktable the individual xmp file is read when and if the image is opened in darkroom. It seems that the current method could still be used, but instead of getting the info from the xmp file when the image is opened in darkroom it could get it from the LR catalog when the image is opened in darkroom.
This is a good suggestion, but C1 and others probably have a paid, full time enginner who reverse enginners the LR database and maps those LR modules onto C1 & co.
Darktable has zero full time, paid staff. All are volunteers.
Knowing adobe, the formats probably change often, so an import of a catalog file is probably good only for a few versions.
I’m not trying to be disparaging at all, but it probably won’t happen. If it did happen, it’d likely be error prone and require a lot of support.
Yes, of course, I know they are commercial products with paid employees and darktable is worked on by volunteers. While it would be nice if someone who is very familiar with the design and programming of darktable would work some more on this I realize that it probably won’t happen. I think this is a huge bang for buck type of thing though. Sorry for the expression since no one who works on this is getting any bucks at all. Like all of us I am very grateful for all their hard work.
A further refinement of the above idea. In order to maintain backward compatibility with the current xmp method then have a global option to choose what to do if a LR xmp file exists and a LR catalog exists that determines which one to use and which to ignore for a particular image. It would be even better to have 3 choices for that global option:
- If both exist use the xmp.
- If both exist use the catalog.
- If both exist ask what to do when opening the image in darkroom the first time.
Yes, the LR catalog has some changes from time to time. I suppose the LR xmp files also change sometimes, at least with regards to new editing instructions, new or changed values, and so on. I know, this is all a can of worms.
That’s not the issue at all. I have made this mode to migrate out of Lr when I had a Lr license. At this point I’m out of Adobe crappy business plan and certainly won’t by a license to fix or enhance this mode. Since my first implementation there was some updates and later some fixes based on some XMP given to me to update some part of the parsing. But that’s all we can do.
And now please realize that there is 0 chance (yes zero) to get a development that will get the identical export jpeg. That’s just impossible given the very difference there is between the core dev engine.