We need a Red SDK with the camera [Archive]

Jesse Wendel

05-26-2007, 04:55 PM

Yes, a SDK please.

As I just said in another thread, I already know I've got custom stuff I wish to do, which simply isn't possible absent access to the box and programmability.

From my point of view, you've got a computer running already. Of course I understand your need to keep your code walled off completely. I work with custom boxes every day. But most of these boxes, primarily hardened linuxes, even though the vendors handle updating the code, allow the analysts in charge of the servers for our data centers (the team I'm on), to scp or directly connect to the boxes if we want to do something, change a setting, or so forth. They are OUR boxes, so if we want to modify something beyond the interface, well, that's our call and our fate if we screw it up, including paying the service fee to fix it. Heh.

In fact, one of the purchasing decisions on the purchasing grids of my colleagues and I, is always, can we get into the box and modify stuff if we need to, or does this vendor feel they need to lock us out of our own box. Grrr.

I echo the call for a SDK and access to everything but the proprietary code of RED. As I said in another post, I already know development work I wish to do (or pay to have done, or actually, beg a friend to do for me), for example, encrypting to AES every frame prior to them being written to storage. So each frame is already AES encrypted when written to disk, flash memory, etc. That way, no one can read the data but someone with the passphrase. Period.

Shouldn't be hard. But will only work with a SDK and access to the data stream.

I'm certain other people will have other needs, desires, hopes and wishes.

Thank you for everything you've done to date. Best wishes,

Jesse Wendel/Seattle

Shawn Nelson

05-27-2007, 12:19 PM

Nooo...because the SDK can come after the camera is released. Please Red? SDK?

Clayton Harper

05-27-2007, 02:06 PM

Strong agree. Programmers standing by.

Joe Aurili

05-27-2007, 07:02 PM

yep, please SDK

Jarred Land

05-27-2007, 08:57 PM

Let's get the camera first, folks. Patience, like Silence, is golden.

Let the SDK come when it comes.

amen brother, amen.

Shawn Nelson

05-27-2007, 09:22 PM

amen brother, amen.

Oooh, so does this mean ya'll got an SDK cookin for a post-camera release?

Jarred Land

05-27-2007, 10:04 PM

it means lets build the camera first :)

Jay A. Kelley

05-28-2007, 05:33 AM

Perhaps it's just me, but given the amount of custom work going into this thing, and the nature of the industry in general... Let me put it this way: Are SDKs common in broadcast industry hardware, and does having one pose any Risk to RED at all? Or does it require a certain way of structuring code?

Questions worth asking

Jay

Mark L. Pederson

05-28-2007, 07:22 AM

Are SDKs common in broadcast industry hardware, and does having one pose any Risk to RED at all?
Jay

My understanding is NO.

Anyone have a Sony 950, Varicam, Viper or D20 SDK handy?? Do you have an SDK for your DSLR? (seriously, if you do, please email it to me)

Now, there is NOT MUCH that RED is doing that is "common in broadcast industry" - so, yeah, all bets are off -

There's a ton of intellectual property in that camera - and there are several other issues related to releasing an SDK - one is simply the EXPENSE of having engineers create the SDK - and that expense may be "opportunity cost", not just "hard cost" - and companies want their product to work they way the designed the product to work and third party "hacking" and "coding" makes companies very concened about their product fuctioning properly.

For example, I am sure APPLE is about to reluctantly cave on 3rd party apps for the iPhone (which I think is a good idea) - but this was a heavily discussed major "issue" -

But yeah, by definition, and SDK is "set of development tools that allows a software engineer to create applications for a certain software package, software framework, hardware platform, computer system, video game console, operating system, or similar."

So, I think it is REASONABLE to ask that AFTER THE CAMERA has shipped, that RED considers creating some kind of SDK that at least allows people "hooks" into controlling the camera functions - we shall see - and I will be pleading for it as well -

meantime - the more ideas you post for the RED TEAM on this forum, the more likely you will be to see more of the features you want in the camera when it does ship -

Jeff Kilgroe

05-28-2007, 09:33 AM

I wouldn't expect an SDK to ship with the camera... Lots of work still to be done.

And as offhollywood says, SDKs are essentially non-existent in the industry. Rare situations come around like ILM working with Panavision and Sony to modifiy the F900 for shooting Star Wars....

For a RED SDK, I'm not asking for, nor would I expect a full SDK where I can get into the innards of the camera, compile new OS tools, menus, etc.. For a RED SDK, I'm thinking of just a couple API libraries for Mac and PC that make it easy to directly talk to the camera via a couple ports. So in a sense, it's not even an SDK.

Would be extremely useful and could just start one more trend in the industry, allowing users to quickly integrate camera control into their own software tools. It would be really cool to have RED mounted on a MoCo head like VF's Mirus and have the head motion as well as camera settings be controlled by the same notebook computer while shooting timelapse or repeatable MoCo FX shots.

I would actually hope RED doesn't release a full SDK. Because of support issues and you'd have all sorts of people making various things to load onto a RED camera, with no guaranty of what they will ultimately do.

Apple definitely needs to cave on the 3rd party development for both the iPhone and the iPod. I don't think they should make it completely open, but if they at least opened up some form of developer program so we could have some decent games and utilities, that would be nice. iPod is supposed to play games, but when there's only a handful of re-hashed garbage to pick from, it's hard to sell it as a device that can actually play a game. I've got a few good ideas for iPod games once they go to larger multi-touch screens -- and that is not very far off.

Joe Aurili

05-28-2007, 10:01 AM

When I say SDK, I'm really just thinking of being able to trigger all of the functions of the camera remotely. Whether it is a SDK or API.

Keith Nealy

05-28-2007, 10:05 AM

You've all listed great reasons why and why not an SDK is a good idea from many points of view except this:

RED is leading the way into the digital revolution with a totally unique concept and business plan. There seems to be no doubt that cameras are moving in an IP direction. Because most functions are software based, it opens the door to great change, flexibility, and the development of tools that we can't even dream of yet.

It will be done eventually - no doubt about it. But will it be RED to lead the way? This is a marketing decision as well.

The more RED can distance itself from "normal" cameras, the more it will create a whole new class of cameras.

And if that new class can deliver, not only superior images, but operational tools never before found on a camera, it will command a dominating position in the camera world.

This thread is similar to others such as one about the intervalometer and frame accumulation mode. These tools are possible because it is just an alteration in the software code.

The question is not a matter of "should we do an SDK"... but when.

Of course, if it's not immediately, which is likely because of the work that needs to be done to get RED out the door, it should be considered and planned for as an upgrade because it will create an unbelievable marketing advantage that will secure its position as a revolution approach to cameras.

Quality AND control AND a price we can afford?

This is a no-brainer. It will happen sooner or later. But other RED immitators are being developed now that they see the potential.

RED needs to be the first, the biggest, and the best to create a commanding lead in the industry.

An SDK that offered full controll possibilities... open to third party applications, would create a new indusrty for plugins. We would be trading them like we do custom scene profiles or buying them like aftereffects plugins.

The possibilities are endless.

It's only a matter of will and courage.

If anybody has those qualifications it's Jim. so I predict it's not a matter of if... but when.

aloha,

Keith

Curran Giddens

05-28-2007, 10:27 AM

Would be extremely useful and could just start one more trend in the industry, allowing users to quickly integrate camera control into their own software tools. It would be really cool to have RED mounted on a MoCo head like VF's Mirus and have the head motion as well as camera settings be controlled by the same notebook computer while shooting timelapse or repeatable MoCo FX shots.

or even better, have RED mounted on a MoCo head like VF's Mirus and have the head motion as well as camera settings be controlled by the same software on a notebook computer.

or maybe that is what you meant.

Jarred Land

05-28-2007, 11:07 AM

Jesse Wendel

05-28-2007, 01:11 PM

an sdk would be valuable mostly for control since we have a usb host port on the camera.. for those applications, such as Curran's examples.

just dont expect it..... there is alot of development required to provide such a tool. if you get one eventually, consider it gravy.Jarred -

I certainly don't expect a SDK when the camera ships, but to go back to my original example, I have a shoot on which I want to encrypt to AES standard every frame of film in the datastream before it is written to the drives.

This would mean access via a SDK to, well, to what a SDK allows access to. Given that, it should be a fairly easy thing to do. Take the stream, encrypt it, send it to the drives for storage.

So it may be gravy to you, but it's super-tasty gravy to me. Sure, I could just shoot and record onto disk, then encrypt off-line, but that's literally doubling my work-flow, plus greatly increasing the risk of someone getting access to something they shouldn't have access to. Once the shot is encrypted, it doesn't matter whom has access -- unless they have the passphrase, they're not going to see the output.

A SDK isn't just about remotely controlling motion. It's about all the stuff y'all haven't thought of yet. It's about unleashing the creativity of the entire RED community, not to mention vendors. It's the difference between a great box that which adds and extends on to a category, and one which creates its own category and forever alters the domain for all which come after.

A SDK lets everyone else get in the game and makes it more interesting to play with your toy, then to go out and play with someone else's. By the time the competition comes along, everyone is so deeply in bed with you, other vendors won't care about the competition -- the question will be, "Is this RED compatible?" , just like the original IBM PC defined a new category when it came out and let people add and extend and build off its specifications. Apple did not, and while I love Apple, the original IBM specification took over and controlled the market, and remains in control of the market till today.

Are you going to be the IBM or the Apple of this new market you are inventing? That's the question I'm asking when I ask for a SDK. That ain't gravy. It's the entire market. Personally, I think RED should be the market-maker, and that means an open box.

Respectfully,

Jesse Wendel/Seattle

Jarred Land

05-28-2007, 01:28 PM

Shawn Nelson

05-28-2007, 01:36 PM

What are Jim's thoughts on all this?

Jay A. Kelley

05-28-2007, 03:30 PM

What are Jim's thoughts on all this?

I think Jim's off doing something right now Shawn, I wrote him a rather detailed and sincere note just yesterday but have not gotten a response.. He's working on something I am guessing

Jay

Shawn Nelson

05-28-2007, 03:50 PM

Jim is definitely busy, but he is on the boards even as you typed out that message.

Miltos Pilalitos

05-28-2007, 04:45 PM

I don't think an SDK for RED is really going to happen.

What Shawn is asking is not a Software Development Kit. He wants the tools to code his own RED firmware. Since the firmware is responsible for the way the RED will work and operate i am sure the RED team would not like the idea of people putting their hands in their baby's innards.

The i-phone's SDK that was mentioned is not a tool to change the way the i-phone will work. It's a tool to help you build applications for the i-phone's "operating system".

In the case that i am wrong about this and RED does allow straight access to it's processor and chipset from third parties i am sure that less than 5% percent of RED owners will be able to actually do anything useful with it. If you want to get a taste of what an SDK looks like you can download one for Eyeon's Fusion from here: http://www.eyeonline.com/web/eyeonweb/products/developer/developer_v5.aspx

You need good knowledge of C++ or scripting to do anything useful with it and this is just for software. I can only imagine what kind of skilset an "SDK" for hardware might require...

Shawn Nelson

05-28-2007, 04:55 PM

Miltos, I am a degreed Computer Science working as a software engineer for over 5 years, I know what an SDK is and that is what I asked for. I don't want to write new firmware to change Red nor change the innards. Re-read my original post, I was asking for the ability to access "Meta Data, USB port, SD Cards...overlay custom info on output". Does this sound like changing the fundamental nature of the camera to you? It sure doesn't to me. What I want is a tool to help me build applications on top of Red.

Lastly, C++ is not that difficult, I've used it for 7 years now.

EDIT: What Jesse wants to do with encrypting the frames of data as it's passed on would probably fit what you are talking about, perhaps you thought I was going that direction. But what I asked for was strictly the domain of an SDK and writing high level applications to do interesting things that would not touch their core software.

Miltos Pilalitos

05-28-2007, 05:10 PM

Hey Shawn, you must be part of that 5% i mentioned! :-)

In my opinion, Meta Data, USB port, SD Cards and especialy overlay custom info on output IS part of the firmware.

The only other way i see it possible to do what you want is if the camera has some kind of RED OS and some flashable chips that are solely for custom made code.

Anyway, i am sure only one of the RED team could answer that for sure.

Miltos

Shawn Nelson

05-28-2007, 05:27 PM

Changing the driver of the USB port or SD Cards would be firmware, but simply ACCESSING them would be an addon application, perfectly suited for use by an SDK. I'd love to be able to write an application that allows for someone with a Bluetooth enabled PocketPC to log comments wirelessly to a bluetooth SD card that Red then places up on screen. Things like that.

As for OS, I'd bet their using Linux. So you'd simply write for the same version they have and then they could expose their library routines and we could run with that.

Miltos Pilalitos

05-28-2007, 06:21 PM

If RED was indeed running Linux, doesn't it imply that to access part of its hardware you need Kernel access?

I can imagine a million things going wrong with such access. From simple infinite loops derived from buggy code to purposefully made attacks that could permanently damage the camera.

i have personally seen PCs (running WINXP) permanently frying from malware code with Kernel access (playing with the CPU voltage).

Even if all the above sound a little sci-fi and we could code stuff without Kernel access, what would happen if one of the "add-ons" was slowing the camera down or affecting something else in the camera's performance that was not immediately obvious?

Should RED also build a QA department to test custom made code and give approvals? Should we take the full responsibility for trying our code on a $17500 hardware?

I am not saying that what you are asking for is not cool. It is, but it raises a lot of issues that i personally don't care to see them resolved now. I don't want to receive my RED in 2 years! :-)

Do we all need an SDK as the title of this thread suggests? My answer is that if the RED team did it's job well we definitely don't.

Miltos

Shawn Nelson

05-28-2007, 08:15 PM

I don't aim to be antagonistic, but I'm getting the feeling you aren't a software engineer. You're diving headlong into techo-paranoia without knowing the full story.

If RED was indeed running Linux, doesn't it imply that to access part of its hardware you need Kernel access?
Nope, you can have read only access or limited access.

I can imagine a million things going wrong with such access. From simple infinite loops derived from buggy code to purposefully made attacks that could permanently damage the camera.
That's why properly developed code protects against such things. It would be very easy to make an SDK such that any user-created code could not take down the camera. So moving on...

i have personally seen PCs (running WINXP) permanently frying from malware code with Kernel access (playing with the CPU voltage).
Again, they would simply not allow such low-level access. Your argument is akin to suggesting that if you let someone open the hood to the car THAT THEY'll DESTROY THE ENGINE!! This seems like a statement designed to make people afraid.

Even if all the above sound a little sci-fi and we could code stuff without Kernel access, what would happen if one of the "add-ons" was slowing the camera down or affecting something else in the camera's performance that was not immediately obvious?
Again, you can make task managers that do not allow any user-created routine to be given enough processor speed to do such a thing. This is operating systems 101.

Should RED also build a QA department to test custom made code and give approvals? Should we take the full responsibility for trying our code on a $17500 hardware?
People can f1ck up their Red plenty without user-created code. QA departments are not needed to protect people, that sort of protection can be built into the Red.

I am not saying that what you are asking for is not cool. It is, but it raises a lot of issues that i personally don't care to see them resolved now. I don't want to receive my RED in 2 years! :-)
Uh....we've already established that we aren't asking for this before ship.

Do we all need an SDK as the title of this thread suggests? My answer is that if the RED team did it's job well we definitely don't.

You're not grasping the potential here. Maybe you would never need it, but a lot of us would.

If you don't want an SDK then fine, never use it! But your worried attacks on such an idea are puzzling. By all means, never let your Red see user-created code. But please, cool off so those of us that do can proceed without unnecessary talk of the sky's impending collapse.

Jeff Kilgroe

05-28-2007, 09:03 PM

or even better, have RED mounted on a MoCo head like VF's Mirus and have the head motion as well as camera settings be controlled by the same software on a notebook computer.

or maybe that is what you meant.

Yeah, that's pretty much where I was going with that. :)

david farland

05-28-2007, 09:09 PM

I believe what Shawn wants is for Red to publish their api so 3rd parties can talk to it. This has been done a millions time (probably!) before.....depends on how closely red wish to hold onto their licensing of 3rd party tools, as to whether they will or not. They realise 3rd party integration is vital, it's just what paradigm they'll use to distribute access.....anyway as far as priorities are concerned I suspect it's cart before the horse for them right now.

Cheers,

Miltos Pilalitos

05-28-2007, 09:14 PM

Shawn, I just listed a number of issues that in my opinion might be raised by a release of an SDK for this particular hardware product and make such a release difficult to happen.

Since the camera has not shipped, we don't have the slightest idea about the hardware and how it works. We have no idea what kind of software drives it or what the software platform is. We don't even know if an SDK would be possible in the way you are suggesting. Right now we can only speculate unless you know something that the rest of us don't. If you do, please share it with us.

When you are starting a new thread on a forum full of users with various opinions and different needs you cannot expect everybody to align 100% with your perspective. However, i said that your idea is cool! I never said that i didn't want such an option or that i am afraid that the sky will collapse. Don't be too "puzzled by my worried attacks" because i am not attacking anything or anybody.

There was no need to tell me to cool-off or to suggest i am diving into techno-paranoia. Anyway, this is not the first time i see this kind of personal attacks in these forums so i am not surprised. Never mind...

Shawn Nelson

05-28-2007, 09:21 PM

Miltos, I did not attack you personally, so try not to extract that and make yourself a victim. I was poking at your ideas, since I felt they were not accurate in this context.

EDIT: I don't mind you disagreeing and not wanting to use an SDK, and I certainly welcome informed injection that comes from experience. But I felt you were afraid of things that aren't what they appear to you.

Unless Jim wants to pop in here, I'm content to let this subject fade off for now.

Jesse Wendel

05-28-2007, 10:28 PM

Jesse.. i understand what your asking for. You need to realize though that an SDK that just opens up the camera control vs. an SDK that actually changes encoding of the frames and how images are being processed are two totally different things, and totally different liabilities.

I do understand but it's very likely I don't understand enough. *smiles*

So first, to be clear, I'm going to respect any decision you and the RED Team make, regardless of if I agree. Once the decision is done done, then I'm not going to second-guess you or snipe; your game, your rules.

That said, in my world, instead of taking Program A and writing it to Disk, I'd simply pipe it through an encrypting program and then write to Disk

Before: A > Disk
After: A > Encryption Wrapper > Disk

All this lives in a world of standard calls, inputs, outputs, and so on, as obviously you know. When I read how the drives are RAID0 FAT32 drives, and we simply use FireWire, then it seems to me all there is here is a computer with a sensor attached sending realtime data inbound for processing. So my first assumption was, just insert an Encryption Wrapper or any other kind of transform into the middle of the dataflow, and we've got us a ballgame.

But now that I've read your comment above and think it through a bit more...

I imagine you've got the writes -- especially with the hard drives being RAID0 -- having some kind of write checking going on at the program level, over and above normal file-system write checking at the OS level, just to make certain the frames are properly committed to disk, flash, or whatever, before you let the RAM release. The more I think about it, that's probably one of the real deadlocks, getting the data out fast enough to disk AND reporting back to the program that the writes are fully committed.

So sticking something in the middle of that, while not impossible, would require some hooks and a way of looking at the whole process, that would be a way of looking at things which would take some reworking, perhaps more than "some" reworking, yes?

Anyway. I'm sure I'm not the only person whom in the long run would like to dance in the datastream, sticking Transform A piped to Transform B to Transform C, and then and only then, write and have it still report back to call it RED INTERNAL that the write of Frame 1.01 successfully committed with A1.01, B1.01 & C1.01 all included. Followed by F1.02+A1.02+B1.02+C1.02 all reporting back okay. And so on and so on. You've got a hot box. Let's rock and roll. *grins*

Please consider this an open request inside of my larger conversation about Open vs Closed companies. Don't say yes or no now; it is enough for me to know you understand what I'm looking to do. In the meantime, I'll encrypt afterwards. *sighs*

Thank you again Jarred for all the work you've done, and for considering the request long-term.

Best regards,

Jesse Wendel/Seattle

I Bloom

05-28-2007, 11:12 PM

Interesting thread.

Back in the days when not to many people seemed to know about RED I wrote them an email suggesting they consider open sourcing their firmware. They wrote me a kind letter thanking me for my input but suggesting that that wasn't a possibility. That's not a bussiness model that works for them and I respect that.

I'm also a programmer and someone who can code in C and write realtime code for embedded systems. My hope is that RED will view the potential for 3rd party developement as a huge priority and not as an extra. There is a huge incentive for someone like me to develope tools that I see a need for, especially if I can market them to other RedUsers. Each third party tool that is developed for RED is an another incentive for people to adopt their platform. An SDK won't just be used by people who can code for themselves, it will be used by end users who adopt those additional tools, making the camera the hub of a whole set of tools for cinematography and special effects.

Think about the dominance of the companies, such as microsoft, that provide the operating system and not the hardware. They have an entrenched position in the market, because so many other companies are committed to their system. I think that RED hardware will eventually meet its match, it's their relationship to their customers and to other vendors, that is really going to decide their longterm fate.

So I would say "go all the way" RED, and don't wait a long time to do it. Provide the API to control your camera and manipulate your codecs. Also strongly consider opening up the camera to internal manipulation on some level, allowing other developers to add features that you won't dream of. Think of your camera as a PLATFORM, not a device.

I think its only to your benefit to do this.

IBloom

Shawn Nelson

05-28-2007, 11:24 PM

Think of your camera as a PLATFORM, not a device.

Amen!! This is *exactly* what "Making Obsolescence Obsolete" is about! :construction:

istvanttt

05-29-2007, 12:35 AM

Jarred -
..........
....... just like the original IBM PC defined a new category when it came out and let people add and extend and build off its specifications. Apple did not, and while I love Apple, the original IBM specification took over and controlled the market, and remains in control of the market till today.

Are you going to be the IBM or the Apple of this new market you are inventing? That's the question I'm asking when I ask for a SDK. That ain't gravy. It's the entire market. Personally, I think RED should be the market-maker, and that means an open box.

Respectfully,

Jesse Wendel/Seattle

Reading your arguments I recall that initially it was the Apple II which was an open low-cost computer and it became a winner in most of the scientific labs. There where tonns of 3th party HW and SW interfaces to use that little CPU for infinite needs. Apple was the clear winner, but then they gave this concept up for the closed Macintosh system, and the IBM PC took over all that business which Apple probably didn't consider as important. (at that time Apple didn't make market researches to find out who their customers where; once they started to understand what happened they quickly invented a special NU-Bus system but it was too late to recover the lost market)

I do agree that the first step has to be to bring the RED ONE to work (eh, sorry I mean to market), but to keep a space open in the system to allow a future development of APIs to give with the help of a SDK space for additional 3th-party HD or SW applications would give an intersting twist to this RED revolution.

I do understand that the RED ONE does not need to fullfill the requests to be used like a computer, but the digital reality gives the possility for a lot of uses of this camera which we haven't yet considered. Why closing the door before it got even opened?

Jesse Wendel

05-29-2007, 01:42 AM

[Everything below here I've moved from the Timecode thread. Sorry about moving it for anyone rereading, but this part of the post clearly belongs in this conversation, not that one. --jwe/sea]

If nothing else -- and here I return to and am going to riff for a while fairly deeply on the larger point I started to make in the SDK thread -- if RED truly wishes to own the market for the long haul, it is necessary for RED as IBM did, as Linux has done, as even (finally!) Sun is doing, to open up and let people innovate on top of what they have done. I AM SO ABSOLUTELY NOT SAYING GIVE PEOPLE ACCESS TO RED'S PROPRIETARY CODE OR SENSOR. I am saying that opening up everything BUT the crown jewels of the architecture and code in detail will allow people and companies to innovate to the code and to the hardware; that will make the new core question everyone will ask: "Is your hardware/software RED compatible?"

And that is when you truly own the market.

I don't know the history of cameras so I can't make my case for this there. But the history of computing, both on the software and the hardware side is clear. Companies which open up succeed. Companies which stay closed, fail or only keep a nice small safe bit of the market. But they never own the whole market; at best, a small chunk or niche markets. Like Apple. Nice profits. Great brand. But IBM is whom you bet on thirty years ago if you must bet your entire future on a single strategic relationship.

And frankly, today, IBM is still whom you bet for fifty years into the future for the whole of computing. I say this as someone who loves Apple. But they are and remain a niche player. Big. Innovative as hell. Great marketing and Gods do I love their design. None the less, IBM dominates computing in a way Apple does not, can not, and never will.

Does RED want to be Apple or IBM?

If RED wants to be own the future of digital cinema -- to be IBM -- they need to open up as widely as possible, holding back only the crown jewels. If they want to be relegated to niche status -- Apple -- with Sony or Panasonic continuing to dominate the market, they should open up only a little, a few hooks, tease us a bit, and that's about it. People will love them, respect them, think they've done something great. They may well win an Oscar for their innovation. And then the big companies will move in.

Really it's Jim's call -- be the dominant market leader with a company which is still dominant 100 years from now, or be a cool niche player. IBM or Apple. Microsoft or Linux. IE or FireFox. IBM is dominant because it embraces openness. IBM sells hardware, code, and services. IBM also sells TRUST. People buy IBM because people trust IBM to leave them with the assessment they've been taken care of.

I am buying from RED because I trust Jim, I trust Jarred, and I trust the RED Team to leave me saying to myself, "I've been taken care of." No kidding, that's why I'm putting every bit of my money into a RED camera. Because I trust RED. Period. I am certain that at the end of the day, I will walk away, saying to myself, "These people really took care of me." That's trust. And IBM sells that.

So...

What's my point?

IBM is an open company. Open companies dominate industries. Where they haven't dominated industries (Microsoft), the closed companies are getting their asses kicked by the open software and open companies. Linux, PostgresSQL/MySQL, FireFox, Apache, all these are kicking the hell out of Microsoft Server, Oracle/SQL Server, IE, Microsoft IIS, and so on. The curves are clear -- from the original IBM PC through FireFox, open beats closed, over and over again.

IBM shows us that a company which is essentially an open company, which works out in the open with its customers -- the new IBM sells Linux, for those of you not keeping up; it blogs, it tells people what it is up to. This ain't your Daddy's IBM. *laughs* -- is trusted by its customers. Trust sells.

Thus people will buy:
a) on trust,
b) let you keep your truly proprietary stuff private. After all, that's what makes you you. Then, everything that isn't genuinely private is open. A company wide commitment to openness and sharing and transparency;
c) expect to be taken care of, not as customers, but as individual people known personally one by one to all of your Staff. In each and every interaction you are committed to leaving every person saying to themself, "I've been taken care of."

Trust.
Private stuff private; everything else open.
Everyone left saying, "I've been taken care of."

This is the strategic decision -- and result -- of being open. This is the decision RED must make.

Anyway, I'm going to be quiet now. My point I think is sufficiently clear. *laughs* Besides, daughter #3 (Kyle, 17) wants to watch a movie. *smiles*

Happy Memorial Day to all,

Jesse Wendel/Seattle

Rob Lohman

05-29-2007, 04:10 AM

Okay, definitely interesting stuff. I see three levels of what (some of) you guys call an SDK.

1) change the inner workings of the camera. Due to the complexity of the hardware and firmware inside the camera any changes here are highly complex and probably need low-level access (as in, you can't easily put an SDK on top of that due to hugh amount of data & processing speed).

2) control the camera through an API / SDK. This should be fairly easy to do and I understand that request

3) SDK to work with the footage to integrate it into other applications and such. This should also be fairly easy to do and I can see how this could be interesting.

Jeff's encryption would be an example of #1. People have indicated that an SDK here could easily allow protection of the camera innards and should prevent anyone from blowing it up.

I don't think that's easy or perhaps possible without significantly limiting what you can do or losing too much performance. There are a million inter dependencies and tightly coupled stuff inside. You just cannot easily abstract that and maintain all the performance characteristics and such.

In my personal opinion I don't see #1 happening, but we'll see. Perhaps a good comprise would be to see how we can enhance the firmware & hardware with the features everyone wants the most?

SDK #2 would probably be a good candidate to start with. Shouldn't be too hard and allows everyone to do some nice remote control stuff.

For SDK #3 I would probably think about some form of licensing or collaboration to make sure the integration is done properly since it affects image quality for example.

Obviously we keep this in mind since we like to work in a similar manner inside RED. What and when we open stuff up is something that will have to be discussed in due time (ie, not now).

Thanks for your suggestions!

JohnF

05-29-2007, 04:54 AM

Rob,

I totally understand RED's position about point 1. I too would be concerned about any app that could even slightly effect camera processing speed. I also wouldn't be surprised if a number of RED's possible competitors would be very happy if such a package was released...

I just wanted to say that point number 2, remote control over camera, would be really handy and would certainly make a lot easier or speed up some of the work I do no end. Though a simple hard wired remote option would be nice too!!!
(I've always thought that all electronic cameras should have a universal remote like MIDI. I look on with envy as a musician demonstrates the ability to control 8 or so instruments with 1/100sec(and faster) accuracy whilst altering their parameters on the fly)

JohnF

oldphart

05-29-2007, 07:20 AM

This is the first high-volume camera with serious processing power. Therefore, experience tells us it is going to be hacked, with or without the cooperation of the makers. It is not exactly cheap, but it is cheap enough that somebody conceivably could want to risk ruining it in order to adapt it to some specialized need. That has happened to almost everything with a microprocessor, from toys to car engine controllers.

The really competent modders do not need an SDK, but a published API with some guarantee of which functions are going to be stable will be a benefit. This is all it will take to make it hacker-friendly, and it will endear the company far outside the professional cinematographer circles.

As for on-the -fly encryption, I think that is best done in the disk drives. Encrypting drives are commercially available and not very expensive.

Jeff Kilgroe

05-29-2007, 10:49 AM

Yeah, encryption seems like a waste of resources in-camera. Best to do it when offloading to other storage, like the encrypting hard drives or onto conventional media with encrypted file systems / folders.

A camera control API is really all that I would be after. I don't do much software development these days, so I doubt I would need any larger SDK to start integrating REDCODE support into other applications. Such an SDK would be nice -- but like Rob said, that's probably best for those interest to actually work directly with RED to maintain image quality and to make sure it gets implemented properly.

But I think a control API would be a great place to start. And yes, it would really gain RED a lot of respect and following outside of the cinema community with hackers and modders. A market that should not be underestimated. And like oldphart just wrote, there will be a few who feel the RED camera is expendable or cheap enough to completely hack apart and/ or build something else.

Jesse Wendel

05-29-2007, 11:56 AM

Sure, I'll work around my encryption issue. *laughs* Last thing I need is 50 (or 500) irate shooters on my door complaining I slowed down speed for everyone with my stupid problem. Heh.

In addition to it being a specific issue I'm going to need, encryption was also an example of a class of problems and Rob's correct -- it would need access to the core functionality of the system. If he doesn't see that happening, well, that's their call. I think it is eventually in RED's best interests to abstract what Rob is calling Level 1 out if possible, but I do understand that would require a major redesign.

And quite possibly I'm wrong. Perhaps the solution to needing core functionality is not to do transforms in camera but to continue the post-production revolution. Have RED do what it's doing so well -- get the data at the highest possible quality to media X, and then let it be transformed once it is out of the camera and onto the media.

Yes, I know in Film, people do many, many kinds of in-camera transforms. Just look at the tricks Michel Gondry pulls off. *shrugs* What I'm proposing is akin to making this possible. But maybe the trade-off in speed, power, and danger to the core is simply not worth it. No one but the RED Team is likely to be able to make that call, though I agree with oldphart -- RED will be cracked and modded; everything cool and hot is. *shrugs*

Instead of letting the system be cracked randomly, it truly might be better for RED to consider doing a Level 1 redesign when they have the time, to make in-camera transforms possible and accessible. That way they can separate out their crown jewels as much as possible -- black box them if you will -- while putting everything else at a level of API's and so on. I'm not unmindful of the level of work I'm suggesting. It may not even be possible given how, as you said Rob, everything is tightly coupled. *shrugs* What I am certain of is someone is going to crack it open as is (not me!) and publish. The internet makes certain none of that theft by publishing of your IP will be reversible or stoppable.

Publishing your own hooks into the core means the only people who will be reverse-cracking the core are true criminals; the ones whom are trying to steal your code and sensor. Everyone else can simply use the hooks to get to Level 1. This alone might make the redesign worth while. As I said, this is a call only your team can make.

I believe the more you are open, the more your camera become a major platform for development of all kinds of innovation you can not yet imagine. This is good for you, good for your customers, good for anyone whom believes in RED.

Thank you for your time Rob. I am content, deeply appreciative, and happy to wait and see what happens.

Jesse Wendel/Seattle

Rob Lohman

05-29-2007, 01:50 PM

To continue with your encryption example: I don't think there's enough processing power left to do that. A simple XOR perhaps, but that doesn't give you any real protection unless you can have an effective one time pad. I'm running truecrypt on a decent Windows machine and I don't think it exceeds 50 MB/s throughput speed. Our data rate is around 30 MB/s and all the stuff is already busy processing that.

A transform is usually simple since that is either a lookup table or a matrix. If it is for image processing then it's better in post.

For the moment I cannot really see what anyone could add inside firmware that would not touch large (or all) parts of the system and thus requiring deep access. It's like a real-time Operating System where you have to be very careful to not introduce stability & performance issues.

Now I'm not saying something like this will never happen. Who knows. I just think it will be very difficult to do (properly & reliable).

For your encrypting solution it would probably make sense to solve this at the storage end. Probably easier to write some custom stuff there than on the camera.

I don't really see why anyone want to "crack" something unless they are just curious what's inside. Most people crack software & hardware to remove (artificial) barriers like region protection and movie copy protection etc.

Of course there are the people who want to run linux on their XBOX but I do think that this is a little bit different.

I am hopeful we can deliver the features our customers want. If not directly out of the gates then through future software & hardware upgrades.

I Bloom

05-29-2007, 02:40 PM

For the moment I cannot really see what anyone could add inside firmware that would not touch large (or all) parts of the system and thus requiring deep access. It's like a real-time Operating System where you have to be very careful to not introduce stability & performance issues.

I'm thinking more about on-set tools not stuff that would be better served in post. Scopes, etc. Stuff to use for previsualization during FX shots. You would have to keep your proprietary code binary but set it up so that we can link it in. You probably don't have many spare cycles in your imaging transfer and compression pipeline, but I bet in your interface you do. Any place you are thinking, "what more could you want here?" Trust me, THERE IS MORE.

Warm regards,
IBloom

Jesse Wendel

05-29-2007, 05:53 PM

*bows three times*

No problem moving my AES encryption (http://en.wikipedia.org/wiki/Advanced_Encryption_Standard) to immediately after the shoot. It needs to be managed with enormous impeccability such that I can make specific promises to my documentary subjects about the security of their interviews. If I can't do it in-camera, then it's just a day-of-shoot work-flow issue.

The actual encryption is easy. It isn't harder than copying from RED RAID to a pre-encrypted and mounted AES RAID. Then my only question becomes, can, for example, BestCrypt or PGP and a very fast RAID array handle both decrypting/encrypting with a large key plus throwing multiple streams of video/audio up to FCP?

I guess the answer is yes, but I'm only going to really know by experimenting. *laughs* I'm pretty sure I'll be fine in software alone, but worst case, I can always buy a hardware AES accelerator and offload there. Anyway, this part is now off-topic. *smiles*

As for the rest, um, I don't know enough about the way the inside of what we've been calling Level 1 is structured to say what the value is of building an abstraction layer vs the performance hit. The part I am certain of Rob, grounded in 27 years at this point since I first started hacking on the PDP-10 while doing graduate work as a Paramedic at UAMS (Arkansas) is that a certain group want to get in deep. It's simply how they're wired. And while some of us grow up and become responsible, others, well, don't.

More importantly, I think ibloom, myself, and everyone else whom is speaking up for access is right -- if you provide access they will come, come and build systems, code, interfaces, programs, devices, and thingy-ma-bobs that are not simply useful, but sell, sell and which establish an entire secondary market around RED.

I have no idea what my needs are going to be for getting inside. It seems inevitable to me that I have unique needs. Just always turns out that way. I buy stuff which handles 80% of my needs from someone I trust deeply to take care of me, and whom I can talk to, someone that truly listens to their customers. That's y'all. Then I script the next 15% at shell or do without which works most of the time and when it doesn't (since I'm not a developer myself) I have a friend whip me up a quick program, or pay someone to write what I need. That handles everything else. Because there's no way you can possibly anticipate what I'm going to need for the obscure parts of my documentary three years from now when I'm still learning how to even shoot!

So the more hooks, the better. The more opportunities, the better. And since you're in the best position to make the call on what destabilizes the camera and what doesn't, make the call. I trust you. But if there's a question about putting in a hook and the issue is, you don't see what it would be used for, but it doesn't destabilize, put in the hook. I assure you, someone will make use of it for something. That's the point about being open -- you don't know what it will be used for. One of your key jobs from my point of view, is to open up the interface so people can invent stuff you wouldn't come up with in a life-time. It also isn't RED's job to come up with the additional stuff -- it's to make a solid platform on which we can play, invent, and rock and roll.

I mean, really, who at IBM would have ever thought to use the IBM PC platform to make movies? Run Real-time OS's and control oil-drilling platforms? Go on the space shuttle? Model the weather? Control attached lathes? Let kids drive cars through Paris? Let grown-ups fly 747's into Oakland in a thunderstorm using a real joystick and pedals. Knit? Make coats? Build Lego robots? All this and more came from an open system. None of which was imagined by the original IBM gang releasing the PC. They just opened it up and people got creative. Let us be creative with RED. Don't limit us in advance.

The voices are telling me to shut-up, that the point is now overly clear. *laughs*

Rob -- I don't think anyone is expecting anything right away. I for one am awe-struck by what y'all have done to date. It's just something to keep in mind as you're coding, so that it isn't a recode later, which might then be something no one is willing to do. Platform, not product. What and how much gets exposed, of course, your call.

Best, and thanks again,

Jesse Wendel/Seattle

Ken K

05-29-2007, 08:11 PM

Of course there are the people who want to run linux on their XBOX
Wait, you mean I'll be able to run a Linux server on my RED? Will you guys be doing a custom version of Folding@Home for the RED, too? :)

Seriously though, I'd totally dig having the level 2 and 3 SDKs available for the RED. I can just see all kinds of cool little add-ons from our community, enhancing some of our peculiar workflows. Oh, and I definitely want a pirate copy of Shawn's PocketPC app - that would be great! :shiftyph34r:

Joel Kaye

05-29-2007, 09:20 PM

Do you have an SDK for your DSLR? (seriously, if you do, please email it to me)

Here's the SDK for your EOS. Have fun.

http://www.usa.canon.com/consumer/controller?act=SDKHomePageAct&keycode=Sdk_Lic&fcategoryid=314&modelid=7474&id=3464

Miltos Pilalitos

05-30-2007, 01:54 AM

Here's the SDK for your EOS. Have fun.

http://www.usa.canon.com/consumer/controller?act=SDKHomePageAct&keycode=Sdk_Lic&fcategoryid=314&modelid=7474&id=3464

If you read carefully the link you just send you will find the following information:

The Canon Digital Camera SDKs do not replace the software that was supplied with your Canon digital camera.

The Canon Digital Camera SDKs comprise a set of APIs, DLLs, and static link libraries that provide an interface for accessing Canon digital cameras and data generated by Canon digital cameras.

That means these SDKs are used to help you assemble code for remote accessing your DSLR. This code is not to be run on the camera but your computer.

Rob Lohman

05-30-2007, 02:16 AM

oldphart

05-30-2007, 03:14 AM

...
I mean, really, who at IBM would have ever thought to use the IBM PC platform to make movies? Run Real-time OS's and control oil-drilling platforms? Go on the space shuttle? Model the weather? Control attached lathes? Let kids drive cars through Paris? Let grown-ups fly 747's into Oakland in a thunderstorm using a real joystick and pedals. Knit? Make coats? Build Lego robots? All this and more came from an open system. None of which was imagined by the original IBM gang releasing the PC. They just opened it up and people got creative. Let us be creative with RED. Don't limit us in advance.

This is, indeed, what it is about. The ability to use something for a totally different purpose from what the makers were able to imagine, and which it would be way too expensive to design a dedicated device for.

I can imagine a scientist wanting to make a device for some new form of real-time image processing. The output will not be anything like a normal video stream. Getting the parts to build the device will be prohibitively expensive, and one-off image detectors are not easy to buy. It would be much cheaper and more convenient to just buy everything already in a ruggedized package, install QNX or Montevista and start testing the experimental software.

Or maybe somebody needs a high resolution image, but with the ability to selectively vary the readout frequency or integration time for parts of the image? Maybe somebody could want two normal frames, then one with double exposure time - not for anything to do vith video or cinematography, but for totally different reasons where the desired quality is entirely different?

People will find out how the hardware interfaces work and where interrupts come from, and they will adapt operating systems. If they can use the existing operating system (and scrap whichever part of the firmware they do not need), it will be easier. Just provide a simple specification, and the hardware hackers will use a Red as their raw material instead of something else. It will not be important in the beginning, since demand is greater than supply, but it might in the long run - and it would be good for the value of used and even damaged cameras.

Joel Kaye

05-30-2007, 10:44 PM

If you read carefully the link you just send you will find the following information:

That means these SDKs are used to help you assemble code for remote accessing your DSLR. This code is not to be run on the camera but your computer.

I read it pretty carefully. What's described is exactly what some of the users here are asking for in a SDK. I personally just want the ability to run the whole camera remotely with a laptop or PDA.

Jesse Wendel

05-31-2007, 12:07 AM

I personally just want the ability to run the whole camera remotely with a laptop or PDA.joelnet -

That ability would come from programs built on top of the API (Applications Programing Interface -- commonly called hooks) exposed in what is currently being called Level 2 of the proposed RED SDK.

The nice thing is, you are never going to have to personally code a thing unless you choose to. Someone else will take the SDK once (and if) it is released, write a program to control the whole camera remotely with a laptop or PDA, and either sell it, or much more likely, release it here on the board most likely in a new section of the board just for Programs under the GPL. Then everyone can debug, make it better, build something new on it, and so on.

Someone might whip out a basic remote control mechanism and release it; someone else builds on that a fancy menu driven program with lots of options; next person adds time delays; someone else makes it work underwater; someone else fixes it for aerial shots, while another... well, you get the point. After two-three months of active development, we've got a solid, fairly bomb-proof remote program, not to mention bugs being reported back to the community quickly. I suspect you'll find this board hosting a large RED program development community, once the SDK is released.

And at any point if you're not satisfied or you need something custom which isn't out there, you can take any of the programs released under an Open Source license, and have it modified to meet your needs or use it as a base to build what you do need, probably within a fairly short time.

SDK's -- because you don't know the future.

RED -- Platform, not product.

*smiles*

Jesse Wendel

I Bloom

06-18-2007, 02:51 PM

Jesse: there are ton of programs as you no doubt know to do that on your computer. Personally I'm using truecrypt(.org). However, that seems to be limited to using one processor which highly impact its throughput speed.

It also depends on which encryption algorithm you're running and with how many bits. With truecrypt you can run triple encryptions on a stream for example. It also allows you to encrypt a full harddisk or partition, which sounds like something you would like. Best of all it's free & open source.

Hopefully they'll add Mac & multi-threading support soon.

Thanks for the detailed write up. Always good to hear what everyone is interested in.

ibloom: your thoughts on using something like that for vfx does make sense, thanks.

One more thing Rob. There a lot of things I think we can accomplish in camera, while the camera IS NOT ROLLING, i.e. previsualization in between setups. Thus freeing the processor from the compression load, which I assume is one of the largest loads. I have some really specific things in mind, that I think qualify as being things that shouldn't wait until post.

IBloom

Gavin Greenwalt

06-18-2007, 06:53 PM

It seems like for the near future what 99% of all 'SDK' users need is just access to the control APIs. It doesn't seem like that should be at all difficult considering I would like to believe that's how RED is interfacing with the low-level firmware themselves. Righttttt?

Most interfaces I've encoutnered operate on a

[interface application] -> [interface APIs] -> Functions/Classes/Firmware/Hardware

Or maybe that's just how I program my applications. If RED was designed in such a way it would seem like there would be no need for an SDK per say so much as documentation for the existing APIs that RED is using for interfacing with the firmware.

the RED camera shouldn't care if it receives the call:
"RecordStart();" from the built in interface or a custom surface app right?

Jesse Wendel

06-18-2007, 09:54 PM

Or maybe that's just how I program my applications. If RED was designed in such a way it would seem like there would be no need for an SDK per say so much as documentation for the existing APIs that RED is using for interfacing with the firmware.

*laughs*

With respect, you're missing the point. The point isn't how YOU program. It's how someone you've never heard of doing something you can't imagine comes up with something that does something which is so freaking cool, 20% of RED owners decide they just HAVE to have it.

No one knows what is possible to build. Yet. That's why simply exposing the API's isn't sufficient.

RED should commit to a full-blown SDK precisely because of what you said -- maybe that's just how you program your applications. And maybe some other way is how that other gal programs hers. But no one knows how the third person programs her applications, when she makes the hand controllers do a thing in conjunction with the EVF which is exposed through the SDK along with some custom code modifying focus pulling. No one even thought it was possible. And now, no one can live without it. Because people are sitting 50 feet away inside the helicopter and pulling focus remotely on these grips using the EVF through a fiber cable to the camera. All because of the SDK. For example.

That's the whole point. You don't know what people will build. Or how.

RED -- Platform, not product. RED SDK -- because no one knows the future people will invent (or need.)

Thanks,

Jesse Wendel