GateLabR opens the GateLab gating application on a SingleCellExperiment or a flowWorkspace GatingSet from an R session, for flow cytometry and mass cytometry (CyTOF) data. It does three things.
The object is gated where it is. launchGatingApp(sce) or launchGatingApp(gs) opens a browser tab on its samples, one at a time or pooled, drawing the assay chosen in the header. Rectangle, polygon, ellipse and quadrant gates build one population tree for the object. The interface is GateLab's, with its Strategy, Illustration, Layout, Plotting and Statistics tabs, and with shiny 1.14 or later the R prompt stays free while the tab is open.
The gating is stored in the object. Gates, populations, scales, compensation records and figure settings are written to metadata(sce), or to a keyword on every sample of a GatingSet, as the work is done and restored when the object is opened again, so saving the object saves the gating. A GatingSet also brings its own hierarchy: the gates it holds open in the app, each in the transformed space the object evaluates it in, with the same counts.
Populations come back to R as data. "Save to SCE" stores which events each population holds, read with gatelabPopulations(), gatelabHierarchy() and gatelabLeafPopulation(). "Export populations to colData" writes a column per population for diffcyt, CATALYST or any other tool that reads the object. On a GatingSet, "Save to GatingSet" writes the populations to its hierarchy as flowWorkspace gates, so gs_get_pop_paths(), gh_pop_get_count(), gs_pop_get_data() and ggcyto read them as they read any node, and save_gs() keeps them. gatelabGatingSet(sce) builds a GatingSet from a gated SCE, its populations written as the same nodes, for flowWorkspace, openCyto, ggcyto and CytoML.
It exists because a Bioconductor cytometry analysis holds its events in a SingleCellExperiment, while manual gating is usually done in a separate program on FCS files, and a gate drawn there has to be exported and matched back to the object's events. GateLabR gates the object itself, so a gated population is a column of the data the next step already uses.
remotes::install_github("david-priest/GateLabR")
library(GateLabR)
launchGatingApp(sce)
GateLabR starts from a SingleCellExperiment or a GatingSet and does not read FCS files itself; flowWorkspace::GatingSet(read.flowSet(...)) or CATALYST's prepData() assembles them (the vignette shows both). To gate FCS files without R, use GateLab in the browser, which is the same application.
For flowWorkspace and openCyto users, nothing changes in the object's conventions: a GatingSet parsed from FlowJo, Cytobank or Diva with CytoML, or gated by openCyto, opens with its hierarchy, transforms and compensation as they are; a gate drawn in the app returns as a rectangleGate, polygonGate or ellipsoidGate under its parent's node, named as the population; a population the object's gate types cannot hold (a quadrant, a gate excluded from a population, a polygon drawn in another transform space) returns as its exact per-sample membership, a booleanFilter-class node that gh_pop_get_indices() reads like any other. The object is modified in place, as flowWorkspace always modifies it: a matrix applied in the app goes through compensate() on a writable, uncompensated, untransformed object, and a GatingSet loaded with load_gs() is read-only on its data, so for one of those compensate and transform before launching.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
