Experimental Darktable Build for MacOS (wide gamut, signed)

Software darktable
1

// EXPERIMENT // PLEASE DO NOT SHARE //

Darktable on MacOS has two significant flaws:

  • It is unsigned, so you need to make it executable with xattr
  • It is limited to the sRGB color space

The former requires an Apple Developer Account.

The latter is a limitation of GTK3, which can’t currently read the display’s color space in macOS, and defaults to sRGB instead. Over in Darktable on macos: are there bugs with ICC profiles?, some fine folks figured out that you can patch GTK3 to default to Display P3, which isn’t as good as actually reading the Display’s color space, but is surely better than sRGB.

So here’s an experimental build of Darktable 5.6 with these two issues addressed:

darktable-5.6.0-arm64.dmg

If you have an sRGB display, macOS will take of converting from DP3 to sRBG. You will need to set your soft proofing display profile to Display P3 RGB to see DP3 content.

Screenshot 2026-06-21 at 16.53.12
Screenshot 2026-06-21 at 16.53.122478×1958 1.09 MB

(in a DP3-capable browser, darktable and this screenshot show a logo. The image is full-red without a logo in sRGB)

This is at the moment just an experiment. Please let me know if the DMG works for you without xattr, and whether you can see DP3 colors. Please do not share the DMG outside this forum for the time being. I’m still figuring out the legal side of code signing.

4 Likes
2

Do you mind sharing the .png? Thanks in advance

3

It’s from here: Darktable on macos: are there bugs with ICC profiles? - #121 by lineweight

But my screenshot shows the same pixels in the same colorspace, so you can use them interchangeably :wink:.

1 Like
4

Thanks… I managed to see it by manually adding a Display P3 Profile to KDE and firefox, everything is a lot less saturated now though.I don’t want to pollute this thread though :smiley: I’ll create post if there are developments

5

So you applied the simple quartz patch which is used by ART already and compiled against the patched gtk+3, everything else equal?

EDIT:

Never mind, I got it already. I have got a local installation of patched gtk+3 in /opt/local specifically for ART (which I build from sources) and it’s picked up by the darktable build as well, because its path has precedence over the homebrew package.

It works!

6

Yes, exactly! I’m still meaning to write a blog post on how to do it at home, but haven’t found the time yet.

(Could I still ask you to see if you can run my DMG without xattr? I can’t check myself since my own machine always accepts my own executables.)

7

Fully up-to-date Tahoe OS, M1 Max Studio - still need to go to Privacy & Security> open anyway. So perhaps xattr not working correctly?

8

Thank you Andy! Strange, I would have thought that this shouldn’t be necessary for a signed application. I’ll research some more.

9

Can you elaborate on what you are trying here?
Signing a macOS app bundle requires a valid certificate of an official Apple developer account. There is no other way.

1 Like
10

I created an Apple Developer Account, payed for the developer subscription, and signed the app bundle and app with my signing certificate. Apparently this didn’t work, or wasn’t enough.

My goal is to “donate” my Apple Developer Subscription to the darktable project to sign their MacOS binaries.

3 Likes
11

There are instructions in packaging/macosx/BUILD_hb.txt

12

Those instructions tell the user how to authorize the package to run with the xattr command (by the way, I get a pop up window request, no need to run xattr).

This is not like signing the bundle with an Apple Developer Account, which otherwise wouldn’t require the manual authorisation of the user.

1 Like
13

From BUILD_hb.txt:

’’’
4). Create application bundle from build files. To properly sign the app bundle you can optionally provide your developer certificate email/id by defining CODECERT:
export CODECERT=“your.developer@apple.id” # optional, not required
3_make_hb_darktable_package.sh
’’’

14

Yes, that’s what I did. I did set the CODECERT, and it did finish successfully. I went through a handful of iterations until it worked.

I’ll investigate further.

15

To be compatible with default security, you need to notarize and staple the app and then notarize the dmg. Code signing is merely step 1.

1 Like
16

Thank you! How silly of me. Jumping through one hoop is obviously not enough to satisfy Apple’s need for “security”.

But thanks to your comment I found the relevant documentation for notarization, and will see what I can do.

1 Like
17

These are the steps I use for notary. Notice the compression method for the app is different compared to the zip command. The password will be an app-specific password you generate on the apple website.

First set your credential:
export NOTARY="--apple-id user@email.com --team-id ABCDE12345 --password abcd-efgh-ijkl-mnop"
Specify which app:
export APP="/Users/me/MyApp/build/MyApp.app"

Notarize the app:

# Notarize the app
    ditto -c -k --sequesterRsrc --keepParent "${APP}" "${APP}.zip"
    echo "Uploading..."
    sudo xcrun notarytool submit "${APP}.zip" ${NOTARY} --wait
    sudo xcrun stapler staple "${APP}"

Notarize the dmg:

# Notarize the dmg
    zip "${dmg_name}.dmg.zip" "${dmg_name}.dmg"
    echo "Uploading..."
    sudo xcrun notarytool submit "${dmg_name}.dmg.zip" ${NOTARY} --wait
2 Likes
18

@bastibe just curious, did you ever figure out how get al that security stuff from Apple to work?

19

Too much life stuff happening last month, I’m afraid. Taxes, vacations, work. But I’ll get back to it eventually.

1 Like