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 :)

Adobe/Cineform/Iridas Workflow?

Lin said:
The parameters you are mentioning are accessible to us through the SDK as well.
Click to expand...

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.

Lin said:
Are you saying that you have created your own Bayer interpolation algorithms, that are different from RED's?
Click to expand...

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
 
:-) 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
 
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.
 
David Taylor said:
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.
Click to expand...

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
 
luki said:
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.
Click to expand...

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.

luki said:
We have access to the RAW data and can choose how we derive RGB data from the RAW frames.
Click to expand...

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
 
Lin said:
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.
Click to expand...

...and performance limitations.

Lin said:
You can choose how to derive RGB data from the RAW frames using RED's algorithms or using your own algorithms?
Click to expand...

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
 
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
 
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.
 
Tresch said:
:-) 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
Click to expand...


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

Mick van Rossum NSC
 
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
 
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
 
You must log in or register to reply here.
Back
Top