Adobe/Cineform/Iridas Workflow?

[Edgar Pitts]

I know that the current SDK and R3D format prevents Cineform from converting directly to Cineform RAW, but we are looking to lock down and test a workflow for an upcoming feature film.

We will be editing in Premiere with the Cineform codec, finishing in AE and grading in Speedgrade. My questions pertain to Cineform and how their different codecs (4.4.4 and RAW) work with the Speedgrade products.

We would like to purchase Speedgrade XR and grade RAW footage. With the current limitations R3D and Cineform, this puts us in bind.

Are there any advantages or disadvantages for the 4.4.4 versus RAW workflow with this setup? AE integration and performance is also an important issue for us as well.

Thanks.

Edgar

[David Newman]

The CineForm SDK is part of the Speedgrade product line up. As we do allow RAW conversions with the new R2CF tool, SpeedGrade XR will work fine. 444 is also supported by the same CineForm SDK, with the same features and quality of RAW decodes. What I don't know is whether CineForm 444 is active with Speedgrade XR, that will be under Iridas's control.

[Lin]

Yes, Cineform 444 works in SpeedGrade XR, as do all Quicktime, AVI or RAW-based file formats.

We are also showing native REDCode support at IBC, based on the RED SDK.

Lin

[Nils Ruinet]

We are also showing native REDCode support at IBC, based on the RED SDK.

Lin
Is that without transcoding, similar to Scratch ? (I mean realtime)
Or does it perform a conversion to DPX first ?

[Lin]

Is that without transcoding, similar to Scratch ? (I mean realtime)
Or does it perform a conversion to DPX first ?

Yes, without transcoding.

Transcoding to Cineform first however makes it easier to achieve real time speed, as they currently have an edge over REDCode, performance wise.

Lin

[Edgar Pitts]

Thanks for the responses everyone.

David - That is great that you can now transcode to Cineform RAW. We will be getting our first Red test footage shortly, and I can not wait to jump into this new workflow.

Lin - Is there a performance difference or advantages between Cineform 444 and Cineform RAW in performance on Speedgrade XR?

Edgar

[Lucas Wilson]

Is that without transcoding, similar to Scratch ? (I mean realtime)
Or does it perform a conversion to DPX first ?

Just want to clarify - and Lin, please correct me if I am wrong!!!

SCRATCH does not perform a transcode at all, but accesses the R3D files natively. There is no delay in load-in time for R3D files. Loading 100 files will take about 1 second.

Speedgrade does perform a transcode, but not to DPX, rather to Cineform, so they do get the goodness of Cineform - smaller size, faster transcode time, etc.

But it is not a realtime directly from R3D process, and it is not the RAW media.

Best,

Lucas
------
ASSIMILATE, inc.
LA, CA, USA

[Edgar Pitts]

These are two different things - R3D & Cineform files.

I assume that if you have already transcoded to a Cineform format you would not have to transcode in Speedgrade XR. Correct?

[Paris Remillard]

Just want to clarify - and Lin, please correct me if I am wrong!!!

SCRATCH does not perform a transcode at all, but accesses the R3D files natively. There is no delay in load-in time for R3D files. Loading 100 files will take about 1 second.

Speedgrade does perform a transcode, but not to DPX, rather to Cineform, so they do get the goodness of Cineform - smaller size, faster transcode time, etc.

But it is not a realtime directly from R3D process, and it is not the RAW media.

Best,

Lucas
------
ASSIMILATE, inc.
LA, CA, USA

I don't want to speak for Lin, but what I read from his posts is that Speedgrade will have native R3D support just like Scratch does, without any transcoding necessary. If, however, you want faster performance, transcoding to Cineform will speed things up. As with Lucas, correct me if I'm wrong.

[Lin]

Just want to clarify - and Lin, please correct me if I am wrong!!!

SCRATCH does not perform a transcode at all, but accesses the R3D files natively. There is no delay in load-in time for R3D files. Loading 100 files will take about 1 second.

Speedgrade does perform a transcode, but not to DPX, rather to Cineform, so they do get the goodness of Cineform - smaller size, faster transcode time, etc.


Hi Lucas,

no, there is no transcoding involved. You click on the (RAW) R3D media and it plays. You can select the resolution (Full, Half, Quarter) and you can work with your native R3D footage.

As for my mentioning Cineform: Cineform has done a very good job designing a file format that performs very well. So they currently hold the performance crown. If you go through a transcoding step first, converting a R3D to Cineform in an offline process, you will have better performance without buying a monster machine. But the drawback is the offline process in between.

So with SpeedGrade XR it's your choice, work with R3D directly or with Cineform. Both open directly and instantly.

I am sure most other grading apps like Nucoda, Baselight, Quantel will have the same functionality soon. The SDK provides for this.

Hope this clarifies the question.

Lin

[Lin]

Thanks for the responses everyone.

Lin - Is there a performance difference or advantages between Cineform 444 and Cineform RAW in performance on Speedgrade XR?

Edgar

Cineform 444 is an RGB codec, so it contains data that has already been Bayer interpolated from the original RAW data. In the case of RED files, this bayer interpolation is produced by the RED SDK.

Cineform RAW is a RAW codec, containing the original sensor data in a compressed format.

The immediate difference is that RGB data is three times the size of the original sensor data. The Cineform compression does a good job at keeping the sizes down, but it still has to deal with more data.

Both file formats play in real time on a moderate off the shelf machine in SpeedGrade XR.

Cineform RAW is very fast in SpeedGrade XR because we can use our GPU-powered RealTime RAW 2.0 engine on it. So we don't have to go through the CPU, which is already busy decoding the compression, and offload the Bayer interpolation to the graphics card. That's the reason we can play up to 4K in real time in render quality for other cameras (D21, Phantom 4K, DALSA 4K).

If (when) RED allows access to the RAW data through the SDK, you will be able to playback 2K in real time on an off the shelf 4 core workstation. At current time, RED want to make sure the RAW is always interpolated in the same way, so they allow access only through their CPU-based algorithm, through either the SDK or the Scratch node. So there is no way to transcode from R3D to Cineform RAW and no way for us (or anybody else) to access the RAW data.

Opening up the RAW also opens up a can of worms for RED, since it's easy to implement a really crappy Bayer interpolation and the resulting pictures will then be blamed on RED. Maybe a certification process for HQ algorithms like RealTime RAW are the solution.

Lin

[Mike Zinner]

So there is no way to transcode from R3D to Cineform RAW and no way for us (or anybody else) to access the RAW data.

Well, no direct access to the RAW data but there is a workaround.

Cineform uses the RGB data that's made available by the RED SDK and interpolates it back to RAW data. This is slow and most probably results in a slight image quality loss but after this step you can use all the advantages of Cineform RAW.

[laguun]

Just want to clarify - and Lin, please correct me if I am wrong!!!

SCRATCH does not perform a transcode at all, but accesses the R3D files natively. There is no delay in load-in time for R3D files. Loading 100 files will take about 1 second.

Luki, yes, you are wrong - speedgrades raw support is much more advanced, what also can be expected from -the- pioneer of raw DI.

Its no different in speedgrade XR - it supports redcode directly.

But speedgrade XR supports also all the other RAW formats, which scratch doesnt:

ARRI D21 .ari
ARRI D21 S.Two RAW (.dpx)
Cineform (.avi/.mov)
DALSA Origin 4K RAW (.dpx)
Phantom HD/4K (.cine)
REDCode RAW (.r3d)
Silicon Imaging SI 2K/SI Mini (Cineform RAW .avi/.mov)
Silicon Imaging SI 2K/SI Mini (Uncompressed .siv)
Weisscam HS-1 RAW (.wcr)



Speedgrade does perform a transcode, but not to DPX, rather to Cineform, so they do get the goodness of Cineform - smaller size, faster transcode time, etc.

No. This is one additional option, which scratch also doesnt offer yet, but one can also work with redcode directly. Decoding to cineform before gading is an interesting option, as cineform has a faster than redcode in all applications and is also natively supported in many other applications which dont support redcode.

Also, speedgrade can use the GPU for debayering processes.
To use the GPU also for redcode, the sdk needs to be extended to raw data file access as well.


red should certify the state of the art manufacturers to access raw directly in the SDK - that way, even faster and better native DI options would be avaialble.

Its also important to understand that speedgade runs directly under OSX, Windows and linux - i however dont know if linux supports all raw formats.

[Lucas Wilson]

Its no different in speedgrade XR - it supports redcode directly.


If (when) RED allows access to the RAW data through the SDK, you will be able to playback 2K in real time on an off the shelf 4 core workstation. ... So there is no way to transcode from R3D to Cineform RAW and no way for us (or anybody else) to access the RAW data.

Laguun,

Read what Lin said. At the current time, they are not accessing the RAW data. So yes, it is different.

Speedgrade is a great tool for RAW workflow, and this is not meant as a putdown! I am just clarifying how things work.

Lucas

[laguun]

Laguun,

Read what Lin said. At the current time, they are not accessing the RAW data. So yes, it is different.

Speedgrade is a great tool for RAW workflow, and this is not meant as a putdown! I am just clarifying how things work.

Lucas

Hi Lucas,

speedgrade accesses the raw data -directly- through the red sdk, the debayer is in reds code. There is no need to transcode.

To further benefit of the advanced in-gpu debayer iridas has for all other 2K and 4K raw cameras, the red sdk needs to allow direct access to the JPEG2000 files, which is still missing.

[Lin]

Laguun and Lucas,

SpeedGrade accesses the R3Ds through the RED SDK, exactly like Scratch accesses the R3Ds through the Scratch Node that is available from RED.

At present time, RED gives nobody access to the RAW Bayer pattern. So both SpeedGrade and Scratch get a Debayered RGB image as a starting point for further processing.

If we had access to the RAW, like we have with other cameras, we could do some interesting things, but we don't.

So GPU-accelerated RAW is not possible with R3D at the moment. We may have that in the future. In the meantime we have to live in the real world, which, unfortunately, is the only place where you get a decent steak.

Lin

[Lucas Wilson]

Laguun and Lucas,

SpeedGrade accesses the R3Ds through the RED SDK, exactly like Scratch accesses the R3Ds through the Scratch Node that is available from RED.

At present time, RED gives nobody access to the RAW Bayer pattern. So both SpeedGrade and Scratch get a Debayered RGB image as a starting point for further processing.

If we had access to the RAW, like we have with other cameras, we could do some interesting things, but we don't.

...

Lin

Sorry Lin, but that is not correct.

SCRATCH does not start with the debayered RGB image. We start with the RAW file at the bayer stage. That is why - within SCRATCH - you have access to all the color metadata parameters contained within an R3D file and can access/change them through the course of a grading session.

Also, this may not be obvious because you are not a SCRATCH customer. ; ) But, the node that is on the RED page is no longer current. With the 4.0 release of SCRATCH, the "node" is no longer separately obtained from the RED website, but is an integral part of the SCRATCH installer.

But to be clear - we are not using a debayered RGB image as a starting point. We are using the RAW R3D file and have control of it as a RAW image.

Lucas
------
ASSIMILATE, inc.
LA, CA, USA

[David Newman]

That is why Lin and myself and looking forward to direct RAW access from SDK, putting all vendors on an equal playing field regarding R3D decoding. RED SDK does however allow you to control all the color metadata, the only missing feature is RAW bayer access which impacts performance opportunities.

[Edgar Pitts]

A certified vendor program sounds like the solution.

Red is obviously providing direct RAW access to Scratch, why not let some of the leaders in RAW also have direct access???

[Lin]

Sorry Lin, but that is not correct.

SCRATCH does not start with the debayered RGB image. We start with the RAW file at the bayer stage. That is why - within SCRATCH - you have access to all the color metadata parameters contained within an R3D file and can access/change them through the course of a grading session.

The parameters you are mentioning are accessible to us through the SDK as well.


But to be clear - we are not using a debayered RGB image as a starting point. We are using the RAW R3D file and have control of it as a RAW image.

Are you saying that you have created your own Bayer interpolation algorithms, that are different from RED's?

Lin

[Lucas Wilson]

The parameters you are mentioning are accessible to us through the SDK as well.

As you know, the SDK is a work in progress. Because of our long relationship with RED, we currently have access to more than is revealed in the SDK. That will change over time, as has always been REDs intent, and as they have said many times. But today, that is the way it is.


Are you saying that you have created your own Bayer interpolation algorithms, that are different from RED's?

We have access to the RAW data and can choose how we derive RGB data from the RAW frames.

Lucas
------
ASSIMILATE, inc.
LA, CA, USA

[Patrick Tresch]

:-) a Scratch seller told once smiling...

"the r3d sdk has been released, but we still will be the best..."

Did anybody test the difference between the Redcine/SDK debayer and the Scratch debayer?

I've seen a lot of noise on shots coming from Redcine debayer wich dissapeared once passed through a Scratch debayer... (no denoise was added).

Patrick

[David Taylor]

Being as Red is currently controlling the process for access to images (whether through RedCine, Scratch, or the SDK), and being as in the not-too-distant future there will be far more images produced through the SDK than through Scratch, it doesn't seem in Red's best interest to allow images delivered through the SDK to be inferior to images produced from Scratch. Red's positioning has always been "it's about image quality". If they live this credo then they'll want to deliver the highest quality images through the SDK to all of their third party partners.

[Patrick Tresch]

Being as Red is currently controlling the process for access to images (whether through RedCine, Scratch, or the SDK), and being as in the not-too-distant future there will be far more images produced through the SDK than through Scratch, it doesn't seem in Red's best interest to allow images delivered through the SDK to be inferior to images produced from Scratch. Red's positioning has always been "it's about image quality". If they live this credo then they'll want to deliver the highest quality images through the SDK to all of their third party partners.

Makes sense to me.

Now I hope RED will release the debayer code and beleave Iridas, Chrome, and the big players in DI business are taking their job seriously.


Patrick

[Lin]

As you know, the SDK is a work in progress. Because of our long relationship with RED, we currently have access to more than is revealed in the SDK. That will change over time, as has always been REDs intent, and as they have said many times. But today, that is the way it is.

I have no doubt that this is true. Fortunately we see no relevant things missing in the SDK at this stage, except for audio support.



We have access to the RAW data and can choose how we derive RGB data from the RAW frames.


You can choose how to derive RGB data from the RAW frames using RED's algorithms or using your own algorithms?

It is my understanding RED currently only allows their algorithms to ensure consistent picture quality.

True or false?

Lin

[Lucas Wilson]

I have no doubt that this is true. Fortunately we see no relevant things missing in the SDK at this stage, except for audio support.

...and performance limitations.


You can choose how to derive RGB data from the RAW frames using RED's algorithms or using your own algorithms?

Correct.

But... we work extremely closely with RED to ensure that anything we do is consistent with their pipeline and image integrity. We firmly believe that RED understands best how to treat their images and how to interpret them. And RED is constantly updating and improving how they deal with imagery from RED ONE. So, anything we do that is "different" in any way from RED's original plan is vetted and approved by RED before it goes anywhere.

Honestly, most of what we do has to do with performance enhancements, which is why we can load hundreds of R3D files in a matter of seconds, and instantly have all of them available for playback from the 1/2 rez high decode in realtime.

Lucas
------
ASSIMILATE, inc.
LA, CA, USA

[Jay A. Kelley]

Lin,

From what I understand, Assimilate got involved with RED and Jim long before there was a working camera. It's my opinion that, based on their early faith, their special treatment was well deserved. They were not so much a 3rd party vendor, as a "vendor partner". Of course this was a while ago, and now with the introduction of the SDK it could be asked the position is still such a hot idea. It's clear that Assimilate is still being given treatment and access to RED that their competitors are not. Hopefully this will change soon. :sarcasm:

Until then, it looks like you and a number of other companies are doing a fantastic job.

The cineform Solution is a good one to all of this, remember SCRATCH and SpeedGrade are FINISHING programs, and in my humble opinion, Cineform does a great job of being a fantastic solution for WORKFLOW. Once you get into Cineform at the editing stage you will be good to go from then on, all the way through finishing.

This brings up a question I had not thought of until now.. Luki, does Scratch support Cineform?

Jay

[John Tissavary]

You can read cineform Quicktimes with Scratch, but there is no AVI support in Scratch at all.

The two file formats that work best (performance / reliability) in Scratch are DPX (the winner) and R3d (comes in second - still some quirks here and there). I have read cineform files with no problem, but writing them is another story entirely.

For some reason, as with DNxHD, I have no luck writing Cineform QT's out of Scratch - which really bothers me on a nearly daily basis as those are my two favorite codecs to work with - both are indispensable in my workflow, and being forced to write DPX and re-transcode to DNxHD or Cineform really is a drag.


cheers,

John T.

[Mick van Rossum, NSC]

:-) a Scratch seller told once smiling...

"the r3d sdk has been released, but we still will be the best..."

Did anybody test the difference between the Redcine/SDK debayer and the Scratch debayer?

I've seen a lot of noise on shots coming from Redcine debayer wich dissapeared once passed through a Scratch debayer... (no denoise was added).

Patrick


Very important question indeed; is the Scratch debayer better than the redcine debayer? Lucas ?

Mick van Rossum NSC

[Lin]

Jay,

I am completely aware of the long relationship between RED and Assimilate.

What is important to me is to avoid having rumors going around that what comes out of the SDK is somehow inferior to what Scratch outputs.

Lucas just confirmed that they basically optimize for performance. That is something I think everybody can live with, because performance is easy to test.

We have some technologies in the pipeline that will make the performance penalty of working with slow-to-decode files, such as full 4K R3D files, irrelevant.

We hope that we will get access to the RAW, because we think we could improve on both performance and possibly even quality, something we have done for all other RAW cameras on the market. Our GPU-based RealTime RAW 2.0 Debayer is among the best algorithms out there and we have already started work on a RealTime RAW 3.0 for release at NAB 2009.

Cheers,
Lin

[Edgar Pitts]

Lin,

Can you point me to any whitepapers or additional details about the Speedgrade XR workflow? If a project is edited in Premiere and conformed in After Effects, how do you get the project into Speedgrade? Do Speedgrade and After Effects integrate at all?

Thanks.

Edgar Pitts
Producer
Jetrefilm Entertainment
http://www.jetrefilm.com