Blender AgX in darktable (proof of concept)

kofa · June 15, 2025, 2:52pm

Double-click any slider to reset it to its default value (often 0).

elstoc · June 15, 2025, 2:52pm

Double-click a slider to reset it to the default value. If its default is not zero, you can right-click and type “0”

commutergraphics · June 15, 2025, 2:55pm

thanks

kofa · June 15, 2025, 2:56pm

I think you may have played with this at one point:

They are at version 3 (but master, and my branch, are at version 2):

github.com/darktable-org/darktable

src/iop/toneequal.c

eccb2d1f3


      
                  else if (row == 4) printf(" -2\n");
                  else printf("\n");
              }
              // Print the x-axis markers
              printf("%s\n", x_axis);
              // Print the x-axis labels
              printf("-16 -14 -12 -10 -8  -6  -4  -2  0   2   4   6   8\n");
              printf("\n");
          }
          
          DT_MODULE_INTROSPECTION(3, dt_iop_toneequalizer_params_t)
          
          /****************************************************************************
           *
           * Definition of constants
           *
           ****************************************************************************/
          
          #define UI_HISTO_SAMPLES 256 // 128 is a bit small for 4K resolution
          #define HIRES_HISTO_SAMPLES UI_HISTO_SAMPLES * 3 * 16
          #define CONTRAST_FULCRUM exp2f(-4.0f)

s7habo · June 15, 2025, 3:30pm

Because you don’t have to repeat all the settings on the curve if you only want to quick change the primaries preset.

Edit: I misunderstood your statement. Ignore this comment.

kofa · June 15, 2025, 3:32pm

I think Martin meant you could now simply apply/load the primaries from the unmodified base primaries preset to null out the modifications without discarding curve settings.

MStraeten · June 15, 2025, 3:46pm

recent macOS arm64 build:
darktable-5.1.0+998~gd5eadc4a87_arm64.dmg

same comments as in Blender AgX in darktable (proof of concept) - #181

Christian-B · June 15, 2025, 4:56pm

That’s right, I tried out the new version of the tone equaliser using the same ‘test’ configuration folder, and it caused bugs.

priort · June 15, 2025, 5:47pm

Will do…father’s Day here in Canada…but I can likely fire one up shortly

kofa · June 15, 2025, 6:42pm

I don’t think there is a bug:

the master branch, as well as my branch, have tone equalizer version 2;
the experimental tone equalizer branch has version 3;
when you tried it, it upgraded your presets to version 3;
and now they cannot be read by my branch or by the master branch (you say you don’t see the problem with the master branch, but I think you made a mistake, and weren’t running master when you tested).

priort · June 15, 2025, 8:05pm

https://www.dropbox.com/scl/fi/1ndvvmgvbsr3i6bp98rzg/darktable-5.1.0-1129-g70a3d9bb0c-win64.exe?rlkey=zo3qp1kk7j6ffx6bz6dlr006t&st=zpuwjkr7&dl=0

Christian-B · June 15, 2025, 9:56pm

You’re right, it’s not a bug. For those reading this, I’ll try to summarise the situation clearly.

I use the Master version of darktable to process my photos, installed on Linux Mint via the OBS repositories.
For testing with AGX, I use the command ./Darktable-AGX.AppImage --configdir ./darktable-test, so the configuration files and databases are separate and I don’t have any problems between the two versions.
Unfortunately, I ran a test with the tone equaliser version using the command ./Darktable-TE.AppImage --configdir ./darktable-test, which caused the problem you mentioned above.

So, for my next tests, I started from scratch by creating a configuration folder for each test version and reimporting my presets.

I hope I’m not too confusing, especially since my English could use some improvement.

Eary_Chow · June 16, 2025, 5:47am

Something seems wrong after turning on high quality processing

Hmm…

kofa · June 16, 2025, 5:51am

Thanks for reporting, I’ll check. There was no intentional change to processing lately.

Suki2019 · June 16, 2025, 3:09pm

one question

since i like to work with key commands:
can you give the colorpickers unique names so that you can give them key commands?
e.g. white dot: “pick color W”
and black dot: pick Color B… etc?
thanks

kofa · June 16, 2025, 6:04pm

f_matas_Alexamini_OutofGamut_2.aces.00243.exr is quite close:

Matas_Alexa_Mini_sample_BT709.exr is not (I guess that’s what you used):

I’m wondering if that’s because of the D50 vs D65 difference? A given RGB triplet in D65 is a different absolute colour than in D50, but the sensation (relative to the corresponding illuminant) is the same, correct? Starting from the same input space, converting to D65 Rec 2020 and D50 Rec 2020 should result in the same numbers, as I understand. But using the Blender rotation/insetting numbers (rotating/insetting the D65 primaries relative to the D65 achromatic) result in a different matrix in Blender than they do in darktable (rotating/insetting the D50 primaries relative to the D50 achromatic), so the input to the curve is different, too, and so is the output of the curve. Could that be the reason?

Eary_Chow · June 16, 2025, 6:32pm

I suspect this could be because of a missing clamp of negatives before the inset, where the luminance compensation happened in Blender’s AgX. With that clamp it should look closer. Not sure though, if you already have the clamping in place, this is indeed weird.

Or it could be that you clamped it after the inset, which is a different order of operation comparing with Blender’s AgX, and with AgX SB2383, which also clamps before the inset matrix.

I think that one was mis-interpreted? It looks like it’s ACES2065-1 being mis-interpreted as Linear Rec.709

EDIT:
I think I am getting a similar result after I swap the order of operation in my node group:

This is very possible.

kofa · June 16, 2025, 8:40pm

Or it could be that you clamped it after the inset

There are have to clamp, don’t I? I cannot apply the log operation to negative values.

I’ve added negative-avoidance before applying the inset/rotation matrix. Not perfect, but much closer – thank you! (BTW, should I set darktable’s display profile to sRGB for these comparison screenshots?)

vs previous:

I don’t understand where I have to clamp before insetting; I though it’d be best to keep the information as long as possible. Even if colours are outside of Rec2020 (have negative components), they may be valid colours inside the human-visible gamut.

Eary_Chow · June 16, 2025, 9:11pm

If you don’t have ICC profile embedded in your screenshot, yes I believe your screenshot will be assumed to be sRGB by web browsers in general.

I don’t think there’s right or wrong here. I honestly believe that both orders make sense. It’s just that the original AgX SB2383 puts the clamp right before the inset, and Blender’s AgX was modified from SB2383, it inherited the order. And since changing the order makes a big difference, it’s important to note.

It’s a bit more tricky. We are dealing with camera colorimetry here, and different cameras have different metamerism behavior compared with humans. Basically, cameras are their own unique observers.

I don’t know too deep on this part, but I believe conventionally Camera observer data is hackily converted to human observer colorimetry with 3x3 matrix, and since it’s hacky, it produces a lot of “outside of the spectral locus” non-sense values, like pointing to a position on the world map even more southern than the south pole, the “blank paper” region of the world map. The spotlight in this footage is one of these cases.

At this point we are just dealing with some weird mathematic result of some matrix transform that hackily attempted to convert between different observers. It’s a bunch of non-sense anyways.

RawConvert · June 16, 2025, 10:56pm

Some of these process tweaks are sounding a bit subjective or involving tricky colour science. Would it be cleaner to do pure Blender maths? Or at least have that as version 1 of the module, together with the curve manipulation. Then later add version 2 if improvements were identified? (rather like filmic).