OpenDRT for ART

[agriggio (Alberto)]

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.

@jedsmith

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.

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:

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.

[jedsmith]

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.

@agriggio

I have also a CTL for the 2499 DRT image formation which I would love to add,

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

[agriggio (Alberto)]

Hi again,

@jedsmith

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

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 . 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

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…