Every year I start a fresh Lightroom catalog, and most contain hundreds of photographs and digital drawings. That scale is exactly why I kept postponing my move away from Adobe’s subscription.

I’ve had my eye on the free and open-source RAW photo developer, Darktable, for quite some time. However, I didn’t want my first attempt at migrating years of edits to be from a huge Lightroom catalog.

My pandemic-era 2019 catalog offered a safer test. Lockdowns meant my photography sessions amounted to a measly 20 DNGs, though those files still contained crops, masks, ratings, color labels, and adjustments.

I migrated that catalog from cloud-based Lightroom to Darktable. The originals and organization survived for the most part, but Lightroom’s editing instructions arrived in very different states.

My smallest Lightroom catalog still had plenty to lose

The limited collection contained almost every kind of edit I needed to test

With only 20 photographs, my Covid-era landscape catalog was small enough that I could inspect every image before and after migration. That was ideal because I wanted to spot any subtle changes, not glance at hundreds of thumbnails and declare the move a victory.

Each photograph was a DNG raw file, rather than a finished JPEG. That meant its appearance depended heavily on Lightroom’s processing. Being non-destructive, Lightroom doesn’t permanently apply my adjustments to raw pixels. It stores the instructions for things like white balance, tone curves, and exposure adjustments in a hidden cloud database rather than an XMP sidecar.

My Lightroom catalog had plenty of adjustments that I feared weren’t going to migrate over to Darktable peacefully:

• Cropped compositions.
• Spot removal thanks to a few hot pixels on my Pentax.
• Linear and radial gradients.
• Brush masks.
• Automatic subject and sky selections.
• Global Lightroom workflow-specific adjustments, such as clarity and de-haze.
• Chromatic aberration removal and lens correction.
• Color temperature, saturation, and tint.

Adjustments weren’t the only thing I worried about. The surrounding catalog organization work was also important. I had added keywords, star ratings, color labels, presents, and pick-and-reject flags. So the collection was small, but it represented every part of my normal photography development workflow.

Simply opening all 20 DNGs in Darktable wouldn’t prove much. I wanted to know whether the photos still looked right, whether their editing history was still useful, and whether I could still find and organize them without manually rebuilding.

Lightroom exported my photos, not its catalog

Original + Settings embedded the Adobe instructions inside each DNG

Since Darktable can’t open a Lightroom cloud library, or even import a .larcat database, getting the files over wasn’t a classic catalog migration. In Lightroom, I selected all 20 photographs and exported them using the Original + Settings template. Adobe returned one DNG for each photograph, but no portable catalog and no separate XMP sidecar, which was rather worrying.

I soon discovered that nothing was actually missing. Raw DNG can store XMP metadata inside the image file, so Lightroom had embedded its non-destructive settings alongside the raw data. I pointed Darktable at the exported folder and imported the lot.

Darktable then created what I wanted to see. A second file beside each photo file using the .dng.xmp extension, which was Darktable’s own sidecar. These are where Darktable stores future adjustments, and they’re my ticket to getting away from Adobe Creative Cloud.

All 20 images appeared in Lighttable immediately. Organizational elements like keywords, star ratings, and color labels followed them, but the Pick and Reject flags didn’t. Opening an edited photograph did reveal that compatible Lightroom adjustments had become individual entries in Darktable’s edit history.

That was more encouraging because it had recovered the raw photos and some of the work attached to them, but Adobe’s catalog structure itself had unfortunately stayed behind.

OS

Windows, Linux, macOS

Developer

Johannes Hanika

Darktable is an open source photography workflow application and raw developer.

The same sliders did not produce the same photographs

Adobe’s settings survived in three very different states

Darktable’s Lighttable made the migration look almost perfect at first. The thumbnails were all present, the ratings and labels were recognizable, and opening Darkroom showed imported operations in the history stack. Unfortunately, comparing the photos told a more complicated story:

White balance needed attention on every photo because Lightroom’s values didn’t map cleanly to Darktable’s controls, and photos rendered much warmer. Tone curves transferred only standard light adjustments, not Lightroom’s full rendering.

Highlights and shadows also appeared changed in the Darktable modules, but the resulting photos were flat and lacked the contrast and tonal range of Lightroom. The most disappointing loss was Lightroom’s Split Toning adjustments. The Split Toning module in Darktable is actually one of its best features, but unfortunately, its values don’t have any equivalent in Lightroom to map to it.

One of the more dramatic failures was exposure adjustment. Since I don’t typically touch exposure values in my workflow, this affected only one photo that I had. Darktable imported the adjustment, but rendered the photo as enormously overexposed.

Other work like cropping and spatially aware editing simply vanished, though I expected that. That included all linear and radial gradients, masking, and automatic sky and subject selections, along with their non-global adjustments. Even though “haze removal” and diffuse/sharpening modules do exist in Darktable, Lightroom’s de-haze, clarity, and texture values seemed to have no usable equivalent.

XMP can describe Adobe’s settings, but it’s not a universal recipe for accurate rendering across different platforms. Darktable uses different modules, numerical ranges, color processing, and processing order. Two controls can even share a similar name without applying the same math to the pixels.

So, unfortunately, while my editing history had crossed over, the original edited appearance of the photos had not.

I kept the raw files, but accepted that some edits belonged to Adobe

Local ownership was worth several repairs and a less convenient backup routine

This was not a flawless migration in any sense of the word. White balance needed adjustment, crops and lens corrections had to be redone, and creative adjustments had to be rebuilt. Across thousands of images, that’s a huge job that could take weeks. Lightroom also makes synchronization automatic, whereas a local Darktable library leaves its DNGs, sidecars, database, and backups all up to me.

I would recommend that anyone who needs identical historical renderings export finished TIFF or JPEG copies before pulling the plug on Adobe.

My main reason for moving to Darktable was ownership. More software is becoming a service rented month by month, with continued access governed by accounts, subscriptions, and ever-changing policies.

Adobe also says it may analyze content stored on its servers for product improvement, though it should be noted that it’s possible to opt out. Adobe also explicitly mentions that it does not train AI like Firefly on subscribers’ personal content. Nevertheless, I would rather keep my photos outside the policy question altogether.

The good news is that the migration gave me that. All 20 DNGs remain editable, and keywords, ratings, and labels all survived. Before importing the folder into Darktable, I used PowerShell to calculate a SHA-256 fingerprint for every DNG and save the results:

Get-ChildItem *.dng | Get-FileHash -Algorithm SHA256 |
Select-Object Path, Hash |
Export-Csv .dng-before.csv -NoTypeInformation

After importing, editing, and exporting a new JPEG, I calculated the hashes again and compared them with the saved list:

$before = Import-Csv .dng-before.csv
$after = Get-ChildItem *.dng | Get-FileHash -Algorithm SHA256 |
Select-Object Path, Hash

if (Compare-Object $before $after -Property Path, Hash) { "FAIL: One or more DNG files changed" } 
else { "PASS: Every original DNG hash is unchanged" }

A file’s SHA-256 value changes if its contents change, so matching results showed that Darktable had left every DNG intact and untouched. Its adjustments only now exist in the new .dng.xmp sidecars rather than inside the raw files.

My comparison returned:

PASS: Every original DNG hash is unchanged

That result finally settled the larger question for me. I won’t dump thousands of photos into Darktable at once and hope for the best. I’ll be moving my remaining catalogs over one year at a time and exporting reference copies of images I care about.

Darktable certainly isn’t a drop-in replacement for Lightroom, but it’s where my photography workflow is heading from now on. The migration is going to be slow, but each completed catalog will leave me with locally owned originals, portable sidecars, and one less reason to keep paying Adobe.