Welcome to our community

Be a part of something great, join today!

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

RED LOG export for grading

F

Filipo

Banned
Joined
May 22, 2008
Messages
126
Reaction score
0
Points
0
Age
37
Hello,
I need to render a 30 min RED shot movie as 10bit LOG dpx files,
so they can be used in grading on Baselight or Lustre (it will be determined in the next few days). Unfortunately their systems don't have RED RAW upgrade yet. I was told to export 10bit DPX log, so they can use their custom 3dLUT for KODAK 2383, profiled for their projector.
Since this LUT was made for film scans, and not red,
it is little bit difficult to match the red render to film scan in log space.

I have seen in this forum various option people use,
but should I render in REDLOG or PDLOG985 with some exposure and saturation corrections, like Autodesk workflow says ?

thank you

Filipo
 
In my experience, taking the Autodesk approach, and rendering PDLog985 with exposure set down 2 stops works well in BaseLight, and appears the way a colourist would expect a film scan to do.

But as always, test your workflow with the facility you are using, and also talk to the colourist about whether they want the DPXs 'flat' ie with no meta-data applied, or with basic settings like white balance already done.
 
Nick Shaw said:
In my experience, taking the Autodesk approach, and rendering PDLog985 with exposure set down 2 stops works well in BaseLight, and appears the way a colourist would expect a film scan to do.

But as always, test your workflow with the facility you are using, and also talk to the colourist about whether they want the DPXs 'flat' ie with no meta-data applied, or with basic settings like white balance already done.
Click to expand...

Actually according to Filmlight, they do not recommend using PDLog985. Instead, they prefer RedLog. But at the end, nothing replaces good old fashion testing:wink:
 
Baselight does support R3D directly in the latest builds. You need a 16 core machine for 2K playback, but maybe 1K would be ok for you.

You also might consider a linear light workflow:

Render into 16bitTIFFlinear, using cameraRGB as color space and linear as gamma space. DO NOT alter the image in any way in RL, do not add a color matrix, DO NOT push iso. Leave all at default.

Don't freak out, when the pictures appear dark, apply a rec709 gamma curve onto the picture in the grading suite, to have a good grading starting point, or create your own.
Your colorist must understand that the is dealing with linear data. I also would NOT recommend pdlog985. This was designed for film workflow and while the adobe recommendation works, the linear-tiff did work more foolproof for me.

Compared to DPX, you have ABSOLUTELY every information from the sensor in the TIFFs, but you pay it with bandwidth.
Before I get trashed about how little you loose in the DPX conversion, when done right, I say... yes WHEN done right.

I prefer to have all options open in the grading, rather to fear, that I might go back to R3D->DPX, because I accidentally DID crop that half stop of highlight.
 
Jonas said:
Baselight does support R3D directly in the latest builds. You need a 16 core machine for 2K playback, but maybe 1K would be ok for you.

You also might consider a linear light workflow:

Render into 16bitTIFFlinear, using cameraRGB as color space and linear as gamma space. DO NOT alter the image in any way in RL, do not add a color matrix, DO NOT push iso. Leave all at default.

Don't freak out, when the pictures appear dark, apply a rec709 gamma curve onto the picture in the grading suite, to have a good grading starting point, or create your own.
Your colorist must understand that the is dealing with linear data. I also would NOT recommend pdlog985. This was designed for film workflow and while the adobe recommendation works, the linear-tiff did work more foolproof for me.

Compared to DPX, you have ABSOLUTELY every information from the sensor in the TIFFs, but you pay it with bandwidth.
Before I get trashed about how little you loose in the DPX conversion, when done right, I say... yes WHEN done right.

I prefer to have all options open in the grading, rather to fear, that I might go back to R3D->DPX, because I accidentally DID crop that half stop of highlight.
Click to expand...
16 bit TIFF is an overkill, but the biggest reason why 10 bit LOG DPX are used instead, beside huge savings in storage space and performance hit is TIFFs don't support time code, which makes it pretty useless for any kind of DI pipeline. And yes, you do need to know how to transcode it correctly into LOG DPX and that is why I wouldn't recommend it doing it at home on computer monitor. And yes, BS does support r3d natively in version 4.3, but for any kind of DI pipeline with CGI you are right back in the DPX camp:smilewinkgrin:
 
jake blackstone said:
Actually according to Filmlight, they do not recommend using PDLog985. Instead, they prefer RedLog. But at the end, nothing replaces good old fashion testing:wink:
Click to expand...

Absolutely - test, test test!

Baselight's Red Workflow guide says:

If you plan to treat the material as log (for example, if it is going to be transferred back to film) then REDLog would probably be a better choice
Click to expand...

…not the use of the word "probably":wink:
 
ok... I need some explanations please...
first of all raw is lin or log?
what's the best settings to make a log-to-lin LUT if I went for Redlog dpx 10bit?
and for PDlog 985?
What's the differnce actually between redlog and pdlog985?
why RED doesn't give the right values for a redlog LUT in every compositing and color correction applications?
Thank you very much
 
Marco Graziaplena said:
ok... I need some explanations please...
first of all raw is lin or log?
what's the best settings to make a log-to-lin LUT if I went for Redlog dpx 10bit?
and for PDlog 985?
What's the differnce actually between redlog and pdlog985?
why RED doesn't give the right values for a redlog LUT in every compositing and color correction applications?
Thank you very much
Click to expand...

Marco... this is the Log DPX complaining thread...

http://www.reduser.net/forum/showthread.php?t=31727

Please do post your rant...
 
Thank You all very much for help.
We went with CAMERA RGB/RED LOG rendering.
Filipo
 
REDLOG TIF

REDLOG TIF

I have been using R3D to REDLOG TIF without correction in REDCINE.

My system does not need timecode from the R3D so TIF work in my DI workflow, the new shot "SMPTE" starts with 01:00:00:00 for the slate on each shot.

The TIF are graded for video gamma so they look much the same on any "uncalabrated" system or TV etc.

The graded TIF are then formatted (additions in development) for my film recorder software which is calabrated for 2383 to show on film the images much as they look on the monitor.

Film will never look the same as a monitor since one is addative and the other subtractive, there are some colors that can never match, the LUT can only restrict the gambit to those that are close.

My goal though is to try to have the shadow and highlight detail match, and my "gamma spread" feature does that expanding the tonal range you can get off the film recorder monitor in one pass by making more than one pass. The film sums the brighness from each pass to build up deeper blacks and more subtle highlights.
 
You must log in or register to reply here.
Back
Top