Cineform?

[Jay A. Kelley]

I won't buy a mac because so far it's not a matter of them being the "best" solution.. They are simply the ONLY solution.

It's like watching a race with only one runner.. He's the best on the track, but only because no one else is allowed to race.

Once other programs and choices are out there, then I will take a hard look at MAC, and Scratch for that matter.. I am moving up and Scratch looks like a possibility, but I won't go near them as long as they are the only ones who have direct support... It's a bad business move for me.

Jay

 

[Karl H]

This is slightly off-topic, but I'm one of those that gave in a switched from a PC to a Mac. Am I happy? well, mixed feelings. Most Red footage I've shot so far has been 16:9 - so i cant use the proxy feature in FCP anyway. (I didnt know about this limitation until I had shot)

I spent about $5000 on my mac, 8 core, 16G ram, FCS2... along with at least the same amount again on monitors, raid units etc (which could be used with my PC too) . Now with that set-up on my Mac I bring in 2:1 redcode proxies into FCS, on my raid, and is realtime? not even close, even at 1K the proxies stutter. Applying any fx to 2K proxies takes a long time to render. Redcode is aquisition only so I have to render back to prores on the timeline and it's 4:2:2.

I think there are two reasons for this speed. First redcode as it stands today isnt optimised for any kind of playback or post workflow. Also FCS isnt multithreaded, or at least not multithreaded well..... I've done as much as rendering in motion and FCP at the same time. The Mac slows down and stutters but the CPU monitor never goes above 40-50%. Very odd. It appears not to use all 8 cores. That's a big deal when you really need them.

No mattter what effect I tried to do, FCP alone would have 10 mins remaining render time and only be at 40% cpu usage. Same goes for conversions and exporting.

Im not saying Mac and FCS is bad, there are a lot of great things about it. Perhaps I'll grow to edit with proxies, as it is great being able to see your footage instantly, but the stuttering just puts me off as an editor. Bear in mind you would still have to apply some sort of basic CC to stop the raw files from looking milky, so you're back to rendering regardless. I bought a Mac specifically for Red workflow and I expected it to be easier and more powerful than it is.

With 2K proxies I was expecting to have full quality real time playback and also I thought there was meant to be a plugin that gives you access to the raw controls, so you can tweak the curves, direct in FCP? So far this hasnt emerged. I hope build 16 brings some post speed enhancements on the Mac

Together with cineform I think the PC is primed to be a more powerful and realtime solution for the indie guy not wanting to go uncompressed or with scratch. Also with cineform you stay 4:4:4 throughout the post workflow. I hope too that you can apply realtime basic CC to cineform RAW clip on the timeline (anyone know this?).

The best workflow for me so far has been to go redcine > 2K prores. Maybe it's me but when I edit I like to edit with a onelight cc and in realtime. If im going to go that workflow of converting then there is no real advantage to going mac at all right now.

By the way, Im speaking with very limited experience here, I havent had my mac for long and it's had little use. (mainly due to not having the birger mount yet)

 

[M Most]

Most Red footage I've shot so far has been 16:9 - so i cant use the proxy feature in FCP anyway. (I didnt know about this limitation until I had shot)

It's been pretty well known and heavily discussed, at least here.

Now with that set-up on my Mac I bring in 2:1 redcode proxies into FCS, on my raid, and is realtime? not even close, even at 1K the proxies stutter. Applying any fx to 2K proxies takes a long time to render. Redcode is aquisition only so I have to render back to prores on the timeline and it's 4:2:2.

That should not be the case, as 2K proxies play just fine (at least in straight play through in Final Cut, not in QT Player or with effects applied - but I digress..) on my basic Mac Pro with dual dual core 2.6 GHz. You cannot use "High" quality playback in FCP for this, however - try either Dynamic or Medium. You should not have to select Low quality to get real time playback. You can keep frame rate at full, though.

Im not saying Mac and FCS is bad, there are a lot of great things about it. Perhaps I'll grow to edit with proxies, as it is great being able to see your footage instantly, but the stuttering just puts me off as an editor. Bear in mind you would still have to apply some sort of basic CC to stop the raw files from looking milky, so you're back to rendering regardless.

Not really. You can open up each clip in Red Alert, set a basic color correction (remember to set up your monitor for 2.2 gamma before you do this), and make new proxies without rendering anything. The color corrections will play back anytime those proxies are accessed.

With 2K proxies I was expecting to have full quality real time playback

I don't know why you would expect that. It's always been made pretty clear (at least to me, and I'm pretty unforgiving myself) that this is not the case.

Together with cineform I think the PC is primed to be a more powerful and realtime solution for the indie guy not wanting to go uncompressed or with scratch. Also with cineform you stay 4:4:4 throughout the post workflow. I hope too that you can apply realtime basic CC to cineform RAW clip on the timeline (anyone know this?).

Yes, you can. However, in all of the apparent euphoria about Cineform, it is rarely if ever mentioned that in doing a conversion, you are going through two codec cycles using two different lossy codecs (Redcode and Cineform). It doesn't matter that Cineform is planning to do a "Raw to Raw" conversion - you still have to decode Redcode to extract the Raw information, and re-encode using Cineform to create a new compressed Raw file. Both of these codecs are nicely optimized, but there is no getting around the fact that you cannot go through two very high compression ratio passes without losing something in the process. So to produce final, master quality product, you will probably want to heavily test such a workflow before declaring that it is acceptable.

The best workflow for me so far has been to go redcine > 2K prores. Maybe it's me but when I edit I like to edit with a onelight cc and in realtime. If im going to go that workflow of converting then there is no real advantage to going mac at all right now.

That's not an uncommon view, especially from users with investments in PC's. But if you're using ProRes as your format, you actually do have to be on a Mac because that codec only exists on the Mac. You could, of course, use various other codecs on a PC if that's what you prefer. Cineform comes to mind for this.

 

[David Newman]

Yes, you can. However, in all of the apparent euphoria about Cineform, it is rarely if ever mentioned that in doing a conversion, you are going through two codec cycles using two different lossy codecs (Redcode and Cineform). It doesn't matter that Cineform is planning to do a "Raw to Raw" conversion - you still have to decode Redcode to extract the Raw information, and re-encode using Cineform to create a new compressed Raw file. Both of these codecs are nicely optimized, but there is no getting around the fact that you cannot go through two very high compression ratio passes without losing something in the process. So to produce final, master quality product, you will probably want to heavily test such a workflow before declaring that it is acceptable.

We have gone through this quality testing many of times for uncompressed to CineForm encoding, with plently of high-end post house customers. Yes, please do the testing for yourself. Yet your understanding of compression is a little flawed. There are not two added generations involved, Redcode is already compression, you can't avoid its loss whether you go to DPX or CineForm or use it natively. The is only one generation to consider, the CineForm encode. CineForm has been used to archive uncompressed sources with higher quality than HDCAM SR, acceptable to most, yet converting from a pre-compressed source like Redcode is in fact much easier and introduces significantly less loss than compressing from DPX source (which is what we are typically tested against.) So generation losses are not equal. Next, CineForm is hardly "high" compression, it is signifactly less compressed than the Redcode source, data rates will often increase 50-70% when encoding to CineForm with a log curve (Redcode currently peaks at 9:1 to CineForm's range of 6:1 to 4:1.) All this results in no one being able to determine original of a DPX file generated from Redcode directly or one that has gone through a CineForm generation. Something else to consider, compression is so much less of a factor than actions like scaling filers, demosaics, and color work. We intend to our best at all of these when given the opportunity.

 

[Karl H]

thanks for the tip on the proxies mike, I will try that, and if I can get playback at 2K then I may well use that workflow instead.

When I say I expected realtime playback, I guess Im saying I hoped for it. If cineform can play back 4K in realtime from a RAW wavelet file on a modest spec PC, then Redcode with a few iterations of optimisation should be able to do the same.

Put on top of that I bought a computer 4x more powerful than my old one (which could play cineform 1080p 4:4:4 fine). And I expected a lot more. I think cineform is an amazing little codec

Of course it doesnt help that FCP isnt multi-threaded, which is a killer no mac fan boy appears to be willing to tell you until you've bought the thing.

All Im saying is the general vibe seems to be for Red footage , Mac is the way to go. It's almost drilled into everyone. I dunno, I may have made the wrong choice, Ive had the opportunity now to use both cineform and the prores workflow and I cant say I feel Ive taken a leap into the future by buying the mac. Infact I see prores as an offline, while I see cineform as an online.
We wont even get into the fact that motion 3 is super slow - thats another digression.

I made my mac purchase as a last minute decision to get out of the way before my end of year tax; so I didnt spend much time in the apple forums on here to know about the 16:9 problem. I found out after I had shot and it didnt work .

Maybe you could help me out with a mac question, as im new to FCP and Red. As far as i know each proxie is in a subfolder of the clip name, so lets say I want to import 100 proxie clips, do I have to go into each subfolder to import the files individually 100 times? is there a way to batch import all of my clips at a certain proxy (i.e. not import all my proxies, just the 2K ones).

thanks (I know I should have asked this in the apple forum, but its kinda cross merged).

 

[M Most]

Maybe you could help me out with a mac question, as im new to FCP and Red. As far as i know each proxie is in a subfolder of the clip name, so lets say I want to import 100 proxie clips, do I have to go into each subfolder to import the files individually 100 times? is there a way to batch import all of my clips at a certain proxy (i.e. not import all my proxies, just the 2K ones).

thanks (I know I should have asked this in the apple forum, but its kinda cross merged).

I think this was actually answered recently in the apple forum.

The easiest way I've found to do this is to import the master folder (the one in which you've put everything: the R3d files, the proxies, etc.) into Final Cut. Note that you might get an error message saying that FCP doesn't support all the files in that folder. That's OK, ignore it. Select that folder in the Browser, then use the Find function (edit->find) to search for what you want - for instance, all files ending in "_H". It will then open up a new window with only those files. Select them all and drag them into either the Browser directly, or into a bin you create inside the Browser, then delete the original imported folder. This is a very fast way of doing what you're asking.

 

[laguun]

Final Cut is a good solution, and i own it.
However for Red, it has lots of limitations compared to Adobe CS with cineform, in quality and speed.

Adobe CS is full 4K, fcs can be hacked to "almost" 4k or is 2K.
Adobe CS has full 15/16bit RGB processing, Final Cut pro sadly has only 8bit RGB. One can use YUV instead of RGB, but having colorspaceconversions for a post workflow is highly problematic if you aim at maximum quality, dci or filmout. For TV its less of an issue.

Adobe CS cineform works in 4K in realtime, and 2K is easy, in RAW and RGB, while for FCP you have to go for 2K YUV non-raw (prores) to get RT or have to lower quality to playback 4K raw files via a 2K proxy.
Adobe CS is crossplatform, OSX and win, while FCP is OSX only.

However, FCS is still an very good offer with an excellent proce/performance ratio, and motion is excellent as well. But that Adobe CS 3 has (meanwhile) gained substantial speed and quality advantages over it is something which should be rememberd - and hopefully Apple will adress this. I dont understand why Apple why apple doesnt eliminate the long standing issues so many FCS Users endure daily (mainly: Gammashift, disfunctional Color integration, the 8bit RGB barrier and the missing full 4K) as they would highly improve FCs usability and the user experience.

 

[Dj Joofa]

Adobe CS has full 15/16bit RGB processing

I think Adobe Premiere can do 32 bit (float) per R, G and B also.

 

[Dj Joofa]

Next, CineForm is hardly "high" compression, it is signifactly less compressed than the Redcode source, data rates will often increase 50-70% when encoding to CineForm with a log curve (Redcode currently peaks at 9:1 to CineForm's range of 6:1 to 4:1.)

Can you directly use the compressed RedCode co-efficients (I assume they have used a standard wavelet transform) without going through decompression of RedCode to uncompressed to compressed cineform?

Additionally, if RedCode has already removed redundancies by a factor of 9:1, then why don't you keep that factor? I can understand that given uncompressed sources and then going either 9:1 RedCode or 6:1 Cineform on that uncompressed source, but as you say in your case you operate on RedCode data and not uncompressed source.

(1) If the nature of redundancies that you are removing via (6:1) more or less the same as RedCode (9:1), then probably a lower compression factor is not going to help much. (2) However, if the nature of Cineform redundancy removal is different than RedCode, then to some extent it will be closer to what MMost said of the cascade of two redunancy removal units operating in tandem.

I assume that Cineform case is closer to (1), and perhaps that is the reason that Cineform compressed files are visually indistinguishable from direct DPX via RedCode as you mentioned.

 

[Sven Seynaeve]

Hopefully this aint true.... Avid would take to much benefit from it and gain market share again against Cs and FCP. This approach ;if it is true, could put us CS users in the corner again<; and only slow down independants. And btw their upgrade rates aint nothing but very expensive....with hardware going out of date rather sooner then later....

Having used Protools for some time, this is the last thing I'd love to see happening.

 

[David Newman]

Can you directly use the compressed RedCode co-efficients (I assume they have used a standard wavelet transform) without going through decompression of RedCode to uncompressed to compressed cineform?

Additionally, if RedCode has already removed redundancies by a factor of 9:1, then why don't you keep that factor? I can understand that given uncompressed sources and then going either 9:1 RedCode or 6:1 Cineform on that uncompressed source, but as you say in your case you operate on RedCode data and not uncompressed source.

(1) If the nature of redundancies that you are removing via (6:1) more or less the same as RedCode (9:1), then probably a lower compression factor is not going to help much. (2) However, if the nature of Cineform redundancy removal is different than RedCode, then to some extent it will be closer to what MMost said of the cascade of two redunancy removal units operating in tandem.

I assume that Cineform case is closer to (1), and perhaps that is the reason that Cineform compressed files are visually indistinguishable from direct DPX via RedCode as you mentioned.

Probably the simplest response is that not how it works, plus wavelets are not all the same. While we could target a lower data rate, we simply give that option to the user. These data rate reflect our Filmscan1 mode using a Log 90 curve, all under user control. Filmscan1 is the same mode we use in our SR comparisions and our DPX testing, yet they are quality level higher and lower to meet most needs.

 

[David Newman]

Regarding the NLE, FCP vs Premiere, both have 32-bit YUV 4444 modes. However, Premiere also has RGBA 16-bit, RGBA 32-bit modes and more filters that support them. Premiere internals are better, but in general using 32-bit float mode will give you equal quality on both products.

 

[laguun]

Regarding the NLE, FCP vs Premiere, both have 32-bit YUV 4444 modes. However, Premiere also has RGBA 16-bit, RGBA 32-bit modes and more filters that support them. Premiere internals are better, but in general using 32-bit float mode will give you equal quality on both products.

If its possible to use YUV instead of RGB, yes, but many animation, VFX & grade systems are RGB only, as are most masters here.

Therefore having a YUV editing in the middle of several RGB systems and software is a mayor issue, which apple should fix. Or - if i missed that - does cineform use FCPs YUV float to process cineform RGB and RAW?

 

[David Newman]

There is enough precision in 32-bit float, it doesn't matter what the pixel colorspace is. Using 32-bit float, YUV to RGB transforms are effective lossless. Within FCP, CineForm RAW and 444 use the 'r4fl' YUVA 4:4:4:4 32-bit pixel format to deliver full quality. I believe Redcode within FCP does the same -- it is the only way to get beyond FCP's 8-bit limitations.

 

[Dj Joofa]

Is there a direct comparison for Cineform vs. Sheer Video codecs? I noticed that they are also using 'r4fl' flavor codecs.

 

[David Newman]

Is there a direct comparison for Cineform vs. Sheer Video codecs? I noticed that they are also using 'r4fl' flavor codecs.

Sheer is a nice codec, but a quite different solution. Sheer is mathematically lossless YUV or RGB codec, the datarate will be about 3-4 times higher than CineForm 444 encode. As CineForm can encode RAW there is another 3X advantage to the CineForm bit-rate. Sheer makes sense for some high-end SD or HD work, but at 4K the datarates become more of a driving factor.

 

[Dj Joofa]

Thank you very much David for your quick replies.

 

[Mike Harrington]

David

Do you guys still have the deal that if we buy prospect 4k....we get the debayerer for all forms of Raw (whatever you call it) once it is released

 

[David Newman]

David

Do you guys still have the deal that if we buy prospect 4k....we get the debayerer for all forms of Raw (whatever you call it) once it is released

Yes. We will not be charging current Prospect 4K customers for the up-coming RAW conversion utilities once they can be made available. We have said that anyone who purchases before the end of May will be in that category, although that may be extended if the SDK still seems a long way off.

 

[Gopher77]

although that may be extended if the SDK still seems a long way off.

Don't say that!