In your export module, the profile is set to “image settings”. What happens if you export to sRBG?
As far as I know, there is no such option in the Preview. It is included a priori.
The easiest option is to open the resulting photo in Photoshop, or in 3dlut creator.
In your export module, the profile is set to “image settings”. What happens if you export to sRBG?
I won’t see any difference if I turn this option on. The result will be the same as if I had not enabled this option and left everything by default - “image settings” instead of “srgb”.
I will see the same gamma offset in the output when I open the resulting file in a program that supports the color management system - colorsync support (previev.app etc).
Thank you all for your help me. Feedback is also help.
1 Like
I’ll take a look tonight been busy all day…
To me the difference in your images boils down to active modules…While I can’t tell how you generated the output.tiff . If I disable filmic, sharpening and the exposure bump (scene defaults as in your xmp) then the image in Darktable looks exactly like the output.tif, ie darker less sharp and less contrast. I also exported your image with both srgb and adobe profiles to new tif files and loaded them back in DT and they look the same as they should when color management works…
In summary for me the outputs match the view…
I am using Win11 and a recent build but this should not impact things.
It has been a bit difficult to follow but to me the files you presented are explained if indeed you generated the tiff without those modules and then perhaps you reset the history stack which will add them back if the scene referred workflow is the default… this would give the brighter image with more contrast that you see…
No, that’s too “strong” )) Make an image export, then include something and so compare the picture )))
well
I load a new image into the program.
I do not touch anything.
I export the image 
(The source material was taken from the same raw photo collection. I did not upload them, so as not to upload unnecessary files here, to the hosting.
If need, I will upload it).
windows is windows. So is the Linux OS.
It is quite possible that if I had done all these experiments on such operating systems, I would not have encountered such interesting things. But I work on mac OS. The program where I encountered the problem was running under that one. The program itself was downloaded from the official website. install | darktable
The version of the program that was downloaded from there is the latest one - 3.8.1.
I also tried to build a program from source - the result of the export is identical to the first result - a bad result.
I wanted to contact the developer who ported this software to mac os. There is a list of developers at contact | darktable page.
parafin/Igor Kuzmin/OS X maintainer - http://paraf.in/ But the page at the link is unavailable.
Perhaps you could engage him on GitHub: parafin · GitHub.
Created a bug report. mac os | gamma shift in the image when exporting · Issue #11736 · darktable-org/darktable · GitHub
The report was closed considering that it was not a bug. The reason is that the raw file differs from the exported one in tiff, etc.
“It’s not a bug that raw pictures look differently in different editors, they are just processed differently. If you for example export this picture as TIFF and then use it as the test source, then it will look the same everywhere (e.g. in Preview, in dt darkroom view, after dt export), because in case of already processed image like TIFF or JPEG there’s no processing by default. For raw it’s not the case. Closing as not a bug.”
I didn’t even have time to add the answer that the same problem appears with the import of a normal tiff, or jpg. (Although, in the first post I said that the problem occurs not only with raw).
This is a very interesting image.
Same settings, except modern vs legacy chromatic adaptation (camera reference WB + color calibration vs as-shot WB):
BTW, even on Windows, the exported TIFF (imported back into darktable) does not match the darkroom view of the DNG (I used another XMP sidecar for that, though).
_MG_6068_01.dng.xmp (10.6 KB)
I’ll have to look again…I didn’t see that …they looked the same to me when I did it. I just looked at the meta data in the OP tiff file and the embedded xmp seemed to indicate that filmic etc were turned off. Indeed when I did that the images matched from what I could see as his darkroom view had the scene defaults applied… The DR display with those modules disabled match the output of the provided TIFF as least on my system… I will go back and look. I hadn’t tried the different WB setting as I was trying not to change things from the OP…I will have to go back and look at that… I did an export setting it to export with and srgb profile and adobe and re imported and on my system the all the images matched the preview state of the raw… so again I will have to go back it was likely late at night when I was doing it…
It’s all very cool, of course. But which xmp did you use? )) If I delete the picture a001.tiff (conditional name example) from the image library (lighttable), but leave the files themselves (tiff, xmp), and reload the picture a001.tiff into the program, I will see such a trash)) that it is better not to look at it. It will be very light gamma. As if we had set the gamma to 1 instead of 2.2 for some picture. ))
If I delete the xmp file and re-import it after, then everything kind of looks more sane.
I used the XMP I posted above.
(edited: quoted original question)
Why I noticed the gamma shift issue when I started using this program for the first time in my life.
I liked some of the tools in it that Davinci Resolve doesn’t have. When you change hue/sat (color correction) and others. But I work with video sometimes and I needed some way to get the 3dlut files out as a result.
But this program doesn’t know how to export such options. But I remember doing the same thing with Lightroom - I took and applied effects to hald files, and converted the hald files themselves into 3dlut files and everything was fine. Considering that I also converted the gamma of the processed photo (tiff image from Davinci Resolve), because lightroom didn’t know what gamma some Davinci had. Gamma and color space. and then I imported into Adobe Lightroom, processed such an image and applied the effect to the hald file, and so on.
Such a conversion profile is not difficult to create and apply. I took a file, opened it in Photoshop and converted it with my profile. That is, I didn’t put it in Lightroom or anything else. So that the programs would open the photo as usual.
I did the same with Darkroom.
But! When I copied the created style of the program for hald and saved such a hald, I saw a lot of artifacts, when I already converted hald to 3dlut and applied such 3dlut to video in Davinci Resolve.
And then I found out that darktable applies some kind of sharpening to all the images and whatever else is out there.
I turned those effects off, leaving only what I needed. So I kept the style and applied it again.
It worked out great and more! - There was no gamma shift, but! I saw a staircase. As in gradients. staircase on objects where there are smooth transitions of light and shade.
When applying similar 3dlut files created in 3dlut Creator, or in Lightroom (hald > 3dlut with 3dlut creator) I never saw such treshold effects.
That’s when it became easy for me to save a normal image from the darkroom, not a hald. To make sure that this program saves everything correctly.
Seeing the problem, I started googling various resources. I came across this topic and decided to bring it up.
In my hands I am seeing none of the issues except for sure it seems the legacy and modern WB are not the same as you noted and this has been noted before with the discussions around those D65 numbers for certain cameras…for me I have seen this before…its mostly in the highlights from what I can tell…if you place a bunch of pickers on the image and also look as you toggle back and forth between legacy and modern the image gets a bit brighter…not a ton but some. As for the effects seen on the Mac by the OP. I don’t see them and I just redid both photos that have been shared…mind you keeping it simple to look at the data …so no processing …no filmic no base curve nothing and legacy wb as shot…and when I export the image and bring it back in it looks the same. A set of color pickers placed around the image show mostly identical values…and I don’t see any case of extreme lightening mentioned by the OP.
I also don’t see any sign of the issue that was noted about removing and reimporting a file.
Going back to the original post it was clear that the provided tiff had been saved with different settings than we present in the darkroom preview used for comparison…that might have just been an oversight and the issue may be real on a mac…I am just not seeing any of this
I must admit its too early in the morning for me to follow that last post about all the lut conversions back and forth etc etc…
If you have issues with your monitor profile, the preview would look different / weird / wrong.
But loading a tiff file and not doing anything to it and saving it again in sRGB should look (almost) like the input.
Make sure you do NOT touch input profile module (leave the working profile to linear rec2020).
The output is only used if you want your files to be in a certain profile , but generally this should be sRGB.
All the soft proof settings should also be left at default to get started.
What i know from macos, is that the os is doing the color management for apps , unless an app really requests 'i know what i am doing , let me draw my own pixels '.
So just to get started , you should not touch any setting (and for sure not set anything to adobergb , because that has no place except for an output profile ).
Open a tiff file , that has an ICC profile embedded in it (and for giggles , make sure it is not a CMYK profile ). Make sure all Darktable modules are disabled that can be disabled .
In the export , save it as a jpg , set it to sRGB output and relative mode . Export it , compare it to the input tiff in a color managed program (like Photoshop ). They should be similar (gamut limits and such not accounted for right now ).
Note that i completely ignore how the file looks inside of Darktable. The input and output are being checked .
If you have a monitor calibration profile and have it set in macos settings , you should not set it anywhere in Darktable is my guess (but I’m not 100%) on this.
Of that input - output check is being done correctly and is NOT ok, it looks like therenis a bug with the build you are using. Darktable’s color management is done with a library internal to Darktable (lcms2, not using macos libraries AFAIK) so it should work the same as any other build using lcms2.
What i learned from using a 2017 Macbook pro , is that of a program is not pretending to be color managed , macos interprets it as being sRGB, so macos will take whatever the program is drawing , and interprets it as sRGB and makes sure it looks ok on the profile in the OS display settings.
Now, if a program advertises itself to macos as being color managed , it gets more choices and can draw in bigger gamuts than sRGB for instance , but it has to do a lot by itself suddenly . I guess this would mean you would have to select the monitor profile somewhere in Darktable. Note, this is monitor profile . NOT soft proof profile , not input profile , not output profile , not working profile .
Also note that i can’t imagine you have to select adobergb anywhere in monitor profiles or soft proof profiles. The only use case would be if your monitor has an adobergb mode you are using , and you have NO monitor profile selected on system settings.
The moment you profile/calibrate your monitor , you select that monitor profile, not Adobe RGB or something.
You also don’t select it as working profile , be a use Darktable usually uses linear rec2020 as working profile which is fine. You don’t use it as an input profile , unless you know the input file is adobergb but it has NO adobergb profile embedded. Of this is the case , comparing in other apps would go wrong anyway since they don’t know the input is adobergb and would interpret it wrong. And you don’t select it as output profile unless you want your output file to be in adobergb. And you would know if this would be required / desired for your use case.
If you see a shift in the histogram in Darktable, I’m guessing something in the Darktable pipeline is still changing the values or pixels. On the other hand , still confused about what the histogram is displaying in Darktable (i would suspect ‘working profile’ but there have been bugs and I have been wrong before , so I’m absolutely not sure what it is doing these days ). If it’s displaying your input file in the working profile , then yes, it would look different to what you expect , because it is converting the input to linear rec2020.
The preview on your screen is rendered from this linear rec2020 to whatever Darktable is using for drawing. ND if you export , that linear rec2020 is converted to the output profile (either set in the output profile module per file , or overridden in the export settings ).
It’s also not really clear to me what you are comparing with preview.app (the built-in viewer in macos , for the uninitiated). Input tiff vs exported tiff / jpg? Your monitor profile / soft proof settings / macos settings should have no effect.
If it’s raw file as input vs what you get from Darktable as export , then yes , that would be different , as preview.app uses a completely different pipeline for displaying raw data (a raw file has no 'true, correct look. Only interpretations).
If you are comparing a tiff input file to how it looks inside Darktable, then maybe there is more to discover . If you are comparing how it looks in Darktable vs how the exported file looks in other software , then also there might be more to discover ).
Yes, but this time the only difference is the highlight handling. Do you think that is due to the profile?
