When running CellRanger on 10x scRNA-Seq data, a BAM file is output with the aligned reads. These reads have an xf tag, described here:

The bits of this tag are interpreted as follows:

  • 1 The read is confidently mapped to the transcriptome
  • 2 This read's barcode, UMI, and feature combination was discarded in favor of a different feature with higher read support
  • 4 This read pair maps to a discordant pair of genes, and is not treated as a UMI count
  • 8 This read is representative for a molecule and is treated as a UMI count
  • 16 This read maps to exactly one feature, and is identical to bit 1 for transcriptomic reads. Notably, this bit is set for a Feature Barcode read, while bit 1 is not
  • 32 This read was removed by targeted UMI filtering.

In a real dataset, I have this distribution of xf values:

$ samtools view possorted_genome_bam.bam |  egrep -o "xf:i:[0-9]+" | sort | uniq -c
66263599 xf:i:0
99892363 xf:i:17
  245179 xf:i:19
 8283967 xf:i:25

It is clear to me that 0 are unaligned, 19 = 16+2+1 are discarded, 25 = 16+8+1 are kept (and used in the feature_barcode_matrix); but I do not understand what happens to the 17 = 16 +1. They seem to be good reads, they are aligned on genes, yet they are discarded.

One possible explanation from my reading of this paragraph is that the reads with 17 are PCR duplicates, thus ignored, whereas the reads with 19 are in a group matching different genes (several reads with the same BC/UMI but matching different genes). But this doesn't look right when exploring the BAM file manually.


1 Answer 1


From the documentation at https://kb.10xgenomics.com/hc/en-us/articles/115003646912-How-is-sequencing-saturation-calculated-

All of these samflag 0x400 reads have an xf tag value of 17, which consist of bits 1 and 16. This also means these reads do not have the xf bit of 8, which mark representative reads from a group of duplicates. The converse isn't true though. The xf17 consist mostly of samflag 0x400 duplicate reads but also of samflag nonduplicate reads.

  • $\begingroup$ Thank you for the useful answer, however I don't think it's fully answering the question: that suggests that some of these reads, but not all, are duplicates of some sort, but still leaves to me some mystery about what the other ones are, how the duplicates are detected etc $\endgroup$
    – Alexlok
    Apr 13, 2023 at 12:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.