Kona RGB 10-bit for VFX?

There has obviously been endless discussion on the YUV to RGB conversion going from Final Cut to After Effects and back again so Im not looking to re-hash that here (incidentally Adobe has made great strides with this in CS3 with the implementation of Media Core and it will definitely improve a VFX workflow that relies on Final Cut). A discreet-snob asked me recently if our Kona card was a problem when we capture YUV content and need to composite in an RGB environment. It obviously isn't and we do it everyday and know how to adjust for it, however, it got me wondering if capturing to the Kona's 10-bit RGB codec was a possibility when coming in from digibeta or HDCAM for heavy VFX compositing? Will it do a realtime YUV to RGB conversion in hardware and give superior results to quicktime or media core? This in theory would seem to more closely mimic a smoke or FFI by keeping everything RGB all the way through (although not true 4:4:4). Or in actuality since the kona card is YCrCb on its input, will this literally give the same results in hardware that we're used to seeing in software (clipped overbrights, loss of detail, etc)? I thought of this at night at home and will try it out tomorrow, just looking for the opinion of some of the technical gurus out there. Thanks!

We are currently working on a Feature shot on DvcPro HD. We have onlined it in AJA RGB 10 bit Full range. And it works kind of great. Because we don't strugle with conversion after capture when supplying the VFX folks with DPX files. But it looks like FCP has a problem with this. We cant render anithing in this codec in final cut without clipping an crushing blacks.
But we can export without cnversion without problems.

This problem was discovered many years ago when we worked with a studio on Sin City. The problem lied in the Quicktime. Try a plug in for FCP called Glue Tools that will allow you to render back out to DPX and see if that solves your problem.

We have MANY customers going between RaveHD (which also has the option of capturing and working in full range) and Apple products. Most of them are using FCP simply for the Edit and all of the heavy lifting is being done on RaveHD.

In a nutshell.
Capture on RaveHD, bring DPX directly into apps (AE, FCP, etc), Edit and do the VFX magic, Render VFX shots back onto to RaveHD. (RaveHD can be a network mount you can render directly to)

From there they can take the CMX from the edit and conform on the RaveHD for print to tape, color, dailies, etc...

Keeps the image what it should be, no issues with codecs :)
Pretty much all of our customer base are the high-end houses where this must work flawless....Mostly all film-out projects where full range is a standard part of the workflow. We started in VFX and built the product around those needs first and understand all this very well.

*Added note RaveHD does support converting DPX to QT and other formats if a studio doesn't need to edit with full uncompressed frames.

yep, I know glue tools.
Well we don't really have a problem, we use aja's QTtoDPX tool to convert the captured rgb qt files to dpx for vfx.
As long as we don't let FCP or any qt based software touch the material we're fine :-). except after effects 8, with their new media core, so that our comp tool right now.
BTW i'm looking forward to the new version of glue tools, it has been announced that there should be easy setups for dpx = real time dpx playback in FCP. Now we just need capture :)

RaveHD was designed to handle this type of project. Lots of hidden tools that aid in the overall workflow such as conforming and now database asset management to boot.

AND

If your not working in 4:4:4 we have a new cost effective system (the cats out of the bag). This information is not public yet (it is making its way onto the website) so please email me off list and I will pass on prices and info.

IF

You are working in 4:4:4 our current solution is still a very cost effective solution in comparison to others.

We are worldwide and sit very heavily in feature film work. Last major projects were Spiderwick, U23D, Enchanted, and Horton to name a few.

RaveHD is a turnkey solution so you get the RaveHD application, all components and storage. It's a unit that is a Linux server that thinks it's a VTR.

Difference between RaveHD and VTR exchange.....the hardware is all tied together to make it work right. We wrote our own drivers for the AJA and LTC boards (which are both great hardware solutions) along with the entire RS422 library. No third party stuff. Not an easy task but it produced a solid solution :)

Software applications rely on the hardware around them and do not always have control of their environment. i.e. if an application sits on a system with other applications, conflict can occur, better yet hardware conflicting with hardware. We see this everyday and there are numerous threads about why something doesn't work. It's not the app or the hardware the app was written for, it's everything else in the mix.....

An application designed around hardware and that can control the hardware environment will always prove to be better. Will just software apps work, absolutely but be weary of the conflicts you may cause by installing that mysterious device you bought at Frys....

VTR exchange is a great app, built by a company who makes great hardware (grobble, grobble) put it on a system that it was designed around it will just run, but really how many people really leave their systems alone. Everyone needs to multi-task everything these days.

Me. I just want that black box that I can turn to and that I know will work each and every day.

LOL ( BB does not read this forum)
and you do know you cannot online with Rave HD either don't you.... : [

"Me. I just want that black box that I can turn to and that I know will work each and every day. "

So true, too many people now a days forget that for many people content is not ever acquired by the editor or editing platform and with Tapeless acquisition at the mainstay of production - professional tools like Rave HD are becoming more and more common on-set.

Actually you can use RaveHD a couple of ways in regards to this. Since RaveHD is a Linux server you can mount directly to it and apps that use DPX frames natively, well it's just like a freakin big drive to the host system. I have seen this used with Apples Color product this way (I'm sure many others I just remember this one because it was so easy to set it up). Other apps (editors) can absolutely work the same way. This is one of the benefits of RaveHD, it's so open and plays well on the playground with others.

Native timeline editing in RaveHD. The time has finally arrived. Throw in the native database support we rolled in and online/offline editing/conforming/etc.is pretty sweet and different than any other applications approach (straight forward and non-proprietary, go figure). This of course addresses a much bigger workflow solution that I am not letting onto here but you will begin to see the light shortly.

[Martin B. Wehding]" we don't strugle with conversion after capture when supplying the VFX folks with DPX files. But it looks like FCP has a problem with this. We cant render anithing in this codec in final cut without clipping an crushing blacks. "

Martin
I am going to second Ramona's comments on Glue Tools. it allows you to handle the DPX files directly within FCP by creating a QT "wrapper" or REF file that points to the original DPX frames, it is by far the simplest and easiest way to work with DPX content from VFX or even RED sources.