Hei there,
I was using darktable 3.8.1, which was the default in Ubuntu, installing from the apt repository.
Then I upgraded to 4.4.2 and since then my images show with an increased contrast, without me doing anything:
And even exporting an image with no modifications done at all results in a changed image.
Original and exported image, see, how I loose all detail in the lower part in the second image:
I tried both installing 4.4.2 from ppa:ubuntuhandbook1/darktable and via snap but there was no difference and even on my windows pc with DT 4.4.2 it is the same. So to me it seems to be related to the version.
Is there some preset in newer DT that I should turn off? Any other idea why I it won’t let me start on the original image?
I am not sure when the new module order was added but if you check there is one for jpg now that moves exposure and this can make jpg look different… your options are raw 3.0 legacy and jpg… you could see if that impacts it…at one time jpg was not identified and the raw module order was applied to jpg files…not sure when all that came about…its found down in the bottom right… you could play with it and see if it might be the issue…
Edit: Looking deeper this should have been introduced in 3.8 I think but I know initially jpg were not by default given the right module option for some time …but this should also be only for a new edit or import and not a change to your old files…
Thanks for the super quick response!
Trying around with your example image I could not reproduce the issue.
The sharpening also appeared to be unrelaterd.
But I now found out, that it was the input color profile that defaultet to Adobe RGB (compatible) when it should have been sRGB. It automatically got it right when I removed the exif of the image so it seems to misinterpret something there.
It would be great if I would not have to change this for every single image and being a dt novice I do not yet know, where to change something like that globally. I’ll have a look but in case someone could point me there, I’d be grateful!
(I guess saving it as a style and apply that on a whole stack might work but is not quite straight forward).
If it is using Adobe for jPG as the input profile you must have that embedded when you shoot them?? otherwise I think they would be srgb…if you are talking raw it shouldn’t be adobe rgb so maybe you were tinkering with an auto applied preset??
I just checked and you are right, my camera is set to Adobe RGB.
Now I’m a bit puzzled:
If I open that image with either of my image viewers or with RawTherapee or dt 3.8.1 it is displayed as when I now change the input color profile to sRGB. Are they then all mistaken?
But I assume, if the camera is set to Adobe RGB, I should also input them in dt that way and brighten the dark from there to retain the detail, right? That’s probably a very basic question, I’m sorry…
If the camera outputs AdobeRGB images, running it through any image processor and exporting them (without making any changes) as sRGB should slightly change the colours.
Are your image viewers / browsers colour managed?
They are default, so I guess no (Gnome Image Viewer, Shotwell Viewer)
I thought, that at least RawTherapee would adapt to the color space but checking the metadata in RawTherapee it just say ColorSpace: Uncalibrated whereas the exiftool ouptuts Interoperability Index : R03 - DCF option file (Adobe RGB)
You have to be aware not only of your input profile but also your display profile… I suspect esp with windows many people have it setup in the OS with a different profile than what might be set up in the software and so the color management might be working in an application like DT where you can set the input and display profiles and it will color manage but other apps might not or might use the OS setting… I’m on the windows side and can’t speak to pitfalls in the linux OS but right now the windows 11 photo viewer is terrible. It is auto enhancing or brightening every photo. This is reported on by several people. I have gone in and very carefully set the OS to be my calibrated profile and equal to one I use in DT but it doesn’t matter that viewer is useless… ironically the preview created in file explorer is indeed accurate. In my case I use xnview in windows because it allows me to specify the display profile so it gives me accurate previews of my exported files… I did at one time use Faststone image viewer but it was giving me a lot of artifacts in the image when I was scaling the preview so for now the best previewer for me is xnview on the Windows platform… I think many people use the one proposed by @kofa as a reliable option for a color matched viewer…
I’m still new to Darktable but a lot of the problems I had when I started out was me simply overlooking things because I didn’t fully understand all the terminology. But could this not just be a result of the newer version of Darktable using the scene-referred workflow compared to the display-referred workflow?
Unless you have a good reason to change it, and use a fully color-managed workflow with an AdobeRGB capable monitor, you should not be using AdobeRGB. Use sRGB instead and save yourself some trouble.
I think it will turn out to be a color management thing esp since it appears the OP was using Adobe RGB as part of the workflow but even at that only recently has DT been applying the jpg module order to jpg files by default. When you go back and look at old jpg edits many will use the raw module order… Depending on the edit moving exposure and some other modules after the input profile with the jpg pipeline can have a serious effect… so I guess there is room for a few things but I think unless it is clear that the OP has CM locked down from the OS, to the viewers used to assess the change, to DT then its hard not to question that as a first and most likely culprit…
