Welcome to our community

Be a part of something great, join today!

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

Cineform response to Final Cut Studio?

so would I be right in assuming the following so far:

Redcode :

Pros: Edits directly in FCP, no transcoding. FXplug to assign looks. Free.
Cons : No montior support, processor intensive. No PC support.

Cineform :

Pros: Multiple streams of realtime editing/fx on a PC or MAC. Monitor outputs via Blackmagic card.
Cons : Expensive, have to tanscode.

this maybe simplifying too much, but am I on the right lines here?
 
FCP, in it's high quality render path, does everything in 32 bit float and has done for years. Our REDCODE codec is designed to spit out it's data in 8, 16 or 32 bit depending on what the host app is asking for at that time. Once we get REDCODE RGB working, that will accept the 32 bit data and put it back to 10, 12, 16 or whatever we figure out will work best.

You've got to remember that RED is a really small team, and we're working very hard on making sure the software side works well, has a workflow and integrates with the camera hardware, and that's not a simple task. So I'd better get back to work.....

Graeme
 
Greame, isnt 32 bit float only an option in FCP's YUV mode, when rendering from and to an YUV Codec?

BTv. Hope you'll be able to show off some stills of the REDCINE interface soon, for us stuck at home base :-)
 
32 bit float is for YUV only, but Graeme has kind of hinted before that REDCODE may be able to 'pretend' to be YUV to Final Cut (remember REDCODE RAW is only 'pretending' to be RGB). FCP works internally at 4:4:4 all the time as far as I'm aware, even for 4:2:2 codecs.
 
Yes but then you have a dual color space conversion. From RGB to YUV, and back again. That shouldn't be something you'd want for color accuracy :- Greame?


When the RAW file is debayred it's stil a RGB file although it's in the sensors native colorspace.
 
Doing a RGB to YCbCr to RGB at 32 float is totally transparent. I'd not worry about it in the least - I don't. Sure it's a concern at 8bit, but at float - no problems. Basically it's just a hack behind the scenes to make it all work and you'd never notice in in practise. And yes, FCP internally is always 4:4:4.

I don't see any reason why you can't see what you're doing in FCP and REDCODE out your Kona card. I'm sure we had it working in the office out over SDI to a big plasma.

Also, if you transcode to any other RAW format, you're loosing links to RED Metadata and what it means, and white balance would have to be reverse engineered and you'd not have the benefits of our tried and tested colour space transforms and sensor colorimetry data.....

Graeme
 
But isn't there a colour space conversion happening anyway when the de-bayered file is converted from camera native colour space to the working colour space? RGB->YUV->RGB is normally particularly destructive because of the 4:2:2 sampling normally used by YUV. If it stays 4:4:4 it would not be so bad. If all processing is 32-bit float, there should be negligible quantization errors. Now the only thing you're left with is gamut mis-matches, which I agree could cause some colour information to be lost.

EDIT: once again Graeme's there before me!
 
Ok, sounds great. So basically you do the colorspace conversion inside the codec and present YCbCr 32-bit floats to FCP?
Ok, I was just confused because I thought the FCP quicktime File I/O was limited to 16-bit integer.
 
So the color space is always 4:4:4, either yuv or rgb...and 32 float.

You can natively edit 4k (or low rez offline version) in FCP and 2K color fx in Color...yeah?

Color has LUT's that can be read by Redcode and visa versa.

So hopefully the Color FX's can also be read by Redcode so you can do a final conform of it's 2K output to 4K in FCP.

Or am I way out?

Cheers,
 
Graeme. Hope you'll cosider implementing a simple lossless mode in the REDCODE RGB codec as well.
Having a high quality uncompressed RGB codec that you can use in FCP would be really useful.
Not to dismiss your wavelets, but I can still imagine a few places where I'd want to go fully uncompressed.

Can't really grasp why no one else (Blackmagic, AJA) has implemented this color space conversion in their RGB codec's before. (Other than a few thoughts about you being a genuene geniuos)
 
As the subject still has CineForm in the title

As the subject still has CineForm in the title

Let's get 1st party support going before we worry about 3rd parties!

Graeme

That is backwards. The whole point of embrassing third party support is that customers do not need to wait for the first to get all there products complete (and there is no such thing as a feature complete product in post.) Look at CineForm's relationship with Adobe, Adobe wanted HDV support for Premiere Pro 1.5, so they licensed CineForm as we had already released products that served that market back in Premiere 6.5 days (nearly 2 years earler.) Adobe allowed third parties from a very early stage by posting their SDK online, for all who wish to use it. When Adobe released PPro 2.0 which had its own HDV support, third parties like CineForm and Matrox simply shifted their features to address a higher-end market. All this helps Adobe even though they have large development team. The smaller your team the more third parties can help. Graeme, you have you own business, got a good reputation, and then your position at Red, primarily because Apple was open enough to allow you develop your effect filters / plugins. This an business approach that is proven to work. I know producing a full SDK is an engineering effort, but we don't need that day one, just a small change here or there is all we have asked.
 
I fully understand your point David. Once we get our support done I fully expect others will come along and fill in niches, but I also think RED should offer at least the basic workflow on each platform we support - that's what I mean about getting 1st party support right first. You're totally correct about 3rd parties being great to either provide support for a new format when the producer of that format offers no support or for filling in a niche, like I do with advanced chroma upsampling algorithms in FCP and Color.

Graeme
 
No, but please tell us what you want supporting apart from the obvious 3 A's - Apple, Adobe and Avid.

Graeme
 
Thank you for least acknowledging the request, and that RED does realize there will be parts of the market you cannot address. It was getting frustrating from here. Still a RAW pixel format would only be a small effort for your team and get the real-time PC post up and running very quickly, even if it was a CineForm solution. This would not be before your own PC offerings as we do require the existence for REDCINE to do anything, which will serve a wider market. Please keep this option open.
 
We're keeping all options open, but we do need to fully concentrate on our own path for now.

Graeme
 
No, but please tell us what you want supporting apart from the obvious 3 A's - Apple, Adobe and Avid.

Graeme

That would seem to be the obvious choices, though I would not place them in that order. Anything beyond these platforms could be considered secondary in terms of market share.

Good to know that all three major NLEs fall into the category of supported platforms.

Thanks,

Kevin Halverson
 
I'm probably on the low end of the economic spectrum trying to buy a red, a freelancer in a small market that teaches college to make ends meet. I own PC's so to try to switch to mac for me is not economically possible. So a PC solution like Adobe is what I'm hoping for. Yet I'd hate the thought that I could shoot in such a great format only to lose color or resolution going to the NLE. So thanks for your tremendous efforts in bringing this type of capability into a realistic price point, I'll definitly be staying tuned for developements on the PC front.
 
No, but please tell us what you want supporting apart from the obvious 3 A's - Apple, Adobe and Avid.

Since you asked...

Linux. In some format that Autodesk applications understand.

I can't be the first one to bring this up - can I?
 
Back
Top