Details¶
Camera Control¶
There are two classes that facilitate camera control:
All interaction with the camera (connecting to different services, exchanging data, etc) is handled by PyWunderCam
,
while state tracking and validation is handled by CamState
.
CamState
exposes all camera parameters as class properties and the getters and setters of those properties are
doing the marshalling from and to the camera parameter names. To reduce the amount of communications with the camera,
all the changes of individual parameters are scheduled in one batch rather than changed immediately.
When the state is obtained with something like:
wc = PyWunderCam()
camera_state = wc.camera_state
The camera state object is entering edit mode. In that mode, any changes to its attributes are simply recorded and put in a queue. If multiple changes are applied to an attribute, only the last change is preserved.
When the state is assigned back to the camera with:
wc.camera_state = camera_state
All queued camera state changes are applied to the camera and the responses collated to reflect the latest camera state.
Resource I/O¶
All interaction with the camera’s file system occurs over a typical HTTP interface. The onboard camera control service
does contain file system functionality (e.g. calls to list, retrieve, delete files) but since an HTTP interface is
provided, all file related requests are handled via HTTP “verbs” such as GET, POST, PUT, DELETE, HEAD
.
There are three classes that facilitate file I/O:
The design here is straightforward, a ResourceContainer
contains zero or more SingleResource
or
SequenceResource
. SingleResource
represents a single file, SequenceResource
represents mutliple (grouped)
files, such as those that result from taking pictures in “Burst” mode. SequenceResource
is in fact a list of
SingleResource
with a set of convenience functions.
When the file system state is captured with something like:
fs_state = wc.get_resources()
PyWunderCam returns a dictionary with two top level ResourceContainer
s. One for images and one for videos.
A ResourceContainer
is a representation of the camera’s file state at the moment it was obtained. To discover
new files that were created as the result of an action (e.g. taking one or more pictures or videos), simply subtract
two ResourceContainer
objects. Usually these are the AFTER the action and BEFORE the action was taken
objects. This temporal order (AFTER-BEFORE) needs to be preserved, otherwise the difference is obtained but results
to an empty set.
This means that a camera’s actions can be scripted and a collection of the files that were generated be returned to the
user in one block. For example, the user could obtain a baseline ResourceContainer
, program the camera to obtain
two single shot images and 2 bursts at different rates and finally get a ResourceContainer
with all the files
that where created by this “programmable” type of action.
Resource Metadata¶
ResourceContainer
s are relying on
regular expressions with named groups
to extract metadata from the filename of a resource.
In the case of the Wunder360 S1, image and video filenames follow a simple naming pattern that encodes the type of file resource, the date and time of acquisition, the frame (if acquired in “Burst” mode) and the format of the resource in the extension.
The named regular expression rules used by the Wunder 360 S1 are already encoded in constants
pywundercam.IMG_FILE_RE
and pywundercam.VID_FILE_RE
.
Metadata for a SingleResource
are accessed via the .metadata
read-only attribute.
Resource Transfers¶
File transfers are handled by pywundercam.SingleResource.get()
and pywundercam.SingleResrouce.save_to()
.
Specifically, if an image is retrieved, it is served back as a PIL.Image
object and can be readily used by a wide
array of other Python packages. save_to()
will simply transfer the file and save it locally.
The SequenceResource
equivalent save_to()
and get()
functions have similar side-effects but automatically
applied over image sequences.