Beta memo: at this time the forums and insider use two different registration and login systems. We're working on unifying the process, so if you register with your same e-mail on the forums and insider we'll merge your accounts later. To access the forums please use the login below. -Thanks.
Results 1 to 2 of 2
31st March 2012, 14:44 #1Member
- Join Date
- Mar 2012
Scratch and Nuke linear EXR workflow
Im trying to figure out a correct linear openEXR workflow with nuke (and at times AE) using Assimilate Scratch as the \"hub\".
This is what the ideal workflow would look like:
1. Shoot on Red Epic
2. Import .r3d files in Scratch and transcode to openEXR for compositing
3. Comp in Nuke and send final shots back to scratch as openEXR.
4. Output from scratch as sRGB for web (and at times as Rec 709 for HD)
The trouble i am having is keeping the colors and the look consistent throughout this pipeline, and also making sure i dont anything stupid to the data along the way. When setting the RED metadata to redgamma2 before transcoding to EXR in scratch the EXRs in nuke need to be interpreted as sRGB in the read node to look (somewhat) the same as they did with redgamma2 in scratch. As i understand it they should be interpreted as linear in nuke? (im the sRGB viewing LUT in nuke as well)
If i set the red gamma to linear in scratch and then transcode to EXR files i can interpret them as linear in nuke and it looks fine. But when im writing out new (comped) EXR files from nuke and bring them back into scratch i cant find a way to set them as sRGB before i output my final file. The only thing i can find is changing the input remapping to rec 709, or \"squared\" which the scratch manual sais is \"useful for Linear Light material, such as R3D files, to set the proper gain for a normal monitor gamma range.\"
I also found there was some way to use RedLog in scratch and then use the LogtoLin node in Nuke. The problem here is that when i get the rendered EXRs back into scratch from nuke i am having the same problem as before.
Is there some crucial step that i am missing or something that needs to be done in another way?
15th April 2012, 17:40 #2Member
- Join Date
- Apr 2012
You opening you shots in Assimilate Scratch and converting the log-files from RED to linear colorspace using RedGamma LUT (witch is the gamma-correction curve). In result you have a linear data in EXR sequence. Scratch in this process is a converter of formats and colorspaces. So, when you open this EXR sequence in Nuke you will automatically read the linearized color information and the colorspace in Read node must be Linear (default). If you have different colorspace in Read node that\'s mean you made error in some process in Scratch.
By the way, as you have a logarithmic color from RED source and if you understand that you colorscape in EXR is Linear but the setting of colorspace in Read node is non-Linear (sRGB for example), DON\'T CHANGE the colorspace mode in Read node. This will clamp your color information! This is important for compositing. To change the colorspace use the Colorspace node.
And I think that the solution for you is to work with native colorspace from RED in any software you need. Don\'t change the colorspace during converting in Scratch. Use the LUT-files for viewing the color correct in any compositing App. When you working with REDgamma open your EXR in REDgamma and apply the LUT to work in normalized and linear colors in Nuke. After comp do the same operation to convert the linear color into REDgamma and write the REDgamma sequence to composed EXR. After you can open you result EXR in Scratch as it must be - same the source color. In Scratch to view and render for sRGB or rec709 you will apply the REDgamma fuction to linearize the result again. In comp process you hadn\'t changed the color, so you will have the same color and log-data as source shots from RED. This is my pipeline for working with RED sources.