SDK - that's not hype...

[Patrick Tresch]

Patrick, as you know Assimilate is the only one with full R3D integration at the moment.

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

 

[Simon Blackledge]

Which 3rd party are you talking about here?

s

 

[Gunleik Groven]

Wild guess: Iridas...

That the SDK is not going towards GPU accelerated solution is indeed strange.
Everyone wants REDRAW workflows (without doubling the data like the Apple prview does)

But there are of course no policy which is stopping this from happening.

 

[Sanjin Jukic]

Wild guess: Iridas...

That the SDK is not going towards GPU accelerated solution is indeed strange.
Everyone wants REDRAW workflows (without doubling the data like the Apple prview does)

But there are of course no policy which is stopping this from happening.

Gunleik,

don't forget that Patrick is a Swiss.

Could be more like a Swiss made Chrome Imaging's Matrix from Geneva.

 

[JanneJansson]

All CPU intense jobs with huge amount of independent tasks (separate frames/pixels) will benefit gigantormosly by being GPU run....but!
To rewrite a normal SDK to make use of the GPU is not a easy task.. just now In a year or two, every other home hacker can do it.

 

[RivaiC]

I still believe RED needs to focus what need to be done first. Make the RED ONE steady before jump into the next product. But Jim wont go that route anyway....

 

[Stephen Williams]

Gunleik,

don't forget that Patrick is a Swiss.

Could be more like a Swiss made Chrome Imaging's Matrix from Geneva.

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

 

[Gunleik Groven]

I still believe RED needs to focus what need to be done first. Make the RED ONE steady before jump into the next product. But Jim wont go that route anyway....

RED ONE is steady (here @ least), and unless they choose to abandon RED RAW for the next cameras (which is sorta unlikely... ) I don't really see the conflict of interest you are suggesting.

There may be other conflicts of interest, but not with an ongoing cameraprogram.

Just my 2mill Icelandic Kronur...

 

[RivaiC]

i'm not talking about the steadiness of camera. I dont have any problem with my camera either, other than the EVF itself. There're lots of things that RED needs to do beside that, SDK is one of them, Adobe Plugins, Avid stuff (future), etc

 

[Lin]

Wild guess: Iridas...

We don't talk about SDK internals, so whoever Rivai called, it was not us.

We have a working R3D plug-in that is entering beta next week.

Best,
Lin

 

[Jeff Kilgroe]

Tresch, and others...

The SDK license agreement is a non-disclosure agreement of sorts. There are many things that really are not to be discussed to those who have not signed the agreement. But some things have been openly discussed around here before.

The SDK is what it is for now and it's an evolving piece of software. Some of its limitations have been discussed online and I'm not sure that was appropriate or not.

Other than that, what RED has given with the SDK seems fairly well written and it's super easy to work with.

To insinuate that the RED SDK is badly written software or that RED is not pushing for something that is "state of the art" is very short sighted. They are working to build a complete SDK and give all developers (and customers) what they want. Like their other software tools, it takes time. And this is all still very much beta software. They have given us something to build off of and have arguably given us more than Sony, Panavision, Thompson and Panasonic have ever given any of their customers or potential developers. Many of the developers wanting to jump on the bandwagon now, had no interest in RED last year or even long before that when RED was openly pursuing software partners.

 

[Sven Seynaeve]

To me it seems, after being in contact with some grading sollutions representatives for finding the best sollution right now, nobody seems to answer without hesitation.

Everybody seems to promise that they will or are already handling r3d files directly, but if you ask a little further they get stuck and change subject somehow... and there you get at the point you once were...

Imho RED should give us a little more info on what is going to happen with 3rd parties in the next future, because it doesn't make sense paying less on a camera system, but then picking up the wrong edit and grading sollution and losing a lot more money on this side when things could have gone another way.

Picking the wrong post-sollution could kill your business...

 

[Jeff Kilgroe]

I don't think RED can comment on third parties... They have released an SDK, it's up to third-parties to make use of it. RED is not doing any sort of detective work or dictating what applications third-parties can make. I'm sure RED knows nothing about 99.9% of what is being developed out there since the SDK was released.

There are currently limitations to the SDK and this will improve, but the foundation is there and the SDK is perfectly usable to release a commercial product. Some developers may be holding out for specific features or unable to make their intended application until the SDK offers some specific functions (I actually fall into that category). But at this time, the SDK is perfectly capable of loading R3D data, debayer that at any level of quality from full all the way down to 1/8th or whatever, and place that into an RGB or YCrCb framebuffer with plenty of headroom.

Notice Lin's post right above my previous post -- Iridas is going to beta with an R3D plugin next week. The tools work, solutions are coming. This doesn't happen overnight.

 

[RivaiC]

No Lin, i'm not talking about Iridas. It's best if RED can take things a bit steady . I'm very excited about 13th November and so on. But i'm even more concern in a good way about current situation like Adobe plugins and all. I never whine about this, still slowly waiting for an update. We will see

 

[Gunleik Groven]

We don't talk about SDK internals, so whoever Rivai called, it was not us.

We have a working R3D plug-in that is entering beta next week.

Best,
Lin

Realtime?

Gunleik

 

[Patrick Tresch]

I'm sure RED knows nothing about 99.9% of what is being developed out there since the SDK was released.

Sorry but I'm sure your wrong. And those who pushes for an optimal SDK are in contact with RED. So the SDK developper know what the needs are.

No Iridas is not the one, nor Autodesk, but both are encontring poblems. Why should Autodesk promote a DPX/Crimson workflow if R3D is much more efficient ? (less time consuming / fewer disk space and speed / better quality).I'm happy to know that Iridas found a solution hope it's RT.

http://www.postmagazine.com/Media/Ma...er final.pdf

We have to be clear that with or without SDK the developper will do their money with DPX standard, but it's in REDUSER's interest that the SDK is developped!

Patrick

Happy Halloween! :holloween:

 

[I Bloom]

Sorry but I'm sure your wrong. And those who pushes for an optimal SDK are in contact with RED. So the SDK developper know what the needs are.

No Iridas is not the one, nor Autodesk, but both are encontring poblems. Why should Autodesk promote a DPX/Crimson workflow if R3D is much more efficient ? (less time consuming / fewer disk space and speed / better quality).I'm happy to know that Iridas found a solution hope it's RT.

http://www.postmagazine.com/Media/Ma...er final.pdf

We have to be clear that with or without SDK the developper will do their money with DPX standard, but it's in REDUSER's interest that the SDK is developped!

Patrick

Happy Halloween! :holloween:

Patrick,

It sounds like you are responding to a lot of misinformation by distributing more misinformation.

I'd just like to point out that the Crimson->Autodesk workflow is about as popular as the Crimson->Scratch workflow. A sign to me that the dream of a completely compressed raw workflow, may be just that for the next few years.

We shall see I guess.

IBloom

 

[Patrick Tresch]

Patrick,

It sounds like you are responding to a lot of misinformation by distributing more misinformation.

I'd just like to point out that the Crimson->Autodesk workflow is about as popular as the Crimson->Scratch workflow. A sign to me that the dream of a completely compressed raw workflow, may be just that for the next few years.

We shall see I guess.

IBloom

Ibloom,

Be sure I don't have anything against your great tool.

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

But you probably got an argument saying R3D is not a way to go for postproduction...

Even so, it's faster/easyer/cheaper to confom and CC R3D with Scratch (last job I did we used the native R3D files) and it's a pitty that the actual SDK don't permit other manufacturers to be as competitive as Assimilate.

Ian, I hope this was not misinformation.

Patrick

 

[Gunleik Groven]

Patrick,
I'd just like to point out that the Crimson->Autodesk workflow is about as popular as the Crimson->Scratch workflow. A sign to me that the dream of a completely compressed raw workflow, may be just that for the next few years.

We shall see I guess.

IBloom

And that makes some sense...

 

[Jeff Kilgroe]

Sorry but I'm sure your wrong. And those who pushes for an optimal SDK are in contact with RED. So the SDK developper know what the needs are.

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. They know we want serious optimizations and better multithreading, 64bit support, CUDA/ GPU hooks, etc.. AFAIK, the R3D file format is still under development and they're not opening up yet because they don't want criticism over software breaking with each new camera build.

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.

I'm not sure who you're talking to, but I have to agree with Ian about spreading misinformation. The SDK does have lots of limitations, no denying that. But in its current form, there is no reason any third party who is seriously interested in supporting the format can't be integrating the R3D toolset right now and well on their way to making a usable product that will improve with each new SDK update. As for RT ability, that's a tough one. It will come with further optimizations and abilities added to the SDK. But more certainly with more powerful hardware. 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.

As for the RED workflow, gloom-and-doom rhetoric, it's so stale. I hear/read it almost every day. And yet, there are thousands of cameras out there and real projects going through post, every hour, every day. Those with post issues or the need to wait around for a "better" solution to present itself, can keep their issues while I and many others continue to work. If something better comes along, I'll upgrade. But I'm not going to speculate or start trying to peer into Big Jon's crystal ball and buy into some post solution that supposedly may be better in the future.