Doom9's Forum - View Single Post - .ti3 Parser / .3dlut Generator for madVR + .3dlut toolset

nand chan · 26th August 2011, 00:25

Concept of a proposed scripting language I was toying with, as an analog to the above flowchart GUI:

Code:

!Input_Range 16 235
!Input_Depth 8 8 8
!Output_Range 0 255
!Output_Depth 16

# Import the CalFile namespace, which gives us access to the CalFile() filter
!Import(Files.CalFile)

# Example .3dlut generation script
!Pixel {
  
  # Since this is going to be a YCbCr script, first convert to RGB using the BT.709 primaries
  ConvertToRGB(BT709)
  
  # Now we want to adjust for our screen's somewhat darker gamma curve
  Gamma(2.2,2.35)
  
  # And apply the calibration info from an argyll file
  CalFile("path_to_file.ti3")
  
  # And just for fun, grayscale it
  Grayscale()
  
}

Things to consider:

- Allow custom scripting logic or not? Eg. declaration of variables, creation of custom transform filters or just allow loading these via managed assemblies
- Maybe include the pixel pulldown / pullup logic into the !Pixel pipeline itself? The reason doing this might be bad though is it would disencourage creation of meta-data, which renderers such as madVR would rely on.

Interesting realization:

If I went through with this scripting language, it obviously wouldn't be limited to just .3dluts. I could, for example, save them as transformation pipeline packages (.tpp?) and apply these to images etc. manually.

I could also introduce filters such as ChangeGamut() or ChangeWhitepoint().

I've also put some thought into how to do multiplexing. In the most basic idea, single-pixel filters would be distinguished by some sort of extra markup in the name, for example a period or $ or _ or something.

Code:

# Single filters could be applied like this
Multiplex(BlockR, BlockG, BlockB)

# For example
Multiplex($Gamma(1.0), $Gamma(0.9), $Gamma(0.8))

# A null or noop operation could either be represented as “null”..
Multiplex($Gamma(0.5), null, null)
# ..left out..
Multiplex($Gamma(0.5), ,)
# or perhaps done with $Cat() or $Default() or something
Multiplex($Gamma(0.5), $Cat(), $Cat())

# Larger blocks of multiple filters would be joined by { }
Multiplex({ $Gamma(0.5) $Add(0.1) }, { $Gamma(0.8) $Add(0.2) }, $Cat())

# Which can be stretched over several lines
Multiplex({
  $Gamma(0.5)
  $Add(0.1)
}, $Cat(), $Cat())

# The basic idea here is that newlines are ignored
Gamma(
  2.2,
  2.35 )

Further thoughts: Maybe extend my scripting format to custom amounts of channels? For example, a 3 -> 4 channel convertor that would convert from RGB to CMYK.

This obviously wouldn't be saveable as a .3dlut due to the limitation of the file format, but I could still save them as .tpp and use for proofing or something.

Feedback / thoughts?

26th August 2011, 00:25	#89 \| Link
nand chan ( ≖‿≖) Join Date: Jul 2011 Location: BW, Germany Posts: 380	Concept of a proposed scripting language I was toying with, as an analog to the above flowchart GUI: Code: !Input_Range 16 235 !Input_Depth 8 8 8 !Output_Range 0 255 !Output_Depth 16 # Import the CalFile namespace, which gives us access to the CalFile() filter !Import(Files.CalFile) # Example .3dlut generation script !Pixel { # Since this is going to be a YCbCr script, first convert to RGB using the BT.709 primaries ConvertToRGB(BT709) # Now we want to adjust for our screen's somewhat darker gamma curve Gamma(2.2,2.35) # And apply the calibration info from an argyll file CalFile("path_to_file.ti3") # And just for fun, grayscale it Grayscale() } Things to consider: - Allow custom scripting logic or not? Eg. declaration of variables, creation of custom transform filters or just allow loading these via managed assemblies - Maybe include the pixel pulldown / pullup logic into the !Pixel pipeline itself? The reason doing this might be bad though is it would disencourage creation of meta-data, which renderers such as madVR would rely on. Interesting realization: If I went through with this scripting language, it obviously wouldn't be limited to just .3dluts. I could, for example, save them as transformation pipeline packages (.tpp?) and apply these to images etc. manually. I could also introduce filters such as ChangeGamut() or ChangeWhitepoint(). I've also put some thought into how to do multiplexing. In the most basic idea, single-pixel filters would be distinguished by some sort of extra markup in the name, for example a period or $ or _ or something. Code: # Single filters could be applied like this Multiplex(BlockR, BlockG, BlockB) # For example Multiplex($Gamma(1.0), $Gamma(0.9), $Gamma(0.8)) # A null or noop operation could either be represented as “null”.. Multiplex($Gamma(0.5), null, null) # ..left out.. Multiplex($Gamma(0.5), ,) # or perhaps done with $Cat() or $Default() or something Multiplex($Gamma(0.5), $Cat(), $Cat()) # Larger blocks of multiple filters would be joined by { } Multiplex({ $Gamma(0.5) $Add(0.1) }, { $Gamma(0.8) $Add(0.2) }, $Cat()) # Which can be stretched over several lines Multiplex({ $Gamma(0.5) $Add(0.1) }, $Cat(), $Cat()) # The basic idea here is that newlines are ignored Gamma( 2.2, 2.35 ) Further thoughts: Maybe extend my scripting format to custom amounts of channels? For example, a 3 -> 4 channel convertor that would convert from RGB to CMYK. This obviously wouldn't be saveable as a .3dlut due to the limitation of the file format, but I could still save them as .tpp and use for proofing or something. Feedback / thoughts? __________________ Forget about my old .3dlut stuff, just use mpv if you want accurate color management Last edited by nand chan; 26th August 2011 at 05:17.