FCP-->Crimson-->Color-->FCP

[Rick Darge]

I used to cut in FCP/Crimson and grade in Redcine. I'm now trying a different approach and am liking what I'm seeing..

Cut in FCP using the M files or a 720p downrez, send XML to Crimson, match clips, Render out Full quality 2k DPX files via Redline, import into Color, grade, export ProResHQ 2k files, conform in Crimson, output via FCP

How many other peeps are doing this?

 

[Gunleik Groven]

To put it mildly, this is a better workflow...

It's also quite important how you treat the RAW files in RC prior to exporting the DPXs...

 

[BigLu]

I did excatly what you did.
First i used to go FCP - Crimson then Redcine back to FCP and then to Color.
But I am now going FCP using the H Proxy then to Crimson via XML which give me problems matching clips. Then render out a full quality ProResHQ go to FCP then into Color grade it and then im back into FCP for any last touches.

I like the idea of 2k DPX files via Redline im going to try that tomorrow.
Thanks for sharing that RGD
gave me hope.

 

[Rick Darge]

Gunleik, can you enlighten me? Right now I'm using Redline for my DPX renders. If I sent the clips to RC beforehand, I probably would just touch the white balance and the sharpness. All of my curves and secondaries would be handled in color.

Is there a way to force color to name your rendered clips to match the input name? Crimson doesn't know what to do with Color's simple naming structure.

It's not so much an issue since I can export my color sequence to FCP, and as long as I imported the DPX files in the correct order, FCP should match it on the import.

 

[Rick Darge]

Also, RC before Color would be a good place to make all ASA adjustments as well I imagine..

 

[buneba]

I used to cut in FCP/Crimson and grade in Redcine. I'm now trying a different approach and am liking what I'm seeing..

Cut in FCP using the M files or a 720p downrez, send XML to Crimson, match clips, Render out Full quality 2k DPX files via Redline, import into Color, grade, export ProResHQ 2k files, conform in Crimson, output via FCP

How many other peeps are doing this?

this workflow work fine but exporting in ProRes is not as good as in unccomprest 10 bit 720p

 

[Gunleik Groven]

White balance is actually quite often the least important problem (depending on how you shot)

it doesn't really matter whether you use RL/RA or RC, but if you're not totally comfortable with what you do when you set up your clips in Crimson, RC is still the way to go. It is also a good place to get rid of noise.

I'll come back to this post later

 

[Brandon Kraemer]

Similar Workflow

Similar Workflow

I used to cut in FCP/Crimson and grade in Redcine. I'm now trying a different approach and am liking what I'm seeing..

Cut in FCP using the M files or a 720p downrez, send XML to Crimson, match clips, Render out Full quality 2k DPX files via Redline, import into Color, grade, export ProResHQ 2k files, conform in Crimson, output via FCP

How many other peeps are doing this?

I work in a similar way. FCP -> Crimson -> Redcine (one-light, color space and gamma correction) -> DPX file sequence out -> Color or Shake or AfterEffects -> FCP.:matrix:

 

[Rick Darge]

White balance is actually quite often the least important problem (depending on how you shot)

it doesn't really matter whether you use RL/RA or RC, but if you're not totally comfortable with what you do when you set up your clips in Crimson, RC is still the way to go. It is also a good place to get rid of noise.

I'll come back to this post later

I'm interested in hearing more of your thoughts on this subject. Right now I am using RC to do a light color correct, protect my highlights, bring up my black levels just a tad to make the image as flat as possible. I then add sharpness when necessary. I'm outputting the DPX files now and will take them into Color to do a deeper grade.

Gunleik, what is the most important reason to use RC in your op?

 

[Gunleik Groven]

The most frequent question I get in pm's, is about noise. "How do you get those low, noise, low light images??? Please give me the secret sauce!!"

(And this is pre and post build 16...)

The answer is quite easily: Look at the camera specs, and stay true to them.

The fun thing (for me) about these questions is that I for one, don't really mind noise... It's just good to know how to get rid of it when you need too...

So... When will I use RC?

Too much - I am afraid - is my answer, as the rendering engine of that buggy app really sucks!

BUT
It's a usefull little tool, when it doesn't explode in your face. (more so when we are again allowed to choose which format we want to export to, but that is a sidenote...)

The cam is 320/5600k in daylight.
More like 160/5600k in tungsten (yeah. Hate me for that statement, but I have had a multitude of experiensed DPs using lightmeters to doublecheck the RED meters when we shoot, and that is generally a good pointer IMHO)

So. How to, what to?
(I am sorry if this post seems OT, but it's an honest attempt to answer your "When to RC question. Really!!!)

The thing is (or rather: I find them to be) if you take these rather public parameters into consideration from shoot to post, you can get really noisefree and high dynamic images out of the RED ONE.

IF, on the other hand, you choose to make your images to look good on set and you expose with the auto or preset whiteballances in cam (exept for 5600k/320ASA) you're in for a tough ride...

And that is still very true with all the new buil16 wizzardery. Actually I think I'd like to get a way to work around some of that wizz stuff, but that's for later...

Do this little test:
@ night/late evening: Set your cam to 320 ISO 5600K and use the (full) waveform as an exposure meter. Expose "to the right" as far as you get. Shoot.

THEN push the auto wb, or set your cam to tungsten.
Look at the waveform and expose accordingly....

You'll have some fun in post recovering that last shot.
I could most definitely NOT help you out. But the cam will (still in B16) tell you: Everything is fine...

In other words: When you shoot: Keep in mind that your sensor is always the same, even when you change your lights.

NOW, post.

Post on RED (even with Scratch @ your service) has two stages (to keep things simple).

1. The developing stage
2. The CC stage

In other words: You have three very separate processes that make your image:

Exposure
Developing
CC

It's easy, right?

The thing with film, is that the photographers are used to expose according to their stock. The thing with video is that photographers are used to expose and tweek as close to a finished result as possible.

The thing with RED is that even though it technically IS a videocamera, photographers should treat it like film.

Then the post people should first be content with doing a nice conform/one-light that may look like... how to say it? Crap! There is still 4 time as much luma and chroma data in the 12 bit file as a 4:2:2 10 bit file. Most likely it is more similar to a 4:4:4 data amount (@ 10 bit) than a 4:2:2. But that's for others to discuss..

Generally spoken:
When everything is shot at or close to the sensor specs, you can use RA/RL for a general development of the files. Just remember the -0.4 exposure parameter to recover what may be lost in the top, and you're fine. (RedSpace is a nice way for you to take this into consideration...)

NOW for the more problematic shots. That's where RC is your (not very friendly) friend. (because RC is crippled beyond stupidity. And I am NOT talking about external monitoring options...)

Let's say - for arguments sake - that RC equals the scan and one-light in a film workflow. Just for arguments sake (and so could RA/RL for most tasks, but RC has some advantages when coupled with Crimson and FCP)

What do you want to get out of that process?

In my case, the answer is: As much info/data to CC as possible...

Let's say you agree with me...
Sorta: Just for fun, and for arguments sake.
What would you do?

I find RedLog to be a good startingpoint (even with B16)
And then I basically care for that none of the channels are blown (if that's what I want. That is, if I am looking for an image to pass the CM.com viewers...)

Sometimes I WILL have to do some WB stuff. Basically keeping things within "not blown" range. Then I'll try to NOT use the temperature to make those adjustments.

What is the fun thing about LOG and why are bits important?

problem is, I don't generally look for a low contrast image... I more often look for an image that uses most of the spectrum, without applying the lower three bits.

Why?
Because how you perceive DR has a lot to do with precission, and precission in the lower 3 bits (even in the 3rd) is rather low.

If I manage to spread my (problematic) image over most of the histogram AND manage to stay out of the lower 3 bits, my image WILL look milky and low contrast on an 8-bit monitor, but that doesn't make that a true assesment. Is just true for what you see. Not for the data in the container.

SO I use RC (and RA/RL) to pack the most of the data into a higher precission area. That's it. The rest is for CC apps.

RC is cool for its quick response when changing parameters...

And in a low-light/tungsten shot I'd most likely lower the asa (towards 160...) and compensate with brightness/contrast and curves untill I could see from the histogram that I have most data whithin reach.

THEN I may do some WB adjustement, but again: Not really to make the whites white, but more to make the whites adjustable.

Then I'd output 10bit LOG DPXs or AJA files for the rest of the process.

But That's just me...

As to build 16, the previews are just gamma changes, and RedSpace just pushes the preview "up" and "down" (aplies a sexy S curve...) when you're on set and thus protects the highlights AND lowlights for videodudes.

But my guess is that most of the wizz stuff happens when the new files hit POST, and I sure would like a way to controll them or turn them off... But again, I'm still chopping my trees on thatone.

I know I am way off general wisdom here, but these are things I do...

G

 

[Steve Sherrick]

This is a great discussion.

I've been wanting to test with 2K DPX, but I'm still awaiting a high end RAID solution. I should have by next week and will put a lot of this type of workflow to the test. Up until now I have been doing a lot of ProRes or when I do Uncompressed I'm having to scrub through.

I agree with a lot of what Gunleik is saying. Noise will emerge if you don't respect the specs of the sensor.

 

[Rick Darge]

Thanks a lot Gunleik, That really helps me..

There seems to be some discussion about Rec709 DPX files VS. Redlog DPX files. Graeme said it doesn't really matter what you choose but I've heard from you and others that you want to go log with DPX because you will be throwing away info..

 

[Gunleik Groven]

I think that discussion is about 16 bit LIN TIFFs...