How do I configure ocio to use an existing Premiere .cube lut in Blender?

Question

I have recently purchased an Insta360 One X camera and am interested in using its Log video mode and doing post-production in Blender. Insta360 has produced a log lut for use in Premiere (Pro2_iLog_LUT_1.0.0.cube) which I'd like to use in Blender, because I 💙 Blender & I'm a beginner not a pro.

From what I've read:

1. OCIO (the colour management that Blender uses) supports .cube files (though I'm not sure the Iridas format is the same as Premiere but I don't get any errors)
2. Premiere uses rec. 709 as it's internal colour space the same as Blender (though I might be wrong)

So I thought in theory this should work fairly easily. So I tried using it by adding this to the OCIO configuration file (config.ocio):

  - !<ColorSpace>
    name: Insta360 Log
    family:
    equalitygroup:
    bitdepth: 32f
    description: |
      Pro2_iLog_LUT_1.0.0.cube for use with the Insta360 Log mode
    isdata: false
    allocation: lg2
    to_reference: !<FileTransform> {src: Pro2_iLog_LUT_1.0.0.cube, interpolation: linear}

On some trial video the new setting in Strip Input -> Input Color Space looks a lot more washed out than the default sRGB setting, and very similar to the Raw and Linear settings. I'm assuming I should see the video in normal colour in the preview and render ports.

I have tried changing every parameter in the colorspace config (including those that aren't shown) with no real difference. I even converted the .cube to a .3dl using pylut with no real change. I can't help but think either my rec.709 assumption is wrong or I'm missing something entirely.

I hope someone can help & TIA!

(I have read all of troy_s's posts on luts and they don't seem to cover this sort of configuration / import)

Edit:

As an update and in response to troy_s's excellent answer for anyone else interested, I ended up with this:

- !<ColorSpace>
  name: Insta3601XLogToRec709
  family:
  equalitygroup:
  bitdepth: 32f
  description: |
    ONE-X-LUT-Final-V1.0.0.cube for use with the Insta360 Log mode
  isdata: false
  allocation: uniform
  to_reference: !<GroupTransform>
    children:
      - !<FileTransform> {src: ONE-X-LUT-Final-V1.0.0.cube, interpolation: best}
      - !<ExponentTransform> {value: [2.4, 2.4, 2.4, 1.0]}
  from_reference: !<GroupTransform>
    children:
      - !<ExponentTransform> {value: [2.4, 2.4, 2.4, 1.0], direction: inverse}
      - !<FileTransform> {src: ONE-X-LUT-Final-V1.0.0.cube, interpolation: best, direction: inverse}

(Spot that I didn't even manage to find the correct lut from the Insta360 website)

The colour result did seem to be slightly more rich than the camera's 'normal' mode, so I imagine this could be a useful tool if someone wanted to mess around with the 'look' of their output video without losing colour information on the way. But could also be a usable option if using Premiere is out of the question and you just need any other way to access some Insta360 log footage.

However the performance when previewing is awful when compared to say the sRGB built-in Input Colour Space (2fps vs 20fps) on a non-GPU Macbook Air. I tried modifying bitdepth, allocation and interpolation and nothing seemed to make a difference. I'm putting this down to:

• the .cube which appears to be a 3d lut rather than a 1d lut which I imagine are more difficult to process, and
• the exponent transform which again I imagine is some non-trivial calculation

For me I'm not sure this is going to be a usable workflow unless it speeds up significantly on my machine with a decent GPU. I may post back here with those results. Now I'm off to read Paul Chamber's blog posts! Thanks again troy_s!

Edit2:

I'm afraid on my GPU machine there was an improvement but it wasn't due to the GPU. The playback speed appears to be CPU-bound. Also I tried enabling proxies and increasing the cache size but neither made a difference. Oddly at certain points it did speed up to real-time and then slowed down again so I imagine it is trying to cache frames in the background but not managing to keep up.

Answer 1

Greets Racitup. Flattered to be mentioned in your post.

I'll start this off by saying that Adobe really doesn't have a very good handle on this sort of thing. It's a bit of a mess as Adobe has an ecosystem to support.

Let's try to sort out your questions in order...

I have recently purchased an Insta360 One X camera and am interested in using its Log video mode and doing post-production in Blender. Insta360 has produced a log lut for use in Premiere (Pro2_iLog_LUT_1.0.0.cube) which I'd like to use in Blender, because I 💙 Blender & I'm a beginner not a pro.

Not sure what a "pro" is, but you'll need to remember a key thing about working with transforms via LUTs or otherwise; they are blind as a mole. Transforms only specifically apply to a particular input, and will deliver a specific output. If either doesn't match your context, you are hooped.

1. OCIO (the colour management that Blender uses) supports .cube files (though I'm not sure the Iridas format is the same as Premiere but I don't get any errors)

Depending on the formatting, Iridas should work. Minor formatting differences impact the ability for various software to read and / or write the various LUT formats, and sadly, there are a near infinite number of nuances.

2. Premiere uses rec. 709 as it's internal colour space the same as Blender (though I might be wrong)

Blender uses REC.709 as the primaries, yes, however there is a rather radical difference with how the internal model works. That is, Blender and 2019 forward looking applications use a scene referred model. Why does this matter? Because Adobe uses a legacy display referred model. A scene referred model (search this site for some fantastic information) keeps the importance on the ratios between code values, and no specific meaning to any particular code value. That is, the code values could range from negative infinity to positive infinity, and it's up to a particular transform chain to give it meaning.

On the other side is the display referred model. That is, the code values fit within a minimum to maximum range, which could be called 0.0% to 100.0%. This is known as display referred because the code values exist in reference to a particular display, with a set minimum and maximum output.

If all that seems complex, it means your data is living in two different worlds. If your goal is to mix CGI with footage, the display referred world is incompatible with the scene referred world. If your goal is to only apply LUTs to your imagery and see them as per other software, it's not much of an issue.

On some trial video the new setting in Strip Input -> Input Color Space looks a lot more washed out than the default sRGB setting, and very similar to the Raw and Linear settings. I'm assuming I should see the video in normal colour in the preview and render ports.

It should be noted that Blender has some wildly different code paths, and the VSE is no exception here. You have to have a firm handle on what is going on to fully appreciate how much of a nightmare this is.

To simplify this, we need to focus on the three states of your code values in your image buffer. Input, Reference, and Output. For reasons I won't go into here, your reference (aka "working") space is scene referred linear, and your footage will get transformed "to" that, before being shipped out to the output. By assigning your transform to the footage, you are instructing Blender what the code values mean and how to get to scene referred linear.

I'm guessing that at this point you might already see the problem. Your LUT is actually intended to be applied on your footage as an "aesthetic" interpretation of the data to prepare it for a REC.709 broadcast display. That's probably giving too much credit to the developers of the camera, but we'll stick with that for now.

As you can probably see, this means that you have your log-like encoded Input code values, and those are intended to be rolled directly out to this Output transform to get to a REC.709 / BT.1886 output. Having looked at the Insta360 LUT in question, that's my best estimate.

So what to do? First is to realize your footage is mostly useless for CGI work without a transform to undo the log-like encoding and take you to scene referred linear. There's an absolutely amazing series of blog posts from Paul Chambers that I can't recommend enough, if this is at all of interest to you. Heck, even if it isn't, his six part series and the post on proximity lighting are fantastic reads.

Next, even if you are happy with display referred, it means you'll need to wrap your little transform up as a bundle. Also, given we don't know what the Insta360 flat log-like encoding is, we can't really "undo" it into any useful state, and worse, we can't invert 3D LUTs. So, the best we can do is something like the following. Bear in mind that OCIO really isn't great if manually editing the files, but alas, here we are with the caveat firmly in view:

  - !<ColorSpace>
    name: Insta360 Log
    family:
    equalitygroup:
    bitdepth: 32f
    description: |
      Pro2_iLog_LUT_1.0.0.cube for use with the Insta360 Log mode
    isdata: false
    allocation: lg2
    to_reference: !<GroupTransform>
      children:
        - !<FileTransform> {src: Pro2_iLog_LUT_1.0.0.cube, interpolation: best}
        - !<ExponentTransform> {value: [2.4, 2.4, 2.4, 1.0]}
    from_reference: !<GroupTransform>
      children:
        - !<ExponentTransform> {value: [2.4, 2.4, 2.4, 1.0], direction: inverse}
        - !<FileTransform> {src: Pro2_iLog_LUT_1.0.0.cube, interpolation: best, direction: inverse}

If you can provide the LUT I could be more useful here. I can't appear to find the one you listed anywhere. The only "proper" one I can see is this one available at the download link. Also note, I've not tested the above stanza, so it might break.

Hope this helps...