Red camera without Mac and FCP [Archive]

Finner

04-25-2007, 04:48 PM

There are some die hard PC guys here and I personally don't quite get it. RED has stated that they will work with other NLE's and computer companies then Apple but Apple and RED have been working together for quite a while now and it looks like they plan to work together well into the future. From what I can see it is one thing to have your RED footage work with a PC but that will come no where close to how well I feel it will work on an Apple that has Had peices of its new FCP system custom made to work with a RED one. PC users can grasp all they want to there computers but to me it just seems like a waste of money and a loss of FCP RED specific features developed by the RED/APPLE teamwork.

Michael Schrengohst

04-25-2007, 05:08 PM

Peter McCully

04-25-2007, 05:13 PM

Finner

04-25-2007, 05:17 PM

At NAB apple was showing its new 2 button mouse. It still looks like 1 button but it tilts left and right so you have a left & right click.

Jason Murphy

04-25-2007, 05:26 PM

Umm, Apple's had a multi-button mouse for quite awhile now (even though, yes, it still does look like a single-button mouse with a tiny ball-bearing on top of it). Of course, I've been using a 3rd party multi-button mouse on my Mac since I got it 3 years ago, no problem.

All that said, as far as I'm concerned, the more platforms the RED technology runs well on, the better.

Rob Lohman

04-25-2007, 05:29 PM

REDCINE is fully supported on Windows, as is the QuickTime codec. Apple & FCP was a very good place to start. As with everything the software is in development too.

Craig Bowman

04-25-2007, 05:39 PM

I will wait to see what RedCine and workflow is like on the PC. If I have to add a dual quadcore with FCP Studio 2 and native RedCode Support I'll just be all broken up to pieces about that!:biggrin:

Peter McCully

04-25-2007, 05:43 PM

Rob Lohman

04-25-2007, 05:43 PM

I will wait to see what RedCine and workflow is like on the PC. If I have to add a dual quadcore with FCP Studio 2 and native RedCode Support I'll just be all broken up to pieces about that!:biggrin:
REDCINE works fine on PC. Obviously workflow highly depends on what software you're using and such. We want to make it as good an experience as we can!

Kevin Halverson

04-25-2007, 05:46 PM

I have little doubt that RED originated material will present any problem to a PC based NLE. I fully expect that PC based Avid and Adobe platforms will represent a very substantial portion of the NLEs that turn out serious RED projects.

ChristopherKenworthy

04-25-2007, 05:54 PM

I'll be using both platforms anyway.

I don't think we can afford to play Platform Wars anymore. I've been a dedicated Mac fan, and have used them for 15 years, but I boot Windows when I need to. If I was a hardened PC user, I'd swallow my pride and buy a good Mac system with FCStudio, and use it for nothing but Red work.

laguun

04-25-2007, 06:33 PM

i am pretty os-agnostic, having used & owned sgis, macs, alphas, pcs...
however...
some windows/X86pc 4k editing/DI
Avid DS Nitris
Discreet Lustre
Assimilate Scratch
Adobe Premiere
...
fcp & color however are 2k, and we want a online 4k workflow.

i would like to add a osx pc/apple to our network, having worked with nextstep on pc (that was the os later known as osx) and mac os in the 90ties. but why should we downgrade a pc-basing 4k post to a osx 2k post for a 4k camera? doesn´t sound to logical to me.

ChristopherKenworthy

04-25-2007, 08:34 PM

but why should we downgrade a pc-basing 4k post to a osx 2k post for a 4k camera? doesn´t sound to logical to me.

I see your point. I'm finishing in 2K, but I imagine 4K from start-to-finish won't be too far around the corner.

laguun

04-25-2007, 08:41 PM

I see your point. I'm finishing in 2K, but I imagine 4K from start-to-finish won't be too far around the corner.

4k start to end is reality on windows (and linux) for some years, even premiere can do it.

i wouldn´t mind adding osx if osx would have such a workflow. FCS has a really good price/performance. but i don´t think we will see 4k on FCS this year, when the announced upgrade is 2k. And we -need- 4k.

Craig W. Bickerstaff

04-25-2007, 09:08 PM

What are you guys smoking In the freshDV interview Ted says it's 4k end to end in FCP

ChristopherKenworthy

04-25-2007, 09:13 PM

What are you guys smoking In the freshDV interview Ted says it's 4k end to end in FCP

Yes, for FCP, but FCStudio isn't always 4K. Unless I've missed something, Color is 2K max. So, anybody doing their own DI would prefer Color to be 4K. Of course, you can take it to somebody else and spend the money, but the joy of FCS is the in-house aspect, if you've got the skills. 4K all the way through to DI would be perfect, but for that, we have to wait.

Lucas Wilson

04-25-2007, 09:29 PM

What are you guys smoking In the freshDV interview Ted says it's 4k end to end in FCP

Do you also believe that Anatrim will make you lose 50 pounds overnight because the e-mail says so? Ted tells the truth... but he's sorta like an oracle. You have to ask the right questions to get the answers you need.

Ask yourself the following questions:

1) 4K RGB playback in realtime is 1.2GB/s. How many FCP stations at home have that sort of connectivity? So... do you really think FCP is pulling 4K from the wavelet when it plays back?

2) Color is limited to 2K right now. Explain how you fit 4K into 2K. Feel free to use diagrams.

3) When was the last time you played back a 4K Quicktime in realtime? Give it a whirl one day.

Lucas
-----
Cynical Shill
ASSIMILATE, Inc.
LA, CA, USA

laguun

04-25-2007, 09:38 PM

color is 2k only, thats for sure, so there is no DI/Grade 4k in FCS.

i understand that FCP can playback redcode reduced to 2k and 1k, when its 4k in the redcode.

but is it possible to have FCP work online @4K uncompressed or raw?
i have been told different: that FCP is 2K max.
I would be a happy if i have been informed wrong and FCP indeed can handle 4k.

Premiere Pro does 4k (4096) uncompressed, and so do many other windows (and linux) systems, be it discreet, avid etc. to be precise - since years.

i hope i am missing something, but i am not aware that there is any 4k DI system on osx.

Craig W. Bickerstaff

04-25-2007, 09:40 PM

After looking at the tech specs of the site it looks like an issue of waiting for a software update.

It says 2k a lot but REDCODE isn't even mentioned so I'm putting this in the wait and see.

laguun

04-25-2007, 09:42 PM

2) Color is limited to 2K right now. Explain how you fit 4K into 2K. Feel free to use diagrams.
Lucas
-----
Cynical Shill
ASSIMILATE, Inc.
LA, CA, USA

Lucas...
...if FCP doesn´t do 4k i suppose i will spend a loooong time in your both @ IBC 2007...

Chris Kenny

04-25-2007, 09:56 PM

1) 4K RGB playback in realtime is 1.2GB/s. How many FCP stations at home have that sort of connectivity? So... do you really think FCP is pulling 4K from the wavelet when it plays back?

2) Color is limited to 2K right now. Explain how you fit 4K into 2K. Feel free to use diagrams.

3) When was the last time you played back a 4K Quicktime in realtime? Give it a whirl one day.

You're right about Color; Apple makes this very clear.

As for the other issues... who said anything about uncompressed, or about real-time? Any 4K workflow in FCP would presumably be compressed on both sides. Ingest right from REDCODE RAW (which we know FCP6 will support in an update, though we don't know if it will support ingesting at 4K) and then render to REDCODE RGB or JPEG2000 or whatever.

If FCP can online at 4K, I would guess the way it would work is, you cut your movie at 1K or 2K, and then flip the resolution on the timeline to 4K, swap the 1K/2K QuickTime proxies (the little QT files that instruct the REDCODE component where to pull the actual data from and what resolution to feed to QuickTime) for 4K proxies, and export to your output format, not in real-time.

Note that FCP5 lets you select frame sizes up to 4000x4000 already. Now, for all I know getting those extra 96 pixels might require rewriting half of QuickTime. But it's also possible that it would be trivial. And either way it's possible Apple has done it.

Desert Rune

04-25-2007, 10:11 PM

Yes, I am looking around at Apple. I will need to learn to play the one button mouse concerto. This after finally mastering William Gates' symphony for three fingers:- ctrl:alt:delete!

The irony. Because as a Mac user, I will only use a Microsoft branded mouse. I HATE all of Apple's line of mouse!

dalemccready

04-25-2007, 10:20 PM

I second that...I haven't used a mac mouse in years and the side scrolling microsoft intellimouse is perfect for scrolling across and in/out of timelines in FCP and AE. Couldn't go back to the 'designed' white mighty mouse. Not enough functionality when I have 4 fingers and a thumb sitting there

Stephen Gentle

04-25-2007, 10:43 PM

Note that FCP5 lets you select frame sizes up to 4000x4000 already. Now, for all I know getting those extra 96 pixels might require rewriting half of QuickTime. But it's also possible that it would be trivial. And either way it's possible Apple has done it.

Actually, I'm pretty sure that there's an XML hack that you can do to get full 4K. It was mentioned somewhere on the DVXuser boards, I think.

Anyway, with REDCODE support, Apple will have upped Final Cut's maximum resolution.

Hopefully next year at NAB they will release a new version of Color that can do 4K as well.

Desert Rune

04-25-2007, 10:49 PM

Emery Wells mentioned on a podcast episode (forgot the show name) where he said that developers or Apple's engineers hate the Quicktime architecture. I've had problems with Quicktime myself, notably gamma and scaling handling by Quicktime. Hopefully, I'd like to see a day when Apple completely abandons QT in favor of a writing a completely new media architecture for the 21st century.

Poi Boy

04-25-2007, 11:03 PM

Luki,
I know you are anti fcp, but like I said pre nab put a nail in the avid coffin...apple IS going after the high end, not hype, just a matter of time.
-A

Chris Kenny

04-25-2007, 11:42 PM

Actually, I'm pretty sure that there's an XML hack that you can do to get full 4K. It was mentioned somewhere on the DVXuser boards, I think.

Yeah, I was actually just thinking about that after I posted, and I went and tried it. It works. I created a 4096x1743 sequence, dropped in the stills from the PJ short, and rendered. I do, in fact, get a 4096x1743 QuickTime movie out the other end. I can't come anywhere close to playing it back in real-time (I choose PNG compression for the test, and ended up with a data rate of 260 mbytes/s), but stepping through frame by frame seems to show it came out. I even tried a cross dissolve between two of the images, and that worked fine. Everything also worked with a 4096x2304 test image.

So, maybe there are some subtle issues somewhere, but it looks like FCP can technically do 4K.

Anyway, with REDCODE support, Apple will have upped Final Cut's maximum resolution.

Hopefully, and hopefully Red's QuickTime component will be able to feed full 4K into QuickTime. (I would imagine this would be the case, because you'd definitely want it in apps like Shake, even if you were otherwise doing a 2K finish.)

Jarred Land

04-25-2007, 11:46 PM

Martin Drew

04-26-2007, 01:29 AM

I will need to learn to play the one button mouse concerto.

If you get a Mac do yourself a favour, junk the mouse and get a Microsoft one, they are loads better and have plenty of buttons!

M

Craig W. Bickerstaff

04-26-2007, 01:36 AM

If you get a Mac do yourself a favour, junk the mouse and get a Microsoft one, they are loads better and have plenty of buttons!

M

Such a waste of a mouse, If your gonna junk it then mail it to me I actually like mighty mouse believe it or not.

Beyond the frustrations of having to clean the scroll ball it functions just fine.

Oh you can ship me those old one button mice if you want as well I'll start a collection.

Martin Drew

04-26-2007, 01:40 AM

Hey Craig

Maybe you then you could get yourself a windmill and move to Amsterdam.:biggrin:

M

laguun

04-26-2007, 06:38 AM

remember you can export through redcine to a format almost any app out there can understand. And many non FCP apps have no problem with 4k.. Ive used after effects, premier pro, shake and a few others without issue over the last 8 months.

Jarred, just to understand it
can FCP only do 2K?

i have read here that one can "hack" the XML in FCP to get 4k - what does that mean? is that supported?

Lucas Wilson

04-26-2007, 06:49 AM

Luki,
I know you are anti fcp, but like I said pre nab put a nail in the avid coffin...apple IS going after the high end, not hype, just a matter of time.
-A

FCP currently, today, cannot open a 4096x2048 timeline. Color is limited to 2K. Will Apple address these issues? I feel certain they will... and soon. But reality is a good thing.

If it makes you feel better...

Avid currently, today, cannot open a 4096x2048 timeline. Media Composer doesn't have *any* integrated color correction tool other than the Composer "Color Tool" (shudder) Avid has announced no plans for REDCODE support making the workflow from RED for offline editorial cumbersome at best. If you're going to use a RED camera, then FCP is the obvious and natural choice for editorial.

I'm not "anti-" anything. I'm just realistic about what apps can and cannot do in relation to any particular job.

Lucas
-----
ASSIMILATE, Inc.
LA, CA, USA

MikeCurtis

04-26-2007, 07:52 AM

A couple of tidbits:

FCP XML hack - news to me. If it can be made to handle that resolution...sure. Great.

However, the MUCH bigger issue - Unless you are doing cuts only, with no titles or cross dissolves or color correction in FCP....FCP CANNOT process RGB in greater than 8 bits on the timeline. FX plug is 32 bit floating point space internally, but AFAIK, asking direct questions to Apple dev team at NAB, the limitations are still there. Want 10 bits/channel? Y'CbCr is the only mode to support 10 bit.

And if trying to do high end work, bit depth is MUCH more important than the difference between 2K and 4K.

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.

Even if you're going to a festival to show your film, if you don't want to drop the big bucks for filmout, an HDCAM is ususually fine.

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

So we need to look to other tools for that is the bad news, but the good news is, few of us really need to finish there. If you get theatrical distribution and you want to do a 4K finish....go to a Scratch house or somesuch.

Hollywood has just started getting used to 4K finish work at the highest end. While reading native Redcode RAW in is great, after coloring they'll still need to render out to 4K files (or at least 2K proxies for RT playback at minimum) so big throughput infrastructure is still required at present....perhaps in future, Redcode RGB might be good enough if can be decoded fast enough?

If they got that working right, that'd save HUGE money on RAID/SAN costs...

-mike

laguun

04-26-2007, 08:01 AM

Avid currently, today, cannot open a 4096x2048 timeline.
correct me if i am wrong - DS can?

laguun

04-26-2007, 08:08 AM

asking direct questions to Apple dev team at NAB, the limitations are still there. Want 10 bits/channel? Y'CbCr is the only mode to support 10 bit.

argh. bummer.
there goes FCP even as 2k system for us.
ok, FCP then is a cool offline tool with 2K DI via color.
shoot->edit fcp redcode @ 1/2k->export fcp edl via redcine to 2k dpx->color via 2k dpx->master then via something else than FCP as it has no 10bit RGB.

And if trying to do high end work, bit depth is MUCH more important than the difference between 2K and 4K.

indeed. there are plenty of project which i can do at 1080p/2k. there are none i could do in 8bit.

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.

which happens to be a mayor part of our jobs...

Even if you're going to a festival to show your film, if you don't want to drop the big bucks for filmout, an HDCAM is ususually fine.

100% true.

So we need to look to other tools for that is the bad news, but the good news is, few of us really need to finish there. If you get theatrical distribution and you want to do a 4K finish....go to a Scratch house or somesuch.

hmmm hmmm hmmm - luki, how much was an scratch seat? could you drop me a pm?

Chris Kenny

04-26-2007, 08:29 AM

However, the MUCH bigger issue - Unless you are doing cuts only, with no titles or cross dissolves or color correction in FCP....FCP CANNOT process RGB in greater than 8 bits on the timeline. FX plug is 32 bit floating point space internally, but AFAIK, asking direct questions to Apple dev team at NAB, the limitations are still there. Want 10 bits/channel? Y'CbCr is the only mode to support 10 bit.

It doesn't seem like this is a problem.

FCP's "High-precision YUV" is actually full 32-bit, not just 10-bit. FCP also does all internal processing at 4:4:4, even in YCbCr mode. So, REDCODE apparently just presents itself to FCP as a YCbCr codec, and gets 32-bit 4:4:4 processing. See here (http://www.reduser.net/forum/showpost.php?p=32888&postcount=82) and here (http://www.reduser.net/forum/showpost.php?p=32908&postcount=86).

(Remember, there's no real penalty for converting between RGB and YCbCr if you do it in a 32-bit color space.)

Graeme Nattress

04-26-2007, 08:38 AM

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

Graeme

M Most

04-26-2007, 10:31 AM

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

04-26-2007, 11:16 AM

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

04-26-2007, 01:37 PM

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

04-26-2007, 01:46 PM

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

04-26-2007, 02:13 PM

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

04-26-2007, 02:17 PM

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

04-26-2007, 02:49 PM

laguun

04-26-2007, 03:09 PM

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

04-26-2007, 03:13 PM

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

04-26-2007, 03:25 PM

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

04-26-2007, 03:49 PM

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

04-26-2007, 05:14 PM

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

04-26-2007, 05:19 PM

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

04-26-2007, 05:33 PM

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

04-26-2007, 05:34 PM

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

04-26-2007, 05:56 PM

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

04-26-2007, 06:09 PM

Rob Lohman

04-26-2007, 06:26 PM

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

04-26-2007, 06:48 PM

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

04-26-2007, 07:19 PM

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

Seán_T

04-26-2007, 07:25 PM

Luki,
apple IS going after the high end, not hype, just a matter of time.
-A

Yes "Apple" and "Hype" are never seen hanging out together. :tongue:

Apple might "look" high end but if you want it to be competeive with a big iron suite you'll have to throw a fair bit of cash at it.
I really dont see too many high end facilities closing their doors in the face of the FCS2 assault and dumping their resolve's or pogle's, baselight's, lustre's, scratch's. (well maybe one or two)

Now at the end of the day its still the "Artist not the paintbrush" that gives you the look you desire. But a lot of colourist's still like horsepower, I would not want to be in a grading suite with a director and half a dozen producers with anything less then a real time colour tool.

Although I can see us picking up a copy of FCS2 so we can open up peoples project and help fix them.

Seán_T

04-26-2007, 07:37 PM

If I may add one more thing. In the past some of the distributors and networks have insisted that an uncompressed post workflow be followed. Now I dont see this as a real issue but its interesting to think you could be in breach of contract by compressing. I doubt any real current agreement would have this. Although some bonding companies still insist on tape for recording so they can send in the bailiffs and seize something tangible (this will change).

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)

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.

david farland

04-26-2007, 09:47 PM

Excellent post Laguun.....Thank you

Poi Boy

04-27-2007, 12:22 AM

Sean.
Actually that is the beauty of the apple fcs thing, you don't have to throw nearly as much cash at it to get very very close to the high end facility quality.
Aloha
-A
And yes talent always rules no matter the tool. ain't it great ?

Stokestack

04-27-2007, 03:03 AM

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

Shake and AE will want 16-bit RGB in the b64a (16-bit RGB) pixel format. As long as the codec offers that, you're good.

Rob Lohman

04-27-2007, 10:10 AM

b64a is what we're supporting

laguun

04-27-2007, 12:02 PM

b64a is what we're supporting
excellent.

Brandon Rice

04-27-2007, 01:08 PM

Same thing is happening with HVX as well. The PC users struggle with P2 or achieve substandard results. I saw the RED footage working in the APPLE booth at NAB, nowhere else. FCP Studio 2 should generate more interest among PC users.....

Actually the HVX works flawlessly with Avid and a PC. I'm a PC+Avid guy, and I'd like to see Avid compatible with RED in the near future.:matrix:

Nik Manning

04-27-2007, 01:50 PM

Using FCP for offline and cuts only would it be possible to finish in 4K in Motion 3? Using something like Colorista and conduit for Color grading now that Motion can motion track and do 3D?

garageman

04-27-2007, 02:05 PM

Actually the HVX works flawlessly with Avid and a PC. I'm a PC+Avid guy, and I'd like to see Avid compatible with RED in the near future.:matrix:

I'm a Mac and Avid user and would like to see Avid compatible with RED. According to the Avid moderator on the Avid forums Avid are talikng to RED, but I don't know how true that is. Some say it's up to Avid and others that it's up to RED?

Brandon Rice

04-27-2007, 03:43 PM

HM. that's troublesome... I hope they get on the same page soon.

GlennChan

04-28-2007, 03:35 PM

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

My understanding (from reading his website) is that it reduces rounding error when converting between R'G'B' and (video) Y'CbCr.

If you look at the math of it (according to him there's no formal branch of math that covers this) and work out the formulas, you see that you always have rounding error when going from same bit rgb <--> ycbcr. This makes sense because YCbCr defines a lot of colors that don't exist in RGB (and also because the colors don't map 1:1). If you want lossless conversions between RGB and YCbCr, then Andreas' Synchrony scheme will do it... but you need to tack on two extra bits.

Charles Poynton's book (and likely his website) should have all the right formulas.

1b- It gets a little more complex than this since there are:
--scale factors, offsets (8-bit video Y'CbCr puts legal values in the 16-235/16-240 range, whereas 8-bit rgb is in the 0-255 range); there's also video format R'G'B' which would use the 16-235 range (well, the 10-bit equivalent of it)
--video Y'CbCr puts chroma in the 16-240 range, whereas luma is in the 16-235 range (for 8-bit formats)
--depending on whether you're dealing with video or computer imagery, the transfer functions are different between sRGB and Rec. 709 and Rec. 601

2- To me, color shifting is something else... i.e. if you encode/decode Y'CbCr with the wrong formula (or set of formulas), then you will get big errors in color accuracy. An example:
http://www.spectsoft.com/wiki/RaveManual/Support/Whitepapers/Spectsoftrec601rec709diff

This can happen because there are 3 sets of formulas for encoding/decoding rgb<-->ycbcr.
Rec. 601... used for standard definition formats
SMPTE 247M (this is for the obsolete 1035-based transitional HD format; some equipment can be set to use these formulas)
Rec. 709 for all modern HD formats

If you want to resize rec. 601 values for an HD format, then you actually need to convert the Y'CbCr values from Rec. 601 to Rec. 709.

3a- I believe with Redcode you don't pick up any unnecessary rounding error when going
redcode (12-bit linear light, integer) --> FCP rendering (32-bit Y'cbcr, floating point) --> output format

Because you have an overkill of bits in 32-bit floats, you don't get unnecessary rounding error (other than what the output format is doing).

3b- If you don't devote a lot of bits to floating point then you can actually get a lot of rounding error / loss in precision (a lot more than you would think)... this gets into some wacky/not obvious math.

http://docs.sun.com/source/806-3568/ncg_goldberg.html