top of page

Unmixing: the tortoise beats the hare

Updated: 12 minutes ago

Today's tip: when running your single-color controls, take it slow.


These are not generally huge effects, but it can still help.


To show what happens, today we've got examples of the same panel run on the Aurora with the controls run on high speed versus low speed with an acquisition delay. In both cases, I've done the unmixing using the wizard, setting the gates like I normally would (upper end of the positive, using a universal negative, using cell controls). The fully stained samples were run once, on medium speed and re-imported to be unmixed both ways. So, it's exactly the same data, just unmixed using matrices derived from the same controls acquired in two ways.


Note: this is not intended to be a good panel. It's just meant to be a large panel using what we had lying around. It's good for revealing errors with unmixing due to the complexity (and also be useful for exploring autofluorescence). You can check out the data and panel design on Mendeley Data, if you're interested. The examples below are all mouse spleen.


Unmixing accuracy


The unmixing can still be pretty accurate on high speed. Surprisingly so, given the quality of the controls, as we'll see later. Here are some issues I spotted:


Running the controls at higher speed can introduce unmixing errors
Running the controls at higher speed can introduce unmixing errors

The CD39 is the biggest issue I could find. The IgM-AF532 is off with respect to several channels with similar wavelength emission, but it's only really noticeable on the brightest events (intracellular staining here, so those are plasma cells). Otherwise, there are some little things that are off in both cases, many due to spread, one due to aggregates of an old antibody and others probably due to inadequate extraction of the autofluorescence.



Unmixing precision


If you want to separate very similar fluorophores, you need to reduce the unmixing-dependent spread as much as possible. For this, it helps to have precise measurements of the spectra. Running the controls slower can help with this.


Increased unmixing spread with speedy control acquisition
Increased unmixing spread with speedy control acquisition

That's obviously not a huge effect, but it represents a free gain in resolution that is otherwise hard to achieve.


We can look at this resolution loss a little more formally by assessing the how much variation there is in the data and how well centered the data are around zero. For this, I'm using a metric based around the robust standard deviation and median as related to the total range of the cytometer.


With high-speed control acquisition, we lose resolution in a few key areas, particularly ones that are harder to unmix such as BB515:KB520 and PE-Cy5:PE-Fire 640.
With high-speed control acquisition, we lose resolution in a few key areas, particularly ones that are harder to unmix such as BB515:KB520 and PE-Cy5:PE-Fire 640.

We can also see this in the similarity matrix and the overall complexity of the panel. The complexity index of this panel goes down from 36.47 (high speed) to 35.09 (low speed).



I couldn't spot the differences by eye, so here's a plot that measures the differential.


It's primarily in PerCP-Fire 806, where I have CD39 (low expression, low frequency) and had unmixing errors. The differences are coming up in parts of the spectrum where autofluorescence predominates.




Why this can happen:

  • Originally, I wrote this: [Running the samples slower allows more time for them to pass through the laser and flow cell, meaning more photons can be collected. This means brighter signals, which means more precision in the measurement (reference: Steen, Cytometry 1992).] Sanjaya k Mallick and Idun Dale Rein have pointed out that this is not correct. The sample velocity doesn't change with increasing flow rate, but rather it widens, allowing more cells to pass through simultaneously. This increases the CVs at higher flow rates, reducing precision. They've also pointed out that this reference is quite dated, so I'll look for newer ones when I get a chance.

  • More precision in the definition of the spectra can translate into better unmixing, particularly if you're using cell controls. BD also has some nice data showing that you can get better separation on low speed, which is likely true for most, if not all cytometers.

  • When you're running on high speed, more of the same is recorded during the initial boost/priming phase of acquisition when the stream is unstable. If the stream is unstable, you're likely to get imperfect excitation by one or more lasers, which could affect the spectral signature.

  • When you're running on high speed, the sample is more likely to clog. This happened to me in this experiment (see below). A clog can definitely affect the measurements. One easy way is to prevent you from acquiring more cells in a sample, leading to not having enough events to adequately determine the spectra from the brightest events in your data. For example, the IgM-AF532 I used did not acquire enough events in the speedily run control, meaning I had to use a lower gate, resulting in inaccurate unmixing of the IgM-high plasma cells.

  • Generally, if you're rushing, you're more likely to make mistakes. A mistake in any one of the controls will affect your entire experiment.



High speed acquisition is more likely to destabilize the flow
High speed acquisition is more likely to destabilize the flow

In the example above, the SBUV445 control run on high speed has clogged. Notice that the x-axis is in minutes rather than seconds--acquisition is stopping when the time limit is reached rather than the desired cell number target. On the right, with the BV711 control, we can see unstable event rate due to recording immediately during the boost/prime, which has been elided from the "slow" control by setting an acquisition delay of 10 seconds.


Recommended approach: For large panels, acquire the controls on low or medium speed. Set an acquisition delay so that the first burst of data from the boost are not saved. Cytek uses a 10sec delay for storing the controls in the reference library--and with good reason--but 4sec can be adequate. Depends on how careful you want to be and how much you can tolerate the extra time (and cost) involved.



Eurasian Bullfinch, Finland

コメント


bottom of page