SDK - that's not hype...

[Dj Joofa]

No system out there today, short of a large compute cluster, even with a perfectly optimized SDK, is going to give full quality debayer from 4K REDCODE at real time, let alone give full color grading tools on top of that.

I don't know how can one substantiate that statement ... It should be doable. Systems out there exist which are doing more complex stuff in realtime ....

 

[Jeff Kilgroe]

Systems out there exist which are doing more complex stuff in realtime ....

Such as?

Yes, it is do-able, but no off the shelf system is going to do it right now. It's going to take a specialized hardware and software combination to do it and no one has announced such a thing yet. I keep looking to AJA to be the one... Large compute cluster may be an extreme claim, but then again, if a single off the shelf workstation isn't going to get it done, then multiple systems of some sort are needed, or additional specialized hardware.

I also fully believe that if someone, like AJA, came to RED with a plan to make a REDCODE accelerator card, RED would work with them and give them the support they needed.

People under-estimate the complexity of decompressing the wavelet structures and then applying a quality debayer process. I bet an 8-core nehalem workstation (should be able to buy these within 4 to 5 months) with properly optimized software and GPU access for color and image transform functions could probably do it. Today, it's a stress on current 8-core systems overclocked to 4.2GHz to play back 2K via a half-res HQ debayer from 4K RC36. And that often doesn't even work 100%.

 

[M Most]

Just wondering why the biggest player in postproduction (Autodesk) still promote DPX instead of the use of native 12bit REDcode?

Probably because there is no Linux development kit yet. And almost as probably because they feel that working with uncompressed DPX files uses the computer resources in more useful ways than attempting to do a real time debayer process at high quality. I don't necessarily agree with that in all cases, but it's a valid view.

 

[Bruce Allen]

Glad you're so sure. :sarcasm:

Just as with camera hardware, RED is listening to what people want in the SDK and software tools. They know those of us with the SDK want full access to the R3D file structure. They know we want full access to the RAW data to create our own debayer methods and work with our own optimizations.

Yes.

They can only deliver so much in a given amount of time. Like the RED One and current RED software tools, the SDK is a work in progress.

STEP 1: find alread-exsiting R3D file spec document on Red server

STEP 2: email R3D file spec to developers

HOW IS THIS SO DAMN HARD?

Bruce Allen
www.boacinema.com

 

[Dj Joofa]

Such as?

Next time when you are in Austin, just let me know, and I shall take you to an amazing tour of technology.

 

[roryhinds]

is the SDK being written by RED or by Assimilate?

I believe RedCine is written by Assimilate so that explains its slow development and restricted features.

Post is the biggest problem facing RED shooters at the moment, unless you've dropped $80k on Scratch.

 

[Jeff Kilgroe]

STEP 1: find alread-exsiting R3D file spec document on Red server

STEP 2: email R3D file spec to developers

HOW IS THIS SO DAMN HARD?

That isn't hard... But is that really what would be in RED's best interest? The problem with giving out that information at this time is it removes control from RED as to how the image looks. Some companies have very good RAW / debayer capabilities (Iridas as an example) and would probably do well. OTOH, if you have Joe Developer who turns out a half-ass debayer algorithm and beats RED to market with a CS4 plug-in (hypothetical example), then what's to keep the majority of people who download it from assuming that the problem is with the camera, and not with the third party software?

We will get access to the data and file spec at some point. But now is not that time. As much as I want the file spec myself -- my planned application depends on this knowledge, I'm going to have to side with RED on this one.

Next time when you are in Austin, just let me know, and I shall take you to an amazing tour of technology.

I could take you on a hell of a tour here too. But seriously, give me an example of a commercial product I can buy today that would be accessible to most of the RED ownership here. Even the big expensive guys like DVS with thier Clipster4K can't do RT playback *AND* CC on files that have already been processed into natively supported and/or uncompressed data formats, let alone try to do a decompression and full quality debayer on such data.

 

[Lucas Wilson]

is the SDK being written by RED or by Assimilate?

I believe RedCine is written by Assimilate so that explains its slow development and restricted features.

Post is the biggest problem facing RED shooters at the moment, unless you've dropped $80k on Scratch.

ASSIMILATE is not writing the SDK.

As far as REDCINE, stick to things you know, instead of harmful speculation.

The "problems with post" argument is soooooo tired. SCRATCH is *far* from the only answer for RED post.

Sorry for the abrupt response, but people complaining at this point that ASSIMILATE and "Red's deal with Assimilate" is what is holding up successful post-production is quite simply ludicrous.

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

 

[Lucas Wilson]

I don't know how can one substantiate that statement ... It should be doable. Systems out there exist which are doing more complex stuff in realtime ....

Raw horsepower is far from the only factor here.

Lucas

 

[roryhinds]

Sorry Lucas, just sharing my view on things.

The impression we get is Scratch is the only system that works with r3d files natively.
Is it not?

Is REDCine not written by Assimilate?

 

[Dj Joofa]

But seriously, give me an example of a commercial product I can buy today that would be accessible to most of the RED ownership here.

Jeff, this is a RedUser forum, and I don't do advertising for our own and other people's work and products here. But, of course, I can comment on my understanding of how complex a system should be in order to do stuff you mentioned in your original message.

Raw horsepower is far from the only factor here.

Lucas, you have to give me some benefit of doubt here, for me to appreciate what exactly is needed besides raw horsepower. Trust me, unlike many people out there, we deal with such things with our own raw hands every day.

 

[Bruce Allen]

That isn't hard... But is that really what would be in RED's best interest? The problem with giving out that information at this time is it removes control from RED as to how the image looks.

Some companies have very good RAW / debayer capabilities (Iridas as an example) and would probably do well. OTOH, if you have Joe Developer who turns out a half-ass debayer algorithm and beats RED to market with a CS4 plug-in (hypothetical example), then what's to keep the majority of people who download it from assuming that the problem is with the camera, and not with the third party software?

This did not happen at all with DSLRs.

Care to give me an example of people saying a Canon or Nikon DSLR is bad based on results with crap RAW developer?

If it looks like suck they'll swap software. Survival of the fittest. Healthy competition. Basic principle.

Bruce Allen
www.boacinema.com

 

[Deanan]

Hello,

I was just surprised of that statement and phoned some friends to know why the hell the SDK integration does take so long...

The friend told me that the integration has been done in 2 hours but...

The truth is that the RED SDK is really badly written and takes much more CPU power that it should and drops RT capabilities, wich makes it a no go for a lot of highend post-solutions. At the beginning R3D drop frames caused randomly crashes and it was very unplaisant to explain their customers that the system crashed not because of their software.

The SDK could also be written to be GPU only but they did such a "bad" job on the way R3D debayer is done and how it is encoded ( one exemple: SDK decodes in all rrrr then gggg then bbbb pixels when every displays read it in rgb/rgb/rgb... this slows the RT capabilites) that they are looking for works around to loadoff work to the background debayering to DPX to make it playable in realtime. (I'm not a sofware expert but it is what I understood...)

He also told me that every single change they ask RED, takes weeks to be implemented even if it would be a 15min work. SDK is clearly not RED's priority. More than one month has passed since last news.

These bugs made him concentrate on other priorities. I think I would have done the same... but at the end who are the loosers? Not RED, not my friend...

We all heard of november 13th...:sorcerer:

But there is another thruth wich is far from hype called :

SDK

I wonder why RED doesn't push for an state of the art SDK. I know that post-production is not their business, but making a camera and locking down the ability for other companies to have access to an efficient decode is

- not responsable
- not competitive (for non Assimilate post-production manufacturers)
- not fair to the customers

RED has to aknowledge that they have to put the tools in the hands of the industry to take advantage of their great R3D files.

What is the meaning of doing a 5k camera if 4k workflow doesn't yet flows?
What the meaning of selling thouthands of REDONE and a preview of ten of thousends Scarlett if there are only workarounds?

Third party graphic accelerators wich announced they would play natively realtime R3D files are also on hold.

This post is not inteded to blame nor to harm anyone. But as a RED user and a DOP I ask RED to push the SDK to a state of the art level wich will give me access to the tools that are standard in the industry.

Thanks

Patrick

There are hundreds of developers on the SDK program and alot of them are asking for custom stuff yet they all expect us to give them priority support and make changes exclusively for them.

Besides the SDK there's a todo list a mile long which includes keeping up with camera/format changes, apple, assimilate, adobe, other partners, future camera changes, bug fixes, core improvements, redalert,rushes,redline, qt codec, and on and on. Some of these benefit the sdk also and some don't but we can't drop everything to work on the sdk because everyone will still want something custom. The SDK is not a magical thing automatically makes everyone happy.

 

[Sanjin Jukic]

Hi,

From the accents at Chrome, I would guess there are many Americans working there, I believe approx 40% of Geneva residents are foreign.

Stephen

UN HQ is there and many more international organizations of a different types. And of course the banks are there too.

No doubts about Geneva's international identity.

 

[Stacey Spears]

Is REDCine not written by Assimilate?

My understanding, and I could be wrong, is that ASSIMILATE builds a DI platform called ASSIMILATOR. Both SCRATCH and REDCINE are built on top of this platform. ASSIMILATE wrote the SCRATCH application and RED wrote REDCINE application. Again, this is just my understanding.

 

[Bruce Allen]

Deanan, just tell Jim you need a suitcase of money, another 50 coders, plus scantily clad girls bringing everyone grapes. Or else you'll mutiny, leak the file format docs and tell us to go bug all the 3rd parties

Bruce Allen
www.boacinema.com

There are hundreds of developers on the SDK program and alot of them are asking for custom stuff yet they all expect us to give them priority support and make changes exclusively for them.

Besides the SDK there's a todo list a mile long which includes keeping up with camera/format changes, apple, assimilate, adobe, other partners, future camera changes, bug fixes, core improvements, redalert,rushes,redline, qt codec, and on and on. Some of these benefit the sdk also and some don't but we can't drop everything to work on the sdk because everyone will still want something custom. The SDK is not a magical thing automatically makes everyone happy.

 

[Lucas Wilson]

Sorry Lucas, just sharing my view on things.

As am I.

The impression we get is Scratch is the only system that works with r3d files natively. Is it not?

With the SDK out, at this point, define "natively."

It is currently the only system that works with R3D files in the way it does. But I know an awful lot of people doing a great job with RED post that do not own SCRATCH. Saying "Post is a big problem unless you own SCRATCH" is just wrong. Would I like for everybody to own SCRATCH? Sure! But you don't have to have it to build successful pipelines.

Is REDCine not written by Assimilate?

As I have said many times on this forum, REDCINE is a collaboration between RED and ASSIMILATE.

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

 

[Shane Betts]

Just a little perspective here for all those who say that the RED workflow is too complex or a workaround.

This camera is not a replacement for an HVX or even HDCam, this is a digital 35mm. So here's a link to Avid's recommended workflow schemes.
http://www.avid.com/resources/workflows/advanced_workflows/index.asp

Just click on the link for feature films and tell me the existing RED workflow isn't way less convoluted than that.

Sure it could be and should be much simpler than it currently is but, like I said, perspective...

 

[Mike Harrington]

That isn't hard... But is that really what would be in RED's best interest? The problem with giving out that information at this time is it removes control from RED as to how the image looks. Some companies have very good RAW / debayer capabilities (Iridas as an example) and would probably do well. OTOH, if you have Joe Developer who turns out a half-ass debayer algorithm and beats RED to market with a CS4 plug-in (hypothetical example), then what's to keep the majority of people who download it from assuming that the problem is with the camera, and not with the third party software?

the image can be ruined by many proceses....
starting with the lens...
if I use a garbage lens, then it's possible people will think it's the camera
if i do an 8 bit color grade and have banding everywhere....it's possible people will think it's redcode compression....

you can never control that....
what Red can do is certify raw debayer's that they believe represents the camera's quality....and wash there hands of the rest.

and there are a few out there who are quite capable

not bashing Red here...just don't agree that controlling the debayer will protect the reputation of the camera....the camera's quality can easily be established as it is measurable and quantifiable....

The reputation that needs protecting....is the openness of the workflow
People I know have lost Red jobs from fear of the workflow....valid or not

 

[Emmanuel Cambier]

Red and Assimilate collaboration

Red and Assimilate collaboration

As I have said many times on this forum, REDCINE is a collaboration between RED and ASSIMILATE.

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

Hi Luki,

As much as I enjoyed using RedCine for the first time a year ago (thanks), I have to tell you how disapointed I stand today of the collaboration between Red and Assimilate.

RedCine looked good last year when we thought this was just the first draw of meaningfull Post solutions for the red community.

A year later RedCine is still the same AUTISTIC program that will allow you to nicely optimize your R3D files, but when it comes to output those files in a meaningfull and convenient way, this is age stone.

If it wasn't for Crimson, Redcine would be hardly usable without loosing huge amounts of time and resources.

Even with Crimson, the time it takes for RedCine to output is kind of lame when compared to RedLine or Clipfinder.

By the way ClipFinder is a great aplication that shows what could have been easely done during the last year, with what seems to be little effort and plain goodwill.

I am confident Scratch is a worthy program that deserves all the attention it gets, but I can't help to think that the Red-Assimilate collaboration have been beneficial to Assimilate, mostly.

A year later the Red community is still orphan of an affordable way to work efficiently with R3D files.

I don't put the blame solely on you, but am forced to say that your help hasn't bear the fruits I expected.

Now that the SDK is out, I pray that we finally get what we need.:meh:

Emmanuel