RGB and deliverables

[Andrew Young]

You use REDQUICK to put a quicktime wrapper on the file. Your computer sees this media as it does any other QT media. Now you can choose to tell that file to play back at a frame size of your choice. 4K, 2K, 1, K or .5K

I have heard from Red that right now 2K is the max playback of the 4k Quicktime files, which may be why they use 4K DPX files played from a server at their screenings. If I am wrong about this, someone from the Red Team please correct.

 

[Nathan Troutman]

RED's biggest push should be for affordable, reliable, inexpensive compact flash media that can be used as the archive. They could really revolutionize post by creating a large demand for fast, inexpensive solid state media that is affordable enough to keep on the shelf.

Shoot ONCE
transfer ONCE
archive ONCE

If the CF media becomes the archive, like tape or film, then we have solved MANY interm problems. David

Anybody know the long-term reliability of CF flash as an archival storage medium?

If your footage isn't going to magically disappear in 5 years, CF could work and be another option to DLT tape based solutions - also provided that capacities grow, and price shrinks.

 

[Jim Arthurs]

When you capture from an HD CAM tape you have the choice of capturing that to an uncompressed 10 BIT HD signal which is about 165MB/sec. This means that there is actually about six time more number crunching when you are working in a HDCAM uncompressed workflow. If you captured the HDCAM to DVCPRO HD it might be about 14MB/sec.David

For fun, I do have to point out that the actual RECORDED data rate of HDCAM to tape is about 22MB/sec... or about the same as 8bit uncompressed SD.

I know this, because I own an NLE system that used the raw Sony HDCAM codec data. This is the signal that comes form the HDCAM decks optional SDTI card. The system was a modified DPS Reality boardset that could ingest via the boards SDI inputs and output the same. Think "firewire style" editing elevated to 22MB/sec using the HDCAM codec instead of the DV codec. Problem was, Sony charged $4000 just for the codec license, and you needed an HDCAM deck with the SDTI card just to monitor the footage. Limited use, but a mighty fine way to make lossless dubs with edits though...

 

[Steve Freebairn]

I think the big question might be:

How exactly does RED footage work in FInal Cut Pro?

We know that it REDCODE will be supported in a future release so this has me assuming that ANY red footage with a QT wrapper file can be used as any other CODEC in FCP.

What I am curious about is if FCP can edit the proxy files or whether those files need to be transcoded before being able to edit them?

This would obviously be a huge time saver.

Stuart?

Could you lay out a brief FCP workflow if I shot 4K REDCODE.

David

Stuart, please do so for FCP and Premiere.

battistella, didn't you mention in another thread here that you worked on the recent Superman? Didn't you guys use Premiere?

Even if Red is pro Apple, who here doesn't have a client or work with people who use Adobe products like Photoshop (which hopefully will be able to access the 4k files), After Effects, and heaven forbid Premiere Pro?

Someone please tell us the workflow and compatibility with Adobe products.:help:

 

[David Battistella]

battistella, didn't you mention in another thread here that you worked on the recent Superman? Didn't you guys use Premiere?

No. I didnt work on Superman. We use FCP now, but I have experience with every NLE system dating back to the laser disk based EDIT DROID.

Now if that is not dating me I do not know what is, sheesh!

David

 

[Steve Freebairn]

No. I didnt work on Superman.

David

Sorry, confused you with someone else on the board.

Still need to know from a member of the red team how Adobe works with Red.

 

[Joe Carney]

I thought Rob Lohman was working on the DirectShow version. haven't heard anything about that in awhile.
Still with Adobe now being cross platform, Quicktime is still needed on Wintel boxes.
Adobe (Premier) has been very silent about all this, their Mac version seems to be released in stealth mode or something. hehehe.

 

[M Most]

Workflow to get footage into an AVID or non REDCode supporting pipeline/system
........

So what's the problem with RAW again?

The problem is twofold. First, none of us have any idea how long those transcoding steps are going to take. Second, almost everyone here seems to make the assumption that playing back a proxy in FCP means you now have a deliverable product. As far as I can tell, this is not the case if you want the best quality demosaic, which I assume one would on a deliverable product. That requires a full render/demosaic from the original source files, i.e., an online conform/render. I don't know that I'm right about this, but I also don't know that I'm wrong, because I don't think we've really gotten a definitive answer.

By the way, this is exactly how it's handled in Cineform (real time demosaic is proxy quality, the final product requires a full render).

 

[Jeff Kilgroe]

I don't think most everyone is assuming that realtime proxy playback is good enough for deliverables. But I do think that's a good indication of what down-res times will be like. In other words, I don't think a full demosaic and scale of the RAW footage is going to be a big deal. I would be more concerned about that crappy old DVCPROHD or HDCAM codec you're using and how efficeintly it's going to be able to render out the data to your target format. REDCODE and REDCINE are supposed to be fully multithreaded, if I recall Stuart's and Rob's statements several months ago, around NAB or a bit before. For some reason the transcoding aspect of all this doesn't concern me that much.

We also don't know what quality level we're looking at for the proxy generation and if there's any room to configure or set levels, even up to a full quality render. Fact is, right now we just don't know and no matter what possible theories we come up with, it's all just speculation. The RED team is fully aware of our concerns and yet they seem to have little outward concern for the matter. Perhaps I'm a looking at this through a glass that's half full, but it says to me that we don't have much to worry about.

 

[Gavin Greenwalt]

Scaling can be done at faster than real time speeds. I can almost guarantee it. That's the sort of thing GPUs just love to do.

De-mosaic will probably be pretty snappy I would imagine. Especially in REDCine where the code can be multi-threaded and GPU accelerated.

I'm with Jeff on this one. The slowest step will probably be DVCAM/DVCProHD compression.