Using smite's nice discovery how the locked part of the API can be unlocked, I played a bit with with a Python class that implements the camera API. The class itself is sort of an exercise how far you can get without writing a single special method for each API call, but instead try to get awy with just using __getattr__(). This worked quite well, but dealing with the results of the API calls can be a bit annoying because the JSON data returned by the camera can for example be a nested list with exactly one "inner element", like [["foo"]] -- even for calls where returning more that one string would not make much sense.
Anyway, I attach this class and a few related unit tests to this post. The unit test show what I figured out about the API. Most things was quite easy because the API call getMethodTypes() returns nice descriptions of the API calls.
Everything is based on work done with a DSC-QX10. I assume that it would be possible to get more interesting results with cameras from the NEX series.
In order to successfully run the tests, you'll need to unlock the API with smite's actEnableMethods.sh script. (two requests issued by the script would be easy to integrate into the Python class, but I was too lazy to do it up to now
)
Notes about some details:
I could not figure out how to successfully call getFNumber, getSupportedFNumber, getAvailableFNumber, setFNumber, getFocusMode, getSupportedFocusMode, getAvailableFocusMode, setFocusMode, getAvailableShutterSpeed, getSupportedShutterSpeed, getShutterSpeed. (Also note that getMethodTypes does not return anything about a call like setShutterSpeed).
I suspect that this just shows limitations of what the API for the QX10 supports -- the camera is probably just not supposed to be used by people who like to tweak the settings even a little bit. The API for NEX models hopefully supports the calls mentioned above -- but since I don't have one, I can't tell for sure...
A really odd detail:
When I wrote the test for touchAFPosition, I first got an error in another, already existing, test that worked fine before: test_whiteBalance.
It turned out that getAvailableWhiteBalance() returns an empty list of white balance mode, when an AF position has been selected by calling setTouchAFPosition(). Cancelling the AF posititon again removes the error. Other API calls may be affected too, but I did not check this.
Anyway, I wonder if this weirdness is the only one that might lurk in the API, and if Sony deemed it too embarassing to describe it in the API docs but instead just locked down the API...
