Hi,
I’ve just noticed that @jedsmith released a new version of the OpenDRT display transform as a DCTL. I thought it could be interesting to have it as a CTL that could be used in ART too, so here it is. I went for the presets-based interface (as suggested) instead of the full-blown “stick shift” one.
Note: the best way to use this in ART is to put it in the “CLUT directory” folder so that it is available in the Film Simulation tool.
OpenDRT.ctl (44.7 KB)
dont you have a git repository for CTL scripts where you could put it?
It will get there eventually, yes
Too funny I saw a link to this in another thread a few days ago and when I took a look I thought that it looked pretty cool…I was going to ask you if you had seen it and what you thought about adding it but as I have no idea how hard it is to convert these… it seemed like it might be a big undertaking… you are amazing at bringing nice tools to ART …
This tool looks amazing and with all the presets it can dial in so many looks very quickly…I love the variety of looks you can get with it… I found it hard to decide what I liked best… I used it on this image from a recent playraw…
I’m looking forward to trying more images
Hey that’s awesome! Thanks @agriggio! I spent some time this evening trying to get ART compiled for Rocky Linux 9 (to my disappointment it looks like the tar archive on the releases page has a GLIBC version that is too new for it to work 
Now that I have ART running on my system, can I ask for some guidance about how to get CTL files to show up in ART? I added OpenDRT.ctl to a custom-defined CLUTs directory, but nothing is showing up in the “Film Simulation” plugin’s UI (quite possible I’m just missing some piece of documentation).
Thanks for the help, and super cool to see some interest in OpenDRT over here
Hi @jedsmith
When you start Film Simulation there is a drop down box with a down arrow, click on this and it should be there.
Just for future reference, the ART binaries work just fine in Distrobox which seems to be available for RHEL, so should be installable on Rocky too
Hi @jedsmith, and thanks to you for your great work on OpenDRT! I’ve been following it for quite a while and it has been very inspirational.
If you compiled ART yourself, you need to enable the CTL interpreter explicitly, as that is an optional dependency. In my experience, getting CMake to actually find the CTL lib can be a bit of a hit and miss, so I suggest you take a look at how this is done in the GitHub action that builds the Linux binary (specifically, here and here).
HTH
Also, some more general docs about CTL in ART: Working with LUTs | ART raw image processor
Thank you @agriggio ! I didn’t catch that the CTL includes were not working, that’s why my compile was not seeing the CTL files. I’ve got it working now.
I tested it out a bit, quite cool to see OpenDRT working in ART! I have a sneaking suspicion there is some color management issue, as reds appear a bit over-saturated compared to how I think it should look. I’ll do some more testing and see if I can verify that with more certainty and maybe dig into the CTL code a bit to see how you put it together. Also we should probably remove the HDR controls (Display Peak Luminance, HDR Grey Boost, HDR Purity), if we are not supporting HDR picture rendering. The Display Gamut dropdown also doesn’t appear to change anything. I’m not super knowledgeable about how this hooks in to color management in ART so I’m curious to learn a bit more about what colorimetry is being sent to the input of the OpenDRT CTL, and what happens to the signal after that CTL runs. Maybe we could expose the other display transfer functions and be able to render to Rec.2100 PQ. Sorry for the word salad, my brain is mush on this Friday Eve. Thanks again for putting this together, super cool to see!
Hi,
and thanks for taking a look!
Indeed, your questions made me realize there was a missing color space conversion at the end of the script, which caused the hot reds. Sorry about that, it should be fixed now in this new version:
OpenDRT.ctl (44.9 KB)
(I’ll put this in the CTL scripts repo eventually, once we agree that there are no more obvious bugs).
As for your other questions:
But we are – at least my TV thinks so
See here (and more below): https://art.pixls.us/Hdroutput
What we are not supporting is HDR preview inside ART, but if you export in the right format and encoding, HDR should work.
The Display Gamut dropdown also doesn’t appear to change anything.
This might be due to my misunderstanding of what the selector is supposed to do. I thought that it was doing two things:
If the selector is only performing operation 1, then the fact that nothing changes is a good sign, and it’s a consequence of how ART works (more below). In this case, we can definitely remove the option. If it’s also doing gamut mapping, then you might need to change also the output profile in “Color → Color management” to actually see the effect.
CTL scripts take linear data as input, and are supposed to produce linear data as output. You can select the color space by adding the appropriate tag (in the form // @ART-colorspace: "XXX") in the file itself. ART will then convert from the working profile (selected under “Color → Color Management → Working Profile”) to the selected space and back. This is briefly described in Working with LUTs | ART raw image processor (under “Writing ART-compatible CTL scripts”), but if the wording is unclear I’m happy to revise it.
For OpenDRT, I picked “rec2020” (as I usually do most of the time). Therefore, it takes linear rec2020 in, and it’s supposed to produce linear rec2020 out. The mistake I made in the first version was that I forgot the final conversion from “display_gamut” to rec2020. That’s also the reason why it doesn’t make sense to expose the display transfer functions in the script, as the data doesn’t go to the display, but to the rest of the ART pipeline. It is converted to the display only later, and this is handled with ICC profiles. If you want Rec.2100 PQ, you can select the corresponding output profile in “Color → Color Management → Output profile”.
Best
@agriggio Thanks so much for patiently explaining this stuff to me - I learned some things about ART today
For the Display Gamut dropdown, I think it is correct how you have it set up actually. I just got confused because I did not fully understand that the output of the CTL is display-linear and that the display encoding and final gamut conversion happens later in the image processing pipeline. (It’s super confusing not being able to see the result of the display encoding you select until after you’ve exported the image… but this might just be expected behavior from software designed for editing photos). Unfortunately I do think we would need to keep the selector in the UI, because it does affect some operations in the opendrt algorithm (mainly the Creative Whitepoint). This is unfortunate because it means the user will need to set that parameter in two places
I did a bit of testing this evening and I didn’t notice anything egregiously broken. I did notice one thing, which is that if you use the sRGB Output ICC Profile (Ugh… 
ICC always makes me feel queasy), it is applying the sRGB Encoding function, not the sRGB Display EOTF. This results in the shadows being crushed undesireably in the resulting image. The tonescale function in OpenDRT is constructed with great care to render the image in a pleasing way and should not have any additional operation except to encode the image correctly for the target display device. I do worry that this “bug” might cause unwanted broken images. I don’t know much about the ICC profiles, but maybe it would be possible to fix the ones that ship with ART so that they apply the correct 1/2.2 power function to correctly encode the image without further modifications on an sRGB Display? (We would only be following the sRGB spec if we applied no tonescale or any other operations, and just encoded the image with the sRGB Encoding, and then presented that image on an sRGB Display device with a 2.2 power function EOTF… but it is not 1998 anymore and we have better solutions for rendering our pictures in my humble opinion).
I did test the Rec.2100 PQ one on my HDR TV and it is a perfect match out of the box, so at least that one is working! Though again super confusing that you need to crank up the display peak luminance, and clip the highlights massively only for it to be encoded properly in PQ at after you export… Something to get used to I guess.
One other thing I noticed is that for the info here it mentions that $HOME/.config/ART/ctlscripts works as a default directory to load CTL files from, but it doesn’t appear to work until you manually add that folder in the preferences. Just wanted to check if this is a bug or if it is out of date information.
Another thing is that there might be quite a bit of optimization that could be done if there is the ability to pre-calculate constant memory variables based on the user parameters and pass those values into the function that calculates the transform per-pixel. I’m pretty sure this is not possible in the original CTL language, and I know it’s not possible in DCTL, but just wanted to mention it in case you might have this capability in your ART variation of CTL. For example, all of the Tonescale Constraint Calculations do not need to be done for every pixel, same for quite a few of the calculations throughout the transform. Just wanted to mention it in case it might be possible (Although I’m actually quite impressed at how fast and responsive it is processing on the CPU in ART so nice work on that!).
Hope it helps!
Hi again @jedsmith,
and thanks for your detailed comments!
Some answers below (and sorry in advance for the long text!)
Actually, you should be able to see the effects in the preview, provided things are set up correctly. Now, I fully acknowledge that this might involve tweaking multiple things in multiple places, but I found no better way (yet) given the constraints of the program (basically, we have to work with ICC profiles because that’s what the photography ecosystem is built around, and we would like to stay as cross-platform as possible). In a nutshell, ART always takes the output profile into account when displaying the preview. Therefore, the transform chain is not simply “working profile → display profile”, but rather “working profile → output profile → display profile”. This is IMHO more useful, and it more accurately represents the fact that the output profile is part of the image data.
However, for this to work properly, you need a display profile that can show you the differences. If you have a profile that, say, clips everything to sRGB, then I would expect no difference. But if you have a wide gamut screen with a suitable profile, you should be able to see some difference in some cases. A further complication here is in how different OSes do colour management. On Linux, you simply select the right profile from the dropdown menu at the bottom of the editor window in ART. On Windows, it should also be the same, though I recently learned about auto color management which might complicate things. Finally, macOS does colour management system-wide. In this case, you can select the display gamut that ART will assume under “Preferences → Color Management”.
I did notice one thing, which is that if you use the sRGB Output ICC Profile (Ugh…
This might just be my ignorance showing, but I thought this problem was about the display profile, not the output profile. In other words: shouldn’t the ICC toolchain simply undo the transfer function of the output profile, and then apply the selected display profile? In other words, the TRC of the output profile should not matter at all (well, except for encoding efficiency and avoiding banding artifacts when the output precision is limited, of course) in the output look, or am I wrong? If so, this is something that should be changed outside ART, by selecting a different display profile.
Though again super confusing that you need to crank up the display peak luminance, and clip the highlights massively only for it to be encoded properly in PQ at after you export… Something to get used to I guess.
Great that it’s working! I agree this is not optimal, but unfortunately getting this to work inside ART in a cross-platform way would be a non-negligible amount of work. Using custom processing profiles that are automatically applied on output as suggested here might help but I agree that it’s still suboptimal.
Just wanted to mention it in case it might be possible (Although I’m actually quite impressed at how fast and responsive it is processing on the CPU in ART so nice work on that!)
We use mostly the vanilla CTL interpreter from ACES. There are two optimizations that are applied and that are important:
One more question: it seems that I need to apply a gain of about 1.5 on input in order to preserve middle gray when using OpenDRT. Is this intentional? If so, would it make sense to just premultiply in the CTL script before applying the transform?
Thanks!
Also I forgot to answer to this:
That’s intentional, and the information is still correct. There are actually two places in the ART pipeline where CTL scripts can be used:
The above path refers to the 1st case, where you want to use CTL scripts to implement additional modes for the Color/Tone correction tool. If you put your scripts in $HOME/.config/ART/ctlscripts, they will appear in the drop-down list of that tool. This is meant for scripts that implement various “creative grading” effects that operate on scene linear data. There is a collection of such effects (of varying usefulness and quality) in the ART-ctlscripts repository.
Scripts added to the “Film Simulation” tool, instead, are meant to implement “display transforms” or other similar scene to display mappings (such as darktable’s sigmoid or the integration of AgX emulsion).
Hope this helps
Given your comments above would the art odt that you have created a CTL for be better in the Film Sim or used there… I had experimented with it a fair bit and I really liked the simplicity and the results I could get…
Yes, that would be a good example
Thank you for your in-depth reply!
First, a quick note on terminology: in my reply I will use the term “Image Formation” instead of “ODT”, “Output Profile”, “DRT”, “Display Rendering Transform”, “View Transform”, Etc. I think this term better represents what the transform is doing. And I’ll continue use the term “Display Encoding” to refer to the inverse of the display device’s transfer function or EOTF. Note I’m not including the gamut conversion component of this in this term, because this is usually handled in creative and custom ways by the Image Formation process, and is not as simple as a 3x3 matrix to convert the gamut using CIE Colorimetry.
Ahh, I think this explains some of my confusion. For my custom-compiled version of ART on linux (compiled from the main branch yesterday), the dropdown for the display profile is empty:
Are there icc profiles that I’m missing in some location that I might need to add somewhere? Would love to get this working so that I can properly test it.
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, placing middle grey at around 11% of the overall range or at about 11 nits on a 100 nits Rec.1886 SDR display. This is the convention used by pretty much all camera manufacturer image formation LUTs (except RED), and Resolve and Baselight, and follows the placement of middle grey of the original Rec.709 OETF.
This is a creative adjustment however, as you can tell with the Umbra tonescale preset, which places middle grey about 1 stop lower at 6 nits (This is an increasingly common trend among high end feature films and episodics and shows the influence of HDR image formation bleeding over into SDR). The choice of where to place middle grey through the image formation is arbitrary, because at the end of the day it is just a pivot point for creative decision making about exposure. I see how it could be surprising in this context however, as it seems to normal approach is to start from a blank slate with just the display encoding and build up an “Image Formation” with various adjustments for every picture or preset (And obviously the display encoding roughly maps all pixel values between 0-1 from scene pixel intensity to display light with no transformation (ignoring colorimetry here)).
In OpenDRT’s tonescale parameters, one would adjust this with tn_Lg or Grey Luminance. This adjustment is pretty much equivalent to an exposure adjustment in linear. 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), so maybe it would be useful in the context of ART to expose this parameter for the user and remove it from the tonescale presets.
This makes sense, thanks for explaining! 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? (Sorry if this is obvious and I just missed something! I’m doing quite a bit of learning here…)
Thanks again for your patience and your help!
The dropdown displays the selection from the specified ICC folder that gets specified in the color management tab of preferences…
Mine is for windows and refers to the system folder you would set it to the folder where your OS stores icc profiles or where you save any monitor calibrations that you might have …
