From bf641d06c522b86213b28640e85dc6e483a70cbd Mon Sep 17 00:00:00 2001 From: Matthias Vogelgesang Date: Fri, 31 Aug 2012 16:47:21 +0200 Subject: Extend section on new camera integration --- docs/manual.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'docs') diff --git a/docs/manual.md b/docs/manual.md index 69abae8..0373010 100644 --- a/docs/manual.md +++ b/docs/manual.md @@ -381,6 +381,31 @@ virtual methods. The simplest way is to take the `mock` camera and rename all occurences. Note, that if you class is going to be called `FooBar`, the upper case variant is `FOO_BAR` and the lower case variant is `foo_bar`. +In order to fully implement a camera, you need to override at least the +following virtual methods: + +* `start_recording`: Take suitable actions so that a subsequent call to + `grab` delivers an image or blocks until one is exposed. +* `stop_recording`: Stop recording so that subsequent calls to `grab` + fail. +* `grab`: Return an image from the camera or block until one is ready. + +## Asynchronous operation + +When the camera supports asynchronous acquisition and announces it with a true +boolean value for `"transfer-asynchronously"`, a mechanism must be setup up +during `start_recording` so that for each new frame the grab func callback is +called. + +## Cameras with internal memory + +Cameras such as the pco.dimax record into their own on-board memory rather than +streaming directly to the host PC. In this case, both `start_recording` and +`stop_recording` initiate and end acquisition to the on-board memory. To +initiate a data transfer, the host calls `start_readout` which must be suitably +implemented. The actual data transfer happens either with `grab` or +asynchronously. + [sub-classing]: http://developer.gnome.org/gobject/stable/howto-gobject.html -- cgit v1.2.3