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

Never ever...

H

hifidelity

Member
Joined
Oct 10, 2008
Messages
6
Reaction score
0
Points
0
... would I have thought to write this. But I'm totally disappointed by the whole RED workflow.

Shooting on the RED, editing in FCP and color correct it in Color. A project with multiple clips in one screen, massive zooms and one more night scratching my head why this damn RED Codec won't work as easy as RED is trying to sell us.
:nuke: :nuke: :nuke: :nuke:

First the RED Codec isn't able to work in 1024x576 square pixel within FCP. We tried, but everytime we've rendered the sequence the in and out point of each clip were f***ed up. So, we're going with the PAL Wide Preset. Worked just fine (even if I hate to work with an anamorphic preset) until we've gone into Color. Did our correction and wanted to export the sequences for a final online comp within AE.
I have to admit: Color is not the ultimate choice for color correction but since APPLE and RED tried so hard to sell their workflow we had to trust it, right?

No way. After trying it with different export settings there is no way that color f***s up the in and out point again....

... and so on.

And now I'm sitting here, desperate to get this project going and writing down my thoughts on our experiences.

Sorry for the harsh words, .. just wanted to get this off my chest.

Sincerely
HiFi
But no.
 
sorry dude,you are talking about different things

i have a realtime onset red proxy /onlining with sync audio over night workflow with fcp/lustre here everyday.

that color sucks is not reds problem.
that you need some workflow tests before is for sure.
there are a lot of smart guys here which you can contact for workflow solutions.
but i can understand your frustation.
thats the reason we provide extented workflow service for our clients

edit: i trust the RED QT codec since last week....its version 3.5
couldnt break it though we use to have 3 hour timelines....before the update we transcoded the proxies to pro res

hope this helps
 
Thanks for the fast reply.

First things first:
PAL/SD Sequence
Why do we have to render the sequence every time one clip is moved?

Second:
why is it, that the RED CODE won't work safe with an proper setting sequence setting like 1024x576 square pixels?
As I said: everytime we've rendered the sequence, the in- and out-points of every clip in the timeline were shifted after the render.

Our ungraceful solution was to select an FCP Sequence preset. In this case: PAL Wide.
 
I have to ask at this point.

Are you editing and finishing with the quicktime proxy files?
If so you should realize that they are really only meant for offline editing.

Or,
Are you using the log a transfer approach?

Either way, to make full use of the RED FCP workflow, and the high quality RED footage, you need to do an offline-online.

You offline in FCP using proxies, or log and transfer, then online using Crimson Workflow and REDCINE, or Monkey extract.
 
hifidelity said:
First things first:
PAL/SD Sequence
Why do we have to render the sequence every time one clip is moved?

Second:
why is it, that the RED CODE won't work safe with an proper setting sequence setting like 1024x576 square pixels?
As I said: everytime we've rendered the sequence, the in- and out-points of every clip in the timeline were shifted after the render.

Our ungraceful solution was to select an FCP Sequence preset. In this case: PAL Wide.
Click to expand...

Are you using FCP 6.0.4 with the latest Quictime REDCODE codec? I never used apple's color but the rest you describe should work fine.
 
There is nothing wrong with the workflow, If you have questions ask, research and TEST TEST TEST. I have not had a single problem after I understood how it worked and why.

First off, THe Proxies suck. Just google: Proxies from Red Sucks

You will find hundreds of disadvantages, and a few advantages... Research and test. Don' fall into the ignorance f not learning how something works before bashing it. THis workflow is rather elegant and similar to most workflows already in practice with many other tapeless formats and even Tape formats.

Offline / ONline thats just how you EDIT. Proxies are really crappy Reference files that suck every juice from your CPU to play back in 1/2 speed. That sucks, transcode everything to Prores for Offline and watch your frustrations dissapear.
 
We made an proxy offline and exported the XMLs to Crimson and something in between Crimson and RedCine didn't work so we where forced to go with ProResHQ...
 
x86box said:
There is nothing wrong with the workflow, If you have questions ask, research and TEST TEST TEST. I have not had a single problem after I understood how it worked and why.

First off, THe Proxies suck. Just google: Proxies from Red Sucks

You will find hundreds of disadvantages, and a few advantages... Research and test. Don' fall into the ignorance f not learning how something works before bashing it. THis workflow is rather elegant and similar to most workflows already in practice with many other tapeless formats and even Tape formats.

Offline / ONline thats just how you EDIT. Proxies are really crappy Reference files that suck every juice from your CPU to play back in 1/2 speed. That sucks, transcode everything to Prores for Offline and watch your frustrations dissapear.
Click to expand...

Yeah, well ... the thing is: in advertising often there's no time for excessive testing of the pipeline. Should have said that. :)

We thought of the ProRes way for offline first, but editing without timecodes?
 
Timecode comes in every shot no issues... What have you done to lose TC?
 
Don't bother. I just realized that the post-producer who helmed the project at first did the proxy export by himself and forgot to check the timecode checker for the ProRes export. The next day - when all the footage was transcoded - the director and the editor realized that the timecode wasn't there and pressured us to go on without loosing any time on transcoding again and to work with QT Proxys...
:help:
 
Transcode to ProRes using RedRushes (timecode should come through just fine). Offline with the ProRes files, export xml -> Crimson -> Redcine -> Then back to FCP or straight to color depending on how you need to finish.

In regards to the in and outs being off after you render, I have a question and I apologize if it seems obvious, but I want to make sure. You say that you are using a PAL preset, so is your footage 25, 23.976, 29.97? If it's not 25 are you changing the sequence settings to match the frame-rate of your footage? If not this most certainly will cause you issues.
 
Well that's already going to start you out in a world of hurt.

hifidelity said:
Don't bother. I just realized that the post-producer who helmed the project at first did the proxy export by himself and forgot to check the timecode checker for the ProRes export. The next day - when all the footage was transcoded - the director and the editor realized that the timecode wasn't there and pressured us to go on without loosing any time on transcoding again and to work with QT Proxys...
:help:
Click to expand...
 
hifidelity said:
Yeah, well ... the thing is: in advertising often there's no time for excessive testing of the pipeline. Should have said that. :)

We thought of the ProRes way for offline first, but editing without timecodes?
Click to expand...

this is bad protocol. With a new technology you have to test the workflow or it ends up costing money, time, and reputation. There are many workflows in place for commercials/advertising. Just ask Big T. They seem to have few problems in delivering for HD broadcast.
 
jnewm said:
In regards to the in and outs being off after you render, I have a question and I apologize if it seems obvious, but I want to make sure. You say that you are using a PAL preset, so is your footage 25, 23.976, 29.97? If it's not 25 are you changing the sequence settings to match the frame-rate of your footage? If not this most certainly will cause you issues.
Click to expand...

I understand your question. We shot in 25p and started to work on a 25p 1024x576 square pixel project... that didn't work out as I mentioned earlier.

In conclusion the best workflow would have been:
Offline editing with ProRes (with TC :wink: ), XMLs to Crimson, Crimson XML to RedCine, export DPX sequences to Color, color correct in Color, export DPX Sequences again and do the final online in AE.
 
You can use 1080 Uncompressed 10bit if you don't have Glue Tools, The DPX Quicktime Component for Color/FCP. About $600... If you do then more power to you.

What I've come to do is exactly as jnewm suggests. Only Open Every RAW file in RedAlert and Fill Histogram and add a little saturation, so when you use Red Rushes you can select the settings you made in Redalert so all your Pro Res files are Close to looking pretty good. At that Point your Producer might say... Well these look good lets stick with em! Hell with the Online! I've worked with several Producers that can't see the difference in DPX / TIF / Uncompressed & Pro Res. In addition to costing 20k+ to do DPX on Pablo. We decided to go to DPX in Pablo 4k for most night shots or Problem shots instead of doing it ALL Six - 1 Hour Long episodes in DPX. For us it was Budget... Me and DP can see difference in Pro res vs DPX on a 27 foot screen very easily... All detail is gone in sharper areas, So as always compression does its nasty trick...
 
You must log in or register to reply here.
Back
Top