Darktable internal working color space

Software darktable
1

Recently, a project has required me to work with a slightly modified version of the darktable source code that saves the output of each processing block as a .tiff file when using darktable-cli. For many of the blocks, this has worked fine, but I am seeing issues with buffers saved from colorin to colorout.

According to darktable’s manual:

between input color profile and output color profile : Image is in the color space defined by the selected working profile (linear Rec2020 RGB by default).

For this reason, when modifying the source code, I operated under the assumption that darktable was using linear Rec2020 RGB internally. However, the images saved from blocks between colorin and colorout appear very distorted.

For example, below is an image saved directly from the output of exposure, right before colorin:
(Note I converted the .tiffs to .jpg for ease of uploading to this post; they still look mostly the same)

altura
altura6048×4024 2.65 MB

And next, the output right after colorin:

altura.DNG_colorin_test_0.0
altura.DNG_colorin_test_0.06048×4024 27.8 MB

Something is clearly wrong with the modifications that have been made here. I’ve spoken about it with some of my colleagues, and they suggest that it might be due to incorrect assumptions about darktable’s working color space - perhaps the working colorspace is LAB, and not RGB?

My question is the following: What might be happening with darktable’s image buffers between colorin and colorout? Is it possible that this is the result of a different color space from RGB being used? How could I go about finding out?

Additional context can be provided by looking into the data for the two above images. Below are data from the two tiffs side-by-side:
(before colorin to the left, and after to the right)

image (1) image (2)

Much of the pixel data after colorin exceeds 1.0 - something that should not be happening with RGB images. Is it possible that I’ve saved an LAB image?

I am not very knowledgeable about darktable’s source code, so any help from those more experienced would be much appreciated!

2

If you are looking at the output at the module level before and after colorin then the math is in two different color spaces ie camera/device vs working… maybe the answer is in here… Article: Color Management in Raw Processing

I believe DT profiles are unbounded as well and so are not limited to 1.0 with the use of floating point math

1 Like
3

Thanks for the help, Todd! I’ll give that article a read.

I am aware that there is a color space conversion going on; it just seems - given the output that I’m getting - that something isn’t quite right here. I was just under the impression that colorin converts to linear RGB by default. Perhaps this is not the case with what I’ve been doing. Or, there might be some other oversights in how my modified version of the colorin.c file writes out the processed image.

4

It shouldn’t happen with Lab either… Note that the problem is not that the data exceed 1.0, but that they do so where the input data don’t.

To check that, someone would have to see your modified colorin.c. But I’m surprised you had to change colorin.c to get its output.

5

It might be of interest, darktable master has recently got the --dump-pipe option that will dump pfm files of a module in & output. Might that help?

Also - out of curiosity - what do you use these tiff files for? I might be interested to implement that sort of stuff if there could be a common usecase except for debugging dt…

6

If the output gamut of colorin is smaller than the input one, of course they will.

1 Like
7

Not “will”, “can”…
Then again, in that case we might still have an issue here, as colorin is not the place where you want to restrict the gamut (it’s rather early in the pipeline). And, values multiplied by about 8 (eight) would be a heck of a gamut reduction, the more as the input RGB values shown all indicate colours with low saturation.

8

@rvietor I’ll have to double-check, but I should be able to share my modifications to make things easier.

@hannoschwalm I hadn’t heard about the --dump-pipe option, but it sounds very promising! Could you tell me more about it/how to use it?

Actually, I’m not using these intermediary images to debug. I’m currently working on implementing this paper for Darktable. In short, this involves training neural networks to mimic many of darktable’s core processing modules. Once these are all trained, they can be chained together to replicate the entire pipeline (This could have a lot of interesting applications, opening the door for bringing machine learning to darktable). The plan is to open-source everything once I get it fully working!

Unfortunately, for some of the modules - like colorin or demosaic, I need suitable training data, which I’m saving from just before and just after each module in question. The images that I’m saving from my modified demosaic.c appear to be “reasonable”, but the same modification does not work for colorin.c.

Hope this provides some more context!

1 Like
9

if dt is used with --dump-pipe colorin,colorout,demosaic for example it will dump the in & output of the modules in the list as pfm files (float32 data, either monochrome or rgb) in a temporary directory. The name of that dir is written to the log.