Folks:
I’ve written an article about a simpler yet more powerful interface for point and shoot (“compact digital”) cameras at http://philip.greenspun.com/business/point-and-shoot-camera-interface and would appreciate comments/suggestions. I think this is a great project for a master’s student who likes to code (or maybe a group of graduate students). The practicality of the project hinges on the fact that Samsung has released the source code for the software within two of its high quality cameras.
Thanks in advance for ideas to make this design better.
I don’t think this is a good idea. For all their flaws, cameras have controls that are designed specifically for the task at hand. Think of the Leica X1/X2, for instance, which is incredibly clear and uncluttered. The part that sucks is the workflow post-capture, and the fact camera makers couldn’t write usable software if their lives depended on it (and in fact does).
The Samsung/Sony approach of putting Android or equivalent app-capable OS on the camera is also doomed. Advanced cameras for enthusiasts are a small market, only about 20M units a year or so for interchangeable lens cameras. That’s probably about the same size as the also-ran Windows Phone OS hardly any developer bothers to write for.
The best bet would for CIPA or the like to develop a standardized bidirectional protocol for controlling a camera over Bluetooth, and treat it as a smartphone/tablet peripheral (i.e. like a CamRanger without the CamRanger hardware), along with a one-touch “send to smartphone” button. The idea is zero (visible) software on the camera itself. Users would then be able to do the workflow with their phone/tablet using properly designed software in a market big enough to sustain good app developers.
There’s no mention of the flash in your document. I frequently disable it (because it’s not allowed/too distracting/would make an awful photo) or explicitly turn it on (bright sunny day and you need to fill shadows). The “nighttime flash” option (leave the shutter open for a while, but also fire the flash) is also very useful.
Also, the lighter/darker controls could operate after the photo is taken. The shutter snaps a series of bracketed photos, and you spin a dial to quickly select the best one. Or just shoot everything HDR and tone-map afterwards.
Several years ago, Stanford tried launching something similar with their Frankencamera project. I’m not what became of it.
[Personally I’d find such a camera very frustrating – I love the controls on my old S90.]
Well, nice start. I agree to Fazal statement. I also think there should be standard raw image acceptable to all camera devices and software for post processing.
While I am not aware of the market opportunity for cameras, I would welcome an interface that allows me to leverage my existing knowledge of the Android platform. Last weekend, a friend visited here in DC and we did the “tour.” I don’t use my Canon camera enough to remember immediately where I find every setting. It takes me 30 minutes to use the “wheel” on the camera to go through each item to set it up. Items include verification that the date and time won’t be stuck on each picture, auto focus, shutter speed, storage location (i.e. SD Card) and then several practice shots.
From my experience around DC last week, I would also guess that others would like to combine familiar interfaces with the camera as well. While my research is not scientific, my trips around Washington DC last weekend yielded most people lugging the iPad and taking pictures with that device over a camera they pulled from their pocket. I did find it interesting that I did not see any Android tablets being held up at the Lincoln Memorial, only iPads.
I believe that consumers will still recognize that if you have a camera that is designed for taking superlative pictures, then they will not expect that the camera should make phone calls. Therefore in the adoption of the Android platform, the focus should be on the camera components and making them operate seamlessly. Eliminating the phone components should help to improve battery life.
Camera requirements should include a 802.x or bluetooth in order to post pictures from the camera to the cloud as quickly as possible. This feature allows the consumer to continue taking picture and shift the storage component from a “local” issue, to the cloud. There is nothing worse than arriving home at night after a day of vacation and off loading the camera in order to avoid “losing” a day of work through corruption or loss of a device.
No idea is a bad idea and here’s hoping others can build on this one.
JJD – Camera Shy…