Good question, I kind of remember a discussion about DCP very long time ago when I integrated the project as dev but that’s all. But I lost all details about this discussion. So why DCP is not supported, no idea. That being said, as Darktable is scene referred I’m not sure having a tone/hue correction based on curves makes sense. At which point in the pipeline should the tone curve be applied? Also a DCP profile contains a color matrix, when should it be applied. Probably all those are not to be applied at the same time, so given Darktable pipeline I’m not sure it is easy or even if it is doable.
Thanks for the explanation, Pascal. I will study this subject using the nice material that people linked here, and try to figure out if I can come up with some POC implementation for DCPs in darktable.
My initial idea, in order to keep the scene referred workflow, is to ignore the tone curve from the DCP, so the user still make this decision using sigmoid/agx. My understanding is that the tone curve from the DCP is not some compatible with scene referred, but the other data from the DCP could be used in the input color profile module.
You’ll also need to deal with the white balance if you handle the profile. And again this is not on the same module. Let’s see what you come up with!
Listening to all of this, from a darktable perspective wouldn’t it be better if those DCP files could be converted to .dtstyle files?? (I am not suggesting in any way this is trivial!!!)
I would like to have some styles with the correct DCP file for my camera in the input profile module, and some tweaked agx/sigmoid that approximates the tone curve from the DCP file. But not sure if this is what you meant.
![]()
Ignoring the tone curve was exactly my thought when i read Pascal’s reply. Color is the interesting part. Perhaps later on it would be possible for the base curve module (or even AgX) to pick up the DCP used earlier in the pipe and implement a “use dcp tone curve” checkbox (if a DCP is present, greyed out if not)?
Being able to shoot two color targets (dual-illumant DCP) and have the module interpolate between them is a dream come through. The ICC way of doing things (creating a profile for each lighting condition) was never a practical way of working. There’s also a wide availability of DCPs.
So many interesting developments going on right now, it’s a joyous time to be a hang around this forum! ![]()
Yes, if I understand it the DCP needs a CCT value and that would come from the CC module which is later in the pipeline… It think it would require a lot of reworking to keep track of everything and not break things but as you said lets see if someone can come up with a scheme…
Would it make sense to keep the input profile CCT independent from color calibration? Because
a with a good input profile, color calibration will have very little to do, and its values will no longer represent the scene lighting. (If your DCP is weighted 100% toward StdA because the photo used incandescent lighting, the correct color calibration settings would be 0% chroma. CC would be used artistically or not at all.)
If the DCP adequately describes the scene and it’s not set to 6500K (CCT is not set to 100%), color calibration’s CAT should be disabled my default. It would be like doing white balance twice.
I don’t think that’s possible in the current way things work. While the camera has only one spectral response, the light splayed onto its sensor has particular color temperature, which varies wildly from scene to scene. The color transform information, either matrix or LUT, has to work on data that is affected thusly.
What I’d be interested to see is how significant the difference is between a tungsten-illuminated scene developed with a StdA profile vs a D65 profile. In most softwares, the camera matrix is D65, and we unwittingly use it to develop all our images, and our vision system happily accommodates the subtle differences. Adobe has gallantly offered an alternate workflow with CCT-tailored matrices, would be curious to see if that effort is worth it.
just if you exclusively shoot your picture having the same scene lighting as the one used to create the dcp.
Which in reality means - if you’re able to generate a dcp for each shooting condition then you can also generate an icc for it which is already supported by darktable.
Hello,
It’s interesting to read these discussions about Adobe’s DCP. I’ve also been working on this topic to try to implement it in my experimental branch, but to be honest, the results aren’t encouraging. Especially since I’m getting very good results for my Pentax K-1 using the ICC profiles I created with DCamProf or with the Color Calibration module and a color chart.
Could we have an advantage in the legacy workflow, where the built-in curve is enabled or disabled depending on the chosen workflow? Something like what I do with the tone mapper selector?
Greetings from the Lubéron,
Christian
Hi everyone,
I very much appreciate this discussion here, especially since I am still taking baby steps to understand the problem.
I will definitely report here when I have something more concrete.
I think that Art and probably RT break it down so that you can disable elements of the DCP and get more or less just the matrix for doing scene-referred and then tone mapping later, or you can introduce the non-linear elements of the look table, tone curve and hue-sat tables… as you see fit by enabling the checkboxes
I didn’t go throught the code base but a quick couple of AI queries suggested that the elements of the DCP were partitioned and applied where most appropriate in the pipeline…
So in ART you would disable the those elements and just use the WB part. Then you can use log tone mapping or a ctl or other means of tonemapping. Of course if the DCP has a “look” and that also depends on the embedded tone curve and those other elements then you would need all those for the full overall result but that might not work with the DT pipeline as it is now…
Darktable doesn’t support dual illuminant ICC pair interpolation. It could be implemented, but I don’t think the interpolation is simply linear.
We would want a color picker to help choose the interpolation point. Implementation-wise, it would be useful to know how to interpolate beyond D65 to white balance deep blue sky illuminant. I’m sure much has been written about this. I’ll try to find time to try rawtherapee to get more UI perspective on this. I think the UI for DCP would be the same as the UI for dual ICCs, especially since darktable has great tone mappers and doesn’t require curves from input profiles.
@hanatos is doing something equivalent in his vkdt color management. I haven’t sifted through the algorithm, but it may be easier to snarf than the Adobe spec.
And actually vkdt can do this too nowadays! You can’t really do it by just using the dcp’s, but if you use the DCP to get an estimated spectral sensitivity function, you can easily create a lut that is optimized for arbitrary illuminants. Whether dcp-estimated ssf’s work all too well for illuminants beyond what the DCP itself encodes (A ↔ D65) I have no idea, since even dual illuminant interpolation seems to also suffer a bit of an accuracy loss in between.