Other: My SDK request to Sony to provide custom and streamlined mode operation

starcentral

starcentral

Veteran
I would be lying if I said I never made money off consulting or supporting users of Sony F series camera's, which still to this day continues to bruise and confuse many users considering the rubix cube matrix of possibilities, gotchas, and work-arounds inherent to these cameras.

So recently I asked Sony about providing a SDK for the cameras whereby advanced users could custom program the cameras to operate exactly as they would like it to function in effect providing the ability to create your own "camera operating mode". Any rental house or non-Sony owner would surely welcome this and might see the end of their frustrations.

Just imagine creating your own mode for the camera to custom fit to your needs and requirements. You turn it on and it just works the way you want.

Feel free to show your support by chiming in on this thread on the official Sony F5/F55 user community forums.

http://community.sony.com/t5/F5-F55...tom-and-streamlined-camera/m-p/513922#U513922
 
Foolcontrol is great, but even the free Red app works really well.

I can't imagine Sony would ever open their gear up like this but the benefits of having a gazillion people engineering solutions to common issues are huge to the end user.
 
Foolcontrol was pointed out to me by someone on the Sony forums, but I have to admit I'm not asking Sony for a way that any of us can just create our own UI. We already have wi-fi control which isn't perfect but not bad.

I'm literally asking Sony to make it possible that me, you, or a rental house can install a firmware and turn any camera into an "ENG camera" or "Cinema camera" stripped down of all the bullshit matrix of gotcha's, headaches, and pains in the asses.

I would be the first to program a new mode for the F camera.
 
Correct me if I'm wrong, but it looks like Fool Control simply taps into RED's existing (wireless?) output. It's not an SDK or API or replacement firmware - it's a separate software package that accesses existing hooks in the RED's available I/O suite.

If the above is correct, then that's a far cry from an SDK/API to develop custom firmware.

As for doing something like Fool Control on the Sony FS series... I believe the most promising method would be to develop custom software that connects to the Wifi I/O. I am, actually developing software along those lines currently, and while something similar to Fool Control isn't my primary objective, I will continue to explore what that might look like.

As for an actual SDK/API to develop custom firmware.... I'd love to see it, but I'd bet good money we never will. I could write paragraphs on why not. What I'd rather see is improved wifi remote control options - this is far more practical in the long run, because you're not asking the software company to let you overwrite their firmware, just asking for more input/output hooks to attach to for custom control.

Dennis - out of curiousity, what's your programming background? What languages do you know, and what embedded processors have you previously programmed for?
 
Yeah a wi-fi extension wouldn't cut it for me either. That's amateur hour and wouldn't address any operating mode restrictions currently at hand.

For programming, at a hardware level everything from Motorola, microchip and TI. Software, now mainly advanced web languages. Some C# but I gave up on app development after losing interest in it.
 
Viddovation said:
Correct me if I'm wrong, but it looks like Fool Control simply taps into RED's existing (wireless?) output. It's not an SDK or API or replacement firmware - it's a separate software package that accesses existing hooks in the RED's available I/O suite.

If the above is correct, then that's a far cry from an SDK/API to develop custom firmware.

As for doing something like Fool Control on the Sony FS series... I believe the most promising method would be to develop custom software that connects to the Wifi I/O. I am, actually developing software along those lines currently, and while something similar to Fool Control isn't my primary objective, I will continue to explore what that might look like.

As for an actual SDK/API to develop custom firmware.... I'd love to see it, but I'd bet good money we never will. I could write paragraphs on why not. What I'd rather see is improved wifi remote control options - this is far more practical in the long run, because you're not asking the software company to let you overwrite their firmware, just asking for more input/output hooks to attach to for custom control.
Click to expand...
+1
Sorry to say, but what Dennis is asking will never happen (but I'd love to be wrong!). It's basically asking to open source the firmware for FS7, what would lead to enormous amount of issues and lost sales by Sony.

What we should focus on, and James is right with this, is wi-fi control app. Ask them to release full SDK for wi-fi and add more functionality to it. I'd love to see a live feed, even one with low resolution.
 
They don't need to open the firmware up to greatest extents whereby it would start impacting the product line itself, they simply need to allow developers (or users) to create their own camera operating mode and add/remove functions as they see fit.

So for example one could lock the camera into sgamut3.cine mode, allow gamma selection of slog2 or slog3 and record that to internal cards period. From there add WB (or some paint method) on monitoring signal and/or MLUT last on the chain no matter if the camera is in S&Q mode or not. You can chose to have your waveform run on the underlying recorded signal, or the "painted" LUT version… whatever you decide. Again, the point is its up to you to how you see fit.
 
starcentral said:
They don't need to open the firmware up to greatest extents whereby it would start impacting the product line itself, they simply need to allow developers (or users) to create their own camera operating mode and add/remove functions as they see fit.

So for example one could lock the camera into sgamut3.cine mode, allow gamma selection of slog2 or slog3 and record that to internal cards period. From there add WB (or some paint method) on monitoring signal and/or MLUT last on the chain no matter if the camera is in S&Q mode or not. You can chose to have your waveform run on the underlying recorded signal, or the "painted" LUT version… whatever you decide. Again, the point is its up to you to how you see fit.
Click to expand...
In that case I'm all in :) Will support this on Sony forum.

The whole concept is not far away from "all files", they could work on that. I'd love to see those custom modes (or enhanced "all files") to be assignable to buttons.
At the moment renting a camera to someone is directly connected with explaining all the quirks to customer and answering couple of calls.
 
starcentral said:
They don't need to open the firmware up to greatest extents whereby it would start impacting the product line itself, they simply need to allow developers (or users) to create their own camera operating mode and add/remove functions as they see fit.
Click to expand...

If you were simply advocating for a "deep menu" that let users define how they wanted the camera to operate, that could be saved and recalled like "All Files", that would be one thing. Some work on Sony's side, but within plausibility for a future product if not this one.

If you were advocating for the ability to install an operating system on top of the root firmware, and allow user modification of that OS, but also provide allowance to remove said custom OS, I'd say it's unlikely from Sony, and not likely plausible on the current firmware, but would be very interesting on a future product.

However, advocating for an SDK/API to rewrite the firmware at any level... it's an entirely different can of worms. Among other things, the camera consists of multiple embedded chips, and what we install as one firmware update actually consists of separate firmware updates for each of those chips. So you're programming close to or at the hardware level for multiple architectures that have to work closely together with precision timing. And you'd likely be doing so without a robust debug emulation, and if you can't get Sony to also sell/give you a hardware development kit, you're having to test your code directly on an $8,000+ camera. Bricking the camera is a real possibility. And even if you don't brick it, you might render it incapable of reverting to the Sony firmware.

And now we get into some liability issues. Lets say you (or a rental house) rent out a modified camera. And the crew loses shots due to firmware bugs. Since you've replaced the Sony firmware, liability could fall on you.

Your prior post didn't really make clear how much embedded programming you actually do, but for instance, take the Microchip PIC32 - which I'm currently interfacing with the FS7 - I've only got so many clock cycles at 80MHz, and currently I'm interfacing TCP/UDP and CANbus in the same project. Every clock cycle in the TCPIP stack is a clock cycle not spent managing the CANbus. Hardware registers and modules do some work for me silently, but either through polling or interrupts I have to carefully organize timing. With a camera like the FS7/F5/F55 there are, undoubtedly similar constraints. For instance, there is almost certainly a "new frame arrived" hardware interrupt on one or more chips in the FS7. You've got to service that interrupt promptly, consistently. And making a change in one chip's firmware may throw off the timing of interrupts another chip is expecting. And so forth. It's deeply complicated.

Now, you might propose "Sony should give us an SDK that takes care of those low level calls automatically." Which, on the face of it, sounds great. But whenever you write high level code to safely drive hardware it's not going to be as efficient as carefully addressing the hardware directly. In non embedded applications, where we have GB of memory, terrabytes of hard drive space, and multiple GHz processors, those extra clock cycles and memory management issues are laughable, but on small embedded chips performing time critical operations, every cycle counts. And who knows - Sony may have used hardware that has some overhead left, but typically you choose the cheapest chip that performs to the specs required. You hire engineers who are experienced programming for that sort of embedded environments, and who know how to maximize it.

I'm so sorry, but this is a pipe dream.

The wi-fi on these models may not provide enough control for you. And perhaps, wi-fi is not the ideal mechanism, but ultimately, the realistic, if lofty, goal would be for future models (and current, if possible), to offer increased custom hooks via remote control, whether Wi-fi, ethernet, bluetooth, RS-232,RS-422, RS-485, USB-3, Thunderbolt, etc. And to offer an SDK for that interface.

The wifi on the FS7, by the way, there's no SDK, but I've already deconstructed how it communicates via it's web app, and have successfully emulated the web app using my own software. So, I'm well on my way to commanding the camera from custom software on OSX or iOS, similar to Fool Control. I'm mostly limited by what commands are available. Something that Sony could address either on this or future models.
 
Last edited:
If anything I hope that if enough people get on Sony's case they may provide something. But even if nothing maybe it will convince them that some type of overhaul is necessary.

Their camera's are an absolute disaster, no not for everyone who uses it, but for the ones it is they still count as customers.
 
You must log in or register to reply here.
Back
Top