This is the raw file 1.CR2.xmp (12.3 KB). I’ve only applied white balance and turn the levels to automatic.
I’m new to darktable, would you mind teaching me how to run the darktable-cmstest?
That’s only the sidecar. We’d need the 1.CR2 file as well.
Ooops, sorry, you’re on Windows. darktable-cmstest is Linux-only.
https://docs.darktable.org/usermanual/3.8/en/special-topics/program-invocation/darktable-cmstest/
Are you using a monitor calibration profile in windows?
@Rottie Welcome to the forum! Hope you enjoy your stay. 
Personally, I tend to use Firefox or any browser that supports colour management. That is because that is how many people consume images nowadays. Of course, it depends on your audience.
It is always a good idea to share your raw, image and sidecar, which you have just done. That way, people can check your workflow and also the file itself to see if anything went wrong. If it is fine on our end, it would be a hardware or software configuration issue on your end, which would lead to new investigations.
I noticed:
There is the active module levels in mode automatic. When activating softproof, the image gets brighter. Then deactivating softproof, the image stays bright. (softproof set to sRGB)
In this case, the DT view is brighter than the exportet image, but not as much as in your example.
When first setting levels to manual and adjust the white point by hand, then activate softproof, brightness doesn’t change.
Some smarter people will have to explore how this observation has to be filed.
1 Like
@apostel338 Just ping your favourite dev and they will get on it, although I think they prefer you do the actual reporting. Do so here: Issues · darktable-org/darktable · GitHub. Naturally, be thorough with your explanation, including version, screenshots and examples.
Please open a bug report! The forum is not the place for but reports
JPG and darkroom preview identical…note the snapshot line in the color checker… all good exported as sRGB
Edit …just looked at your sidecar…you have it (output profile) set to adobergb…this is your problem…
@priort Thanks for all the effort, but I have tried different output profiles (including sRGB), nothing changes. My friend had tried exporting the same file (with the same settings) on his device (macOS). And He got the colours right…
Are there any bugs with my darktable (downloaded on 24 Apr), or am I missing something…
Maybe but you are exporting adobergb…so naturally in most software it will look different after export…I found no issues so if you change your output profile to srgb…make sure you are not tinkering with anything in the export dialogue then your files should look as expected if not I am not sure what you have going on unless you have something weird in your display profile as a last edit…and or you are messing with softproofing which is not necessary and could be giving you a false impression of what the exported image will look like… all I can say is I have no issue with your file or xmp if I make that change to the output profile…
I never use levels and softproof myself and I just noticed it with the example in this thread and thought it could be related to the problem of @Rottie, so he/she could test it. I’m also not able to reproduce on any other photo, so there might be an odd combination in Rotties sample.
1 Like
It was a rather peculiar processing:
- exposure was kept low
- rgb levels, a display-referred module, was used before filmic to brighten the image
- after filmic, level was used to stretch the histogram
All of that was done in Rec709, and then exported as Adobe RGB.
Normally, exposure is used to set mid-grey correctly. It seems the 2nd patch above ‘black’ was close to mid-grey, as using that as the sampling point in exposure (and disabling rgb levels) resulted in a correction which then caused the filmic auto-white picker to read 2.81 EV (18% mid-grey is about -2.5 EV).
BTW, all the grey patches resulted in different white balance readings (set white balance to camera reference, enabled color balance, picked the WB from each grey. Correlated colour temperature readings:
- background: 4694 K
- lightest patch: 4486 K (‘white’?)
- then 4504 K
- 4664 K
- 5047 K (‘mid grey’ ?)
- 5469 K
- 4619 K (‘black’ ? It’s not as dark as the ‘CM’ card)
White on the ‘CM’ card: 4856 K
I don’t know what caused the discrepancy between the darkroom and the export - could it be that the 100% white of the working space, Rec709, is simply brighter than the 100% white of AdobeRGB, so during export it was mapped to a less bright value?
1 Like
So, I’ve created a 100% image in Gimp, and assigned the profile elles_icc_profiles/ClayRGB-elle-V2-g22.icc at master · ellelstone/elles_icc_profiles · GitHub to it.
Loaded it into darktable and exported it to JPG without modifications using both ClayRGB-elle-V2-g22 and Adobe RGB (compatible). Loaded them both back to darktable; they are all pure white. So, my guess regarding ‘the 100% white of the working space, Rec709’ being ‘brighter than the 100% white of AdobeRGB’, is clearly wrong. Shows how little I know about colour management.
1 Like
You can set the histogram profile to sRGB or to Adobe…set a color picker in the image…Toggling back and forth and noting the values and then knowing this shows you how the image would change when the Adobe values were assumed to be sRGB in a non color managed app…if color managed it should not be an issue…at least in my experience
1 Like
I’ve solved the exporting problem!!! I re-installed darktable applied advice from @priort and @priort, and it worked. Thank you all for the effort!
One last thing, I wonder are there any modules in darktable similar to the white slider in photoshop?
I’d like to correct the current RGB values to corresponding ideal values on the colorchecker.
Have you tried this process…this is intended to correct for input profile variation etc…
