Bad results using Wide Gamut Intermediate on Cineon scans?

When. grading CINEON film scans I used Davinci YRGB or ACES (ADX10) in the past but testing Wide Gamut Intermediate.

My settings are:
CS: Color Managed
Input: Cineon Film Log
timeline: Davinci WG/Intermediate
Timeline Luminance: SDR100 (tested with HDR1000 as well)
Output: Rec709 2.4
Limit Gamut: output Color space
Input DRT: Davinci
Output DRT: Davinci
* Use inverse DRT for SDR to HDR
* Use white point adaptation
* Use color space aware tools

Resulting image straight of the box is SUPER saturated and overly grainy.

Any ideas or tip?

I've tried the same with Arri LogC3 input and results in closer world to ACES/YRGB base grade but wondering why Cineon Film Log is not working...

Thanks

[Peter Chamberlain]

Can u post or pm a source frame and also the two resulting frames u refer to?
What is generating the film scan?
Is it really Cineon log?

Can u post or pm a source frame and also the two resulting frames u refer to?
What is generating the film scan?
Is it really Cineon log?

I've uploaded stills w/ labels here:
https://www.dropbox.com/sh/0ubx41ytqvgy ... Uyvna?dl=0

Scans are from SCANITY 35mm scanner set to Cineon.

thanks

[Peter Chamberlain]

Report from engineers explains what you are seeing and its a simple operation selection to fix.

As Cineon it is not RGB based and is highly none linear, in general Rec.709 or P3-D65 look best but it will depend on the material.

Because of this, when using Cineon Film Log unless the colorspace is set explicitly using ‘Separate colorspace and gamma’ RCM will default to use the same gamut as the timeline. In this case as DaVinci Wide Gamut is so wide this causes the the over saturation.

To fix you should check the ‘Use separate color space and gamma’ option and set the input colorspace to P3-D65 and see if that now looks correct.

So cineon log is a color space (selection in input colorspace) but then again it isn’t (select it as gamma), and P3-D65 is a colorspace instead, but isn’t because gamma is cineon log and colorspace is made up from combination of gamut and gamma. This terminology Resolve uses is utterly confusing and misleading, maybe engineers can help clean up this part in the UI too.

So cineon log is a color space (selection in input colorspace) but then again it isn’t (select it as gamma), and P3-D65 is a colorspace instead, but isn’t because gamma is cineon log and colorspace is made up from combination of gamut and gamma. This terminology Resolve uses is utterly confusing and misleading, maybe engineers can help clean up this part in the UI too.

There's two things: Gamuts (defining the coordinates of primary colors in the CIE diagram) and Transfer Functions (a mathematical function that maps linear scene values to an arbitrary intermediate - or inverse)

Cineon Log is a transfer function, just like LogC, Log3G10, sLog etc.

But because film stocks do not have absolute gamuts (each stock is different, even the same stock but from a different roll can be different) there is only a standard for the transfer function.

Therefore resolve only applies the transfer function (they call it gamma, which I agree is a bad lingo) and do not change the gamut (aka use the same as what the timeline is set to)


So whenever working with Cineon Log you should (as Peter mentioned) make sure to check "use seperate color space and gamma" and try Rec.709, P3 or whatever fits best.

If terminology you use would make it into Resolve it would be all fine and dandy. It doesn't that's what I'm saying. In Resolve, cineon log is stated as colorspace. Colorspace is used as a term for gamut. Gamma is term for transfer function. None of these is correct.

My brain hurts... Good discussion, though.

I tried the sample images, but I always separate color space from gamma (in Resolve lingo) and so when I switched to Cineon Log for the gamma, I selected Rec709 for the color space and the image looked fine to me. Now I know why. Thx.

Because of this, when using Cineon Film Log unless the colorspace is set explicitly using ‘Separate colorspace and gamma’ RCM will default to use the same gamut as the timeline. In this case as DaVinci Wide Gamut is so wide this causes the the over saturation.

I always assumed it would be paired up with Rec.709/sRGB just like Linear does when you set it to that and change to separate gamut/gamma after. This behavior is completely hidden to the user and shouldn't even exist in the first place. A while ago I already suggested to clean up the ambiguous practices of combined and/or simplified definitions of color spaces. I hope we can see improvements here in the future.

One of which should be to remove cineon film log and linear from RCM unless you separate it. Or hard pair it up with something if you feel that it's necesarry to have in the combined list.
Further more ALL spaces should clearly note their official primaries name and transfer function name unless the OFFICIAL color space name already defines both.

My post from a while ago...
viewtopic.php?f=33&t=151449

I agree it should bundle with some gamut to begin with. Be it an arbitrary gamut between P3 or Rec.709 or be it one of the two. But ignoring the gamut at all and therefore screwing the color management completely is the worse option imho.

If terminology you use would make it into Resolve it would be all fine and dandy. It doesn't that's what I'm saying. In Resolve, cineon log is stated as colorspace. Colorspace is used as a term for gamut. Gamma is term for transfer function. None of these is correct.

That's correct from my experience as well. There's no implied gamut from a film scan. It's "supposed" to be scanned according to Cineon gamma or ADX (in ACES), but my real-world experienced is that this generally crushes the film scan too much for my tastes. I'd rather use a Custom Curve and just apply a more gentle S-curve to not squash the toe of the signal as much. The rest (in terms of color balance) I adjust with Printer Lights and then a couple of nodes for LGG balance and exposure.

I generally try very hard to get the overall balance and contrast set first, and I find that after that, everything generally falls into place in a predictable way (assuming normal film stocks and a good scan).

Hard to tell if you agreed or disagreed Cineon log is density capture by analog film definition (although well defined in full digital workflow too), and yes, there is no specific implied gamut. And thus cineon log doesn’t define a colorspace. As shebbe wrote above, it should be explicitly paired with overridable gamut to make it a compound that could be called colorspace. Implicitly pairing it with working space in RCM2 is wrong in most cases.

My uneducated guess (I’m dumb as duck in film scanning) is that the actual gamut of the cineon data is dictated by the film scanner, but as with cameras, scanner sensor doesn’t have defined gamut in same sense as we speak about here. So if some film scanning expert can chime in, it would be interesting to know if film scanners provide scan data as-is or is it shaped the same way as in cameras, using an optimized transformation to move data to some clearly defined colorspace. Because when doing filmout again, film printer has specific characterstics and how scanned data maps to that should be well defined..?