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

Best REDrushes output to use in DI?

J

Jon Schwartz

New member
Joined
Feb 2, 2009
Messages
3
Reaction score
0
Points
0
I'm finishing a no-budget short film that we shot on a borrowed RED camera. To conform the film, I was planning on converting all of our dailies to 4K DPX files through REDrushes, conforming the film in After Effects CS3, outputting to 2K DPX, and then shipping the 2K conform off to a colorist who is donating his time.

I'm conforming in After Effects because it's free and because there are a number of simple pushes, zooms, etc., to execute.

My question is: what Color Space and Gamma Space settings should I use in REDrushes? I want the highest-quality logarithmic DPX files REDrushes can make. Are these the correct settings to go with:

Look Source: Camera
Color Space: REDspace
Gamma Space: REDlog

Or different settings?

And what's the "PDlog 685" setting in Color Space?

Thanks so much for any advice!

Jon
 
RED is 12 bit linear.

I therefore suggest the following "digital intermediate"

16bit TIFF, Cameraspace: CameraRGB, Gamma space: linear

Huge files, but everything from the sensor is preserved.
Create a neutral RSX file, in RED alert, by reseting all settings and use it in redrushes or redline. Do not touch the iso. As you do not go to log, no DPX, no conversion of anything.

The colorist can put a rec709 curve on the files, and start grading. His system need to be able to playback the tiffs though.
I would not try linear DPX, as this is a mess and not reliable.
 
What if log DPX files are required?

What if log DPX files are required?

Jonas,

Thank you for your clear, cogent response.

I'm afraid that the colorist who's doing us a favor requires that we deliver the show as a log DPX sequence. Since I'll be conforming in After Effects, I can export from REDrushes as 16bit linear TIFF, then do the conversion to log DPX in After Effects. Do you think that's the best plan?

If I had to export from REDrushes directly to log DPX, what settings would I want?

Thanks!

Jon
 
One more question...

One more question...

Jonas,

Also, it appears that I can use REDAlert to generate an RLX file (using the Save Preset option in the File menu), but I can't seem to make a RSX file. What am I missing?

Again, thanks so much for the helpful advice! Your trailer for "Carved" look incredible!

Thanks,
Jon
 
The .RSX is generated automatically every time you grade in RA and put in the folder of the clip.
 
Yeah, that is a bit tricky with the RSX.

You open a shot in RA, and reset all settings.
RA will generate a RSX file in the same folder as the shot.
It is NOT what you can "save as" within the app.
Take this file, copy it elsewhere, and rename it e.g. to linear.rsx .

What grading solution is the colorist using? Maybe R3D support is around the corner.
It really is as simple as putting a rec709 gamma on the linear files, and start rollin'. Maybe if you tell him, that the dpx will force you to pre-grade and that he will not have 100% control over the colors?
Or how a bout a little slap on the a$$, so that he opens his mind to new workflows? - that worked for our baselight colorists...

Going log from a lin medium really does not make any sense and introduces a lot of room for errors. Therefore, try to avoid it, if its not necessary.
 
DPX doesn't really force you to "pre-grade" - the best bet, a route we've followed for a bunch of projects with DPX finish, (assuming that your colourist is happy with this - ours always have been) is to output a redlog DPX stack and give these to the colourist.

Personally, I would conform via Crimson from an FCP XML and then output your DPX stack via RedCine from that pull list - but I'm sure there are other ways...

This will preserve the full information that is (was) captured by the sensor, without any grading decisions having been made before the footage gets to the colourist.
 
That is not true.

DPX in redlog forces you to make choices on what information from the 12 bit linear you put into the 10bit log format.

The difference is small, but this conversion is destructive. It may not matter, when you have all perfectly exposed material. But once you start to push to limits, you will have a lower headroom.

In a redlog/redspace/pdlog(corrected) DPX and TIFF comparison, I found that the 16bit linear TIFF from the RED ONE has more info for grading in it, than a 10bit log DPX.
 
Jonas said:
RED is 12 bit linear.

I therefore suggest the following "digital intermediate"

16bit TIFF, Cameraspace: CameraRGB, Gamma space: linear

Huge files, but everything from the sensor is preserved.
Create a neutral RSX file, in RED alert, by reseting all settings and use it in redrushes or redline. Do not touch the iso. As you do not go to log, no DPX, no conversion of anything.

The colorist can put a rec709 curve on the files, and start grading. His system need to be able to playback the tiffs though.
I would not try linear DPX, as this is a mess and not reliable.
Click to expand...


Tiffs are ok if you do not need timecode, otherwise you have to count frames or play with the file header to get the timecod metadata in.
 
You also can use filetimecode, when using the -V settings in redline.
Baselight conforms splendid that way.
All you need to know is the framerate you shot in.

Frame Settings:
-s or --start <int> : start frame
-e or --end <int> : end frame
-S or --startTC <timecode> : start TC as "00:01:00:00"
-E or --endTC <timecode> : end TC "00:01:00:00"
--useEC : use EdgeCode instead of TimeOfDay/EXT TC
-V or --renum <int> : new start frame number or -1 for timecode as frame count from 00:00:00:00
i.e. 00:00:02:00 = frame 48 @ 24fps
Click to expand...
 
hey there,

i will quickly hijack this thread if that is OK, as it is a similar question I am asking....

Had to go to FCP as I had major issues with avid Media Composer... now we have cut Proxy files in FCP and need to get them to our colourist, who is working wth Bselight.

The colourist says he prefers DPX sequence, as they bring it into their system as DPX sequence HD 1080 25p. They also need the EDL and the footage. They could of course handle the TIFF sequence too (which I understand gives more headroom for grading?)

We shot it in 4K and 3K (for slow motion stuff).I was going to try and see to get the DPX sequence in 3K happening - re-sizing the 4K files to that same size... (don't even know where i would do this bit?)

OK, so how do I best go from these low quality proxy files, to either DPX or TIFF sequence that is good for grading. I want it provide the best option for the easiest grade and most headroom.

I do not own any of this other software and will need to buy it, so if you recommend something, can you please do so from personal experience so that I know it will work - as I wasted days on trying to do this in Avid only to realise it is not yet fully functional.

cheers from Oz

Ps. My understanding was to cut proxies in FCP, buy Crimson and use it to get the FCP XML into REDCINE (not sure if this is what Crimson does?) and whilst in REDCINE, size all shots to 3K and export as either DPX sequence or 16bit TIFF sequence? Am I even close with this work flow?
 
Lin vs. Log

Lin vs. Log

Jonas makes some good points here and on a mathematical scale, this information is correct. However, if you look at the issue from the perspective of the human eye, you will find that they eye responds better to a logarithmic display of information rather than a linear display. For example, if you flash between the values of 1, 2 & 3, the human eye will detect a difference in the shadows. If you look at the values of 997, 998 and 999, you will not detect a difference. Hence the way in which logarithmic values are mapped to the curve. The result with logarithmic is a greater "perceptive" range in the image -both to the human eye and to a computer. Even to a computer, 10bit logarithmic values offer greater perceptive rage because of the way in which we ultimately view images. In addition, in order for a linear image to equal the advantages of logarithmic, the bit depth would probably have to be over 13bits. -Taking into account the amount of math required to process that data and you would be asking for 50% more work from your CPU and only a slight overall image improvement.
In all, the Lin v Log and 10 v 12 is a good question and should be up for discussion. My advice from this thread is to consider 10bit RedLog DPX frames as great way to go. It's faster, offers more visible range, is more compatible with other systems and contains timecode metadata in the file header. This is why most studios handle Red features this way, even when dealing in 4K. Spending more time in the DI will improve the image far more than spending time rendering 12bit linear files.
Jonas is right in suggesting there is an image difference from Lin to Log, but most colorists and color correction tools likely won't be affected by the difference. Our DI team runs frequent tests on Linear vs. Log and even though the specs tell us there is more with Linear TIFF files, our artists simply can't find an advantage to them-even after film out evaluation. This is really good news for anyone using off-the-shelf tools.
 
Mike -

The most concise explanation on the subject matter I have seen on the forums. Thanks for sharing your thoughts. Much appreciated.
 
The point about the eye's perception relative to highs/lows is fine as far as it goes. But I understood Jonas' point to be: make sure you are guarding the information in the highs for clipping. Once you cut that info off it's gone, and the colorist cannot get it back from what you handed him.

Of course, if you are outputting a log from REDcine/alert you could just make sure that the info you are baking in and sending him contains no clipping (reduce iso, adjust curve, etc.).
 
Log v Lin - Highlight Protection in Post

Log v Lin - Highlight Protection in Post

Good point, Chris. Guarding the information especially in the highlights is a must when debayering and/or transcoding.
One helpful hint when considering highlights during a debayer to various gamma spaces is to note is that Red (the company) has already insured that there is no clipping when processing R3Ds in RedLog space. In other words, the gamma curve that Red automatically builds in their tools (same rule applys to 3rd party tools that properly follow the SDK) will not negatively affect the exposure index. This is another reason why working in RedLog is often preferable to Linear Light.

Here is an example to demonstrate this from the recently shot Producer's Guild of America Camera Assessment Test (CAS).

Still #1 shows the characteristics of the image in LinearLight. This is the control.
Note: The histogram shows no clipping. The CURVE is disabled. This is an unprocessed LinearLight image.

Still #2 shows the characteristics of the same image in RedLog.
Note: This histogram also shows there is no clipping. The CURVE is disabled. This is an unprocessed RedLog image.

Still #3 shows the characteristics of the LinearLight image with a CURVE.
Note: By adjusting the LinearLight CURVE to match a logarithmic one you can essentially replicate what RedLog is actually doing to an image. This replication shows how you can trust a Linear R3D file to be converted to Log without losing any of the range of the source 16bit Linear image.
 
@Michael
My argument for 16bit linear TIFFS with filetimecode as the ultimate digital intermediate may also be valid from the point, that it reduces the room for error, while preserving all sensor data.

All you have to do, is to reset all settings in redalert, CameraRGB and linear, and take that rsx and use it for your redline outputs.

Once you found your redline settings, you can leave it to any assistant, being sure that it is done the same way every time.
People tend to get confused between linear/video/log, they use all sorts of wild LUTS, and you end up with one big mess.

Of course, if you know what you are doing, go DPX.

For me, its maybe also a psychological effect. What if the colorists wants to go berserk, and misses that quarter stop somewhere in the shadows?
I certainly do not want to be the guy telling him, we have to recreate the DPX, or god forbid do a dual pass from the R3D's ....(yeah, I have seen THAT !!!)

We had a client who wanted to grade an hour after he finished editing, but luckily in PAL. So we rendered everything into TIFFS and conformed that in BL in the time where he was driving from the editor to us.
I knew the colorist would have all the info he needed, if anything would happen. There was no room for redoing anything.

@Lav Bodnaruk
I would go the 1080p 16bit TIFF (filetimecode) route, nevertheless. BL conforms great from that.

Maybe you should get monkey extract, which renders out from EDLs. Render the sequences with 20frames handles. Render each sequence into separate directories.

The colorist shall let BL interpret the footage as "video", not linear. That way, you start off with a rec709 curve, and the colorist has a good starting point, and is not scared to death by the (wonderful, but) ugly linear tiffs.
 
You must log in or register to reply here.
Back
Top