While I think I qualify as a novice when it comes to using Darktable (DT) for raw file development I’ve been getting results that are quite pleasing to me. The Contrast, Brightness, & Saturation module is something I use quite extensively. Maybe I should point out that my work primarily involves developing outdoor landscape shots taken in early morning daylight.
Most of my experience with DT has been associated with running Version 3.8.1 on Windows. I recently installed Version 4.4.1 and immediately came to recognize that the Contrast, Brightness & Saturation (CBS) Module was deprecated and as a result cannot be used on DT 4.4.1 when doing new edits. Fortunately, it appears to still be supported in the case when working on an image that was developed on DT 3.8.1. As a result, I’ve been trying to learn how to use the Color Balance RGB (CB_RGB) Module as a substitute for the CBS Module. While it appears to offer a lot more flexibility this comes with a lot more complexity.
After a lot of studying and experimentation I’ve been unable to replicate the effect of CBS on an image file of interest even though DT 4.4.1 appears to match the result produced by DT 3.8.1 when developing the same file. In that, as best I can tell both DT 3.8.1 and DT 4.4.1 produce the same results on the file in question.
Therefore, my first question would be, is there a way to turn on CBS in DT 4.4.1 so that it can be used in developing new raw files?
My experiments had to be done on DT 3.8.1 where I was able to use both CBS & CB-RGB. The basic problem is that CB-RGB (after a lot fiddling with it) produces an unwanted color cast that never appears when using CBS. My experimenting has allowed me to produce results where the only difference in development history pertains to the substituting of CB-RGB for CBS. If desired, I can supply image files from my experiments that demonstrate this specific problem.
I feel you - but honestly it really is something of a crutch. For brightness and contrast it’s probably better to reach for RGB curves and get used to clicking in some quick S-curves in conjunction with a luminosity mask. Likewise, after spending more and more time in CB-RGB I find it quicker to use and get repeatable results.
Examples are always good. I think CB module is pretty well behaved and quite flexible. where the cbs module GUI will only work on display referred values and so you may not be actually controlling the full range of data… Are you setting the mask in CB module if not each time you use it you should at the very least set the mask from the mask tab and use the two autopickers set the contrast and grey fulcrums based on the image…
Todd, you referred to CC module. Might you have meant CB (Color Balance RGB)? The Color Calibration (CC) Module is another one I’ve had difficulty with but I wasn’t thinking it pertained to this discussion.
You asked, “are you setting the mask in CB module?”. In the Color Balance RGB Module I’ve been following the advice provided in the User Manual which says, “Masking controls typically don’t require any user modification …”. However, using a different image than the one that provoked this topic I went to the Masks Tab in the Color Balance RGB Module and selected each of the 2 color pickers I found (under a heading called “threshold”). One is called “white fulcrum”, the other “contrast gray fulcrum”. When the color picker is selected the “white fulcrum” changes from 0 to +2.22 and the “contrast grey fulcrum” changes from 18.45% to 91.51%. In both cases the slider moved all the way to right most point. Could NOT make it any higher. In that this seems to be a significant change.
The User Manual (UM) implies that “white fulcrum” affects the 4-Ways tab usage which is something I have NOT yet tried. However, “contrast gray fulcrum” does affect the “master” tab which is what I’ve been experimenting with. The UM suggests this should normally be 18-20% if global brightness has been set early in the pipeline. I do use the Exposure Module to make an adjustment as one of the first ones in my workflow. I’m also following the ETTR recommendations from the UM explained in the overview of Scene Referred workflow. It does look to me like something is amiss when it comes to the “contrast gray fulcrum”.
I will edit… you are correct I meant CB module… You can display the mask after selecting the autopickers…it will of course as you note affect tonal ranges in the 4 way tab and the cross over point for contrast. In other words it will modify what gets lightened and what gets darkened by the contrast slider… at least that is my feeling… you also have a blend fulcrum in the general masking controls for modules when you choose arithmetic blend modes… This can be used when the module correction make the output too light or too dark to keep your exposure intact… Boris has a new video out today that you might find interesting…
This discussion makes me think that maybe there is a more general question that I should be asking. I am using what DT calls Scene Referred workflow. The reason is that the UM suggests this as the preferred method. However, I’m inclined to think that the term “Scene Referred” means ending up with an image that most accurately resembles the actual scene which the camera photographed. In my case this is seldom the objective. My outdoor landscape shots usually in daylight get developed with an intention of exaggerating the perception in what I’d call creating more of an artistic result. This typically involves adding Saturation, Contrast, & Brightness as well as color shifts in some cases. Is it possible that many of these modules, used for Scene Referred processing, are in fact attempting to prevent such exaggerations in the final result? Modules that come to mind are Filmic RGB, Color Calibration, and now Color Balance RGB.
For me, I regard scene-referred as simply meaning the order in which operations are done, with the tonemapper (filmic, sigmoid or base curve) coming more or less last. I like this workflow, and my style is definitely more colourful than nature…
This is a slight tangent, but have you tried using sigmoid instead of filmic? I personally find it is better suited to a colourful style, and I very much like the response of its contrast slider which increases both contrast and chroma what I think is a very intuitive way.
I’ve never used the Saturation Brightness Contrast module, but if I have time later I will have a play.
Edit: regarding color calibration, I have my workflow preferences set to ‘none’ so when I open an image image only the white balance module is applied, (set to ‘as shot’) then I switch on sigmoid and any other modules I want.
I prefer to reserve color calibration for tricky lighting conditions, and creative adjustments. (I know this isn’t the intended workflow, but it works well for me.
In the end you have to use what works and what is comfortable for you. They are your images and they serve you. But you could try sharing one of your examples it seems like you have been experimenting … Do you use blend modes these are very useful for the sorts of things that you are describing as well… Even something like where a module lives in the pipeline might impact the results you are seeing … I can’t recall where the CSB module was applied …it might be listed in the manual… if markedly different then you could try moving an instance of rgbCB to a similar position to see if the impact is altered… in the end examples would help others to maybe share tips and approaches…
I agree it would be nice to see an example, even better one that we could play with. But @priort’s suggestion of creating a style containing a deprecated module is definitely a workaround, and one that should stay viable for as long as dt retains backwards compatibility. (which is always for all I know).
Another way to get to depreciated modules is to use the hamburger menu option and select depreciated modules. Sorry if someone already mention this as I only skimmed the post while travelling.
Also, in my opinion use the modules that work for you. I don’t get get too concerned with display refer vs scene referred modules as photography is about the look of the image.
OK, I can share results for the photo that brought about this post. At present I have 2 image files both produced by DT 3.8.1 where the only difference in the development history stack is that one uses the Contrast, Brightness & Saturation (CBS) Module and the other substitutes the Color Balance RGB (CB-RGB) Module for the CBS Module. Links to the various files are as follows:
In the case of the CBS Module it was pretty simple and straightforward as shown. However, I did a lot of fiddling around and tried lots of difference combinations for the CB-RGB Module. The one shown here is what I ended up with the produced the corresponding image included herein, which was about as good as I could do.
I also included the preview image which I think shows that the lighting conditions do create some challenges when trying to develop this raw file.
That’s not at all the case.
First, in practice, you still end up with an image in a display-referred colour space. Good thing too, when you want to display or print an image on a device which expects such a colour space (like your computer screen!)
As I understand it, there are two main differences between the scene-referred and the display-referred workflows in darktable:
in scene-referred, the pixel values are proportional to the light energy, where in display-referred they are proportional to the log(2) of the light energy. This has some important consequences when using blurs, which could easily cause artifacts in the display-referred workflow (much less so in scene-referred) (see e.g. this article by Aurélien Pierre)
in darktable’s display-referred workflow, many modules expect input values limited to the range 0…1. That means it is up to the user to make sure the values are in that range. Examples of such modules are: levels, tone curve, base curve.
In the scene-referred workflow, the pixel values are in practice unbounded. But we still need to end up with a displayable image with values in the range 0…1. It’s one of the tasks of filmic (or sigmoid) to map that input range to a suitable output (display) range (the other is to transform the data from linear to log(2).) That means that the user has much more freedom while editing.
Steven, no I have NOT but what you say sounds very interesting. I have had a lot difficulty figuring out what the Color Calibration does. I often turn it off and cannot perceive any change. I do typically like to experiment with White Balance adjustments which is about the only thing I actually do with it but the White Balance Module allows for doing the same thing. Also the Color Calibration Module sometimes decides the lighting is invalid and chooses the Custom option. This has occurred on images shot in very normal daylight and I cannot explain how this happens but unwanted color casts can get applied unless I turn off the module. Filmic RGB is somewhat similar. It does allow contrast adjustment which I just about always need. Interestingly the thing it calls Latitude is something I find difficult to associate with affect I can see in the resulting image but I have been reducing it from the standard 50% to around 30%. That was in DT 3.8.1. I notice that in DT 4.4.1 the default is set to 0 rather than 50%. Maybe I’m NOT the only one who thinks a lower, than 50%, value is desirable.
Thanks for that explanation. I did just print out that section of the User Manual but haven’t yet studied it.
Maybe I should clarify. When I referred to my inclination regarding the term “Scene Referred” that came from how it is used in other material I’ve studied that is NOT specific to Darktable but does pertain to raw file processing.
If you set Colour Calibration to none (bypass) in the CAT tab you can then use the brightness and colourfulness tabs for edits or use it as a channel mixer without it doing anything else if you want it off.
I’m having to not use it for white balance, been struggling to get images to look right, if I use the old way just a small WB adjustment and I’ve got a good starting point. I tried creating a profile using a colour checker and that was a waste of time.
This is drifting a but off topic but I think a lot of your explanation is more about linear editing… Scene referred is really a collection of adjustments designed so that you work on as much of the original signal before it gets converted to the display space . For sure a large part of this is also doing so in a linear way which I think is more about what you are talking about and then there are things like the CC module that applies a CAT for wb/illumination which is a method that tries to better represent the original image lighting as it was when displayed on any given set of viewing conditions which can vary greatly. Even the display referred base curve deviates a bit from the definition as it now comes later than in legacy DT which was a more pure display referred workflow ie transformed at the start and now the base curve comes later… I think often terms related to linear editing are conflated with the simple definition of what scene referred editing is ie editing before conversion to display or output devices…
“So, in simplest terms: A scene-referred workflow is one in which we manipulate our images prior to their transformation from camera color space to display color space. A display-referred workflow is one in which we manipulate our images after they’ve been transformed from camera color space to display color space.”
Another thing that was explained to me that I did not initially grasp is that DT never clips any data. Its 32 bit float, its merely that if you choose to use modules expecting display input then that is all the GUI can access. The other data is not clipped but passed along as is for the most part
You would likely benefit from another read of the CC section… I think they mention the invalid situation… It just means that the current CAT CCT value cannot accurately depict wb as defined by this curve. So invalid just means that the current lighting strays far enough from the curve (> than some threshold value which I forget) that it must be defined as custom and not daylight or other standard value from the curve…
From the manual
When the CCT is followed by “(invalid)”, this means that the CCT figure is meaningless and wrong, because we are too far from either a daylight or a black body light spectrum. In this case, you are advised to use the custom illuminant. The chromatic adaptation will still perform as expected (see the note below), so the “(invalid)” tag only means that the current illuminant color is not accurately tied to the displayed CCT. This tag is nothing to be concerned about – it is merely there to tell you to stay away from the daylight and planckian illuminants because they will not behave as you might expect.
FWW Like Nathan I just use wb as I don’t do any fancy lighting and I don’t have to worry about any of the nuances… I do use the tool if I am having issues with wb just to see what it comes up with and or if I do need to mask mixed lighting and for sure I use the channel mixer and other tabs a lot…
When it comes to the CCT tab of the Color Calibration Module the problem I’m having is that the illuminant that is automatically designated varies quite a lot. Almost like it is randomly selected. All of the pictures I’m developing with DT are taken in daylight. The one shared herein was early morning facing the sunrise which was behind some very helpful cloud formations. However, CCT concluded it was daylight. I have others that are much more normal backlit scenes where it concludes a variety of things to include “invalid” and “planckian (black body)”. In the later case, I can still adjust the white balance. Also, if I change it to “daylight” it seems to have no affect on the resulting image but I can still adjust white balance. However, when it is “invalid” white balance adjustment is not offered. In that, it has to be changed in order to perform white balance adjustment.
Is there something I could be looking for in the camera produced metadata that might account for these discrepancies?
Invalid is not wrong it just means don’t try to use the CCT number as a reference to the curve. The correction part is “custom”… you can add or subtract from the chosen illuminant by just tweaking the chroma… this will add more correction or take less… it generally works okay. If you are setting wb to camera reference and set CC to as shot it should look almost always like wb set to as shot… WB is a simple set of coefficients to make white white but CAT is a correction to make items that are neutral in the image appear neutral on the display so this might explain why you often see variations in a series of images…
