OpenDRT for ART

Software ART
21

Hi again,

and thanks for the comments! I like your terminology, I always found the different names quite confusing, especially having zero experience on video.

A few answers below.

As @priort wrote, you can configure the directory where ART looks for profiles. On Linux/X11, it should pick up the default display profile automatically, but I’m not sure this works if you are on Wayland (or maybe you simply have not set a default).
On any case, if your screen is calibrated to sRGB primaries and a pure 2.2 display encoding, this profile should work:
sRGB-gamma2.2-display.icc (740 Bytes)

Yes. OpenDRT is designed with digital cinema workflows in mind, and follows the convention in that domain to map “scene-linear” middle grey 0.18 to “display-linear” ~0.11

Thanks, much clearer now. I agree that in ART it makes sense to have the default preserve mid gray, as this is typically what happens with other image formation approaches. But I also agree it would be nice to quickly change this. So, here’s another OpenDRT.ctl version with an additional “Gain” parameter.

OpenDRT.ctl (44.8 KB)

By default, at zero, it will apply a gain of 0.18/0.11 to preserve mid gray with the default look, but the user is free to override it.
I have also increased the max LUT size to 64, as this should be enough to avoid artifacts while still keeping the performance good on older machines like mine (note: I’m using this source to back up my claim here).

BTW, I have now added the script to the ART-ctlscripts repository. Incidentally, I have also a CTL for the 2499 DRT image formation which I would love to add, but I can’t find a license for the code, so I’m not sure if I’m allowed to do that.

I did find it kindof annoying constantly having to jump between the special effects tab and the exposure tab just to adjust exposure (which pretty much always needs to be creatively adjusted per picture anyways)

For this, you might find tool shortcuts handy: you can hold the “e” key and use your mouse scroll wheel (or press “+” or “-”) to change exposure. If you press “F1”, you can see the list of all available shortcuts:

Screenshot from 2025-04-08 08-51-39
Screenshot from 2025-04-08 08-51-392562×1415 353 KB

Is there a default folder for ctl scripts of this type, or is it purely the CLUT Directory path that is set in the preferences?

No, it’s just the CLUT directory. You can use subdirs though and they will show up as a hierarchy in the dropdown.

3 Likes
23

Thanks for the help @agriggio and @priort – It looks like my super minimal linux machine did not come with any icc profiles. I did successfully set the preferences Directory containing monitor color profiles to ~/.color/icc and I can confirm that the viewer does now change when I select the sRGB-gamma2.2-display icc profile in the dropdown.

However it looks like the display icc profile dropdown does not actually affect the image that is saved out. Only the Output Profile setting seems to affect this. Therefore my original complaint seems to stand (unless I am missing something obvious): The icc profile named sRGB wrongly uses the piecewise OETF encoding function, not the inverse of the sRGB display EOTF. This results in the shadows being incorrectly crushed. I’m less knowledgeable about photo workflows, but it seems like we would want to author pixel data that correctly corresponded to the inverse of the transfer function in the display we were authoring the image for. It seems that the fault here is with the icc profiles that are shipping with ART maybe? I copied the sRGB-gamma2.2-display.icc file you shared into ART-1.25.3.1-1.el9.x86_64/iccprofiles/output/ and used it instead and I get a perfect match to the intended output.

I also put in a pull request with a couple fixes and tweaks to OpenDRT.ctl: It looks like we lost the gamut conversion back to rec.2020 at the end which was causing the output to be over-saturated. I also made a proposal for a tweak to how the “gain” / “exposure” parameter is set up: I would suggest that we set the default value to compensate for the mid-gray point, but still allow that slider to be reset to 0 so that people can match the “original” OpenDRT presets if they desire. Hope it makes sense and helps.

Sadly I Juan decided to take that project closed-source and I don’t think he ever licensed the open source version, so it might be legally ambiguous to bring in unless you were to reach out to him and ask.

I’ve got some poking around to do in all those other CTLs you’ve put together :slight_smile:

1 Like
24

Hi again,

Ah, now I understand the confusion/mismatch. It seems you want your output image to look good “out of the box” when viewed without any colour management being performed. In that case, I agree that setting the output profile does matter.
FWIW the intended workflow with ICC profiles is that you use a colour managed app, which means that the image viewer applies a transform from output to display profile, so the output profile trc doesn’t really matter (assuming all operations are lossless).

Regarding whether the sRGB profile shipped with art is wrong, I’m sure you know this is a bit of a can of worms :slight_smile:. I have no horse in the race, so to say, and definitely not enough knowledge on the topic to take a stance, but I think the sRGB profile shipped with art is compatible with the official ones of the ICC (see also this summary document). If I’m wrong, I’m happy to revise, but otherwise I would keep the alignment with the ICC because I think that’s the expected behaviour in this context.

I also put in a pull request with a couple fixes and tweaks to OpenDRT.ctl

Great, thanks a lot! And sorry for the lost conversion, that’s what happens when you work on multiple machines without version control :slight_smile:

Sadly I Juan decided to take that project closed-source

Ah, that’s a pity. I’ve reached out to him on GitHub, let’s see if he replies.

I’ve got some poking around to do in all those other CTLs you’ve put together

You’re welcome to of course, but please keep in mind that most of them are meant more as examples of what is possible than of what is useful…

2 Likes
25

Hi!

I’ve been trying to port the most recent beta version of Open DRT (v1.1.0b50) to CTL this week, as I’ve been enjoying using it over v1.

Just a heads up, I’m not a programmer and have been using AI to help me do this. So there will likely be issues!

Would love if you could have a look over it :slightly_smiling_face:

Ryan

OpenDRT Beta v1.1.0b50.txt (65.9 KB)

26

@Ryan_Cara:
On some day in the past April 2026, you wrote:

I’ve been trying to port the most recent beta version of Open DRT (v1.1.0b50) to CTL this week […] I’m not a programmer and have been using AI to help me do this. So there will likely be issues!

I’m not a programmer, too! :wink:
Just FYI, by chance, yesterday I went to the OpenDRT site and I noticed that jedypod released the official version of OpenDRT 1.1.0 on January, 22.
So I tried to test your port (based on one of the last betas before the official release), but unfortunately, it didn’t work in my hands.
As I understood you were successfull, instead (is it true or am I wrong?) it means that:

  1. Something was broken in the OpenDRT transition from beta to the official release;
    or
  2. Something changed in one of the latest ART versions.

Actually I’m running ART 1.26.5 which works fine by using the two OpenDRT.ctl files released by @agriggio (at the time of OpenDRT 1.0.0) which are downlodable from his CTL repository.

Regards,
Topoldo

1 Like
27

Hmm strange, I assume you renamed the file to have a CTL extension?

I’ll have a look at this when I get a chance!

But for now use the “Open DRT Full” version available as it uses all of the new methods as the latest version of Open DRT, and I believe the only difference is the presets haven’t been fully updated to match the latest release (but the differences should be extremely minor) :slight_smile:

28

Of course!
I tried to download your script again and now it works!
Maybe something went wrong when I did the first time.
So, no need you to test it!
Regards,
Topoldo

1 Like