Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

LUTs, REDGamma LUTs, REDLogFilm LUTs,... free LUTs as far as the eye can see.

Gavin Greenwalt

Gavin Greenwalt

Well-known member
Joined
Dec 29, 2006
Messages
7,614
Reaction score
0
Points
36
Age
40
I've put together a set of conversion LUTs for converting between RG / RedGamma, RG2 / RedGamma 2, RG3 / REDGamma 3, RG4 / REDGamma4, RLF/ REDLogFilm and many of the industry standard luts. Oh yeah, and they're free. Unless you feel guilty/generous in which case feel free chip in for all of the work it took to make them.

NOTE: THESE ARE NOT OFFICIAL RED LUTS. THESE ARE ON AVERAGE .00001% WRONG. RED HAS NOT SANCTIONED THESE LUTs. That disclaimer out of the way, feel free to also shoot me an email if you find a mistake somewhere in here. I imagine I might have written over the wrong ones. Also if you want a higher precision LUT, let me know and I can send you the "HQ" pack. They're about 5x more bandwidth though and largely unnecessary.

http://indiecinerental.com/gammaluts.html


DISCLAIMER 2:

RedLogFilm and Cineon/LOG are exactly the same. If your app (Nuke, Fusion, Davinci etc) has a built in filter/node/effect for converting between Log and Linear or Log and sRGB etc use the native functions when possible do not use the RLF_2_Lin , Lin_2_RG or RLF_sRGB LUTs unless you have no native choice. The conversion from linear to Log (necessary for RedGamma) will be slower, less precise and generally worse than the mathematical cineon/log function built into the app and will introduce errors in overbrights. Some apps though I realize don't have any native log conversion so I included them for legacy purposes only. Always first and foremost use mathematical functions where possible.
 
Dude your killer bad ass
 
Awesome Gavin!!!
 
Mark L. Pederson said:
depends what you are doing - I like 64 or 65 x 3 LUTs if you are swinging the knobs hard - the future of color pipelines is high precision 3D LUTs.
Click to expand...


Yeah I'll be putting a 64x HQ version together tomorrow.
 
Mark L. Pederson said:
Good. They will fit in the high precision HD-SDI/HDMI 3D LUT side-car module I'm making for DSMC cameras :)
Click to expand...

Good to hear it supports full 64 sized LUTs some apps have odd constraints and limits hence the basic LQ ones to start with.

With an H264 IP Server? ;) Please.
 
nice,

Red should have made these widly available years ago.
But as they have not I think that Jarred should by these from you and put them on the red download page next to redcinexpro.

Good work, will send you a donation for effort.
 
If you email RED they'll send you the official curved for free. I am not sure what their rationalization is for keeping them available on a request only basis. I derived these though without using Graeme's curves using a script and hand fitting so they should give RED plausible deniability if I made a mistake and they somehow screw up someone's footage. :P That would be my guess for their reason to keep them secret.
 
Gavin Greenwalt said:
If you email RED they'll send you the official curved for free. I am not sure what their rationalization is for keeping them available on a request only basis.
Click to expand...

Whatever the rationalization - it's flawed. Like other camera manufacturers - RED should have 3D LUT transforms for their cameras available for download on their website yesterday. Period.

What happens in the real world is that some DIT "rolls their own" and gets it 90% correct - and does more harm than good. I have seen it many times.

RED not posting them for download does RED more harm than good. Rant over.

http://community.sony.com/t5/F5-F55/NEW-3D-LUT-s-for-F55-and-F65/td-p/135617
http://www.arri.com/camera/alexa/tools/lut_generator/
http://learn.usa.canon.com/resources/blogs/2012/eos_c300_luts.shtml
 
64x64x64 CUBEs added to site.

Do I need any higher fidelity LUTs?

EDIT:

Also just as a comment. RedLogFilm and Cineon/LOG are exactly the same. If your app (Nuke etc) has a built in filter/node/effect for converting between Log and Linear or Log and sRGB etc use that not the RLF_2_Lin or RLF_sRGB LUTs. The RLF luts will be slower, less precise and generally worse than the mathematical cineon/log function built into the app. Some apps though I realize don't have any native log conversion so I included them for legacy purposes only.
 
Jake Wilganowski said:
Can you apply these in camera?
Click to expand...

Well... yes and no. No you can't apply them in camera since RED doesn't support 3DLUTs yet. But yes you can apply all of them in camera. Just create a look in RCX and then assign the look to a preset that only affects the camera gamma. Then you can get linear and Rec709 (which you probably don't want). Obviously you can already get RLF, RG3 and RG4 in camera so there is no need for a LUT for those in-camera. These are all just conversion LUTs for post. So if you want to apply VFX in linear space and then apply RG4 you can do that as a final step while comping in Linear.
 
Gavin...very sweet thanks a bunch...was just about to shoot some charts to attempt to do this when I found this thread.

One note....I was testing these in Fusion comparing linear footage with your LUT's to footage brought in with various gamma settings using difference....and they are very precise.

But I did run into quite a few HDRX files that on track 1 the LUT's were up to a 17% difference in the brights.....track 2 is always spot on.
Not sure what is going on here...but I have checked 4 or 5 HDRX shots...and track 1 is always off. And this is using the 64 cubes and forcing fusion into 32bit float...Just FYI.

All the other ones work like a charm, and are very precise.....something funny going on with the HDRX, at least with the footage I have on hand. It may have just been a glitch on that specific firmware, but it sure seems like track 1 gamma is slightly different.
Either that or something is off in Fusion land with HDRX....

Thanks again.
 
Just importing it into fusion.....native r3d. Set import options to linear. Run a file LUT node, apply your LUT. Import same footage again, set import to chosen gamma (same as LUT) and pipe together into a merge node set to difference.

All the LUTs and files I tested were very accurate....usually way less then 1% difference.
HDRX track 1 (fusion calls them 1 and 2) always was quite different in the brights. Track 2 (x track) was always perfect.


It may very well be a fusion issue.
 
You must log in or register to reply here.
Back
Top