0

Cinespace .csp LUT with 1D Shaper LUT crushes shadows

Tobias Pfeiffer

November 02, 2015 17:45

None

Follow

Hi,

I am currentyl experiencing this in RV 4.0.12 but already encountered that problem with RV6+ at another company.

What I want to do is go from Linear to the Alexa standard 3D LUT (AlexaV3_EI0800_LogC2Video_Rec709_EE.cube) in one .csp LUT.

Therefore I am using a 10 bit ShaperLUT with the 3D LUT on top (32 res).

The LUT has been generated with OCIO (ociobakelut) but similar problems arised with other LUT sources as well.

The result looks fine in Nuke with either a OCIOFileTransform or Vectorfield node, but using this as a File LUT in RV crushes the blacks.

It seems like its working with a shaper LUT up to 8 bit but shadows fall apart with the attached 10 bit version.

Another workaround is to use 2 csp LUTs whereas the shaper LUT part is skipped and all transforms happen in the main part (lin 2 logC in LUT1 and logC to ARRI rec709 in LUT2). But this is only a workaround but no real solution to the problem I'm having.

Attached you can find:

• lut_compare.png => Shows the comparison between Nuke und RV
• darkexample.exr => stopped down Alexa sample footge, linear float
• linear_2_Alexa3D.csp => The LUT mentioned above

Thank you in advance for any feedback that might come.

 

Best,

Tobi

lut_compare.png
darkexample.exr
linear_2_Alexa3D.csp

• Facebook
• Twitter
• LinkedIn

6 comments

• 0
  
  Alan Trombla November 03, 2015 20:51

  Hi Tobi,

  There's a (very) long story here, but the short story is:

  A CSP LUT intended to take linear input that has "shaping" pre-lut with dense lattice points at the low end will work much better in RV if you add a block like this at the beginning of the CSP file (just before the prelut definition):

  BEGIN METADATA
  conditioningGamma=0.4545
  END METADATA

  I've modified the LUT you included accordingly and attached it to this comment for you to try.

  Long story:

  • Pretty much all the LUTs (1D and 3D) in RV are applied in HW, so their size is limited by the maximum texture size of the particular card. That limit is often 16k for current cards. A CSP pre-lut is resampled into a 2048-element array by default, though you can configure this with an environment variable ("RV_COMPILED_PRELUT_SIZE", must be power-of-two).
  • In addition to size, the HW LUT lattice points are linearly spaced (in the color/coords of the space in which the LUT is applied, of course).
  • Often the issue is not so much the number of lattice points as their arrangement in the input space. In particular, when the input to the LUT is linear, you often want denser arrangement of lattice points near the low end, aligning with human perceptual sensitivity.
  • In the CSP file format, both the 1D and 3D data are linearly spaced, but the pre-lut data can have arbitrary spacing, so on the face of it you might want to use a pre-lut with spacing appropriate for the shape of the transform the LUT implements, followed by a trivial identity 3D LUT (a non-linear prelut + 1D LUT won't work in RV). This would help in the case of the LUT being applied in SW (Nuke), but RV is going to resample the prelut (linearly) for use in the HW, so this alone does not help (see below).
  • Instead of a simple LUT application, you could adjust whatever PipelineGroup contains the node that applies the LUT to have additional nodes before (and after) the LUT application, so that the space in which the LUT is applied "linearizes" the transform of the LUT so that the equal lattice sampling required in hw is appropriate. But this would require some plugin work on your part in addition to incorporating those changes into the actual LUT file, so that it does things in the new color space.
  • This problem has come up elsewhere for us since people are trying to convert from ACES to ACESlog in order to apply a CDL. In addition to the "linear spacing" problem described above, this transform also has a very large DR, which _also_ reduces the number of lattice points available in the interesting region of the transform. Basically any increase in DR makes this problem worse.
  • In these cases the simplest solution might be to add a "conditioning gamma" to your LUT file. That's an attempt by us to work around this issue by applying a power function (in GLSL) to both the input lattice points and the input data to the LUT. If the power is < 1, this addresses both problems mentioned above by (1) "expanding" the lattice points close to zero and (2) reducing the overall dynamic range of the input. With a gamma of 0.4545, we find that we can visually match the application of an ACES-to-ACESproxy LUT in Nuke, even with the standard prelut lattice size of 2048. 

  (Note that the "conditioningGamma" feature appeared in RV 4.2.1/4.0.14.)

  Hope that helps,

  Alan

• 0
  
  Tobias Pfeiffer November 04, 2015 09:21

   

  Hi Alan,
  thank you very much for your fast response and thorough explanation.
  Makes all total sense to me.
  Seems like this fact is the dealbreaker for my usecase:

  "but RV is going to resample the prelut (linearly) for use in the HW"

  But..

  Yesterday evening I somehow managed to generate a LUT that does exactly what I need without utilizing OCIO. Just hacking it together in Notepad++
  This worked - even in RV (which it theoretically shouldn't).
  Then I started to fiddle around with ShaperLUT sizes and spaces in RV and managed to create a proper LUT with OCIO. This way I was able to generate a LUT from OCIO that works as well (12 bit Shaper, spaperspace AlexaV3LogC).

  Attached you can now find 3 LUTs. All look the same in Nuke, but only 2 of them work as expected in RV:

  • lin_2_ARRI3D.csp: My "Notepad ++" vesion. This one works. No matter where
  • lin_2_ARRI3D_OCIO-noShaper.csp: From OCIO, without setting a shaperspace. This one fails in RV
  • lin_2_ARRI3D_OCIO-ShaperLogC.csp: From OCIO, with Shapersape set to AlexaV3LogC. This one works in RV

  This is no longer urgent as I have a working solution to the problem.
  But maybe you can shine some light on why these LUTs work or don't work. This seems to proof that the shaperLUTs are not lineary resampled, right?

  Thank you!

  Best,
  Tobi

• 0
  
  Tobias Pfeiffer November 04, 2015 09:25

  thank you for pointing to the conditioning gamma!

  could not test it as we are now on 4.0.12. but will for sure after we upgraded.

• 0
  
  Alan Trombla November 09, 2015 01:56

  Hi Tobi,

  Glad to hear you have something that works for you.

  But maybe you can shine some light on why these LUTs work or don't work.

  To maybe clarify a bit, most LUTs work fine in RV, generally speaking it's a shaper lut that takes linear to log, and a very high DR that causes the problem.  It's something we've only started to see recenly.  Especially with ACES luts.   When comparing RV to Nuke, there are generally 2 sources of differences:

  1. As mentioned, HW LUTs must have lattice points that are linearly spaced in the input space, whereas a LUT applied in SW can have lattice points spaced however you want.   This can introduce a "loss of resolution" of the LUT function, and if this happens in the low end, it can be visible.
  2. With a SW LUT, you can use cubic or tetrahedral interpolation, whereas HW luts are always linearly interpolated.

  This seems to proof that the shaperLUTs are not linearly resampled, right? 

  No, it's just that as I mentioned above, the resampling to linearly spaced lattice points actually only infrequently causes a problem.

  Cheers,

  Alan

• 0
  
  Tobias Pfeiffer November 09, 2015 08:35

  Thank you for clarifying!

  Now it got cristal clear (even for me!)

  All the best,

  Tobi 

   

• 0
  
  Bernie kimbacher July 23, 2016 00:37

  Hi Tobias and Alan,

  We are desperately looking for the exact same LUT (apply a AlexaLog->Rec709 LUT to linear images) and it looks like you have gotten to the bottom of it?

  I've been looking around for hours and can't seem to find a solution.

  Looks like this LUT you mentioned is what we would need:

  lin_2_ARRI3D_OCIO-ShaperLogC.csp

  any chance you could upload/send that to me somehow? would be massively appreciated!

  -Bernie