This question turns up on research forums in almost the same words every few months:
“I read Ct values as 32–33, but the software says 35.4. What would be the right answer, my values or the software's?”
Recurring question on qPCR method forums
The honest answer is that neither is “right” in the way the question assumes. There is no ground truth Cq hidden in the tube. There is a fluorescence trace, and then there are decisions about how to read it. Yours and the software's differ, and 3 cycles is a 8-fold difference in starting quantity — large enough to change a conclusion.
The chain that produces a Cq
Four steps sit between the raw detectors and the number on your screen. Each one has at least two defensible settings, and the vendor's defaults are not published.
1. Spectral unmixing
Raw fluorescence from each well contains signal from every dye in the reaction, including the passive reference. Multicomponent analysis separates them using a calibration matrix from the pure-dye spectra. Change the matrix, or let the software build it from your own wells, and the shape of the curve changes slightly before anything is even called a Cq.
2. Baseline subtraction
Background fluorescence is estimated from early cycles and subtracted from every cycle. The estimate usually comes from a fixed window — cycles 3–15 is common — either as a mean or a best-fit line. Change the window, and the baseline changes. The curve then shifts up or down while retaining its shape, which moves where it crosses a fixed threshold.
This step is where the largest silent errors live. Ruijter and colleagues showed in 2009 that a 2% error in baseline estimation alone can move a reported fold change somewhere between roughly 0.7 and 9.5 — a factor of more than ten, from one setting nobody looks at.
3. Threshold placement
Now the trace is in log space and something must decide where “amplification” begins. Three families of answer:
- Automatic, noise-based. Threshold set as a multiple of the standard deviation of the baseline — often ten times. Sensitive to how noisy the early cycles were, and therefore to the reaction, not the biology.
- Automatic, curve-based. A fraction of the maximum fluorescence, or a point derived from the fitted curve. Plate-wide or per-well, depending on a checkbox most users never open.
- No threshold at all. Second-derivative maximum methods find the point of steepest acceleration on the fitted curve. No threshold is placed, so nothing can be “above” or “below” it.
A low noise-based threshold placed early in the curve produces a later Cq than a human eye reading the visible take-off point. That is exactly the 32-versus-35.4 pattern: you are reading the bend, the software is reading a multiple of the noise floor.
4. Interpolation between cycles
Fluorescence is sampled per cycle, but Cq is reported to two decimals. The value between samples comes from a model: linear interpolation, a four-parameter logistic, a sigmoid fit. Different models on identical data differ by tenths of a cycle. This is the step that looks most precise and is least certain.
| Source of difference | Typical effect | Can you see it in the export? |
|---|---|---|
| Baseline window | Large, and non-obvious | No — already applied |
| Threshold rule and level | Tenths to several cycles | Sometimes, as one number |
| Plate-wide vs per-well threshold | Tenths, unevenly across wells | No |
| Curve fit / interpolation | Tenths | No |
| Software version change | Unbounded — “obsolete result” | Warned about, not quantified |
Why the vendors do not simply tell you
Not out of malice. The thresholds are part of a competitive implementation, and the documentation says so in the flat language of release notes:
“this may impact the Cq value for legacy data” · “Obsolete analysis result if the results come from an non-compatible software version.”
Thermo Fisher, Design & Analysis 2.5.1 release notes
“we cannot guarantee the performance of the software or provide support for the analyses”
Applied Biosystems, official documentation, on data from unsupported versions
Read those two together and the practical situation is clear: reopening an old experiment in a new build can change your Cq, the software will tell you the result is obsolete, and it will not tell you either the old number or the new one. The number is real, reproducible within a build, and not portable across builds.
What actually helps
You cannot recover the vendor's decision chain. You can stop depending on it, which takes four habits:
- Write the parameters into the methods section, not just the software name. Baseline window, threshold value or rule, and the Cq method. One sentence now saves a reviewer exchange later.
- Report more than one method. If single-threshold, second-derivative and efficiency-corrected methods land within a fraction of a cycle of each other, your conclusion is not an artifact of one threshold choice. If they diverge, you needed to know before the reviewer did.
- Compare normalised quantities, not Cq values, when you change instruments or software. Cq is not comparable across runs — a point made in the literature more than once — while a properly calibrated normalised ratio is.
- Keep the raw fluorescence. Once baseline correction is baked in, no method can undo it. If you may need efficiency-corrected analysis later, export raw.
Three methods agreeing is not proof of correctness. If the baseline is wrong in the same direction for all three — common-mode error — all three will be wrong together and will agree beautifully. Agreement tells you the conclusion is robust to method choice. It tells you nothing about the baseline.
This is why any tool claiming to “verify” your Cq should state its baseline handling explicitly. A verification tool with a hidden baseline is a second black box, not a check on the first one.
Quotes above are from vendor release notes, vendor documentation and published method papers as cited in each block; the 2009 baseline-error figure is from Ruijter et al., Nucleic Acids Research. This page is written for research use and contains no clinical interpretation.