Welcome to our community

Be a part of something great, join today!

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

Two Weeks... Change is COMING!!

For those curious, the R3D codec uses heavily modified JPEG2000 for the encoding of image data. Right now, some of the fastest, hardware assisted JPEG2k implementations are still barely able to handle 30fps decode for 4k frames, and that doesn't include the demosaic process, etc. Because the JPEG2k is heavily modified (read "now proprietary"), it is unlikely that there will be any "3rd party improvements" to the performance of the codec.

Also, the nature of the R3D file format is such that it really is best suited for raw footage from the camera. R3D is still a lossy compression, which means you'll have generational loss if you decode, and then re-encode back to R3D. It doesn't make much sense (yet) to write R3D footage back out from the NLE. Obviously, RedRay will change this, but as the format stands now, it just doesn't make sense.
 
It should be pointed out that the major reason Cineform is able to get their codec to work so well for realtime 4k RAW playback, is that they are allowed to rewrite significant portions of Adobe Premiere Pro via Adobe's SDK.

In essence, they can wrap the NLE around the codec, and vice versa.

The Cineform / Adobe Premiere Pro relationship is therefore unique in the world of NLE's, and in my opinion will pack the most "horsepower" out of the gate.

-Thor
 
kylemallory said:
For those curious, the R3D codec uses heavily modified JPEG2000 for the encoding of image data. Right now, some of the fastest, hardware assisted JPEG2k implementations are still barely able to handle 30fps decode for 4k frames, and that doesn't include the demosaic process, etc. Because the JPEG2k is heavily modified (read "now proprietary"), it is unlikely that there will be any "3rd party improvements" to the performance of the codec.

Also, the nature of the R3D file format is such that it really is best suited for raw footage from the camera. R3D is still a lossy compression, which means you'll have generational loss if you decode, and then re-encode back to R3D. It doesn't make much sense (yet) to write R3D footage back out from the NLE. Obviously, RedRay will change this, but as the format stands now, it just doesn't make sense.
Click to expand...


The question is if at some point a new format may be introduced that moves on from I-frame only to kind of delta data compression. All the compression we see is purely single frame based. For RED RAY to accomplish the task of storing 4K footage on normal DVDs it'll be tricky to use just the current R3D format, as it will be too large when it comes to feature films. Or Jim buys HD-DVD, seems to be cheap thing these days :)

Anyhow, RED RAY will force the industry to quickly deliver 4K displays. There are many ways how one can build such thing cheap enough for mass markets...

Axel
 
Offhollywood said:
Would you like to bet me $1 million dollars?

You mean on the list on the PUBLIC forum?
Click to expand...

It was a while ago on the Premiere Pro CS3 forums, there is a thread called "Requests for CS4" or something like that. It was mentioned on there a while back, I have not heard any other news about it.

I will take your bet, but if I lose I don't pay you... :innocent:
 
Adobe has at least one Red, maybe more. This info was given to me by one of Adobe's inhouse software testers, so I know for a fact they are working on Red support. When or if it gets released, I don't know.

My money is on Cineform.

-Thor
 
Christopher Grant Harvey said:
It was a while ago on the Premiere Pro CS3 forums, there is a thread called "Requests for CS4" or something like that. It was mentioned on there a while back, I have not heard any other news about it.

I will take your bet, but if I lose I don't pay you... :innocent:
Click to expand...

would you like to change the bet to ONE RED CAMERA BODY?

you loose - I TAKE YOUR RED!
 
kinobairn said:
I think they'll start getting the respect they deserve. It would boost sales a ton. Although, I hope it is a free update.
Click to expand...

Agreed. If Adobe brought out a 3.3 patch for Pr with any form of redcode support I will run naked around for a week!:sheep:
 
Warning: Long Winded Response!

Warning: Long Winded Response!

Thor Wixom said:
It should be pointed out that the major reason Cineform is able to get their codec to work so well for realtime 4k RAW playback, is that they are allowed to rewrite significant portions of Adobe Premiere Pro via Adobe's SDK.

In essence, they can wrap the NLE around the codec, and vice versa.

The Cineform / Adobe Premiere Pro relationship is therefore unique in the world of NLE's, and in my opinion will pack the most "horsepower" out of the gate.

-Thor
Click to expand...

I may be mistaken, but I believe that Cineform only displays 1k maximum in Premiere CS3. If the Cineform RAW codec is different than that, my mistake. But I don't think the Cineform RAW codec (which is for SI-2k support) is going to be relevant to .R3D support.

Premiere...

Personally, I am super excited about Premiere CSx supporting R3d clips natively. I want to offline in Premiere, export an EDL and conform in Scratch. That way at least one workstation can do it all. I'll still have Macs and FCP / Avid around for "real" editors to work on, but when it comes to conforming and tweaking I'd rather do it on a single system with Scratch and Premiere.

And Premiere CS3 is my personal favorite NLE at this point. If only Adobe can get it more stable with larger projects. It's still too memory inefficient and I'm forced to keep timelines down to under 15 minutes. Ideally I'd like to be able to consistently do 20-25 minute reels on a single timeline without any hint of a crash or memory hogging (for Master Collection inter-operability goodness which is sort of hamstrung by apps' insatiable appetite for memory right now).

Also being able to drag clips off the timeline back into the bin for a sub-clip is incredibly important, and I still can't figure out why this isn't supported in Premiere.

My guess is that if those two things can be addressed Premiere will find more open minded editors willing to give it a try on bigger budget shows.


4k Monitoring...

I think the need to view 4k is overestated. Monitoring can be useful at at many resolutions, and the only time I really feel the need to see every pixel is projected on a large screen (DI theater), or zoomed in for critical viewing of portions of an image sequence, and then only for projects destined for that type of distribution. And there the 4k projectors just don't hold up. The 2k Christie and Barco's have better image fidelity, especially in the blacks, than the 4k Sony at this point, IMHO.

Real-time + .r3d rendering...

What I agree fully on is the need for real-time and greater-than-real-time debayer/render farms. Noise reduction in a 4k debayer is critical to me even if I'm scaling to 2k afterwards - the noise characteristics are superior, and I get an extra 1/2 stop easily in the noise floor vs. doing a half res debayer for 2k.

And realtime is possible right now in the form of render servers. Throw a 1U rack with 64 3.x ghz cores (i.e. 8 blades w. 8 cores each) at your clip via Redline and you should be looking at greater than realtime:

@ 3 frames / second per 4k high quality debayer frame x 8 = @ 24 frames per second.

It's pretty standard in digital post production to work with render servers, and with R3D data requiring heavy processer power to render I'm going to guess that 32 core servers will be rather common on Red backends.


Realtime 4k debayer options with Scratch...

What I'm hoping for is that this becomes do-able with Scratch / RedCine. Right now the dependency on GPU (and lack of render-only license and workflow in Scratch) makes this 'challeging', but I can completely envision setups with Nvidia gpu's in blade servers all crunching away debayering and rendering multiple levels of grading simultaneously for rapid output to a SAN.

Remote Render services...

Also, I predict render services like Rendercore here in LA are going to offer remote render options for R3D at some point like they do now for vfx renders. Upload your .R3D files via ftp and download your finished DPX's minutes later - get an entire feature uploaded, rendered, and downloaded in DPX overnight. Not too different than getting your negs to a lab for prints. And if you have SOHONET or other ridiculously fast connection then things'll really fly!

cheers,

jt
 
lunacie said:
I may be mistaken, but I believe that Cineform only displays 1k maximum in Premiere CS3. If the Cineform RAW codec is different than that, my mistake. But I don't think the Cineform RAW codec (which is for SI-2k support) is going to be relevant to .R3D support.

jt
Click to expand...
Lunacie, I'm not sure where your perspective comes from, but to be clear, CineForm RAW is both camera and resolution agnostic. Silicon Imaging uses CineForm RAW, and we worked closely together during the camera development, but CineForm RAW is not specific to SI, nor is it specific to 2K.

Today we have converters publicly available that support 4K Dalsa footage and 4K Vision Research Phantom footage by conversion to 4K CineForm RAW. In fact we have both a music video and feature film projects teed up with Dalsa. Although not released, we also support Arri D20/D21. As all those cameras shoot uncompressed RAW, it is easy to convert them into CineForm RAW at the resolution supported by their sensors, maintaining the benefits of RAW data, but with the very high performance, quality, and workflow of our compression format.

Also, there is no resolution restriction within Premiere Pro or any other application. Virtually no monitors are 4K, so we leverage the multi-res decoding nature of Wavelet algorithms to dynamically decode to either 1K or 2K, but you can also decode to full resolution.

As DeBayering is built into our algorithms, we perform a "dynamic" DeMosaic (meaning you can choose different DeMosaic algorithms) depending on what you are doing in your workflow at the time and what resolution you are decoding to. If you "park" on a frame and want to look at it in full-res 4K (or even 400%) with the highest quality demosaic, whether in PPro, AE, or FCP, this is not a problem.

Like many third parties, we are waiting for the Red SDK. We don't know the features that will be available yet, but we expect to be able to convert from R3D to CineForm RAW files through the SDK in a manner similar to the short-lived converter that we made available last January.

The result will be a real-time online 4K editing workflow in PPro on Windows or in FCP on Mac. (FCP only supports up to 4000-wide rasters, so we can edge-crop 96 pixels from a 4096-wide source at the time of conversion to CineForm RAW).

All the information I have presented about our 4K workflow is available for Dalsa and Vision Research cameras today, so it is not as if it is "hidden". Support for Red is of course a big deal for us, and for a few users on the forum. But because is our workflow is pretty highly developed, Red support is mostly a matter of converting files using their SDK when it is made available. Again, we have no specific insight on features or performance of the Red SDK yet, but we eagerly await its release.
 
lunacie said:
Real-time + .r3d rendering...

What I agree fully on is the need for real-time and greater-than-real-time debayer/render farms. Noise reduction in a 4k debayer is critical to me even if I'm scaling to 2k afterwards - the noise characteristics are superior, and I get an extra 1/2 stop easily in the noise floor vs. doing a half res debayer for 2k.

And realtime is possible right now in the form of render servers. Throw a 1U rack with 64 3.x ghz cores (i.e. 8 blades w. 8 cores each) at your clip via Redline and you should be looking at greater than realtime:

@ 3 frames / second per 4k high quality debayer frame x 8 = @ 24 frames per second.

It's pretty standard in digital post production to work with render servers, and with R3D data requiring heavy processer power to render I'm going to guess that 32 core servers will be rather common on Red backends.
Click to expand...

Agree.

I also wanna see someone can make a background renderer software for RED CINE and RED ALERT.
So we can still working with other shot/project although it's rendering on the same workstation.

Something like Nucleo Pro.
 
Thanks for the info, David.

It's good for everyone to have accurate information about their options.

-Thor
 
You must log in or register to reply here.
Back
Top