Cineon Film Scans

Hi I am new to this forum and looking for some advice on an upcoming project we are going to be working on. We normally work ACES internally for all projects even though not all are our projects are an ACES delivery. So for the most part its a hybrid system where we ingest material into ACES using the correct IDT’s for the cameras used and drop back to the shows native coloursapce to apply any cdl and display luts and go back to native on final delivery as and when required. All has been going swimmingly and made our whole colour pipeline much simpler.

One new project is being shot on film and it doesn’t look like its going to be scanned using ADX even though we have requested an ACES workflow so whats he best way to deal with this as we want to stay ACES internally . So far I believe they are using Cineon to linear curve and any display LUTS and colour ops are set to work in Cineon. Should I still use the ADX IDT to bring them into our internal working ACES colour space and work as I normally do in a hybrid manor going back to the original colour via inverse transform to apply colour ops and display for media back to them. It alls seems to match on a round trip back, but I am concerned this may cause some issues for any CG material that will be added to the shots as the inverse transform is going to ADX and not Cineon could this push things out of range? Or are we best to not work ACES and stick with native linear or use a different method to ingest. Any advice would be helpful.


There’s this from OCIOv2:

  - !<NamedTransform>
    name: Cineon Log to Lin
    aliases: [ Cineon ]
    family: Input/File-io
    description: |
      Traditional Cineon-style log-to-lin with RefWhite=695, RefBlack=95, Gamma=0.6
    transform: !<LogAffineTransform>
      log_side_slope:  0.293255131965
      log_side_offset: 0.669599217986
      lin_side_slope:  0.989202248377
      lin_side_offset: 0.010797751623
      base: 10
      direction: inverse

Thanks Derek but unfortunately we are not on 2.0 yet and won’t be for a while. Any other suggestions?

I believe using Input - RED - Curve - REDlogFilm as the IDT is the same as Cineon. Hoping @Thomas_Mansencal can verify

It is but then you need to change the primaries as they are not ACES but in sRGB so additional transforms will be required. I have tried using Utility - Linear - sRGB but it doesn’t look right to me.

You mentioned CDLs. Are you processing these in Cineon (ie redLogFilm) rather than ADX ?

Yes currently experimenting. Ingest using ADX10, but then all the CDL’s are then applied back in original log. So we do a reverse transform back to ADX10 which puts it back to native Cineon then apply CDL then back to linear again within Nuke using OCIOFileTransform with a working space as log which is defined as ADX10 in the OCIO config . The Display is set up to do the same for the clients Film LUT or we can use the standard ACES Rec709 RRT/ODT. The latter is used to bake into any Quicktimes for them to review, so round trip is transparent.

So if I’m following you Read (IDT) is ADX [ADX to ACEScg] > invADX [ACEScg to ADX]. This would be a noOp, essentially the same as setting the Read node to raw. CDL processed in ADX (based on compositing_log role in OCIO).

I was thinking instead to use the REDLogFilm (=Cineon) curve instead of ADX all the way through, so you set the OCIO compositing_log role to REDLogFilm. Then injest (Read node) in REDLogFilm. That puts you in ACEScg working space. CDL is processed in log (which is Cineon i.e. REDLogFilm). Then apply client film LUT (also with REDLogFilm/Cineon process space) as ODT.

Apologies if I’ve misunderstood anything.

Sorry for late reply been on leave. Using this wont be putting the plates into ACES primaries its just the base Cineon linearisation curve without any colour adaption from what I understand. Any CG would be created in ACES so we would have two different primaries to deal with which is not ideal. I can add an sRGB to ACES conversion using Utility - Linear -sRGB but not sure if thats the best way of dealing with it. Using the Cineon curve I noticed that exposure is very different on the linear images especially noticeable when using ACES RRT/ODT compared to ADX10 which exposure wise matches more closely exposure wise to their supplied Film Emulation LUT.

Right so you could add that on ingest:
Cineon + linear srgb

Yes we could, just want some confirmation that going this route wont cause us too many issues.

I did some testing in Nuke using KODAK’s Maricie as a DPX in cineon color space. On one side I have default Nuke with the read node set to Cineon and sRGB on the view transform.

On the other side I have Nuke with an ACES config, with the viewer in ACES set to un-tone-mapped to match Nuke’s default sRGB display.

I get a pretty good match when I set the ACES Read color space to ADX10. What gives me the best match (afaik it’s a perfect match) is setting the Read to Raw, then using a Nuke ColorSpace node in:cineon out: linear followed by OCIOcolorSpace in: linear_sRGB out: ACEScg.

I get the exact same result if I use CineonLog_to_linear.spi1d instead of the Nuke ColorSpace cineon to linear above. With that in mind here’s the whole thing as an OCIO color space:

  - !<ColorSpace>
    name: Input - Cineon
    family: Input/Film
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Cineon log to lin
    isdata: false
    allocation: uniform
    allocationvars: [0, 1]
    to_reference: !<GroupTransform>
        - !<FileTransform> {src: CineonLog_to_linear.spi1d, interpolation: linear}
        - !<ColorSpaceTransform> {src: Utility - Linear - sRGB, dst: ACES - ACES2065-1}
1 Like

Thanks. Whats the none tone mapped display sRGB_D60sim?

The un-tone-mapped display is based on the display transform from the OCIOv2 demo config which uses the built-in transform. It’s an inv EOTF for an sRGB Display with D65 whitepoint.

<BuiltinTransform> {style: "UTILITY - ACES-AP0_to_CIE-XYZ-D65_BFD"}

I made a version of it for OCIOv1 using Jed Smith’s inverse EOTF Nuke script to create a LUT for OCIO. Here’s the Nuke script (copy-paste into Nuke)

set cut_paste_input [stack 0]
version 13.1 v1.013601b
push $cut_paste_input
Group {
 name InverseEOTF
 label "\[value eotf]"
 selected true
 xpos -192
 ypos 50
 addUserKnob {20 EOTF_tab l EOTF}
 addUserKnob {4 eotf t "Choose the inverse EOTF to apply for the target display device." M {None "sRGB Display" BT.1886 "Gamma 2.6" PQ HLG "" "" "" ""}}
 eotf "sRGB Display"
 Input {
  inputs 0
  name Input
  xpos 400
  ypos -160
 Dot {
  name Dot1
  xpos 434
  ypos -96
set N9838a800 [stack 0]
 Dot {
  name Dot3
  xpos 544
  ypos -96
set N9838a400 [stack 0]
 Dot {
  name Dot4
  xpos 654
  ypos -96
 Multiply {
  channels rgb
  value 10
  name Multiply1
  label "scale input 0.1x for 1000 nit match between PQ and HLG"
  xpos 620
  ypos -76
 Expression {
  temp_name0 Yd
  temp_expr0 0.2627*r+0.6780*g+0.0593*b
  expr0 r*pow(Yd,(1-_g)/_g)
  expr1 g*pow(Yd,(1-_g)/_g)
  expr2 b*pow(Yd,(1-_g)/_g)
  name HLG_InverseOOTF
  xpos 620
  ypos -28
  addUserKnob {20 CONSTANTS_tab l CONSTANTS}
  addUserKnob {7 _g t "Gamma: Extended model for gamma variation according to peak display luminance and surround luminance: BT.2390-8 p32" R 0 2}
  _g {{1.2*pow(1.111,log(Lw/1000)/log(2))*pow(0.98,log(max(1e-6,Lamb)/5)/log(2))}}
  addUserKnob {7 Lw R 600 4000}
  Lw 1000
  addUserKnob {7 Lamb t "ambient luminance level in nits" R 0 200}
  Lamb 5
 Expression {
  expr0 r<=1/12?sqrt(3*r):_a*log(12*r-_b)+_c
  expr1 g<=1/12?sqrt(3*g):_a*log(12*g-_b)+_c
  expr2 b<=1/12?sqrt(3*b):_a*log(12*b-_b)+_c
  name HLG_OETF
  selected true
  xpos 620
  ypos 5
  addUserKnob {20 CONSTANTS_tab l CONSTANTS}
  addUserKnob {7 _a t alpha}
  _a 0.17883277
  addUserKnob {7 _b t beta}
  _b {{1-4*_a}}
  addUserKnob {7 _c}
  _c {{0.5-_a*log(4*_a)}}
push $N9838a400
 Expression {
  expr0 pow((c_1+c_2*pow(r*Lw/10000,m_1))/(1+c_3*pow(r*Lw/10000,m_1)),m_2)
  expr1 pow((c_1+c_2*pow(g*Lw/10000,m_1))/(1+c_3*pow(g*Lw/10000,m_1)),m_2)
  expr2 pow((c_1+c_2*pow(b*Lw/10000,m_1))/(1+c_3*pow(b*Lw/10000,m_1)),m_2)
  name ST2084_InverseEOTF
  xpos 510
  ypos -43
  addUserKnob {20 CONSTANTS_tab l CONSTANTS}
  addUserKnob {7 m_1}
  m_1 {{2610/4096*(1/4)}}
  addUserKnob {7 m_2}
  m_2 {{2523/4096*128}}
  addUserKnob {7 c_1}
  c_1 {{107/128}}
  addUserKnob {7 c_2}
  c_2 {{2413/128}}
  addUserKnob {7 c_3}
  c_3 {{2392/128}}
  addUserKnob {7 Lw t "Display peak luminance in nits" R 600 4000}
  Lw 10000
push $N9838a800
 Expression {
  expr0 sign(r)*pow(fabs(r),1/p)
  expr1 sign(g)*pow(fabs(g),1/p)
  expr2 sign(b)*pow(fabs(b),1/p)
  name power
  xpos 400
  ypos -70
  addUserKnob {20 Params_tab l Params}
  addUserKnob {7 p l power R 0.2 2}
  p {{eotf?2+eotf*0.2:1}}
 Switch {
  inputs 3
  which {{max(0,eotf-3)}}
  name SwitchInverseEOTF
  xpos 400
  ypos 5
 Output {
  name Output
  xpos 400
  ypos 80

It’s intent is for diagnostic purposes. In this case getting the ACES display to match Nuke’s default display-referred sRGB view transform without any tone mapping for comparative purposes.

1 Like