Open Display Transform Versions Save

The state of OpenDRT when I stopped development in 2022.

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.

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.

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

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

• 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?

• Remove bias on distance control
• Rework bias on luminance control
• Switch back to power function on path to white factor because it actually looks about the same with the rgb ratio distance control setup.
• Still need to figure out the kinks in the perceptual setup, and I'm questioning whether it is a good design decision to have something this brittle and non-reversible in here.
• Still need to figure out the HDR tonescale...

• I discovered that luminance weights applied directly to inverse RGB ratios results in the correct weighting, so this is now simplified a lot and looks better.
• Refine luminance control (setup that controls luminance per hue region), to include a bias for what region of norm to remove. Put another way: darken blues and reds below a certain threshold more than values above that threshold.
• Experiment with s-curve on distance factor, the setup which "raises" RGB ratio luminance for more saturated colors. This is a bad idea.
• Add very rough experimental version of a perceptual hue model using OkLab. Behavior is strange for colors near achromatic. To be solved...

• Remove parameters from node because it's a bad idea to expose them for creative adjustments.
• First draft of using luminance weights for affecting both luminance of achromatic, and as a factor to multiply into the rgb ratios
• Not sure the luminance weights are done correctly, but the result looks better than anything I've done so far so I must be on the right track. Or maybe not.
• Tweak exponential function which calculates path to white factor to preserve a bit more color in completely blown out highlights. Might not be necessary to go all the way to achromatic for these areas.

• Add creative whitepoint
• Add parameters to adjust gamut volume size, and luminance, per hue. Prone to artifacts, not ideal given the complexity.
• Multiplying the RGB ratios up is an idea that has potential.
• There must be a better and simpler model to accomplish the same thing.