Red camera without Mac and FCP

[M Most]

A couple of tidbits:

For everyone's discussion of "Well, I wanna finish in 4K," keep remembering that the ONE AND ONLY time a 4K finish is EVER useful/necessary/required is if you have theatrical distribution to 4K DCI spec or to a filmout.

Thanks for saying that. It bears repeating.

Final Cut, at this time, AFAIK, is NOT suitable for a 4K finish. The resolution may be hackable, but unless you're doing straight cuts, you'll be compromising your images for any titles, dissolves, etc (stuff that has to render).

Guys, guys. It's not simply applications that are the bottleneck. Let's inject another bit of reality. 4K means approx. 48MB per frame, at 24 fps that's 1.1GB per second. Does anyone understand the type of storage and processing that requires? And you're thinking about a single desktop Macintosh?? Let's get real, please. The only reason we (or Red) are even talking about working in a resolution like 4K is because of compression techniques. That's what's making it possible. If you think you can get a simple desktop computer to push around, process, and display 1.1GB (that's GigaBYTES, not GigaBits) per second, you're not living in 2007.

Hollywood has just started getting used to 4K finish work at the highest end.

True. And essentially every single one of them are using a proxy workflow to accomplish it. Nobody deals with 4K in real time as a working source. They work with proxies and render 4K for final output only.

 

[Chris Kenny]

As far as processing goes... there seems to be a persistent notion that uncompressed requires more disk space and more processing power. If you think about it for a few seconds, though, this isn't true. It requires more disk space, yes, but it requires less processing power, because there's no need to decompress or re-compress anything. (Remember, essentially any actual image processing takes place on decompressed data.)

Why do people keep bringing up real-time uncompressed 4K, anyway? As far as I've seen, nobody is saying it's reasonable to do uncompressed 4K on the desktop.

In a desktop workflow with REDCODE support throughout, the only time you might need to go uncompressed would be if you needed to to deliver DPX or TIFF files (or whatever) to a facility to be packaged up as a DCI distribution master or printed to film. That would be a final output stage; it wouldn't need to happen in real-time or anything close to it. And it wouldn't even require that much hard drive space, because you could simply write out 400 GB worth of frames, record them to an LTO-3 tape, delete them from disk, and then start over with the next 400 GB worth of frames. Or just output to a series of 1 TB disks and send those over.

In the long run, it will probably be possible to just output a DCI distribution package directly on the desktop, without ever going uncompressed. (Perhaps it's already possible to just output to a series of JPEG 2000 files, and hand them over to a facility to put into a DCI package without further processing? I can't think of desktop a app that outputs 12-bit X'Y'Z' JPEG 2000 files, though.)

Incidentally, I completely agree with everyone who's saying there's almost never an actual need to finish in 4K at the moment. But I also think it's not as difficult as a lot of people are saying it is.

 

[laguun]

Chris is right. The processing bit depth in FCP is a non-issue if you know how to handle it in the codec.
Graeme

Hello Graeme,
the problems start to arise if you work with several softwares (3D animation, VFX, Motion Estimation, 3D Tracking) in a lets say, small team of maybe 10-30 artists.

its near to impossible to track all revisions and their colorspaces, many applications only support RGB or YUV at 10bit and then rounding and colorspace conversion errors happen all the time.

even in A-budget production like matrix II / III bitdepth is often down to 7-8 bit at the end of the pipeline, due to conversion / rounding errors.

many images travel through 15-35 imports/exports before they are finally baked in the master, and many software don´t handle YUV->RGB import side 32 or even 10bit.

so deciding for one colorspace can be pretty cruicial.

the whole fcs/redcode structure is great and certainly a good solution for a huge part of the buyers.

but for 4k mastering (and 2k as well) and networked workgoups typical for b&a-budgets, working in one colorspace is mandatory, i am afraid everything else is a workaround as we would have to measure & qualify every single software in its export/import, how they use quicktime etc.
certainly doable for a smaller team, nearly impossible if you work with different companies in different locations.

p.s. all this shall not sound negative, graeme!
let me add that it is perfectly logical that you run into problems, as you have so many innovations (raw & redcode) and pushing the industries standards to the limits (>4k) and keep doing that on the affordable infrastructure (desktop computers). so its obvious that you find limitations if you push everything forward & to the max. thanks for doing so!

i am just trying to figure out how we at laguun are going to integrate redcode into our 4k workflow. I would go FCS at once if FCP&COLOR would be 4k rgb>=10bit. if not i have to find another solution - premiere/assimilate looks good, and i hope that premiere on osx will also be rgb4k then.

 

[Graeme Nattress]

Well, as FCP accepts a 32 float buffer, we could make the RGB version of the codec 16bit from that 32 float buffer and you'd not be worrying at all.

Graeme

 

[laguun]

Well, as FCP accepts a 32 float buffer, we could make the RGB version of the codec 16bit from that 32 float buffer and you'd not be worrying at all.
Graeme

to understand it, our workflow is then
FCP ingest redcode
FCP edit with redcode
so far and so cool - alone as "offline" this is great.

and now online & vfx - the critical point
FCP 4k rgb >=10bit export to -> DF/Shake/combustion/flame (or DI)
3D renderelements rgb >=10bit -> DF/Shake/combustion/flame (or DI)
VFX composition in software -> render to 4k rgb >=10bit

and reintegration
4k rgb >=10bit -> import FCP through 8bit rgb bottleneck and then mediafile = YUV float 32?

sorry if i am confused - i thought exporting from/to FCP in rgb would be 8 bit (and 2k)? the pipeline above often repeats several times.

 

[Graeme Nattress]

Well, think of it like this - the redcode raw codec is 12bit RGB, but we convert to 32 float YCbCr for upload to FCP for rendering, and we could capture the 32 float YCbCr and convert to whatever bit depth RGB we want on rendering back to the codec. Either way, that brief dip into YCbCr would be totally transparent.

FCP can be funny how it works, but if you can control the codec, there's lots you can do.

However, I think REDCINE would be a good part of your workflow for spitting out 4k DPX files for your VFX and compositing though.

Graeme

 

[Rob Lohman]

The QuickTime REDCODE codec supports many pixel types, including 32-bit floating point YCbCr. We'll also support 16-bit RGB (as in a total of 64-bits) for applications that might want to use that (Shake & After Effects I think).

 

[laguun]

However, I think REDCINE would be a good part of your workflow for spitting out 4k DPX files for your VFX and compositing though.
Graeme

redcine is a fantastic idea and seems pretty clever - but here is the core of the problem.

- at a certain moment in time we have to leave redcine and go uncompress rgb (dpx etc).
- these sources for the compositing/VFX are modified, integrated and rendered, also to uncompressed.
- this footage then is imported to the NLE
and here starts the problem - if we have to use rgb/yuv import we can´t keep the results 10bit rgb with FCP and also not 4k, so roundtrips nle-vfx-nle wouldn´t be possible - if i understand correctly. with premiere this is doable.

as "desktop" solution, there is
offlineedit in nle fcp (directly) or premiere (feeded via redcine) -> edl -> redcine -> premiere (other 4k) on pc and as soon as adobe has cs3 ready on mac as well.

am i missing something?

 

[Rob Lohman]

Normally you do an offline edit (at lower resolution), create your effects work and then use an online / conform / grade station to re-assemble everything.

As said before, you really only need a 4K pipeline if you're gonna project 4K or go out to film with a 4K printer.

 

[laguun]

The QuickTime REDCODE codec supports many pixel types, including 32-bit floating point YCbCr. We'll also support 16-bit RGB (as in a total of 64-bits) for applications that might want to use that (Shake & After Effects I think).

great!
i understand that the limitations in having a intact & repeatable 4k10bitrgb (or even better) are not in redcode & redcine, and that is indeed possible to do so.

i am just trying to find out how we can get rid of doubleexports and "offline" transcodes - and if it makes sense for us to add FCS to the network - even as 2k as 2k will be pretty popular for some time.
i hope you plan to have native redcode in ppro at a later time as well or is that undecided/not official as of yet?

 

[laguun]

Normally you do an offline edit (at lower resolution), create your effects work and then use an online / conform / grade station to re-assemble everything.

yeah, the 4k online/conform/grade is what we are starting to plan for investing (and what i am trying to understand if this is doavle on osx).
While NAB i was under the impression that we would use FCS for this, but as i understand now color (2k) and FCP (no uncompressed 4k reimport/10bit) are not able to do that (yet)

As said before, you really only need a 4K pipeline if you're gonna project 4K or go out to film with a 4K printer.

we want to stay 4k in the pipeline - even with 2k or 1080 out, as 4k offers so more headroom for grading, track, pan/scan/scale, key etc.

luckily we already have 2k and 4k pipelines in the houses, however the 4k workflow is slow & complicated and now with red coming (we have a ~400 and ~900 reservation) it makes sense to begin to change that.

 

[Chris Kenny]

The QuickTime REDCODE codec supports many pixel types, including 32-bit floating point YCbCr. We'll also support 16-bit RGB (as in a total of 64-bits) for applications that might want to use that (Shake & After Effects I think).

Are you talking here about how the codec presents itself to apps, or is data actually stored in the files in these different formats?

 

[Graeme Nattress]

The data for REDCODE raw is 12bit raw. REDCODE RGB is not decided yet. Either way, what we're talking about is how the data is presented.

Graeme

 

[Chris Kenny]

The data for REDCODE raw is 12bit raw. REDCODE RGB is not decided yet. Either way, what we're talking about is how the data is presented.

OK. So, to go back to the issues workflow laguun is raising... we've already established that REDCODE RAW and REDCODE RGB will seamlessly intercut with each other in FCP, right? (They have to, since otherwise you couldn't render anything on a timeline with REDCODE RAW, since you can't encode to REDCODE RAW on the desktop.)

This seems to imply that if you had a Shake composite or you were rendering in Maya or whatever, you could render out to a REDCODE RGB QuickTime file, and then cut that file into a REDCODE timeline in FCP... and this would be 12-bit (or better) data the whole way through, that FCP would process in 32-bit color space, because FCP would be working with the REDCODE timeline as high-precision YUV. Is that right?

If so, it seems like you guys are enabling a really compelling end-to-end compressed workflow here.

 

[Nick Shaw]

If eg Shake could see REDCODE RAW as if it were 16 bit RGB, and write back to REDCODE RGB as actual 16 bit RGB, which FCP would see as if it were 32 bit float YUV, then presumably there would be no truncation of quantization on the round trip. Does that make sense?

EDIT: I think I'm saying the same thing Chris just said at the same time as me!

 

[MikeCurtis]

I think once upon a moon ago I'd heard about the Redcode presenting itself as 32bit Y'CbCr, but I'd entirely forgotten, that opens up all kinds of possibilities. And that's as a QT thing, not an FCP thing, correct?

Riddle me this then - my understanding was that there were inherent color shifts going between RGB & Y'CbCr - Andreas was all proud of his Synchromy stuff because it could do it (under carefully guarded constraints).

-mike

 

[Anders Holck]

The color shifts are there when going from RGB integer to Y'CbCr integer.
Going from 12 bit RGB integer to 32 bit Y'CbCr floats is a whole other ballgame.

When rendering to REDCODE with 32 bit float Y'CbCr going to 10 bit (?) RGB integer I can't imagine you can do it without degradation.

 

[Rob Lohman]

We're working with Apple (as announced) on making it as good as possible. That's the best I can say on everything for now.

Mike: that's a QT thing indeed. If the receiving app supports that 32-bit pixel type it can request that from the codec. I don't know if anyone outside FCP is using that. But we also have 64-bit (16-bit per colo(u)r) rgb in there as well 8-bit rgb & YCbCr forms

 

[laguun]

Riddle me this then - my understanding was that there were inherent color shifts going between RGB & Y'CbCr - Andreas was all proud of his Synchromy stuff because it could do it (under carefully guarded constraints).
-mike

argh, now its beginning to get complicated.


i am not a programmer, however i am teaching at some universities here and there and did supervise a diploma regarding colorspaces, so i still know a little bit. if the post has mistakes en details please pardon me, it was many years ago and also i am simplyfying a little bit...

... just want to bring a little light into the whole yuv<->rgb thing as many people dont exactly know why it is (or can be) problematic for cinema/dci.

YUV is a colormodel, not a colorspace.
a colormodel doesn´t exactly defines what "RED", "GREEN" etc is,
a colorspace does that.

There are several different yuv spaces.

for YCbCr<->rgb just some popular ones:
ITU-R BT.709 (nickname: HD) is : Kb = 0,0722 Kr = 0,2126
SMPTE 240M is : Kb = 0,087 Kr = 0,212
ITU-R BT.601 (nickname : PAL TV) is : Kb = 0,114 Kr = 0,299
there are several others (for print/photo etc)

now without going into the specific Y'PbPr spaces...
Y' = Kr * R' + (1 - Kr - Kb) * G'+Kb*B'
Pb = 0,5 * (B'-Y'/1-Kb)
Pr = 0,5 * (R'-Y'/1-Kr)
does the transfer between RGB/Y'PbPr.

now depending -which- special norm (as 709, 601, 240...) is used for the transfer you get different colors when transcoding - and you loose colordepth.

most desktop software now -doesn´t- say exactly which transcoding norm they use, or even if they do so don´t let you choose.
I even have come across some who used different transcodings in different parts of the software (as export/import) and some who where mixing transcodes and non-transcodes.

even if this is highly simplified and leaves out many problems to take care of (as rounding errors, involved libraries, graphic cards drivers etc), i think this demonstrates how many different ways there are to interpret a "YUV" image correctly and that is important to know -which- special substandard was used to encode/decode and how the software deals with it...

... and that it is pretty tough, near to impossible to keep track of which tool, which version, which format etc is used at what workstation of which company in which layer etc. - but basicly is necessary when roundtripping softwares in YUV.

there are several superior colorspaces (and models) than YUV and RGB, sadly enough none of them really became standard for postproduction. DCI uses a better one, btw

p.s. & disclaimer:
please don´t tear me apart if a formula or value is slightly (ot totally) off, i am no engineer/coder/scientist, just learned the stuff years ago as i am also working as colorist - and wanted to understand why i had chroma/lumashift when doing roundtrips through softwares... and then supervised a students diploma.

 

[Kevin Halverson]

The color shifts are there when going from RGB integer to Y'CbCr integer.
Going from 12 bit RGB integer to 32 bit Y'CbCr floats is a whole other ballgame.

When rendering to REDCODE with 32 bit float Y'CbCr going to 10 bit (?) RGB integer I can't imagine you can do it without degradation.

Certainly it is not an issue of integer versus floating point, rather it is a function of precision of the coefficients used. It would seem that with high accuracy accumulators and coefficients (24 bit fixed point as an example) the result would be effectively perfect conversion in either direction (even over a number of generations).