Page 1 of 1

Extending the axis for CyTOF data

PostPosted: Wed Jun 11, 2014 1:44 pm
by AdeebR
The default data display scale for FCS files from the CyTOF is 4 logs (up to 12,000).

In instances where the staining intensity of some paramaters is too high, and events are pressed up against the axis, I've found that (using Cytobank) the scale can easily be modified to display an extra log (up to 120,000); this makes the data look better and the distribution of events in the upper log seems to make sense.

However, I'm not sure if this is really a valid practice. Does the detector maintain proportional sensitivity for signals that would ordinarily be "off scale" (i.e, above the 4th log)?

Here's an example comparing the default 4 log display and the addition of an extra log:

4_logs.png (1.47 KiB) Viewed 13239 times

5_logs.png (1.66 KiB) Viewed 13239 times

Re: Extending the axis for CyTOF data

PostPosted: Wed Jun 11, 2014 3:49 pm
by anitamkant
The question is about the instrument dynamic range, and it covers two issues. Firstly, should one use such a reagent concentration that the corresponding signal will be over saturated (over four orders of magnitude)? Secondly, is the increased scale valid, or it is erroneous?

When signal intensity is too elevated (above four orders of magnitude) quite a few things could go wrong: detector longevity, its stability, and cell determination algorithm (threshold might be invalid). Under normal circumstances, there is no need to use such a high Ab concentration. I would strongly recommend against this practice for a starter.

Next, a few words about the plot presentation. Yes, it is perfectly valid presentation of invalid saturated data. On the second figure, the front graph has the high-intensity portion which is over saturated and collapsed on the detector max. Some signs of it also can be observed on the next background plot. Without proper understanding of the saturation phenomenon, one could assume that there is a cell population resolved with high Ab concentration, which is not true.

Re: Extending the axis for CyTOF data

PostPosted: Wed Jun 11, 2014 10:03 pm
by AdeebR
Thanks Anita. So just to confirm that I understand your point correctly, the 4th log represents a "hard" saturation point on the detector, and signals above this are no longer resolved in a linear fashion. So in this case, the apparent "high" population on the front overlay is not really a true population, but instead represents the events at the detector maximum, that have been normally distributed around that maximum value as a result of the modified display?

I appreciate your point about reducing antibody concentrations as standard practice. However, I was curious whether data generated in these circumstances is usable or completely invalid.

One thought regarding reducing antibody concentrations though:

It has been standard dogma in the conventional flow cytometry field that a prerequisite to being able to accurately quantify relative changes in antigen expression is to use saturating amounts of antibody (sufficient antibody to bind all available epitopes of the antigen in question). In this scenario, one can assume a ~1:1 ratio of antibody to antigen (ignoring considerations of monovalent/divalent binding), and changes in staining intensity can consequently be interpreted to be the result of increases or decreases in antigen expression. If an antibody is only used at sub-saturating levels, dynamic changes in antigen expression may not be accurately resolved because there is insufficient antibody to bind increased levels of antigen in a linear fashion.

In this particular example, the amount of antibody used was optimally titrated for a maximal staining index using PBMCs (this concentration still produces minimal background staining on truely negative populations, suggesting an appropriate titration). However, the cells in this example are activated dendritic cells that do in fact express very high levels of HLA-DR.

This seems like this could be an issue if CyTOF antibodies have to be titrated down to sub-saturating levels to accommodate the dynamic range of the instrument.

Any thoughts?

Re: Extending the axis for CyTOF data

PostPosted: Fri Jun 13, 2014 7:39 pm
by anitamkant
Thanks to Adeeb for bringing important points to the forum.
1) The dynamic range for CyTOF is 4 logs and that for CyTOF2 is 4.5 logs with saturation point at ~31,625 counts. So you will lose the ability to resolve events that have signals above this saturating value. For example, let's consider 2 cells, one with a mean intensity of 100,000 counts and another with a mean intensity of 1,000,000 counts. Both are saturating and will be recorded as having ~31,000 counts.

2) Your data is usable for relative quantification (which is a common norm in flow and mass cytometry) where sub-saturating levels work fine.

3) Saturation of signal is an issue with any platform where the detector is detecting ions or photons (Flow Cytometry, Mass Cytometry, Plate readers, Microarray systems.....and so on). The idea is to strike a balance for quantifying your highest biological response within the detection limit of the system.

4) Absolute quantification of a "Very HIGH SIGNAL" on Mass cytometry without saturating the system can be done by following methods. (Any other suggestions are welcome from the community):
a) Custom label the high signaling antibody with a lower amount of metal using a suboptimal amount of metal when loading the polymer.
b) Use suboptimal metal like 141Pr for this antibody

Re: Extending the axis for CyTOF data

PostPosted: Mon Apr 29, 2019 6:58 am
I'm Thibault Andrieu and I'm in charge of cytometry core facility in Lyon (France) which include a Helios mass cytometer
When I explore a fcs file generated from Helios, I observe a dynamic range (DNR) between 4096 (10bits) and 65536 (16bits). This DNR is different between masses !
In flow cytometry the DNR define the log scale display ; for exemple for a BD-LSR, log10(2^18bits)=5,4 decade log / fluorescence chanel
Is anyone could give me some explainations ?
What is the exact DNR for Helios ?
In the technical sheet of Helios fluidigm give us a DNR of 4,5 , does it mean 15 bits of numerization ?
Best regards

Re: Extending the axis for CyTOF data

PostPosted: Mon Apr 29, 2019 5:23 pm
by mleipold
Hi Thibault,

I'm not sure that I completely understand what you're asking.

To me, "dynamic range" is the range of intensities that can be accurately measured. In other words, above background noise, but below saturation of the detector. As Anita says below, the detector saturates at ~31,625 counts, so by my definition, that would be the top of the dynamic range.

This would be a separate question from how many bits are required to code the data (in total, or per-channel). I'm not entirely sure how the software writes the FCS files, but looking at part of one of my FCS headers:

It *appears* that the bit range for the data is 4096, *unless* it needs to be greater. So, if the signal intensity coming out of the instrument is 4096<x<8192, then it would be 8192. If 8192<x<16384, then it would be 16324, if 16324<x<32768, then it would be 32768.

I judging this based on the markers in the above section: bright channels like the Bead 140/151/153 channels are 16324, and CD57 is the only one that reaches into 32768.

Hopefully Fluidigm will clarify this further.


Re: Extending the axis for CyTOF data

PostPosted: Mon Apr 29, 2019 6:33 pm
by BjornZ
Fluidigm's $PnR values are not meaningful as far as trying to make statements about the dynamic range of the instrument. There are three settings in the FCS Conversion dialog that affect $PnR:

1. If you have "compatible with FlowJo" checked (default when acquiring samples, wherein you don't use the dialog), then $PnR is the next power of 2 above the measured max. If you don't have that checked, then $PnR is simply the measured max value.

2. The "Auto Scaling" global/per-parameter selector decides if $PnRs are the same for all channels (max across all channels), or are per-channel. Default is per-parameter.

3. The "minimal scaling" value is the smallest $PnR allowed, and I think defaults to 4096 as Mike observed.