DataManager, UserFunctions and ConfigurationSaver
Three infrastructure components: one distributes acquired data, one lets user code hook into the acquisition, one persists the model to CFG and USR files.
hSI.hDataManager
scanimage.components.DataManager. It receives each acquired stripe and turns it into the
scanimage.mroi.RoiData array that the display, the integration ROI manager and the motion
manager all consume.
Member |
Description |
|---|---|
|
Read-only array of |
|
The object that maps stripes onto ROI data. Defaults to
|
|
Rebuild |
|
Clear it. |
|
Entry point called by the imaging system for each acquired stripe. |
Events
Event |
Fires when |
|---|---|
|
|
|
New image data is available in |
|
New histogram data is available. |
hL = most.ErrorHandler.addCatchingListener(hSI.hDataManager,'RoiDataUpdated', ...
@(src,evt)myAnalysis(hSI.hDataManager.hRoiDatas));
Note
These events fire on the acquisition path. Anything slow in the callback shows up directly as display lag or dropped frames - do the heavy work off the callback, for example by buffering and processing on a timer.
hSI.hUserFunctions
scanimage.components.UserFunctions. User functions are the supported way to run your own
code at defined points in the acquisition. They are stored with the configuration, so they
travel with the experiment rather than living in a script.
Property |
Description |
|---|---|
|
|
|
|
Each entry has the fields EventName, UserFcnName, Arguments and Enable.
s = struct('EventName','frameAcquired', ...
'UserFcnName','myFrameCallback', ...
'Arguments',{{}}, ...
'Enable',true);
hSI.hUserFunctions.userFunctionsCfg(end+1) = s;
Your function is called as myFrameCallback(src,evt,varargin), where varargin is
whatever you put in Arguments.
Warning
userFunctionsCfg and userFunctionsUsr are in
DENY_PROP_LIVE_UPDATE - they cannot be changed during an acquisition, not even through
the focus abort-and-restart fallback.
Events
Every event below can be hooked. They are declared on UserFunctions and fired by the
components that own the corresponding behavior.
Event |
Fires when |
|---|---|
|
ScanImage has finished starting up. |
|
ScanImage is about to close. |
|
A GRAB or LOOP mode is armed and waiting for a trigger. |
|
A GRAB or LOOP mode has started. |
|
A GRAB or LOOP mode has completed. |
|
A new acquisition within an ongoing GRAB / LOOP has started. |
|
A GRAB, or one iteration of a LOOP, has completed. |
|
A GRAB or LOOP was aborted. |
|
A FOCUS acquisition started or completed. |
|
A frame has been acquired. |
|
One slice of a multi-slice acquisition has completed. |
|
The digitizer reported an overvoltage condition. |
|
Frames were dropped while logging. |
|
ScanImage moved an actuator to correct motion. |
|
The motor position has, or may have, changed. |
|
A configuration file was saved or loaded. |
|
A cycle data group finished its last iteration. |
|
On-demand photostimulation lifecycle. |
|
Sequence photostimulation lifecycle. |
|
The photostimulation module aborted. |
See also
User Functions for the GUI and worked examples.
hSI.hConfigurationSaver
scanimage.components.ConfigurationSaver. Saves and restores the publicly settable
properties of the ScanImage model - not the hardware configuration, which lives in the
machine data file.
Member |
Description |
|---|---|
|
Read-only. Path of the currently loaded CFG file. |
|
Save to the currently loaded CFG file. |
|
Save to a named or interactively chosen file. |
|
Load a CFG file. With no arguments it opens a file dialog. |
hSI.hConfigurationSaver.cfgLoadConfig('C:\configs\two_color.cfg');
% ... change settings ...
hSI.hConfigurationSaver.cfgSaveConfigAs('C:\configs\two_color_v2.cfg');
The cfgFileSaved and cfgFileLoaded user function events fire around these
operations, which is a convenient place to apply settings that are not themselves saved.