UUTrack.Controller.devices.hamamatsu.hamamatsu_camera.py

File taken from ZhuangLab

A ctypes based interface to Hamamatsu cameras. (tested on a sCMOS Flash 4.0).

The documentation is a little confusing to me on this subject.. I used c_int32 when this is explicitly specified, otherwise I use c_int.

Todo

I’m using the “old” functions because these are documented. Switch to the “new” functions at some point.

Todo

How to stream 2048 x 2048 at max frame rate to the flash disk? The Hamamatsu software can do this.

Section author: Hazen Babcock 10/13

exception UUTrack.Controller.devices.hamamatsu.hamamatsu_camera.DCAMException(message)

Bases: Exception

Camera exceptions.

class UUTrack.Controller.devices.hamamatsu.hamamatsu_camera.DCAM_PARAM_PROPERTYATTR

Bases: _ctypes.Structure

The dcam property attribute structure.

class UUTrack.Controller.devices.hamamatsu.hamamatsu_camera.DCAM_PARAM_PROPERTYVALUETEXT

Bases: _ctypes.Structure

The dcam text property structure.

class UUTrack.Controller.devices.hamamatsu.hamamatsu_camera.HCamData(size)

Bases: object

Hamamatsu camera data object. Initially I tried to use create_string_buffer() to allocate storage for the data from the camera but this turned out to be too slow. The software kept falling behind the camera and create_string_buffer() seemed to be the bottleneck.

class UUTrack.Controller.devices.hamamatsu.hamamatsu_camera.HamamatsuCameraMR(camera_id)

Bases: UUTrack.Controller.devices.hamamatsu.hamamatsu_camera.HamamatsuCamera

# Memory recycling camera class. This version allocates “user memory” for the Hamamatsu camera buffers. This memory is also the location of the storage for the np_array element of a HCamData() class. The memory is allocated once at the beginning, then recycled. This means that there is a lot less memory allocation & shuffling compared to the basic class, which performs one allocation and (I believe) two copies for each frame that is acquired. WARNING: There is the potential here for chaos. Since the memory

is now shared there is the possibility that downstream code will try and access the same bit of memory at the same time as the camera and this could end badly.

FIXME: Use lockbits (and unlockbits) to avoid memory clashes?

This would probably also involve some kind of reference counting scheme.

getFrames()

Gets all of the available frames. This will block waiting for new frames even if there new frames available when it is called. FIXME: It does not always seem to block? The length of frames can

be zero. Are frames getting dropped? Some sort of race condition?

return [frames, [frame x size, frame y size]]

startAcquisition()

Allocate as many frames as will fit in 2GB of memory and start data acquisition.

stopAcquisition()

Stops the acquisition and releases the memory associated with the frames.

UUTrack.Controller.devices.hamamatsu.hamamatsu_camera.convertPropertyName(p_name)

“Regularizes” a property name. We are using all lowercase names with the spaces replaced by underscores. @param p_name The property name string to regularize. @return The regularized property name.