OpenDRT v1.1.0

Redesign many aspects of the OpenDRT picture formation algorithm to improve smoothness, simplicity, and creative control.

New Features

• Add DCI display encoding presets.
  • DCI - 2.6 Power / P3-D60
  • DCI - 2.6 Power / P3-DCI
  • DCI - 2.6 Power / XYZ
• Rework creative white system to work with varying display technical whitepoints. This was extremely difficult to figure out so I hope you all appreciate this one!
• Bring back surround illumination compensation model from v0.1.3. This adds a simple power function based adjustment to compensate for the perceived difference in image appearance between a display in a "dark" "dim" or "bright" surround environment. When an image is viewed in a brighter surround, the perceived contrast of the image is higher due to the Bartleson-Breneman effect. This adjustment "gammas up" a bit to compensate. The DCI Cinema display encoding presets use "dark" surround, the Rec.1886 preset uses "Dim" surround, and the sRGB Display preset uses "Bright" surround.
• Expose Display Grey Luminance as a user control. Now that all tonescale presets use the same middle grey, this can be a user control.
• Refine all look presets
  • Standard: A minimal smooth starting look with natural color rendition and minimal adjustments to create an aesthetically pleasing image. Uses the Medium Contrast tonescale preset.
  • Arriba: A minimal smooth look with slightly stronger saturation and a soft rolloff in shadows similar to typical camera manufacturer picture formation approaches.
  • Sylvan: A smooth starting look with slightly stronger contrast and stronger hue distortions which may be preferential for skin.
  • Colorful: A low contrast saturated bright look. Might be a good fit for animation.
  • Aery: A low contrast look with cool highlights and more pure color rendered quite bright. It features strong desaturation near the grey axis, and darkening of only the most pure colors.
  • Dystopic: A high contrast look with very low mid-purity-range saturation and strong filmish hue distortions.
  • Umbra: A dark moody cinematic look. Features low shadow contrast, warm whites, strong filmic hue distortions, cyan blues, and more saturated colors that render very dark. Works well with a Display Peak Luminance of 200 nits or above.
  • Base (disabled in the DCTL unless manually enabled in the code): only the base components of the OpenDRT image rendering. Practically no preferential adjustements. Purity compression is mostly RGB ratio preserving / chromaticity-linear and very minimal. Mid-range purity is very strong. A good starting point for further look evelopment if absolute control is required (do not underestimate the complexity of this undertaking).

Algorithm design changes

• Brilliance: Split into pre-tonescale and post-tonescale brilliance modules. This improves smoothness and makes folding less likely than with the previous design. Pre-tonescale brilliance darkens more saturated stimuli prior to the purity compression. So if you darken reds with pre-brilliance for example, you will also reduce purity compression. This feels natural.
• Completely redesign the purity compression approach. Removed the second norm and tonescale previously used for purity compression control. Now we use the tonescale as a base purity compression factor and limit that in different ways. Also added a checkbox to completely disable purity compression if desired for some reason.
• Mid Purity: Simplify overall design. Modify parameter space for both to have controls for intensity range and purity range (strength), instead of a single ambiguous strength control.
• Hue Shift RGB: now using a separate hue extraction, so R is more oriented towards orange and B is more oriented towards Cyan. Expose range controls for these as well as it might be creatively desireable to have blue hueshift affect more of the intensity range for example.
• Creative Whitepoint: Add cooler D75 and D93 creative whitepoints and integrate them into the DCI display encoding presets. These could be creatively interesting if a cooler peak luminance is desired.
• Contrast Low: remove per-channel functionality. Location is now down in the same section as the rest of the tonescale functions and complexity is significantly reduced. Same looks can more or less be achieved using mid purity low adjustments, and smoothness is improved. Tonescale is now completely independent from "color" adjustments, but at the same time intimately tied to the look, because a normal looking saturation presented through a high contrast tonescale might look way too saturated through a low contrast tonescale. Keep this in mind when building presets.
• Improve HDR/SDR behavior by using variations of the hyperbolic compression tonescale for different look modules.

OpenDRT v1.0.0

OpenDRT v1.0.0 has been completely rewritten compared to v0.3.5. It adds many updates and features with the goal of improving the default image rendering capabilities so that additional look operations upstream are not necessarily required. Significant rewrites and improvements have been made to improve gradient smoothness and overall image appearance.

New Features

• Improve Tonescale
  • Add Contrast Low module to the tonescale functions. This operation allows creative control over "contrast" in the midtones and shadows, and enables opendrt to form a more finished image out of the box, if desired. It can be applied per-channel or in an RGB ratio preserving manner.
  • Add Contrast High module to the tonescale functions. This operation allows creative control over the slope of the shoulder in the tonescale, allowing higher "highlight" contrast like ACES 1.x, or more "filmic" low-slope shoulder tonescale look.
  • Add Offset control. It turns out that adding a small positive offset is a very important creative component of image appearance, and to omit this operation would be a mistake.
  • Revise tonescale system math.
    • Previously OpenDRT used a tonescale system similar to the one Daniele Siragusano posted on acescentral, but slightly modified to allow exact intersection constraints for middle grey and peak display. It accomplished this by applying the display linear output scale before the power function. The end result was pretty much identical due to the intersection constraints, but the downside was that it was difficult to access the 0-1 range pre-output y scale, which is necessary for many look operations like the high end purity compression. Basically you had to do all parts of the tonescale and then un-scale it for the purity compression and other operations. This always bothered me.
    • For this new version I went back and figured out a new way to solve the constraints when applying output y scale after the power function. This model differs from Daniele's formulation. It prioritizes an exact solve for middle grey, and uses an approximate solve for peak display. Peak display intersection is much less critical to accurately map since small variations are not visible in the image and will suffer from lack of precision in the final integer display encoding anyway. More details available here: https://www.desmos.com/calculator/1c4fhzy3bw
• Refine Purity Compression
  • Previously the purity compression behavior was tied to the "rendering space" weights. To allow more control, purity compression is now driven by a separate non-normalized weighted euclidean norm, which allows better creative control over the purity compression behavior per "wide" RGB hue angle. These parameters are exposed as Purity Compression R G B controls.
  • Purity Compression Range is the new name for the previously exposed Purity Compress Low slider. There is a Low and a High control. See https://www.desmos.com/calculator/8ynarg1uxk
  • Add Purity HDR control. This allows creative control over the amount of purity compression as Peak Luminance is increased. At 0, the purity compression will not change as display peak luminance goes up. At 1, purity compression is reduced as peak luminance increases. The previous model for top end purity compression did not work well with the transition from SDR to HDR.
• Add Mid Purity adjustments
  • Mid-range purity turns out to be incredibly important operation for image formation, especially some amount of compression in mid-range purity at the top end. This helps improve the horrible pasty pastel image appearance in image formation approaches like ACES 2, TCAM, and Arri Reveal. To this end I've added a look module to accomplish this as well as to boost mid-range purity at the bottom end.
• Expose Brilliance parameters. This module is a mix between a creative look adjustment and a necessary image rendering adjustment. Basically it scales down the vector, increasing with distance from achromatic. This operation reduces disruptions in gradients of narrow spectra light sources, and can also be used creatively to achieve more "dense" or "filmic" image appearance.
• Add Hue Shift preferential look modification module. Older versions of OpenDRT had something similar, but it was limited to only adjusting the apparent hue of "highlights" affected by the top end purity compression. This new module offers more flexibility, and is re-engineered to work better as a creative control. It affects more the hue angles near the primaries.
• Add Hue Focus R preferential look modification module. This operation affects mid range purity and also hue angle. For example if Hue Focus R is increased, mid-range purity of reds on the bottom end is increased, and there is a hue distortion at the bottom end towards the red primary from both the yellow and magenta side. And conversely, mid-range purity at the top end is decreased, and the hue angles distort towards the yellow and magenta secondary. This module allows a creatively controllable way to dial in some of the nice look aspects of per-channel without being creatively shackled to the tonescale curve.
• Add Creative White adjustment. This sets the color of the peak luminance in the final image. D65 is the default, but the color can be made warmer all the way down to D50 to achieve a filmic look with warmer highlights. Additionally a Creative White Range slider was added to control how much to affect midtones and shadows. At 1.0, this operation is simply a CAT matrix to the desired whitepoint. At 0.0, it is mixed by the tonescale curve.
• Expose Purity Compress Low module. This is a final "gamut compress" style operation that improves smooth rendering and increased tonality of very pure colorful gradients.
• Add a selection of Look Presets
  • Default: an image formation that includes minimal adjustments for an aesthetically pleasing image.
  • Colorful: A very saturated bright exhuberant look, a good fit for animation.
  • Umbra: A dark moody cinematic look with very low shadow contrast, strong color crosstalk, natural blues, and a warm D50 whitepoint.
  • Base: only the base components of the OpenDRT image rendering. Practically no preferential adjustements. Purity compression is chromaticity-linear and very minimal. Bright saturated highlights will clip. Mid-range purity is very strong. A good starting point for further look development if absolute control is desired.
• Add a selection of Tonescale Presets
  • Default High-Contrast: The default tonescale curve. Enough contrast to maybe be called a "finished" image, but also could be a good base to build on.
  • Low-Contrast: A low contrast tonescale curve that is intended as a starting point for further grading. Requires further contrast to be added in order to achieve something resembling a "finished" image (unless of course a very low contrast look is desired).
  • ACES 1.x: A rough match of the ACES 1.x tonescale curve. One deviation is mapping 0.0 to 0.0 through the tonescale curve, rather than mapping +0.02 to 0.0... because that is moronic.
  • ACES 2.0: An exact match to the ACES 2.0 tonescale function. Very low contrast in the highlights, and very strong shadow toe compression while mapping 0 to 0 through the tonescale function. Be careful with this one if adding additional shadow contrast upstream, without a strong positive offset.
  • Marvelous Tonescape: A dark contrasty cinematic tonescale, which maps middle grey to 6 nits in SDR instead of the more typical camera DRT method of 11.1 nits following the Rec.709 OETF standard. Another way to think about this is that this tonescale is designed for a brighter SDR display.
  • Arriba Tonecall: A low-contrast tonescale with an approach to shadows more typical of camera style DRTs, where there is a strong positive offset, and strong shadow toe compression.
  • DaGrinchi ToneGroan: Another low-contrast tonescale designed as a starting point for further manipulations. Not as good as other options.
  • Aery Tonescale: An aery tonescale function
  • Umbra Tonescale: The tonescale from the Umbra look preset

Full Changelog: v0.3.5...v1.0.0

Release Notes

OpenDRT v1.0.0 is released as a node for Nuke, and a DCTL for Resolve. The DCTL comes in two versions: The normal version which has look presets, and a "Stickshift" version with all parameters exposed. I would strongly urge you to use the presets version first and see how you find it. DCTL does not provide a very good user experience for something as complex as the full transform with all parameters, and it is very complicated and not user friendly. The Nuke node also provides a pretty nifty presets system, which makes it rather easy to build a preset in nuke and then copy paste a single line of DCTL to add a preset.

OpenColorIO Configs

In this release I'm also including OCIO configs featuring OpenDRT, attached as zip files. They include views for OpenDRT "Default", "Colorful" and "Umbra" presets. The configs also include a complete complement of colorspaces which you might find useful. The OCIO configs were generated with ociogen, and feature Filmlight's E-Gamut2 as the working space and reference space (Used with permission from Daniele Siragusano). E-Gamut2 is suitable for working with typical camer...

OpenDRT v0.3.5

Last release of OpenDRT v0.3.x

Full Changelog: v0.2.8...v0.3.5

OpenDRT v0.2.8

The last stable release of OpenDRT 0.2.x, pushed on August 24th 2023.

OpenDRT v0.1.3

The state of OpenDRT when I stopped development in 2022.

OpenDRT v0.0.82

Features

• Add input transfer function options with common camera log and log working space encodings for the Resolve DCTL.
• Add Blackmagic Gen5 colorscience inputs: Blackmagic Wide Gamut // Blackmagic Film Gen5 Log encoding
• Add toe compression into chroma compression factor. This naturally reduces chroma in deep shadows and helps render shadow grain more naturally. No more rainbow colors in the shadow grain.
• Add lenscap black subtraction compensation feature. Pretty experimental but it is intended to add a small value to compensate for negative grain on input. Since OpenDRT maps 0.0 to 0.0, this helps preserve shadow detail. Disable this if manually compensating black levels while grading.
• Add gamut compression operator to better handle extremely high purity input colors.
• Update perceptual dechroma to use ICtCp colorspace. This biases the chromaticity-linear hue paths of the highlight dechroma and gamut compression, along perceptual hue-lines, resulting in more natural looking colors and better appearance matching between HDR and SDR outputs.

Bug Fixes

• Remove semicolons on parameter lines which may have caused issues with Metal on Mac.

OpenDRT v0.0.81

Features

• Add more presets:
  • DCI Outputs, including P3 D60, P3 DCI, and DCDM X'Y'Z'
  • Dolby P3 gamut HDR variants
• Split DCTL into OpenDRT which is preset only, and OpenDRT_params, which has most parameters exposed for experimentation.

Bugfixes

• Fix bug with HLG inverse EOTF
• Clamp negative values in quasi-perceptual dechroma, which was causing occasional artifacts.

OpenDRT v0.0.80

This is a big change with a lot of development work compared to v0.0.75. Here is a summary of the notable new features:

Tonemap

• Replace tonemapping function with a piecewise hyperbolic compression function with power and parabolic toe compression.
  See this desmos plot for details on the math.
  And if you're curious about other options and a verbose history of the development, check out these posts on the acescentral thread. In particular, this one and this one.
• First pass model and presets for HDR displays

Chroma Rendering

• Switch to using a "weighted vector length" norm. This allows a massive complexity reduction while preserving the nice rendering features I was trying to achieve with much more complex methods before:

  • More saturated colors especially blues and reds render darker, while yellow and orange renders brighter
  • Saturation boosted along the red/blue axis while keeping magenta and yellow under control

• Switch the rendering colorspace to Truelight LMS, described in Chromaticity coordinates for graphic arts based on CIE 2006 LMS with even spacing of Munsell colours by Richard Kirk.

• Apply chromatic adaptation for white-point handling as LMS scales in the rendering colorspace.

• Calculate whitepoint normalization factor based on whitepoint and output display gamut, and concatenate with other output domain scale elements

• Add inverse transform

• Completely rework and massively simplify InverseEOTF and EOTF nodes

DaVinci Resolve DCTL Implementation

OpenDRT v0.0.75

• Hopefully resolve issue with oklab perceptual model by moving it into the RGB Ratios setup. Not sure why I didn't think about that before. Also it doesn't require the exposure invariant setup anymore, which seemed hacky. It should be more reversible also.
• Move tonescale to a seperated group that happens prior to all other display rendering operations to try to compartmentalize things a bit more.
• I still think there is a much simpler version of this model possible. There is still too much fiddling and tweaking for my taste. Need to do more experimentation...

OpenDRT v0.0.72

• Increase darkening of red hues in highly saturated and bright regions to try to preserve more tonal range in images with things like light sabers and tail lights.
• Alter perceptual model for a simpler alternative. What do you think?