ffmpeg and linear to srgb .3dl

[Brennan Chapman]

Hello,

I'm currently trying to generate a Quicktime from exrs using ffmpeg.

Our exr's are linear, and I want to bake the sRGB colorspace into the quicktime with ffmpeg.

I'm trying to get generate a .3dl lut file to transform the linear image into sRGB colorspace.

I can then pass this to the lut3d filter in ffmpeg.

I've been having trouble generating a correct lut.

I've tried a few approaches, but I I'm still missing something.

I'm using the default OCIO config for nuke:

nuke-default/config.ocio

I create the 3dl with this command:

ociobakelut --format flame --inputspace linear --outputspace sRGB srgb.3dl

I've been using Nuke to test the lut.

In nuke, I have my exr sequence loaded in with the colorspace on the read node set to linear.

Then, the viewer (ViewerSRGB) is set to use a display lut of sRGB.

Then I create another viewer (ViewerNoLUT), and set the display lut to none.

I create an OCIOFileTransform node and load in the srgb.3dl file I created earlier.

   EXR sequence -> OCIOFileTransform -> ViewerNoLUT

ViewerSRGB and ViewerNoLUT don't match.  The srgb.3dl lut is darker than it should be.

I tried creating a colorspace node in nuke and set the colorspace_out to sRGB.

   EXR sequence -> Colorspace -> ViewerNoLUT

ViewerSRGB and ViewerNoLUT match. No color shifts.

Shouldn't the OCIOFileTransform and the Colorspace node be doing the same thing? and get the same results?

Is there something I'm missing when creating the 3dl?

Thanks for the help!

-Brennan

[Jeremy Selan]

Hello!

Sorry that no one replied sooner.

I'm trying to get generate a .3dl lut file to transform the linear image into sRGB colorspace.

Are your linear images HDR? (I.e., do many of the values go >> 1.0) If so, the problem you're likely running into is that a raw 3D-LUT does not have the precision to directly map HDR scene-linear into output display values such as sRGB.  Some 3D-LUT formats, such as .csp (cinespace) internally include a 1-D shaper lut which *would* allow you do this in one step.   Is csp a viable option here? 

Alternatively, you could use ocioconvert to do the colorspace/format conversion as a preprocess, and the only rely on ffmpeg for the compression step.  While less efficient, this would likely be the simplest pipeline and the highest fidelity.

-- jeremy

[Ben De Luca]

Its worse than that, Its highly likely you are using x264 or another YUV envoded image file and ffmpeg is silently applying a colour transform to the bt601 color space rather than bt709. 

There is a post about it here. https://lists.ffmpeg.org/pipermail/ffmpeg-user/2012-July/007833.html

Sorry to add to the problem.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.