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

Current and Near Future Possible Workflows

R

R Fogg

Well-known member
Joined
Jan 3, 2007
Messages
415
Reaction score
0
Points
16
Location
Los Angeles
Trying to wrap my head around all possible post workflow options for finishing 1080p through 4k. After milling through many posts here I have generated a matrix or possible workflow options. I realize the matrix is overly simplified and my understanding of post, especially the various finishing options is limited, but if any post wizards have feedback or additions I will update the matrix and perhaps it can become a useful reference. (If not for others, at least for myself)

***also indicates near future implementation

Thanks in advance
Ryley
 
Smooth professional workflow

Smooth professional workflow

Hi Ryley,

This is at least the smoothest workflow for longform programs that we could figure out.
At least if you need to have an "what you see is what you get" on set realtime playback in HD 1080P,shot selection, possibities to make dailies, Autoconform in 4K and processing to 2K DPX or 4K DPX.
Scratch is unfortunately the only one right now that can offer this. You don't need IQ offcoure for finishing and grading, all kind grading systems will do the job for you Smoke, Lustre, FCP etc.
We happen to have an IQ thats why it's in our workflow diagram.

scratch%20prepost%20workflow.jpg
 
Hi Mike,

Has the Cineform workflow been tested already? What does it qualitywise when you convert from one compression standard (R3D) to another (Cineform)?
 
dip said:
And how long will it take to convert 3RD to Cineform?
Click to expand...

A high end workstation is currently about 2-3sec/frame to convert from R3D 4K to Cineform4K. Cineform2K has been around for about 2 years, and been used as a DI solution, and the lower resolution CineformHD is even more popular.

The current working workflow is to convert to Cineform in RedCine, edit in PPro, import that project into AE, and export 4K Cineform or DPX files. If you only need a 2K master, that can be exported right out of Premiere if desired. No need to conform on Scratch, etc. You do have to do the processing up front, to get your data into Cineform compression to work with.
 
Dip, thanks for the feedback. I notice you list Avid as an option in your workflow diagram. Would the approach with avid be to go redcine/scratch -> offline with DNXHD proxies -> EDL to scratch to conform with r3d files in Scratch? Or do you use the Redcam generated QT proxies?

Mike, I had the cineform codecs listed but have now added a notes section detailing the caveats of going the Cineform route.
 
Dip, thanks for the feedback. I notice you list Avid as an option in your workflow diagram. Would the approach with avid be to go redcine/scratch -> offline with DNXHD proxies -> EDL to scratch to conform with r3d files in Scratch? Or do you use the Redcam generated QT proxies?
Click to expand...

No the approach would be to make off line DV/cam copies (or Digibeta even HDCAM/DVCproHD) and capturing these tapes into Avid. Make your offline and Scratch will do the autoconform according the generated EDL. Nothing wrong with the proven conventional tape based off line workflow especially for longform edits. All other approaches are quite time consuming.
 
Thanks Dip,
Is this the same approach you would use in FCP or will the redcam QT proxies work here?
 
dip said:
No the approach would be to make off line DV/cam copies (or Digibeta even HDCAM/DVCproHD) and capturing these tapes into Avid. Make your offline and Scratch will do the autoconform according the generated EDL. Nothing wrong with the proven conventional tape based off line workflow especially for longform edits. All other approaches are quite time consuming.
Click to expand...

Wouldn't processing all of the footage to have files to make tapes with, plus making the tapes, be more time consuming. There are advantages to a tape based workflow, but I wouldn't list "time savings" as one of them.
 
Hi dip,
If you already have Pablo you don't need Scratch with grading
capabilities or set up for that. Use it as a R3d data handler, and make
mention of that in your workflow list.
I would stongly suggest most people go 'out of house' for final grade and
film-out anyway. So Scratch as a R3d Data handler is as far as most people
need to go.
Render out to DPX and then let the experts finish the film. This applies to
the Cineform workflow as well, although at a much lower price point.
Cineform is designed for the filmaker with little money and that's most people on this forum.
You on the other hand a Quantel IQ at your disposal,lucky bugger.
Mezmo. Green with envy.
 
You on the other hand a Quantel IQ at your disposal,lucky bugger.
Mezmo. Green with envy.
Click to expand...

Don't envy me you don't have to pay of everery month the loans we have...
I realise that not everyone is in for a Quantel machine. But the nice thing of this forum is that you discuss and change thoughts about how to set up a workflow with RED. For instance your suggestion to look closer into the possiblities of Scratch Prepost cube made me contact the guys of Assimilate.

(Ryley)
Is this the same approach you would use in FCP or will the redcam QT proxies work here?
Click to expand...

The same approach goes for FCP because at this moment the QT proxies have no source Time Code relation with the original R3D files other then a burn in TC. So if you want to use them you have to write the Timecodes of every cut and make the EDL manually. So you can use the proxies but it gives you quite some work afterwards...

Wouldn't processing all of the footage to have files to make tapes with, plus making the tapes, be more time consuming. There are advantages to a tape based workflow, but I wouldn't list "time savings" as one of them.
Click to expand...

But even if you make a shot selection and compare a Scratch workflow to a Cineform workflow I assume you're more time efficient with Scratch.

Let say 30 minutes of footage will take in a Scratch workflow around 40 minutes to copy to DV and another 40 minutes to capture in a FCP or AVID
So in total approx. 90 minutes

The same 30 minutes will take in a Cineform workflow about 30 hours to convert to a Cineform standard.
So I guess the real difference between Scratch an Cineform is efficiency, costs and if you want to work with compression during post or not.
There is a huge price difference between both systems Scratch prepost $55.000 and Cineform including PC and Adobe premiere approx. $ 5.000
 
dip said:
Don't envy me you don't have to pay of everery month the loans we have...

The same approach goes for FCP because at this moment the QT proxies have no source Time Code relation with the original R3D files other then a burn in TC. So if you want to use them you have to write the Timecodes of every cut and make the EDL manually. So you can use the proxies but it gives you quite some work afterwards...
Click to expand...

I might be lost here as to the particular step in the process you're talking about, but I don't think that's right.

I've done the FCP EDL to Scratch confrom/cc. The only thing the QT proxies didn't have from RedAlert was reel number, which required manual input of the 3 digit reel no. in FCP, but less time consuming than manually entering all of the tc info.
 
dip said:
The same 30 minutes will take in a Cineform workflow about 30 hours to convert to a Cineform standard.
So I guess the real difference between Scratch an Cineform is efficiency, costs and if you want to work with compression during post or not.
There is a huge price difference between both systems Scratch prepost $55.000 and Cineform including PC and Adobe premiere approx. $ 5.000
Click to expand...

While all this is true, it is important to point out the conversion to CineForm doesn't take much longer (can be faster on slower disk systems) than conversion to 4K DPX. The slow stage is the development of R3D files, which is very complex. This development has to happen in both workflows, with Scratch it is moved to the very end. But having a developed yet compressed 4K image earlier in the post also also has it own efficiencies, like allowing effects work on any shot without returning to RedCine. In the end the CineForm approach is more video centric than film, online rather than offline, so its workflow will likely appeal to different users.
 
I've done the FCP EDL to Scratch confrom/cc. The only thing the QT proxies didn't have from RedAlert was reel number, which required manual input of the 3 digit reel no. in FCP, but less time consuming than manually entering all of the tc info.
Click to expand...

The only way to keep the source Time codes in the things we've done is by convertingg R3D files via Redcine to DPX. And importing those via Gluetools in FCP. The Quicktime proxies we did only showed the normal Time Code so every clip started at 00:00:00 We're not so familiair with FCP so perhaps there is a way to work around this and to keep your source Time Codes in your Quicktime proxies within FCP?
 
dip said:
The only way to keep the source Time codes in the things we've done is by convertingg R3D files via Redcine to DPX. And importing those via Gluetools in FCP. The Quicktime proxies we did only showed the normal Time Code so every clip started at 00:00:00 We're not so familiair with FCP so perhaps there is a way to work around this and to keep your source Time Codes in your Quicktime proxies within FCP?
Click to expand...

That's definitely not the workflow that we or any other productions I know of used.

Quicktime proxies generated via RedAlert definitely have timecode. The only data they lack is reel no., which Red is aware of and a fix is in the works.

If your QT wrappers had no timecode then I'm suspecting they were generated incorrectly. I have no idea how to generate the 2k/1k/.5k QT wrappers out of RedCine - I wasn't even aware that was its purpose.

The process we used, and I recommend, is to generate wrappers (no processing or conversions!) from RedAlert, bring these into FCP, manually enter only the reel no's in FCP (it'll re-write the metadata to the QT files), offline, generate EDL, import to Scratch, confrom, then do whatever - either write out DPX for CC in Pablo, or CC in Scratch if you so desire. I have done exactly this a number of times without problems.

Be aware that if you change the speed of a clip in FCP it'll show that in Scratch, but variable framerates are not supported in media layers in Scratch (yet) so it'll play back at default fps with incorrect in/out points.

If you are not getting tc in your QT wrappers, double check your workflow - my suspicion is RedCine is not doing what you think it's doing.

regards,

john t.
 
lunacie said:
Quicktime proxies generated via RedAlert definitely have timecode. The only data they lack is reel no., which Red is aware of and a fix is in the works.
Click to expand...

That was fixed in Red Alert at least 2 versions ago. Redcine, on the other hand, still doesn't embed either reel number or timecode in Quicktime exports, at least as far as I know.
 
Missing time code when exporting to QuickTime within RedCine is a bug currently (or a non-enabled feature). It is coming apparently. The QT proxies made from RedAlert maintain proper camera time code however.

Edit: Whoops, too late with that info - already stated above.
 
mmost said:
That was fixed in Red Alert at least 2 versions ago. Redcine, on the other hand, still doesn't embed either reel number or timecode in Quicktime exports, at least as far as I know.
Click to expand...

Thanks for the info Mike. Had a bit of a break from post, so I'm just catching up to the latest releases.

So RedAlert now does embed reel numbers? That'll save some time...

cheers,

jt
 
You must log in or register to reply here.
Back
Top