So today I want to talk about the software that runs our cameras. More specifically than that, I want to talk about why I think that the camera companies should stop sitting on that software and either make it more open and accessible or better yet, make the source code for it available to interested photographers and developers to extend and mess with.

I would argue that there are a whole slew of reasons that this is a good thing for us photographers and the camera companies. Probably more than I can reasonably cover in this post while keeping its length reasonable. But that’s not going to stop me from trying.

Security

Let me start with the big scary fear-mongering headline grabbing keyword; security.

No wait, stop laughing. I’m serious.

Cameras are increasingly becoming connected, network enabled, devices. And with that comes dealing with a whole myriad of security issues that none of the camera makers have really had to consider or think about in the past.

While cameras can stand alone without the connectivity, and hopefully that will remain the case for a long time to come, that connectivity is increasingly becoming a selling point; even for pro level cameras.

For a couple of years now, consumer cameras have been marketed with features like being able to upload to Facebook directly from the camera, or allowing the camera to be remotely controlled from a cellphone or tablet app. Even pro level cameras are increasingly picking up these kinds of connected features. One of Canon’s marketing points with the Cinema EOS bodies is that with the optional Wifi adapter they can be remotely controlled by a DP or camera operator from a tablet.

For the moment, this connectivity is relatively safe for a number of reasons. But safe, shouldn’t be confused with secure. A thing may be safe, for the moment at least, because nobody is trying to attack it or it isn’t being used in away that readily exposes it to attack; but could be woefully insecure making it very easy to attack when the opportunity arrises.

Let me draw a comparison to Pocket Wizard radio triggers. I would hazard to guess, that many people who first get Pocket Wizards have been tempted to mess with another photographer they see using them.

Since most PocketWizards don’t have custom addresses programmed into them, and many of the most popular early models only had 4 channels, anybody with a PW can easily fire anybody else’s PW. Four channels isn’t a lot, and even newer models with 16 or 32 channels don’t make for much in the way of an actual impediment to foolishness.

Now one might argue that it’s just a harmless prank. While I’d agree there no real risk of injuring someone, there is the potential for harm that can be quantified in real money. What is the value of the time the photographer spends trying to figure out why their strobes are going off randomly? If there’s no client there probably not a lot, but what about when this is in front of a CEO on a tight timeline? What about at an event where your flash is being aped by someone else draining the battery and emptying the capacitor rendering it unavailable when you need it?

For the most part photographers using PWs are safe from being messed with. Even though PWs are really popular in the photographic world, there are still few actual users, and even fewer users who are looking to maliciously screw with people. However, they’re not really secure. Anybody with a PW that can sit access the channel you’re using can fire your strobe or remote camera.

Canon and Nikon have done a little bit better with their wireless RF flash systems, of which at least Canon’s offers remote camera triggering. Both offer 10,000 possible PIN or ID codes (0000–9999 inclusive), that makes targeting a specific flash or remote camera marginally harder. However, these flashes aren’t securely paired in the same way say a bluetooth keyboard is paired to your tablet or computer. The PIN/ID is not a positive security measure.

It doesn’t help either, that the track record, across virtually all industries, of companies that haven’t had to deal with security as a core concern, often miss or ignore that aspect on products that require dealing with it. Even companies that are focused on security, often fail spectacularly to get it right.

You could look at the automotive industry as an example, but they’re not alone in this by any means. In 2010 researchers demonstrated that cars could be disrupted while driving by sending fake tire pressure readings from near by. In 2015, it was shown that Chrysler cars equipped with cellular communication systems could be remotely taken over by an attacker, remotely, from anywhere the attacker had an internet connection. If that wasn’t bad enough, the researches in the latter case, tried for months to get Chrysler to even acknowledge, let alone fix, the vulnerability privately before they went to the press to get something done.

While disabling or disrupting a camera remotely probably isn’t going to kill or harm anyone physically, it can significantly impact one’s job performance, and potentially future prospects.

Another security concern is that a connected camera can potentially be used as a vector for attacking other devices or computers on the network it’s connected to. Examples are rampant of this, even in instances where the vector was intended to be a network security device.

In 2011, Columbia University researchers showed that HP printers could be used to intercept information being printed, potentially damage the printer, or be used as a vector to attack other computers inside the target companies network. HP is a computer company, they’ve been a major player since nearly the dawn of the PC industry, they should have known better.

Replace printer with your network enabled DSLR, and the same potential situation exists. A compromised camera connected to your home or office network could be used as an attack vector to attempt to break into other computers to get more important information, like financial data.

In terms of processing power and capabilities, our cameras are much more capable than a printer. Most printers, for example, don’t have a microphone that could be tapped to record and send what is said around the camera — thought to be clear, I’m not aware of this actually having been done yet either. The consumer electronics parallel, some Samsung Smart TVs record your conversations.

Now don’t get me wrong, the sky is not falling; there’s no need to panic. At least it’s not falling right now, and it likely won’t be in the near future.

However, at the same time, it’s important to remember that our digital cameras are fully fledged computers and in many cases fully fledged computers with full network stacks and built in connectivity, either Wifi or wired ethernet, and as fully fledged computers security has to be considered in the same way it would for any other network connected device.

Now what does all this have to do with having access to the source code?

While access to the source code, doesn’t make the camera more secure in and of itself, it does make it much easier for security researches to find, report, and potentially fix vulnerabilities in the camera software. If there are none, then that’s great and the camera makers would have pulled off a feat that hasn’t really been demonstrated in any other industry making a similar transition.

If there are vulnerabilities, the sooner they can be discovered, and the sooner the camera companies can start to understand the required mentality to produce secure software in an internet enabled world, the better off we will be.

Long Term Support

Going almost hand in hand with the security issues, is long term support.

It’s certainly true that the best business case for the camera makers is that we throw out our cameras every time a new model is introduced and replace them. But aside from that being rather wasteful, it’s not always economically practical, possible, or even, frequently, desirable.

I still use my EOS 1D mark III. At 10.1MP, it has more than enough resolution for images targeting the web, and working in studio conditions mitigates any limitations on dynamic range or high ISO performance. Replacing it with even a $1000 80D class body doesn’t buy me appreciably more functionality for my needs, and costs me both money, and disk space strong the now larger images.

However, as far as Canon is concerned this camera is 3 generation out of date and no longer supported. It won’t get firmware updates to fix a potential incompatibility with a yet unreleased lens or flash. Nor will there ever be any new features or improvements of existing ones — of which I can think of at least a few I’d rather like for my uses.

I would argue that my 10 year old camera is still relevant and useful, and shouldn’t just be junked. More modern cameras have the potential for even longer useful lifetimes, especially as the rate of sensor development continues to slow down. While my 1D mark III is still relevant for some work, nearly 10 years later. A modern camera, like a D500 or 80D, could remain relevant easily for 10, 15, or 20 years even though they’ve been supplanted and are no longer supported.

A good parallel example of this issue, both the security aspect and the resiliency of open sourced solutions, is the situation that played out in small office/home office network routers in 2014. Though intended to protect your network from being hacked, manufacturers drop support for these devices after a year or two and with that stop producing updates. In 2014 critical vulnerabilities where discovered in the software that runs on these routers that left millions of users exposed to being hacked.

With closed source firmwares, your device lives and dies on the whims of a company who’s best interests are for you to buy a new model even if your old one still is adequate for your needs.

However, those affected routers all use Linux, an open sourced operating system, along with open source software to achieve their functionality. Because Linux is open source, there were already several projects (e.g., ddwrt, openwrt, tomato) that provided alternatives to the manufacturer firmwares for many if not all of these routers. While manufacturers had stopped supporting many perfectly functional pieces of hardware, these alternate firmwares not only allowed people to keep using their existing perfectly good hardware but to do so securely and frequently with more features than the manufacturers had originally included.

Which leads me to my final point, and perhaps the one I think is the biggest and more useful point I’m going to make.

Niche, Novel, and New Features

Okay so when push comes to shove, security and support are nice and all, but as things stand right now and for the foreseeable future, they’re not really the big concerns.

The real killer feature, is just that — features.

Developing features for a camera is subject to the economics of the manufacturers business. The man hours needed to design, develop, and test the features have to be countered by the marketing value of the feature as sales. Given that there are lots of potential features, any given feature will be prioritized based on how valuable a selling point it’s likely to be. A feature that 1000s of photographers will use will be prioritized above a feature that 10s of photographers will use.

Beyond that though, there’s demonstrably apparent lack of imagination or something in the camera industry. Whether this is because the engineers or managers aren’t serious photographers or the consulting photographers are overly conservative and don’t seeing the utility the potential functionality, I don’t know. However, it is pretty clear that new feature are hard sells internally in many cases.

It’s hard to call the rate at which camera companies adopt ideas even glacial. There are glaciers that advanced and retreated in less time than it takes most camera companies to implement even basic ideas that should be readily obvious to start with.

Take AF fine tuning, for example. Canon and Nikon both release cameras with AF fine tuning in 2007. In 2016, Nikon finally included automation for that process in the D5 and D500, and Canon still lacks the feature entirely. That’s almost a decade between when AF fine tuning was introduced, and when the process was automated by a major manufacturer.

Now bear in mind, one of the things that was mentioned in many of the AF fine tuning white papers back when it was new, was that for optimal performance, you should find tune your camera and lens in the lighting and at they distances that you would be using them before a shoot. Automating a process that takes several minutes to do doesn’t seem like a real stretch of the imagination, even back in 2007 or 2008.

Of course, one might argue that the costs of developing an AF fine tune algorithm might be sufficiently expensive that it’s not worth it. It fails the business case test.

I’d argue that’s not obvious that it does though. There have been articles on how to do AF calibrations faster and more accurately going back to 2008 when the functionality first appeared. My first article on the topic was I believe in 2009, and I wasn’t the first person to write about it. In 2010 I posted a series on how to build an AF calibration target that attempted to be faster and easier to read than the regular scale. In 2012 I posted a script to automate the collection of all 41 AF tune images using a computer.

In 2013, a photographer that goes by “testcams” on YouTube, published his method of AF fine tuning which he called dot tune, that used the AF confirm dot to more quickly ascertain the AF fine tune offset instead of comparing images individually.

Clearly the community has been trying to find effective and efficient ways to preform AF tuning procedures for almost as long as we’ve had the capabilities. Automating it doesn’t at all seem like a stretch give the apparent interest from the community as a whole on the topic.

Yet, even while the community has been trying to find fast and effective ways to do AF calibration, the camera manufactures are still pushing the same story; auto focus on a target, take an image, inspect the image at high magnification on a big monitor, adjust the fine tune step, repeat.

Calling this a glacial pace is a disservice to pace of glaciers.

At the same time, it’s not like the user community has been standing by idly twiddling their thumbs either. Enterprising individuals figured out how to upload custom code to some Canon cameras, first the CHDK project for Canon PowerShot compact cameras, and then the Magic Lantern project for Canon DLSRs.

Both of these projects clearly show the power that can be had by giving enterprising photographers, especially those of us with backgrounds in computer and software engineering, the ability to modify and expand the capabilities of their camera.

Magic Lantern, implemented automation for the dot tune method back in 2013 shortly after the method was described. Well before Canon or Nikon had any hint of providing automated AF fine tuning.

However, because there’s no open collaboration between the camera maker, Canon, and the Magic Lantern community. Canon can’t easily benefit from the features that the Magic Lantern community develops, and the Magic Lantern community is even more seriously hamstrung in their ability to support certain cameras (no 1-series or Cinema cameras, or risk Canon’s legal ire) fast they can add support in any camera.

The Magic Lantern community has also gone on to develop all kinds of added functionality, from time laps tools that do controlled bulb/exposure ramping with lighting change, to lightning trigger scripts, to motion detection triggers, to trap focus, and of course there’s the big selling point for Magic Lantern, 14-bit RAW video, a feature thats only really found built in to Red cinema cameras natively. All of which, in a very real way makes for a selling point for Canon with out added development cost.

And for anyone who might be saying, “Yeah, but photographers don’t have the skills to do this reliably or properly.” The simple fact that Magic Lantern exists and that there’s a community that includes developers not just users, is evidence to the contrary.

But beyond that, photography is a hobby for many more than it’s a profession. And many of those hobbyists come from fields involved in computer and electronic engineering. More of the people I know who are into photography as serious amateurs come from computer backgrounds, than anything else. Several, myself included, come from the kinds of computer engineering or computer science backgrounds and professions that make us versed in the ability to write the kind of software that’s used too.

With a more open approach to the software side of the camera, individuals in the community can go off and experiment with new ideas for features, or implement the features they need or want. If nothing comes of it, there’s noting lost but that persons time and effort. If something does come of it, we can all profit from it. People who are interested in Lightning photography, can spend the time to figure out how to develop an optimal mode to trigger the camera automatically on a lightning strike. People who shoot rocket launches can implement battery conserving sound triggers.

And of course, if none of this stuff matters to you, you don’t have to download and install some random person’s firmware or add-on package.

That’s one of the nicest advantages of the whole thing. People who are inclined to push boundaries, can. And those who need conservative reliable well supported systems can continue to use the stock firmwares developed and maintained by the manufacturers.

Food for thought at least.