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 :)

ReLogFilm and Nuke

L

Luke Mason

Active member
Joined
Apr 25, 2014
Messages
25
Reaction score
0
Points
0
Location
Toronto
We have a DPX sequence with RedLogFilm gamma and DRAGONColor, what's the correct way of working with this footage in Nuke? The goal is to keep the gamma and colour unchanged so we can do colour grading after VFX is done.

Should we use log2lin node or just change the colourspace in the read node?

thanks a lot!
 
I am no nuke expert, but i know it is always better to work or make changes, on a node per node basis. Kind of an underlying principle for any node based software. (like Resolve too)

So, i do guess converting to linear space using a node should be better than doing it inside the read node...
 
Another option could be to do to do the conforming/converting in Resolve or any other equiv; thereby having better control and roundtrip, because you come into Nuke with the files in lin space already.
Just a thought, you should try.
 
Treat the dpx sequence like they were film scans in Nuke. Whatever settings you would use for film, would work with RLF dpx files.
 
why not do a log2lin and/or a grade node to what you think the final will look like and just disable those for the render?
 
paulherrin said:
why not do a log2lin and/or a grade node to what you think the final will look like and just disable those for the render?
Click to expand...

When using log2lin the viewport looks very dark (although it's hows sRGB viewing gamma)
 
The correct way is as follows. DONT TURN OFF YOUR VIEWER LUT.

Add Read Node.
Set Read colorspace to "Cineon".
Comp as normal.
Add Write Node. Write DPX with colorspace set to "Cineon".

Alternately you can check "raw" or set the colorspace to "linear" and apply a Log2Lin node (Default settings are correct for RLF). If the image is too dark then that's how you exported it. Apply a multiply node after the Log2Lin or Read Node. If you want it exactly the same as the read node then apply an inverse multiply right before the write node. E.g. Read (Cineon) -> Multiply (2.0) -> [COMP] -> Multiply (1/2.0) -> Write (Cineon).

There is an optional step too. You can also apply a 3D LUT as the second to last step and use one of my LUTs such as Linear2RG3 and then output RG3 if someone wants that. In that case you would need to apply a colorspace node with a sRGB -> Linear operation after the 3DLUT.
http://indiecinerental.com/gammaluts.html

I 100% guarantee that, that is the correct workflow.

Peter Majtan said:
Luke - any reason why you don't work directly with the RED RAW data? You will simplify your workflow and increase the quality of the final output, never mind saving you storage (both capacity and bandwidth)...

:sifone: Peter
Click to expand...

Because it can be slow to decode REDCode, some nodes get angry at oddity of a read node taking forever (particularly optical flow nodes). Also some nodes such as Frame Average want to read multiple frames so every Nuke frame has to render like 3 6k frames which then caches poorly. DPX and EXR have all of the kinks worked out and don't rely on a third party SDK which changes frequently introducing new possible bugs. Another problem is a compositor changing a setting. However one nice thing about REDCode in Nuke is that you can decode a custom setting.
 
Gavin Greenwalt said:
The correct way is as follows. DONT TURN OFF YOUR VIEWER LUT.

Add Read Node.
Set Read colorspace to "Cineon".
Comp as normal.
Add Write Node. Write DPX with colorspace set to "Cineon".

Alternately you can check "raw" or set the colorspace to "linear" and apply a Log2Lin node (Default settings are correct for RLF). If the image is too dark then that's how you exported it. Apply a multiply node after the Log2Lin or Read Node. If you want it exactly the same as the read node then apply an inverse multiply right before the write node. E.g. Read (Cineon) -> Multiply (2.0) -> [COMP] -> Multiply (1/2.0) -> Write (Cineon).

There is an optional step too. You can also apply a 3D LUT as the second to last step and use one of my LUTs such as Linear2RG3 and then output RG3 if someone wants that. In that case you would need to apply a colorspace node with a sRGB -> Linear operation after the 3DLUT.
http://indiecinerental.com/gammaluts.html

I 100% guarantee that, that is the correct workflow.



Because it can be slow to decode REDCode, some nodes get angry at oddity of a read node taking forever (particularly optical flow nodes). Also some nodes such as Frame Average want to read multiple frames so every Nuke frame has to render like 3 6k frames which then caches poorly. DPX and EXR have all of the kinks worked out and don't rely on a third party SDK which changes frequently introducing new possible bugs. Another problem is a compositor changing a setting. However one nice thing about REDCode in Nuke is that you can decode a custom setting.
Click to expand...

Thanks a lot, you're my hero :)
 
You must log in or register to reply here.
Back
Top