Ok thanks, I was wondering to test it with Blender. when I export as Agc EXR, Darktable automatically converts it to Filmic.
I don’t understand you. You can turn filmic and sigmoid off. That’s how I export floating point, scene referred TIF.
Yes sure, but when I turn it off, then image don’t look the same as it in Blender. So that is why I need some sort of conversion (filmic, sigmoid…), and that is why i wont to tray Agx, so I dont have to use other ones, but get the same image as it was in Blender. I hope I explained it well.
Nice work @kofa! Looking forward to see where you go with this one, and I’m curious to try it out when I have the time.
Yes, I was somewhat involved in the BA forum AgX thread at a time. What exists now in the sigmoid module in the primaries section, is an implementation of the broad principles and process that were established by Troy Sobotka - especially the inset/outset matrices and the rotations of the primaries.
The included “smooth” preset is a manually tuned one to give a sensible baseline result. I didn’t make any substantial effort to match the result with the Blender AgX output, as the curve used in the sigmoid module is anyway different from the curve in Blender AgX, and that alone makes it a bit difficult to match things… Anyway, broadly the results should be pretty similar.
What darktable is missing is some sort of a “guard rail” that catches values that go outside the target medium boundary (values below 0 and above 1). Blender’s AgX includes also the guard rail transformation.
Yeah, at a glance this looks like it might be broken. If one wants to experiment how the restoration of original chromaticity angle after the per-channel curves would look like, the sigmoid module already contains an implementation, controlled by the hue preservation slider. I personally leave it at zero all the time.
I should note, though, that this path likely leads to the “salmon flower” and “salmon sunflowers” etc stuff that is so often discussed in this forum. However, it’s worth a try anyway. Having it bound to a slider makes it very easy to see where this kind of adjustment takes the picture and whether it looks good.
Not sure what the chromatic adaptation would do here, since the inset and outset are working on RGB values and also the output is in working RGB. Chromatic adaptation matrices (Bradford etc.) are a thing when you’re working on XYZ values - there you have the achromatic axis pointing to a direction which is not necessarily (1, 1, 1) (which would be the equal energy illuminant I-E), whereas in RGB you always have the achromatic in the direction of (1, 1, 1), no matter what XYZ encoding you are coming from. I would say having the Bradford matrices applied to the inset and outset matrices is not meaningful.
3 Likes
The current implementation, as I have it, is broken (I did get some matrices mixed up). I’m not sure I’ll ever be able to get exactly what Blender’s AgX does. Please check Blender AgX in darktable (proof of concept) - #10 by kofa.
Thank you. I’ll have to digest your input. My understanding of colour science (transformations etc.) is very basic. I just assumed that since a given colour is represented by one set of values (R1, G1, B1) with one white point, and another set (R2, G2, B2) with another, if I apply a curve for each channel separately, the transformed colour will not match (that is, f(R1, G1, B1) does not represent the same colour relative to WP1 as f(R2, G2, B2) does relative to WP2).
The gist here is really that since you’re working with RGB values encoded in the BT.2020 primaries, your achromatic axis always lies in the direction of RGB = (1,1,1) by definition. No chromatic adaptation needed there.
ICC color management seems to rely on profiles having D50 as the achromatic axis, so that’s why dt’s internal RGB-to-XYZ matrices will rotate the RGB (1,1,1) achromatic axis to the D50 one when going to XYZ. This is really more of an internal detail, and you shouldn’t have to care about this at all when just working with the RGB values. colorspaces.c I believe contains the bits that transform the original BT.2020 primaries w.r.t D65 whitepoint to a profile that refers to D50 as its whitepoint.
2 Likes
Right. During chromatic adaptation, it’s not the RGB coordinates themselves that change, it’s the primaries and the white point/neutral axis (so the ‘absolute’ XYZ / xyY coordinates, or the meaning of the RGB coordinates); I hope I got that right. Thanks for the clarification.
1 Like
The part where the D50 whitepoint really matters is just when converting from a colorspace to another. ICC defines a Profile Connection Space (PCS) with D50 white point, and profiles must include a matrix for chromatic adaptation. By having this fixed in the spec, there is a common process for transforming from any given RGB colorspace to another. This is why the RGB-to-XYZ matrices in darktable also bake in the transformation to D50 whitepoint, even if the RGB colorspace has e.g. D65 as its whitepoint.
2 Likes
OK, so if Linux users want to take this for a spin, try this (never built an AppImage before, just ran the script provided in the sources):
(edit: replaced link with working AppImage)
https://tech.kovacs-telekes.org/dt-agx/Darktable-5.1.0%2B478~gb37c3e25e2-x86_64-ubuntu2202.AppImage
1 Like
I’ll try to have a look.
I’ve also played with gamut compression, you may have seen that topic. E.g.
1 Like
Unfortunately it does not work. Some libraries are missing (GLIBC).
Well, I only tested it locally, and it really was the first time I built an AppImage. Sorry.
I didn’t see any errors as it ran.
1 Like
I can try on Wednesday, perhaps. Until then, you can try copying (edit: obsolete link, do not use) http://tech.kovacs-telekes.org/dt-agx/libagx.so to your module directory (so it’s next to libexposure.so and the others). It was part of the AppImage, so you’ll probably run into the same problem, but it’s worth a shot.
1 Like
Could you try again with this one? I built it in Docker, using Ubuntu 24.04 22.04.
(edit: replaced link with working AppImage)
https://tech.kovacs-telekes.org/dt-agx/Darktable-5.1.0%2B478~gb37c3e25e2-x86_64-ubuntu2202.AppImage
Unfortunately, it doesn’t work either. Same problems with missing (GLIBC) different versions:
/tmp/.mount_DarktaHGhbki/usr/bin/darktable: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.31' not found (required by /tmp/.mount_DarktaHGhbki/usr/bin/../lib/libdarktable.so)
/tmp/.mount_DarktaHGhbki/usr/bin/darktable: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /tmp/.mount_DarktaHGhbki/usr/bin/../lib/libdarktable.so)
/tmp/.mount_DarktaHGhbki/usr/bin/darktable: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /tmp/.mount_DarktaHGhbki/usr/bin/../lib/libdarktable.so)
/tmp/.mount_DarktaHGhbki/usr/bin/darktable: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /tmp/.mount_DarktaHGhbki/usr/bin/../lib/libgomp.so.1)
/tmp/.mount_DarktaHGhbki/usr/bin/darktable: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /tmp/.mount_DarktaHGhbki/usr/bin/../lib/libglib-2.0.so.0)
The list is larger. This is only the excerpt.
OK, thanks for checking. I’ll have to ask the devs how to build the AppImage. It seems running the provided script is not enough, maybe something is missing from my setup.
1 Like
I’ll have to ask the devs how to build the AppImage. It seems running the provided script is not enough, maybe something is missing from my setup.
It is enough. But AppImage will only work on systems with the same or newer version of glibc as the one on which this AppImage was built.
Therefore, building AppImage on recent versions of distros (like in the docker image with Ubuntu 24.04) is not a good idea. For official AppImage builds I use Ubuntu 22.04.
6 Likes
Thank you. Based on that advice:
https://tech.kovacs-telekes.org/dt-agx/Darktable-5.1.0%2B478~gb37c3e25e2-x86_64-ubuntu2202.AppImage
3 Likes
2 Likes