Darktable on macos: are there bugs with ICC profiles?

Software
43

Its hard to know and I think it has been further tweaked a bit over the last few days wrt highlights and some math…check the last few PR from yesterday/today…I have not built with those changes yet…

If I keep it simple and use legacy WB and no other editing I don’t see much of an issue with the exported Tiff I will look one more time… I tried to compare clipped highlights vs LCH that you had and I didn’t see much either …I will look at the region you mention… I used pickers and compared a snapshot of the raw with the exported and reimported tiff for my comparison above and there overall I did not notice much difference…certainly not a big global change in the brightness of the image which I believe is the issue for the OP with this set of images?? Its hard to say when the preview could be impacted by the display profile which could be a bit different for everyone and even in the specific OS if not setup correctly I guess??

44

Speaking of gamma, at one point, Apple/Mac displays had a different gamma. It messed up my prints because I would forget to compensate for the differences. They eventually standardized. Probably not the OP or @EsTaF’s issue, but putting it out there just in case.

45

Here is a split screen…so basically the image with only default filmic and remove exposure.

image
_MG_6068_01.dng.xmp (6.9 KB)

Left (snapshot) is DNG preview… Right is exported TIFF re-imported

No really major differences that I can see…

Edit:

However modern WB…not so good… and default filmic norm makes it worse…

image
image1205×888 281 KB

Setting it to no is better

image
image1157×854 239 KB

46

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.

There is another problem here. What will the original image look like in darktable and in another program that supports cms. I will see the difference already at this step. And so yes - if I open the source in preview.app and the exported file from darktable, which used to be the source, I also open in preview.app, then the source and the resulting file will not be different.

!= - gamut inequality
src.tiff+preview.app = output.tiff+preview.app;
src.tiff+preview.app != src.tiff+darktable.app;
src.tiff+darktable.app; != output.tiff+preview.app;
))

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.

  1. rm -rf ~/.config/darktable
  2. run darktable.app
  3. Open src.tiff in darktable
    ok :slight_smile:

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 ).

ok

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 ).

src.tiff+preview.app = output.tiff+preview.app;
src.tiff+preview.app != src.tiff+darktable.app;
src.tiff+darktable.app; != output.tiff+preview.app;
))

They should be similar (gamut limits and such not accounted for right now ).

Stop. In what ways should they be similar?
Gamma is both saturation and light.
Hue? Hue is similar. ok.

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.

Most likely, darktable is friendly with cms mac os. Otherwise the topic would have been raised not only by me. If you google the question, it has been poorly raised, and the program (mac os port) is many years old.

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.

ok

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 .

Similar situation. the topic would have been raised by the community. it wasn’t raised, which means everything is fine here.
I don’t focus on everyone always, but in this case I need to be clear about the situation and analyze anything and everything. Otherwise I will go far into some wilderness.

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.

Yes, that’s right. darktable uses rec2020 as input.
And yes - let’s localize the question without adobergb, otherwise I’m not the only one who dreams about it )) Just kidding) but we need to simplify the whole topic. To a sane state, of course.

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.

In my opinion, a histogram is not just some waves in a square. Right, wrong, and so on. But it is also a living part of the program system, working with the image as a whole. Everything has to be right here.
See. About rec2020 and others.
What does the input module do in the tools? Right, it interprets the picture and tells the program what kind of picture the program is dealing with. The program, in turn, shows us the picture as it is exposed in the input profile.
So what should we see in the histogram window? Well, the histogram, which represents what we see in the viewport.
That’s if we take the normal cases. Clearly, things may be different and we may need to see other options in the histogram as well.
But, imho, here is the first option should be implemented in the program by default. this is the case in davinci Resolve and in photoshop and 3dlut creator, as far as I remember.

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 ).

!= - gamut inequality
src.tiff+preview.app = output.tiff+preview.app;
src.tiff+preview.app != src.tiff+darktable.app;
src.tiff+darktable.app; != output.tiff+preview.app;

47

Again, the problem grew out of trying to copy darkroom processing settings to other programs.

  1. It wouldn’t be a bad idea to throw all the raw stuff aside. We need to localize the problem, in my opinion. I don’t want to point anything out to anyone, but if we experiment with raw now, it will complicate the topic ;(
    Leave only tiff in the work. Sources, samples received.
    Please ;(

(I will try to record a video on the subject of exporting processing settings from darktable to davinci resolve. About why all this was started in the first place).

48

I think you’d be surprised how little macOS users there are for Darktable, let alone technical enough to dive into ICC / gamma / histogram issues. Still, if there was a bug in the code I agree, it would probably have been talked abou before.

:+1:. Short answer: What is your problem, Darktable’s output file compared to an input file? Or Darktable’s output file (in other programs) compared to how it looks inside Darktable itself? Can you share your input file for testing, so we can follow along? (And see if your Darktable version behaves the same compared to others?).

Well… Let’s think about a regular sRGB monitor to keep things simple. What are we seeing? sRGB data. So gamma corrected RGB. But what data are we working with and are the calculations being done on? Linear rec2020. So what would you expect in the histogram? I would expect working data there, not display data (as in, the histogram should look the same on every computer you open it, independent of the display device used for previewing it). input data should not be there, because we are not working with it at all (it gets converted to working profile pretty early on).
Again, I have no clue what Darktable is actually showing in the histogram.

49

Short answer: What is your problem, Darktable’s output file compared to an input file? Or Darktable’s output file (in other programs) compared to how it looks inside Darktable itself? Can you share your input file for testing, so we can follow along? (And see if your Darktable version behaves the same compared to others?).

Yes, I can.

archive.zip (2.5 MB)

50

Well… Let’s think about a regular sRGB monitor to keep things simple. What are we seeing? sRGB data. So gamma corrected RGB. But what data are we working with and are the calculations being done on? Linear rec2020. So what would you expect in the histogram? I would expect working data there, not display data (as in, the histogram should look the same on every computer you open it, independent of the display device used for previewing it). input data should not be there, because we are not working with it at all (it gets converted to working profile pretty early on).
Again, I have no clue what Darktable is actually showing in the histogram.

Well the profile of the display in the histogram should not be taken into account. Of course. Maybe I wrote something wrong earlier.

51

https://youtu.be/jNpeRUOAbUo

Exporting color correction settings from darktable to davinci.
Thought, now I’ll take all such a handsome guy )) and show artifacts (staircase/searching treshold in the light transitions). But it’s not there and that’s it.

52

ahh.

You are using Darktable to apply some color-changes to a test-image. You save that as a style, then apply that style to a Hald-clut reference image, and export it from Darktable. So you created your own hald-clut. You use some other program (‘LUT Generator’) to convert the hald-clut to an .cube 3dlut.

When applying that .cube file in Davinci resolve (to the same input test image), you see an unexpected huge shift in what appears to be gamma (let’s just say, the image appears too bright and saturation / colors are off).

So this has nothing to do with monitor / icc calibrations in Darktable :slight_smile: .

It could be there are color-space mismatches between your test-image (tiff) and the hald reference/output image.

But it could also be a problem of LUT Generator, or it could be a problem for Danvinci Resolve how it applies the 3dlut .cube file (maybe it expects the .cube file to be for sRGB files so it applies some transforms?).

I don’t know if your darktable has the hald clut module if it’s still around? You could try applying the generated .png in Darktable itself to see if that works there. Or maybe try Rawtherapee to apply it to your test-image (tiff) to see if it works there.
Or use imagemagick (magick input.tif generated-hald.png -hald-clut output.tif) to test the hald-clut.

Try testing the generated hald png first to see if that one is working correct in other programs, that support hald luts. If that works, that means the problem sits somewhere in LUT-Generator and/or Davinci.

53

We have a lot of Mac users that download darktable. But the expectation from their platform is that they use the application, and they don’t tend to help out or be part of the community, it is pure consumption.

54

It is the fully processed pipeline and provides data to the pickers…keep changing the profile and you will see it shift and you will see the picker values change…the display will not…that is controlled by the display profile…

55

So, PC and/or Linux users are more generous? :face_with_hand_over_mouth:

I guess another issue about Mac support is compatibility. For example, I have a first-gen mini in the basement that won’t be any use in supporting dt.

56

:slight_smile:
That’s two points.

  1. the darktable effects that were applied to the table before the saved style was applied. Next, if you have titanium patience )), I turned off these effects in the darktable.
  2. the Embedded profile. Processed image - here the program applied one profile, but when loading the table, it applied a different profile on the input. I also fixed that.

But that’s not the point. Earlier, when I did the table in darktable, the same turned off the effects and the profile of the rules on the same for the image and for the table. But in the output, when I have applied the lut file in davinci, I saw artifacts not in gamma, but in the smoothness of the transition between light and shadow in the image in davinci. Well, what kind of artifacts are these? - If you load a standard black-to-black gradient into any color correction program, you will see a smooth transition from light to dark. But, if you reduce the bitrate of the image, there will be a kind of comb - there will be no smoothness.
I tried to use not imltbap lut generator, and 3dlut creator - this program I trust, because after it there is no problem when exporting lut files from it. We take untreated hald table and apply to it treated. such a treated table is not created in darktable, but in the program 3dlut creator. Save the image in png format and reset the settings in 3dlut creator. load the unprocessed hald and apply the processed hald.png to it. Export the result to 3dlut.cube and send it to davinci - no problem.

Moreover, in darktable we do not observe such artifacts.
But now, when I made a screencast, I did not see any artifacts in davinci.
I am sitting here racking my brains.

I am wildly sorry that I raised so much dust because of my question.

57

We have a couple of windows devs. One, maybe two-ish Mac devs, and the rest are all Linux devs. Its hard to support a platform you do not use. Windows and Mac developers are very welcome to join and help out.

58

How can they help?
For example, I don’t know any programming language. Can they help with money? I’m not that rich. My computer is about 10 years old.
And then. I was a Linux user from 2001 to 2012. I’ve asked for help on forums and I’ve helped a lot of people on forums myself.

That’s not the point here.
A lot of users, as I see it, are not really interested in different topics, at all. Very superficial about what they do. I apologize that from Russia (well, I’m really ashamed of everything that is happening now), but here, people who are interested in graphics, very many run for some kind of fantastic lut files. That is, not by hand in the programs to do something yourself, and download 3dlut set of files and make a magical picture)))
The same is the case with processing. Many climb into the contrast. In the opinion of many, the picture must be contrast, in any case))) Or, having read Itten, they start to roughen up the image. Like robots. But people who know about photography and who can teach knowledge, they also want to eat. if they are bloggers, they adjust to the audience and on the Internet we can find less interesting lessons. That’s the trouble!

The whole issue is quality.

And by the way, you are wrong to say that about the Linux user community.
There were great operating systems in their day - Slackware, Arch Linux. But, at the time, a lot of money was poured into advertising Ubuntu and a lot of people rushed to Ubuntu. I am not against Ubuntu, but in my opinion the quality of Slackware (and the approach) was much nicer. Arch Linux community is alive, of course, but it would be much more alive if it were not for the users who fled to Ubuntu. But that was a long time ago. 2008 - 2012.

59

I noticed one interesting detail in sometime))). Ported software (to windows/mac) is exhibited only if it works well.
I remember the war with the sound subsystem under Linux) I constantly had to tune something. The audio subsystem was then. I don’t know what is there now.

Or displacement of part of the frame when playing video in different players. I don’t remember what this effect is called. Constantly changing video drivers. Searching for solutions on various topics, of which I had many.
Well, of course, it all depends on the hands. But I do not remember any system problems under mac os, but I can not say that it is a washing machine / vacuum cleaner and not a computer. Lots of possibilities, that is.
Linux users are intelligent people, for the most part. But it also takes a lot of time to sort things out if we want to do more than just install the system out of the box.

60

Hopefully someone with DT and MacOS will take your image and see if they can recreate your issue. Taking your two DNG files and exporting as Tiff’s and bringing them back into DT or a preview app that is CM I have no issues in Windows

61

That is, in this case, a person will not see any problems

62

The program is very wonderful. About darktable. Working with rgb tools in the lab paradigm is worth a lot.