dng from Lightroom to Darktable: completely wrong colours

Hi,

Trying to migrate from Lightroom to Darktable. Can’t figure out an issue with color balance on some of my dng files. Here is an example of a shot in Lightroom:

And when I open the same dng in the Darktable I get completely off colours:

I use Sony Alpha A7RIII. Rawtherapee produces a similar pink cast as well. Could someone, please point me to the right direction? After a few days googling I still can’t find a solution…

Here is the dng file (it’s a big one - 170Mb; had to upload to my google bucket):

thanks!

Upload the dng (drag and drop into the text entry box) and people here can try and debug it.

1 Like

Look at the input color profile and see if you are using the embedded color matrix from the dng or the standard color matrix from darktable

I’ve checked that. it uses embedded color matrix. Changing it to the “standard color matrix” produces strong green color tint:

Interestingly enough if I enable “lossy compression” in Lightroom dng export dialog:

the resulted dng seems to open ok in Darktable:

Above: picture on the left uncompressed dng. on the right lossy compressed.

Here is a “lossy compressed” dng:
_DSC7830-Pano_lossy.dng (13.3 MB)

Why not just edit the .arw file in darktable? Why try and edit a DMG exported from light room?

1 Like

From the name and aspect ratio it seems to be a stitched pano.

I have seen this before. Try adjusting the black point.
Screenshot_Black-Point

2 Likes

The image appearance really changes with the raw b/w point.

3 Likes

I suspect that your lossy compressed DNG is just a JPEG embedded in a DNG file.
It’s not a RAW file anymore and you lose information.

1 Like

What an amusing coïncidence, I just encountered the same problem.

A possible hint as to its cause is that the same thing happens in RawDigger unless I set “Apply DNG opcodes” to all 3 stages, in which case it is rendered perfectly:

opcodes

One thing that kind of puzzles me is that mine is supposed to be a linear (RGB) DNG, and yet all four sliders of darktable’s raw black point module have an effect.

LibRaw simply does not recognize that DNG at all, at least when not built with the DNG SDK (which is not available on Linux).

1 Like

This is an unusual DNG for sure. ExifTool/exiv2 say there are multiple “Linear Raw” images in there, but the full-resolution one does not have any OpCodes, only the reduced resolution ones. So there is maybe some open questions about which of these images RawDigger actually used, and same for darktable/rawspeed…

Furthermore, If I try to “merge HDR” my raw files I get a resulting dng with a strong green tint. Individual raw files open/look as expected:

I thought this also, but couldn’t properly open the image with my libraw-based software. I did look up the camconst.json entry for the camera, and their black point is 600…

Exactly, ExifTool says it should be 2048 for all channels @PrimeSeventyThree

This is possibly something for @LebedevRI as rawspeed might not be decoding the BlackLevel correctly in this case since it is stored as RATIONAL type?

ExifTool says it should be 2048 for all channels
what am I looking for in a ExifTool output ? on the file in question I see:

Black Level                     : 18 14 25

Apparently that’s because there isn’t a single component (but three, since it’s demosaiced),
so this is DNG BlackLevel handling when cpp != 1 · Issue #215 · darktable-org/rawspeed · GitHub
I guess, if you could produce a similar problematic DNG, but with a smaller filesize,
it would be good to have on RPU.

As I mentioned, there are multiple images in that DNG, you want to look at the full-resolution linear raw one.

Run exiftool -a -u -s -g1 to see all the images and their tags grouped.