0

Basic LUT questions

J Bills

September 01, 2015 14:24

None

Follow

howdy tweakers - I need to put a standard Lin to Log display LUT into our install of RV.  There was some talk of doing a standard set of "preconditioning" luts (you called them) around v3.8 - were those ever realized?  is there an existing Lin2Log lut floating around anywhere that might save me some guesswork?

 

Also, for my own info, does RV have a "native" LUT format that works any better or is otherwise optimized or easier for RV to "digest"?

 

In my experience, a simple 8bit 1D or 3D LUT works fine for this sort of thing but just curious about like icc profiles and all of that newer mojo

 

and I guess that leads me to the bit depth question.  if I end up  making a simple 3d (3 channel) lut, would 8 bit (256 lines) be enough?  or do people usually bump to 1024 (10bit) or more for RV luts? 

i'm not sure if the extra precision amounts to much when viewing on an 8 bit display, but I've noticed that working in 16 or float in RV yields a HUGE difference in terms of color fidelity and reducing banding - 8 bit is much more banded than other software, I presume because of some graphics card acceleration you all are using, or something.  I assume there are some compromises being made for some sort of acceleration.

 

I can do some experimenting but any existing lut or pointers here would be much appreciated

• Facebook
• Twitter
• LinkedIn

10 comments

• 0
  
  Seth Rosenthal September 03, 2015 07:50

  Hey J Bills,

  It's good to hear from you. We have an example package that adds menu items to RV for creating/installing lin->log LUTs on the fly. It's a bit rough around the edges but it works well. It lets you install the LUT as a 'pre-lut' in front of another 3D LUT (pre-cache or Look) or as it's own LUT in the Look LUT slot. It would be easy to modify to use different LUT positions in the color pipeline, but those made the most sense. I can't seem to attach the file to this post, so I will email it to you.

  FWIW, going Lin to Log the package builds a channel LUT with 2048 samples.

  RV does have a native LUT format (I think it's described in the docs). However, we tend to recommend the Cinespace .csp format because it has the ability to use a 1D pre-LUT and a 3D cube LUT in the same file. RV handles all the color in floating point if possible so the 'bit depth' of the LUT is a bit misleading in terms of what RV does with it.

  Regarding banding, our experience is that RV is better than many apps at handling this. If you are seeing this, it's not OK and we should figure out what is happening.  It would be great to get a support ticket with an example image that shows the banding for you and some information on the OS, graphics card etc.  Depending on what features you are using there are some gotchas with particular graphics cards and some RV settings, one thing to test is to toggle the preference for 'use floating point LUTs' (if you are using a LUT). This feature is completely dependent on what graphics hardware you have and can make a huge difference).

  Cheers,

  Seth

• 0
  
  J Bills September 03, 2015 07:50

  thanks a bunch Seth!  glad I asked.  That LUT you sent should do the trick.

  I'll have a look at cinespace luts for anything I need in the future - good to know.

  I don't doubt that our 8 bit banding is a config related issue - I'll dig a little deeper and see if I can find the right combo, and will start with that pref you mentioned.  Will email and send screen caps if I can't figure it out, but it's probably something simple.  I do think we're using an sRGB lut if memory serves so it's probably just how that is being applied.  thanks a bunch as always!

• 0
  
  J Bills September 03, 2015 07:50

  re: the banding - it appears that it creeps in when we launch RV in 8 bit mode to view longer sequences with limited RAM.  in 8 bit mode the image bands.  This is with the menu option unchecked for Image > Color Resolution > Allow Floating Point.

  If I turn that "allow floating point" setting back on, the banding goes away...  but this begs the question, are the frames still held in 8 bit memory space with that option checked?  curious what that option does exactly and if it's the   'use floating point LUTs' setting you were talking about (which I don't see anywhere in my prefs).  I do see a "Floating point 3D luts" checkbox in the rendering tab...  is that what you were referring to?  because that doesn't seem to do anything in this case.

• 0
  
  Jim Hourihan September 03, 2015 07:50

  Hi J Bills, here's the skinny on floating point in RV:

  • When "allow floating point" is OFF, rv will convert to 8 or 16 bit int when it reads *any* file type (including EXR, float TIFF, etc). The file is left in its native colorspace. This can be bad for float data in a linear colorspace like EXR since it will both clamp and lose perceptual information because the values are not distributed in a way that's best for viewing. The advantage is that you get to put more images into memory. When float is allowed, images come in exactly as they are in the file -- no resampling is done at all.
  • When "Floating Point 3D LUTs" is ON, 3D (cube) LUTs are represented as floating point on the GPU. When its OFF they are converted to fixed point and sent to the card directly. In general, you should not need to have this OFF at this point: that option exists so that mobile ATI and some oldish NVIDIA cards which just can't handle floating point 3D LUTs will work. In addition, I've seen some MacBooks with ATI graphics in the them that do poorly either way -- the result is usually unexpected banding or posterization. However, the last machine I saw like that was from 2007-2008 era.
  • When in doubt, try the Pre-Cache LUT. This is just like the other LUTs in rv, except that its evaluated in software before the image is cached in memory.  
  • Make sure you use a LUT with a size that's a power-of-two. For 3D LUTs that means using a size of 8, 16, 32, 64, or 128 ^ 3. For channel LUTs (1D) use 512, 1024, 2048, or 4096 if you can. If you don't use a power-of-two, rv will resample your LUT which may introduce interpolation artifacts. This is most common issue we've found with LUTs acting in an unexpected manner

  To answer your question, "allow floating point" is clamping and reducing the color resolution of whatever file you're looking at to the point where you're just getting banding for that image -- I assume its an EXR or float TIFF or something similar. If you are loading a floating point image and that option is ON then rv is keeping the image float all the way to the card -- it only becomes lower precision when the pixels are placed in the output frame buffer.

      -Jim

• 0
  
  J Bills September 03, 2015 07:50

  thanks for the tips on luts and for clarifying the floating point pipeline - chaulk that one up to user error.  I had seen the -nofloat flag in use at another studio where I was working and always assumed that was the correct way to do it.  But I get ya, -nofloat is for processing only and has nothing to do with the amt of data being packed into RAM.  we'll happily remove that from our code and never use it again!  I don't even notice any speed difference in loading the frames -  but I get that it must just be in there if you're doing something heavy duty and want to save a little processing time.

• 0
  
  J Bills September 03, 2015 07:50

  had another questions related to luts that I should ask - when I try to use the composite operations in RV's stack mode to quick comp a CG render over a BG live action plate, I get pumped fringing on the edges of my CG, in the gray values of my alpha channel.  It's almost as if RV is somehow doubling the default sRGB LUT in the non-white areas of my FG alpha, or that there's some sort of premultiplication issue going on.

   

  yet my CG is premultiplied and when I do a simple over in Nuke, of course it looks great and absolutely no fringing.  I've been meaning to track down the cause of this for a while - any ideas what could be happening?  It happens when there's no LUT being applied whatsoever and a gamma of straight 1.0.  I can't think of what would cause this.  Is this expected? am I misinterpreting the use of the "over" operation?

• 0
  
  Jim Hourihan September 03, 2015 07:50

  It depends on your imagery, but my guess is you're running up against an issue with RV's architecture. Right now the comp is done in the view space -- which is actually not right. If you have a broad enough fringe, you'll see that the blending is being done in a non-linear space if you have sRGB view on. It needs to be done just before that. We have an overhaul of that part of the renderer in the pipe, but not until after the next version.  If you turn off the View transform (sRGB or gamma or Rec709, DLUT, etc) it should look similar to nuke's if it also has the viewing LUT off.

     -Jim

• 0
  
  Jonathan Berube September 03, 2015 07:50

  Good info! Here is an other question along the same lines. I use RV a lot for flipping EXRs on an srgb monitor display. DaVinci resolve can't seem to be able to display open exr frames as good as RV does. Is there any ways I can use the same lin to srgb lut RV uses in DaVinci resolve? On an Mac btw... Bests, -J
• 0
  
  Colin Davies September 03, 2015 07:50

  Any way I could get my hands on the example package for creating lin to log luts mentioned above? Thanks, Colin
• 0
  
  Alan Trombla September 03, 2015 07:50

  Hi Colin,

  Sorry for the slow response, missed those comments.

  @Jonathan:  glad RV is working well with you.  RV does the lin->sRGB display conversion in hardware on 32-bit float buffers using a shader that implements the exact sRGB transfer function, so I'm not sure how you could do the equivalent in Resolve.

  @Colin: yes sure, here is that package.

  Cheers,

  Alan