Developer I/O

[Eric MacIver]

I asked the following on another board but didn't get a response. Perhaps someone here knows... I couldn't find the answer on my initial search:

Can anyone comment on planned developer I/O connections to the Red? In a perfect world there would be options to read electronic data from the display and current camera settings and timing. Perhaps even a way to provide real-time image "plug-ins" (though I know that opens up a can of worms).

This would help the 3rd party industry develop intervalometers, EDS, laser pointers (that hide themselves w/ camera sync), auto-focus, 3D syncro, etc...

It would obviously help render obsolescence obsolete :)

[Purple]

I wished the whole camera didn't only have some I/O API, but all it's software was actually open-source. After all, it's the sensor that it's all about - keep that closed, I don't mind. Making all software that runs on the cam open source will allow yet unseed innovations with the RED ONE and ensure it's place on the cutting edge for years.

Just my 2 cents.

[Homersapien]

I tend to agree Purple. Alot of the best software i use is open-source. When you look at something like Red it seems an ideal opportunity to do this. The truth is that no matter how good a team of specialists are you will get more out of a program if it's open to intergration. I'm not big on editing but is there any kind of opensource software available for that? and if so how does it compate to the FCP and Avids of the world for example?

[acehole111]

I dont think it needs to be OPENsource. Opensource is a far cry as far as proprietry company intel goes. It could simply have an open api or even accept custom scripts or plug-ins. Similar to how photoshop accepts plugins and such. You could buy special camera tracking plugins or infrared plugins or whatever. Or imagine having that DOP pda application onboard in the camera. This could also lend itself to having red ship in various editions bundled with different utilities.

Either case, plugin architecture doesnt need opensource.

[Eric MacIver]

I agree... With such an advanced product, I'd actually prefer open source not be the case, so that cameras are more controlled (benefit for the used market), but a robust plug-in system would be amazing.

Seems tough, but it seems very interesting. Groundbreaking really. (Not that the rest of this camera is any less than groundbreaking itself).

[Jesse Wendel]

Yeah, as a senior computer guy for a Fortune 500 company, I strongly do not want the camera software to be Open Source, and don't think RED would or should do such a thing.

RED needs to control their own User Interface (UI), both hardware and software, as well as the customer experience.

Everything about RED - the company, the software, and the hardware - ultimately, is about taking care of people (and their concerns.)

RED can't be ass on the line accountable for taking care of people's concerns for digital cinema, if the software which controls the UI and the camera, is open sourced.

What's needed is a robust published API (Application Programming Interface (http://en.wikipedia.org/wiki/API)).

A published API will allow RED to provide reliable access to its camera controls and internal software to both hardware and software developers (as Apple does), while still maintaining control of its own development cycle, as well as maintaining a consistent look and feel across the interface. Yet developers would have the access they need to invent as they see fit - the best of both worlds.

[glenn chan]

???

Red could stamp their name on their official software, which allows them control over their GUI. Now customers could potentially go off and use 3rd party tools/modifications and clog tech support with their problems... but this could also happen with the API model.

[Jannard]

We believe in "open". We hope that all will support the RED project and we'll help them.

Jim

[Clint Johnson]

I think some interesting work could be done with a freely available API even if it is sandboxed away from the most basic funcitons of the camera... and if it does mung things up, it sounds like you'd be able to flash the Red One back to the latest factory settings without pestering them about problems that you've brought on yourself.

[Opcode]

As a former software engineer, I wouldn't want it to be open source either. There's alot of baggage involved in being open source on both the developer and user that would be a hassle on all sides. Besides, alot of identity is lost when things go that route and personally, I would rather see a singular vision drive a product like red, especially when you've got a leader like Jim at the reigns. I agree though, a well thought out API is all that is really needed for the public and 3rd party developers to take advantage of.

[Purple]

If I'm correctly informed, these features are currently not included in the expected feature set, but I wished I could add them to the red:
- simulating a focal-plane shutter to make moving objects appear slanted
- realizing 120fps with the full 35mm sensor&DOF @ a reduced resolution (instead of just having a "16mm" sensor)
- having a "continuous recording and save the last 2 minutes when a button is pressed" mode

An open-source Red (or some sandboxed part of it) would allow me to add those features when I need them; I wouldn't need to ask Red and wait 6-12 months to get it (or not get them at all if Red doesn't think they're needed by enough many people). I know "Redservation" holders that hack, so the market for this is definitely there.

Anyway, rock on, the 4K pics are stunning! :-)

[tlorenzo]

We believe in "open". We hope that all will support the RED project and we'll help them.
Jim

That's great news, Jim. I'll be standing in line for an SDK og API-specification for the RED :thumbup:

[NickJushchyshyn]

Many applications and even hardware have SDKs without being open source.
Adobe applications (well, many of them at least) have freely downloadable SDKs, for example.
Canon also offers SDKs for many of their high end DSLR and even video cameras.

Personally, I think where Canon falls short is not allowing programs to be stored on camera for non-tethered execution.

As a cross posted example from another thread....
It would be cool to be able to create a pre-programed HDR sequence that could be launched on demand. This way, a seperate camera wouldn't be needed to acquire HDR images for VFX shots. Just run out with your reflective ball between takes, callup your preconfigured HDR plugin or preset and fire .... RED acquires 6-12 4k frames, each with progressively longer shutter speeds as their own take. These frames could be post-processed later to generate a full HDR to be used for CG lighting and reflections in Post.

Well, that's one example anyway.
Wouldn't be a streatch to imagine uses for operating the camera in sync with external devices like lighting controllers, motion control systems or even survailance/research devices.

A camera with the dynamic range, resolution and price point of RED also has tremendous applications in the scientific world, BTW. Being able to develop interfaces with software like LabVIEW would be very very cool.

[Eric MacIver]

Just remember a data port that does I/O if you go that route... USB or Firewire should do fine. If the SDK let you specify what data to export based on a request from the offboard device, that should help for development of speedy I/O devices. (Depth finders/focus assist/lds/stereoscopic alignment....)