Developer notes

This page is currently in note-form and contains a variety of useful information. This content will eventually be categorized more carefully.

Simulated mode

You may run BakingTray on any machine with no acquisition hardware or even now ScanImage install by running: BakingTray('dummyMode',true) Most features should work but simulated mode is less well tested than normal operation. Simulated mode assists in development whilst not at the rig.

Running a minimal acquisition and benchmarking

You can initiate a minimal acquisition with no tile saving and even no GUI by setting up the recipe and then running:

>> hBT.runTileScan; hBT.scanner.armScanner; hBT.scanner.initiateTileScan

If you have the GUIs open then any relevant listeners in those GUIs will still fire. This is useful for working out things like timing bottlenecks. For example see issue #23. It's probably a good idea to benchmark a short acquisition if you're made changes to the acquisition GUI or to the SIBT tile acquired callback.

Caching dynamic values

Things like the NumTiles and TileStepSize properties of the recipe are calculated on the fly. So don't access these repeatedly in a time-critical loop.

Running BakingTray with a dummy laser for testing

Although it's possible to start BakingTray in "dummyMode" (see help BakingTray) for running without any hardware, you might want to run with just one hardware component missing. Running with a simulated laser attached is useful, since it allows the acquisition to proceed with the physical laser switched off. Start BakingTray normally then do the following:

>> hBT.laser=dummyLaser;
>> hBT.laser.parent=hBT;

How BakingTray access data from ScanImage to build the preview

The callback function SIBT/tileAcqDone is run by ScanImage each time a tile position has been acquired. This happens because the SIBT constructor adds a listener to the ScanImage object at hSI.hUserFunctions.acqDone, one of the hooks for the ScanImage User-Functions. The tileAcqDone callback captures the last acquired images, downsamples them, and places them in hBT.downSampledTileBuffer, where other methods easily have access to the data.

How is the tile pattern generated?

The acquisition settings are stored in BT.recipe. The tile pattern is produced by the method BT.recipe.tilePattern, which generates an n-by-2 matrix. Each row is a different tile position. The first column is the X stage location and the second column the Y stage location. The matrix is generated by generateTileGrid, which is a function local to BT.recipe.tilePattern. This function produces the tile pattern based upon the following variables:

• The microscope FOV: extracted from the scanner.
• The amount of overlap needed at adjacent tiles: set by the user.
• The size of the sample along X and Y: set by the user.
• The "front/left" position of the whole pattern (this is just an offset): supplied by the user and stored in the structure recipe.FrontLeft

The size of the sample in mm along X and Y is converted into tiles using the class NumTiles, which is attached to recipe. The NumTiles class returns the number of tiles needed to cover the desired area in X and Y. It does this based upon the length and breadth of the bounding box and the tile overlap. At the command line you can do:

>> hBT.recipe.NumTiles.X      
ans =
    11

>> hBT.recipe.NumTiles.Y
ans =
    12