The manual is not too bad also there is a wealth of information in these discussions
Which ‘profile option’ is this? If I am to leave it alone, what value are you assuming it is set to, to start with ?
And if I am to remove the .icc/.icm calibration data from my OS, where should I be setting the ‘color mode’ to?
There is a folder in the config folder call color…profiles are in two subfolders in (1) and out(2) depending on what the profile is used for…this is where you will find profiles and where you can save any calibrated icc profiles that you might make…
Oh dear!, this does not appear, through my distorted-reality perception field, to be going well, does it? ‘This’ being my original request for clarification of just a few of the many aspects of the term ‘color management’ as it is practised within dt. It’s probably a user error (in my case it almost always is), so perhaps I should try re-phrasing the question.
This latest (as I type) response - from a contributor whose inputs are of particular importance and value to me - illustrates my difficulty and is a further illustration of the impenetrability I find is a general characteristic of things associated with dt. Based on the information in this response I went searching for this config folder; that was about 2 hours ago. A relevant selection from the results of a Windows search for “config” are (apologies: I haven’t been able to master the search facility to restrict Windows to search on a single word only):
None of the 15 folders named “config”, found on local disk C, have anything to do with darktable. A similar search on disks D to K on my system also failed to find a relevant dt-related folder called config. Not to be deterred, I searched for a file or folder whose name included the string “…color…profile…”. The total search results are:
I decided that there probably wasn’t any point in searching the other disks.
So what is wrong with me, that yet again I fail to be able to get beyond even the first step in freely given and greatly appreciated advice? Or, to put it another way, how should I rephrase that part of my original question, the response to which is given here, so that I get an answer that is ‘executable’ by me? Ori should I just be taking the hint that I should revert to age and type, forget about the idea of taking snaps in raw format and processing them, sit back in a Pythonesque (as in Monty) comfy chair, turn the TV to some left-pondian soap channel and just drift inexorably to a dribbling and incontinent oblivion?
Well, no. Round objects and coitus-off to that. Time to return to the User Manual, where I read:
“For darktable to faithfully render colors on screen it needs to find the correct display profile for your monitor. In general this requires your monitor to be properly calibrated and profiled, and it needs the profile to be correctly installed on your system”
Good, that was my understanding; I had no problem downloading an .icm for my monitor from the manufacturer’s web-site, nor in installing it (been doing that since color management first arrived in Windows), but just to check, I read:
“To investigate your display profile configuration you can run the darktable-cmstest binary (Linux only) which prints out useful information (e.g. profile name per-monitor) and tells you if the system is correctly configured.”
So, what about Windows? I just have to assume I have installed the .icm correctly. Then I read:
“Bear in mind that high-tier consumer-grade screens usually don’t need a user-made display profile unless you need to perform soft-proofing with professional expectations, since they are properly calibrated to sRGB in the factory.”
Is it because I am definitely and firmly in the cohort which can be categorised as “obviously of ‘not Mensa-class’ material” that I conclude from this extract from the user guide that, despite the opening quote, a profile for my monitor is not really required after all, and I can just get by with my monitor hardware set to a color mode and select the same mode in the menu presented by the gamut toggle, or the softproof toggle in the darkroom?
But hey, that’s where I came in, isn’t it?
True, but I have learned from a set of other, consistent, responses, that I have an inappropriate expectation of the manual. Sadly, I find that the discussions that I am referred to here are actually further examples of the sort of impenetrability that I find in the user manual: I end up with feeling that I know less now than I did before reading; that there are too many clauses/phrases that, to me, are ambiguous or of questionable logic or contradictory; or that pre-suppose - recursively, ad infinitum - an existing set of knowledge/understanding which, if I possessed, would render it unnecessary for me to read in the first place. Result: I fail to get a clear understanding
And it is this repeated experience that creates in me the feeling that I have stumbled, unwittingly, into a macho aficionado’s Christmas party, at which I consistently fail to demonstrate that mine are as big as yours. This is, uniquely, a characteristic of a male dominated ‘universe’; why does it have to be this way?
Apologies, that’s just a rant. I get carried away in my interpretation of the word ‘discuss’.
1 Like
Perhaps search for “darktable” rather than “config”… Almost every program of a certain complexity will have something like a “config” directory, not many will have a “darktable” directory.
As for the theory part, you’ve stumbled into a rather complex subject, with some terminology that can be ambiguous (usually context helps, but…). Fortunately, unless you really need high colour accuracy, or are into high-art printing, you can ignore most of it. The reason for that: most of the people who will see your images on screen will know nothing about colour accuracy (nor care about it).
In practice, that would mean stay with the dt defaults, and first figure out how to calibrate and profile your monitor (knowing why those are two separate steps helps).
Cambridge in Colour has a decent series of pages on colour management and such (also on other subjects, accessible from the linked page)
In darktable you have:
input profile - should match the source, for raw files it’s the camera matrix, for non raws it’s embedded profile in the file
working profile - should be some linear large space like default rec2020, so you don’t clip anything
export profile - depends on intended use of the exported image
display profile - you need to calibrate your screen, calibration software provides the icc profile to your os, so ‘system display profile’ should work (except for windows with multiple monitors, where it’s broken since 2.6)
Hmm, intriguing suggestion; logically it leads to the same result: no ‘config’ folder, no ‘…color…profile…’ file or folder> This is not surprising: the Windows search would have looked inside any folder whose named included the string ‘darktable’ as part of my previous searches.
Unfortunately I have no way of knowing that the dt defaults are for the entities we are discussing: they are no defined in the user manual. I also fail to understand what benefit a user calibration of my monitor and the creation of a color profile for it would have over the manufacturer created .icm, for the use-case of “people who will see your images on screen will know nothing about colour accuracy (nor care about it).” - which caters for, essentially, 100% of my images.
I will get around to doing this, though, just to see if I can discern any difference in the way images appear after I have mastered the art of calibration and profile creation using my Datcolor Spyder. On current progress that should be well before the heat death of the universe.
In the meantime, spookily, my images have not appeared, in the absence of this calibration, to be the veritable spawn of the devil himself - as I was warned they would be by just about every article I have read on monitor calibration (especially those by the calibration hardware manufacturers. Now, I wonder why that is?).
Well, if you have received a device profile for your indivual monitor, using that should be fine.
If it’s a generic profile for your monitor type, it may or may not be good enough.
In both cases, checking that your monitor is calibrated is still a good start. For that, see your monitor documentation or the Benq website/vendor.
Having a good profile for your monitor has two advantages even in your case:
- what the other parties see will be closer to what you intend for them to see, as you have removed the errors on one side.
- and more important, perhaps, if you progress and decide to print some of your work, you’ll have less trouble getting the print colours close to the screen colours (“close to”, as the media are very different).
The problem is mine but also I did not know if you were on Linux or Windows and I supposed that you knew where the DT config files are……You will find the folder in this base folder.C:users\yourusername\Appdata\Local\darktable\
Anthony …NP….a quick questions …do you have a basic understanding of color management??
That might be the first thing to clarify.
From there the approach is to see how that is implemented in DT…its not an easy topic but also a basic understanding is not beyond reach for sure….
In the end with DT data comes in from your camera and moves through stages in your processing. During that journey it passes through some profiles that control how the colors are mapped. The profiles have a color gamut and can have a gamma curve or are linear.
DT uses several which can be set as needed.
True color management is realized when you calibrate your camera, monitor, and output devices to provide profiles that accurately display and manage color.
DT uses ICC color management so these profiles will be icc files…
If you can’t calibrate then you can use profiles provided by DT. They will manage the data correctly but many not be color accurate for your specific hardware….
As you can see it is enough of a topic to write an entire book on….
https://www.amazon.ca/Color-Management-Understanding-Using-Profiles/dp/0470058250
Config files…
Its explained here via the parameters that can control configuration options…
https://darktable-org.github.io/dtdocs/en/special-topics/program-invocation/darktable/
but the reference is Linux specific…see --configdir… for darktable and many many WIndows programs …config information is found either directly in the program’s directory or in subfolder of C:\users\username\AppData
For the DT color profile handling… a summary of the process can be shown here…
https://darktable-org.github.io/dtdocs/en/special-topics/color-management/color-spaces/
You might find this useful??
The configuration and operation files of darktable.pdf (183.9 KB)
Sorry I’m late with this, but it would seem what you need first is a generic understanding of why all this stuff is done, then you’ll be able to map that understanding to the specifics of any software. So, in that regard this might help:
2 Likes
Great resource Glen…exactly the question I posed to @LateJunction . Once you get an idea of the process you can use it in all color managed apps to break down how they are doing things…
That is a great diagram.
One key thing here is that DT also has a histogram profile. Currently this is what provides the data for the histogram output and the picker values and gamut data.
Normally that would be derived from the working data directly at least I would think so to be accurate…How ever DT processes it after the display profile which is often a lower gamut color space. This can introduce some issues that are discussed and partially resolved in the links I provided above… It has been suggested that the only accurate way to confirm if you are getting a clipping artifact from your display profile is to set it to linear rec2020…so in effect match your working, display and histogram profiles to avoid any transforms and see if the histogram data changes…your image will not look correct on the screen but the gamut data would then be accurate…if there is a change but it is minimal then you can likely use your display profile without checking this however if not currently I think it is the only way to truly assess gamut issues esp ones related to saturation…
I think there was some discussion of trying to reorder this but no solution that would not break previous edits was evident at the time…
So its a test that everyone using DT should try just to confirm if there is any issue with the current display profile they use as it pertains to impact on the presented histogram…
Perhaps it’s time to decide what is wanted?
If the aim is to provide images for screen display, then that will require some basic settings: output to sRGB, a screen profile, and that’s about it.
If you want to include printing, things get a bit more complicated.
For the rest: all those different profile settings have a use (I assume). But some of those uses can be rather advanced, and those settings can be usefully changed only once you know what you are doing and why you are doing it.
before bothering around with darktable profiles use the profile you got to get your system (windows) to use this profile for display.
Then the simply use system default profile in darktable for your display and you‘re fine.
If you’re not that experienced with administrating your system, then better don’t copy stuff into system directories you don’t really know. Windows provides the tools to guide you to do it:
For historgram, workspace etc.pp. stay with the defaults unless you have a specific use case like: preparing output for print services
In the mean time read what you can get on color profiled workflow so you get an idea why you want to deviate from the standards.
Using profiles someone told you without understanding the why is the best way into trouble 
1 Like
That’s good advice and Glen’s document above spells things out pretty clearly… ironically on the display profile I never trust the OS and software. I want to implicitly specify the one I want to use. I use windows so I copied mine to the color\out directory so I can specify the exact profile by name.
I am hoping Santa brings me a calibrator for XMAS 
Since I could not calibrate my monitor I always thought best to use the exact profile. However some of those profiles mess a bit with the gamma curve to handle blacks and so when you export in sRGB its not as close as you would like…I found out that actually setting my display profile to DT’s sRGB actually matched my screen/export better than using my display profile…
So I went this route for sometime. I did try the windows screen calibrator just for fun but I wasn’t entirely happy with it…
I am as a stop gap using calibrize now ( https://www.calibrize.com/ ) …simple screen calibrator that will tweak your system profile…make a copy with adjustments and set it as the system…it automates it and you can using the instructions you provided go back and ditch it if you don’t like the results…but I found using it I get a pretty good match for now until Santa come through…
This is why in rawproc I never bothered to figure out how and implement use of the system-specified display profiles - I specify them in rawproc’s properties. Recent rawproc will automatically switch display profiles if you drag the window from one display to another, if you have the two profiles in appropriate properties. Well, 'cept for Wayland, which apparently doesn’t provide the information needed for wxWidgets to know the specific display the application occupies… 
Look in C:\Users\your user name\AppData\Local\darktable.
Or just search for darktablerc.