Is a ProResHQ Clip with the R3D instead of Proxies possible?

[indierider]

Just wondering? Is it possible to have a ProResHQ stand alone clip ride along with the R3D. The way I see it... if you bad ass enough to support an EPIC you should be bad ass enough to cut in ProResHQ.

 

[Craig Parkes]

Umm, this would mean debayering AND encoding a separate file to Prores in camera on the fly... To what is effectively a proprietary format in Prores. Lots of problems with that idea I think.

 

[I Bloom]

Delivering proxies does not mean debayering.

1K Prores in camera is a great idea.

IBloom

 

[Jeff Kilgroe]

Perhaps ProRes can be delivered via a proxy system rather than trying to do additional encodes in camera? More camera processor cycles and more media space used = bad, right? As of now, the proxies are a custom format QT accessed via a pointer to the R3D data. The codec does a debayer (1/4, 1/2 or full) along the way to feed RGB data. As far as whatever application you are using knows, it's just seeing a QT file.

What if the proxy system was expanded to give ProRes (standard or HQ) formatted data? So in addition to _P, _M, _H, _F proxies, you could have ones that are also tagged someting like _Mp, _Hp, etc.. indicating that they will load and work and be seen as a QT ProRes clip? The proxy codec system creating ProRes data on the fly... Should be possible as the debayer algorithms and codec system become better optimized and more refined. Eventually, we should have other debayer options within the control panel too, such as choosing for processing filters like Catmul Rom, Sinc, Gaussian, etc..

For this to work, it would probably also require a hook within the ProRes codec from Apple. But I suppose anything is possible.

 

[Craig Parkes]

Delivering proxies does not mean debayering.

1K Prores in camera is a great idea.

IBloom

Doh - Of course, no debayering... When I think about it if it worked a bit more like XDCAM then I think a lot of people's post issues would be gone....

 

[Brook Willard]

Considering the size of the ioHD... I'd imagine that hardware encoding ProRes requires some notable hardware. Obviously there are other chipsets in that sucker, but it's still no small piece.

Rather than focusing on adding ProRes support to the camera, I'd personally rather see RED create a more viable post workflow for their original codec.