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

Im Confused : FCP +Crimson+ Redcine = DPX & Scratch?

T

Tv_Red

Member
Joined
Feb 15, 2008
Messages
9
Reaction score
0
Points
0
Im Confused : FCP +Crimson+ Redcine = DPX & Scratch?

I just edited my first Red feature, cut in FCP and the editing side went pretty well. We decided to take it to a scratch house and do the workflow that i thought would work best. FCP XML to Scratch to Color & Conform, right? I know the crimson workflow, but i could of done that my self, i figured taking it to a scratch house would be a better idea.

So i go into the first color grading session just to check it out and find out that this is the workflow that they did.....with... Redcine and Crimson and DPX......why? I seem to not get a straight answer from there so i am curious to what you guys think.

I browse on here and see that other people suggest my initial idea and work with that workflow, ive also seen demonstrations and videos of Scratch working in this way.

So now we are about to conform and we ran into some snags. The major one being that the shots that i pushed in on now look not as good quality as it did in FCP or the Reference video or on the review DVDs. (quicknote shot 4k 1:85/ Mastering in 1080P) I asked how they did it and this is how; RedCine 4k shot zoom in to the 1080P frame and export out as a DPX then brought into scratch. Again why? Im an editor so i don't work with DPX every day but because of how they zoomed in and rendered out to DPX then colored....... would you be losing some quality instead of taking the R3D file straight to scratch, apply color and pan & scan then rendered it, right?

Also im now worried because they are conforming in FCP instead of scratch which im pretty confused about but im worried because they are taking all the effects i used and i have no idea if all of my effects are 10bit color....

Any notes/advise/or even to tell me i'm wrong is fine, just want to get my head straight.

Thanks!
 
I would not have gone that route. And I conform and grade quite a bit of Red originated material destined for filmout, DCP, & HD.

My method is to retain maximum dynamic range until the render, the best way to do that, IMHO, is to debayer as the very last step, after all color transforms have been applied.

Not sure why your transforms look bad - perhaps transform filter choice could have been better?

Regarding the DPX / Scratch workflow? Scratch is definitely great at DPX, but the whole reason to use Scratch above other conform / grading tools is its ability to work natively with R3D.

The main reason I can think of that they used Crimson is perhaps there were elements in your FCP timeline that do not translate into CMX 3600 EDL - it's a very simple format - cuts, dissolves, fades, retimes... that's about it!

With Crimson and XML it's possible (I think...) to include the transforms. Maybe that was the attraction?

Also, if there are any effects, they have to be done elsewhere, probably why they're going back to FCP. Scratch, absent plug-ins from Foundry and SpeedSix, has no effects at all. So, the conform has already occurred, for the most part, as that's what Crimson > RC does, that's why my guess re. gonig back for FX.

If you are unhappy with the results, perhaps you can point out the problems to the facility and ask them to go back and do better.



regards,

John T.
 
The major selling point for Scratch in a RED workflow is to stay in RAW untill the last second, but there are currently a couple of hickups in that route.

Please correct me if I am wrong!!! :)

1. If you are playing out to tape in the end (no renders) the "halfrez-high" settings applies to all material, regardless of sourse resolution. That means that a 2k file mixed in a 4k timeline, is laid back as 1024x512 over the SDI, and then upscaled to (e.g.) 1920x1080. Not very nice. Solution: Render out 4k (!) DPX's or TIFFs of your 2k shots. Same goes for 3k shots...
Solution: Be able to set playback resolution independently of source resolution.

2. Many of the tools within scratch works (best) with dpx source. Stabilizers keyers etc are really better off with DPX than RAW source. Thus: Transcode, and lose the advantage of oversmpling when you reframe, unless you go to 4k 16 bit tiffs....
Solution (I guess), is to really "lock" the file after the primary, so that Scratch sees it as a regular videoformat after the primary.

3. It should maybe be more clear to the user, that the primary is pretty much the development stage from RC/RA (workflow wise) and that one should not use it for primary CC to get optimum (clean) results. First Scaffold is actually your primary. A development window where you lock the image data for the rest of the treatment would be a more intuitive solution...

But these are just thoughts...
 
lunacie said:
The main reason I can think of that they used Crimson is perhaps there were elements in your FCP timeline that do not translate into CMX 3600 EDL - it's a very simple format - cuts, dissolves, fades, retimes... that's about it!
Click to expand...

EDL does not work with retiming. Cuts and fades only. EDL is very limited. BUT, since EDL is so simple it does work reliably. Nonetheless, EDL requires some disciplin like legal reel naming - no funny characters and only 8 of them. FCP takes reel names with more than 8 characters and creates its own abbreviated reel names in the EDL (commented).

In this regard FCP does work flawlessly with RedRushes because RedRushes names the reel after the file without the date. The emerging reel names work fine for conforming. But when shooting it's is vital to give every CF card a new number because the date in the reel will be dropped. Otherwise it can happen that two shots have the same reelname.

Back to topic: I would edit in FCP, clean up the timeline for EDL export. Import EDL into Scratch and grade off the native R3D files. It does work, no witchery and delivers the best result. I've done that several times and it is a workflow that has bee establishes over 20 years now. Any posthouse (especially those who have Scratch) should be able to do this. VFX can be done later or before (based on DPX, for instance). Important here is that every VFX shot in the FCP timeline needs a unique reel number.

A XML workflow with Crimson is nice and does work but if you have the money for a Scratch session than why go DPX and not straight R3D? Does not make much sense. FCP - Crimson - FCP is great for all those who don't have or want to spend the money for a Scratch conform/grading.

BTW, if I remember correctly I was well advised to clean up my timeline for a Crimson XML roundtrip... So again no advantage in this regard.

Hans
 
Were they running Scratch on a system that was capable of playing back R3D clips at "1/2 res-high quality" for 1080P layoff?

Unless they were running Scratch on a seriously "performance enhanced" system such as redBOXX (shameless plug here...sorry folks), they would not have been able to playback your 4K R3D files in realtime @ high quality for layoff to tape.

In this instance, the only way they could have done the tape layoff was to convert everything to DPX first.

You should ask them about their Scratch system's realtime capabilities with regard to native R3D clips.
 
BOXXLabs said:
Were they running Scratch on a system that was capable of playing back R3D clips at "1/2 res-high quality" for 1080P layoff?

Unless they were running Scratch on a seriously "performance enhanced" system such as redBOXX (shameless plug here...sorry folks), they would not have been able to playback your 4K R3D files in realtime @ high quality for layoff to tape.

In this instance, the only way they could have done the tape layoff was to convert everything to DPX first.

You should ask them about their Scratch system's realtime capabilities with regard to native R3D clips.
Click to expand...

That's my assumption as well. That because of performance you would end up laying off DPX's from Scratch before you lay off to tape. So if Crimson can do that for you ahead of time and not tie up your Scratch suite then that's money in your pocket. Likewise you can run REDline through QMaster now off Crimson so that's very effective if you have a couple of FCP stations sitting around your facility. Intel only though :(

IBloom
 
I think that is basically the reason, but they made multiple mistakes going back and forth and back again. In my opinion why even have scratch if your system cant handle the 1/2 res play back, even still it had to be re-rendered again out of scratch for a FCP conform which was interesting.

Either way im bummed that it wasn't a straight scratch workflow, wanted to experience that, even though crimson is pretty awesome. But if i was going to use a crimson workflow then i could of gone about color differently and also saved some money.

I would rather not say what post house this is.

Thanks for the response everyone, i thought i was going crazy for a minute.
 
You must log in or register to reply here.
Back
Top