Image intensity (or sometimes called color) data are represented by channels. Channels have real meaning especially in fluorescence imaging where their intensity values are directly proportional to the concentration of the given fluorophore.

There is also another special channel called All or RGB in case of RGB images. RGB and All are treated the same by most nodes. There are, however some nodes that require specifically RGB image. Processing nodes by default process all channels the same. Deconvolution node is the notable exception which allows defining per-channel settings.

The channels parameters have metadata which are assigned before the run of GA3 (during the design of the recipe).

Notably:

All channels must have the same metadata when saved to the ND2 file. They are coerced to maximum value in the save node.

Binaries (a.k.a Binary layers) are typically a result of segmentation. They are made of contiguous patches or segments of pixels representing entities such as cells, spots or organoids. The are displayed as semi-transparent overlays or contours on the image.

The same principles apply to 3D where objects are made of contiguous 3D patches of voxels.

Binary objects may have an ID which links them to the measured features stored in tables. In such case the binary is stored as an “image” of 32-bit integers, where every pixel is a natural number (object ID) or zero (background).

In many situations the object ID is not needed and as it is expensive to compute its pixels are simply marked as objects or background. Stored as 8-bit unsigned integer where zero is the background and non-zero is the object. These objects have implicit IDs going from top-left to bottom-right from 1 to N.

An object to be must not touch others (to be separate objects). It must be divided by one pixel horizontally and vertically.

Binaries have the same limitations as channels regarding metadata during the GA3 run.

Tables 2D arrays of values organized into columns and rows. They are the primary result of Measurement.

Columns in GA3 are typically made of one or more book-keeping (called system) columns such as loopIndex for every loop (time, z-stack, multi-point), object ID and entity for objects followed by feature columns.

Book-keeping columns are used to link a table row to frame, volume or object. If a table does not have such columns it looses capability to link to the image data.

Columns have metadata such as:

Book-keeping columns have always the same ID. Other columns have their column ID kept from the moment of their creation. The benefit being that changing the title does not break the downstream nodes (such as graphs) which reference the columns by ID and update with the title change.

When merging tables however, columns may be discarded because of their ID which is same coming from two or more tables where only the leftmost is taken. In such situation use the Data manipulation > Table Manipulation > New Column ID node.

Rows are filled during the GA3 run. By default tables are processed frame-by-frame or volume-by-volume unless accumulated.

Rows values may contain various data encoded into text such as

Nodes are setup using settings dialogs. Each node have a different more less complex depending of its functionality. Some nodes do not have settings dialog at all.

The set of Control parameters represent the state of the node.

The widgets in the dialog correspond to Control parameters which are:

With a special dialog some Control parameters can turn into input parameters making them “dynamic”.

This is useful when a control parameter (typically a number) has to be set by a preceding node. As an example threshold may take the low limit from minimum intensity or a quantile.

The Image processing graphs typically connect one (or more) processing nodes one after the other from the source Channels node through All channels and save the result.

Three examples below show three common processing nodes:

Figure 660. 

In many cases it is practical to calculate a projection or Reduction over all a loop and the subtract it from every frame.

In the examples below:

Figure 661. 

Segmentation-only graphs create a Binary layer over the original image. Therefore the graphs typically save the original All channels and the binaries from the segmentation.

In the example below two Channels are segmented:

Figure 662. 

It measures field features such as channel intensity or ratio of channels. The measurement produces a table with one row per field (typically frame).

In the example below there is a Measure field (Measurement > Basic > Field) that has an optional mask input such as ROI that is drawn interactively when the graph is ran.

Figure 663. 

It measures object features such as size, shape, position or channel intensity. The measurement produces a table with one row per object. The main input of this measurement node is a binary layer and an optional channel for intensity measurement under the binary.

In the example below the Measurement > Basic > Object is connected the Obj binary coming from the Threshold and to the All channels for intensity measurement. The original channels, thresholded binaries and the object table are all saved.

Figure 664. 

In many cases where cells must be segmented it is practical to segment nuclei first (as it is easier) and grow them following intensity (using the watershed algorithm) until background intensity is met or another cell is encountered. This technique ensures a relatively correct number of cells with more or less adequate cell shape.

Figure 665. 

Then, to ensure that all cells are well-formed (i.e. each has one nucleus and non-empty cytoplasm) use the Binary processing > Cell Processing > Make Cell node before Measurement > Basic > Cell measurement.

Figure 666. 

Records are the products of measurements. They represent tabular data. Measurements produce records one frame at a time. In some cases the task requires bigger chunk of data at once. Hence the rows have to be accumulated over a loop or overall.

In order to display the records nicely as a table or graph chart it requires making a appropriate table or chart out of the mere records.

Figure 667. 

It is common to show the Tables and graphs organized near the image inside panes that allow for showing and hiding the elements as needed.

In the example below the Records output of the Measurement > Basic > Object Count measurement is accumulated using Data manipulation > Basic > Accumulate Records and visualized in a Table and a Timechart showing the evolution of the number of objects over time.

The ObjTable and the Histo both contain frame data and are displayed in the left Results & Graphs > Layout > Stacked one over the other whereas the AccumTable and the Chart containing the accumulated data are displayed in the right Results & Graphs > Layout > Stacked.

Figure 668. 

Tracking objects connects the “same” objects in subsequent frames in time.

As objects appear and disappear on each frame due to nature of the sample and segmentation imperfections the “same” object typically has a different object ID on the next frame. Tracking solves this task by assigning each object a track ID which is the same for “same objects”.

The example below builds on object measurement. It combines track ID coming from the Tracking > Tracking > Track Objects with the measurement columns using Data manipulation > Basic > Append Columns (both tables have same rows – objects). The Tracking > Tracks > Accumulate Tracks puts together all the frames and organizes the Records by tracks.

Figure 669. 

Tracking particles solves the same task of assigning ID to the “same” objects. But it also measures motion features like speed.

In the example below the Tracking > Object Position > Time & Center measures time and position for every object, Tracking > Tracking > Track Particles assigns the track ID, Tracking > Tracks > Accumulate Tracks puts all particles into one record set and finally Tracking > Tracking Features > Tracking Features > Motion Features calculates the dynamics of every object.

Figure 670.