The screen capture is with Ristretto but it’s the same with Geeqie.
Everything is sRGB.
Thanks
Apart from colour management issues (viewer colour managed or not): there are some modules, whose effect depends on resolution; this usually manifests as brightness/contrast change.
On the master branch, which I use, there is a new button to force this in the darkroom, without zooming in to 100% (at the expense of performance), but I don’t think it exists in 4.6.0:
Do you get the problem with other images (say, landscapes with colour)? The problem seems to be more frequent with contrasty B&W.
To see if that affects your image:
- zoom in to 100% - does the image change (unfortunately you won’t see the whole image)?
- when exporting, you have the option high quality resampling. When enabled, it processes the image ‘at 100% zoom’, and scales down the result; when disabled, it scales down early, which means you get better performance, but the same problem that the non-100% view of the darkroom has may occur. If that is the root cause of your problem, exporting at a size similar to the dimensions of the darkroom editor area, with high quality resampling disabled, should result in an image which looks like what you see in the darkroom. I see you have already tried that option, but were the dimensions similar to your darkroom editor’s preview? Since your first screenshot, which is not full screen, is 1961 pixels wide, and the viewer showing the exported image shows an image width of 3340 pixels, that could be the case; but then shots of your export dialogue show a target resolution of 1200x1200 pixels with high quality resampling enabled, and then 1080 x 1080 with it disabled.
If the experiment shows this scaling issue affects your image, you must use the 100% zoom to check brightness, and export with high quality resampling enabled. Alternatively, you must judge brightness without zooming in, and export at resolutions close to the darkroom editor preview’s dimensions, with high quality resampling disabled.
Lastly, do you, by chance, have options like prefer performance over quality turned on?
Surely not your display profile?
Yes, Just tried other images
I have tried with both high quality resampling on and off.
It is turned off.
I went back to some other previously processed images with 4.4.1 and re-exported them with 4.6.0 and they are all highly over-exposed at the export.
Have other people complained about this? I don’t remember.
Something is wrong between 4.6.0 and my setup.
How can I go back to dt4.4.1 or 2? Delete all the dt and keep the xmps? or is there a better way?
Thanks
Can you share an image + xmp?
Can you try reimporting the exported tiff or jpg into darktable to see if it looks like the raw or it also looks bright? If it looks the same, it usually means a color management problem.
Sorting out the problem would be more beneficial in the long run, I think.
You can of course delete darktable and revert to a saved version of config + database. Darktable creates a backup of the database when you upgrade. See
INSTALL last version - #9 by kofa and INSTALL last version - #11 by kofa (on Linux it’s the same, but the files are in ~/.config/darktable).
If you edited the XMP files, darktable 4.6 may have updated them in a way that 4.4 won’t be able to read. But 4.6 is very nice, I really suggest that you let us help you figure out and solve the problem.
raw file + xmp + exported jpeg
pixls.us.zip (18.4 MB)
BTW, it’s not just this images but all the others from: Canon 7D + Canon 7Dmk2 + Fuji X-M1 + Fuji X-T10 + Fuji X-Pro2
Thanks
Your jpg and the processing from the xmp look identical in my system.
Are you saying that when you open the raw+xmp, in the darkroom view it’s also over-exposed?
Because it’s not on mine.
Reply #2:
Thanks: Solved.
Like I mentioned originally that it could be my system. In fact it was my settings.
Somehow (I don’t know how), but the display profile in the lighttable bottom right was set to linear rec709 rgb. Changed it to srgb.Done/Fixed
Thanks
Can you share your display profile setting in dt?
I just saw your edit. Display profile should be set to system and not go srgb.
Like I said. 
I am having the same problem. After processing in darktable, the exported jpg is significantly lighter than expected, similar to the example in the original post. When I import the jpg into lighttable, it looks like it should, basically the same as the processed RAW file. But if I view it in any other program (like Windows Photos or Affinity), it is lighter.
I’ve tried a variety of setting for the profile and intent, but they all give the same results. I assumed that a profile of sRGB and intent of perceptual would work. Actually, none of the settings in the export module seem to have any effect on the exposure of the resulting jpg.
I found another forum with a solution, although it is a drastic one. I ‘reset’ darktable, by moving all the files out of the ‘appdata>local>darktable’ folder (on Windows). So I lost all my settings, but now the exported jpg looks like it should. (I used profile and intent both set to ‘image settings’. Setting them to sRGB and perceptual looks good, too. Again, no noticeable difference with the different settings.)
I just wish I knew which file/setting was causing the problem.
Don’t worry about intent…if you are using the default srgb profile of DT it cannot give you the different rendering intent as it doesn’t have the tables to do so… Your last two comments would lead me to believe that affinity and windows were using the system profile and maybe in DT you were using something else. When you nuked DT then it went back to system for the default display profile and so now all your viewers were looking more like the same… I have a calibrated display and I only use known color managed applications. In those applications I explicitly specify the icc file to be used so that I know all apps and the OS are set to the same profile… I think you just had a mismatch somewhere and the fact that it looked fine in DT makes me think that you had a profile there that was different because while I never trust WIndows Photo viewer Affinity should have handled the jpg fine and it should have looked the same in DT and Affinity if they were both set to use the same display profile… or at least all things being equal they should have
Did you check the OP’s solution?
I found the display profile setting - for some reason it wasn’t visible. All good now.
