Answers.Body: <p>From the documentation at <a href="https://kb.10xgenomics.com/hc/en-us/articles/115003646912-How-is-sequencing-saturation-calculated-" rel="nofollow noreferrer">https://kb.10xgenomics.com/hc/en-us/articles/115003646912-How-is-sequencing-saturation-calculated-</a></p>
  <blockquote>
  <p>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.</p>
  </blockquote>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-04-13T12:20:06.407Z
Answers.Text: 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
Answers.UserDisplayName: Alexlok
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-04-11T05:34:31.557Z
Answers.LastActivityDate: 2023-04-11T05:34:31.557Z
Answers.UserDisplayName: Eric Kofman
Body: <p>When running CellRanger on 10x scRNA-Seq data, a BAM file is output with the aligned reads. These reads have an <code>xf</code> tag, described <a href="https://support.10xgenomics.com/single-cell-gene-expression/software/pipelines/latest/output/bam" rel="nofollow noreferrer">here</a>:</p>
  <blockquote>
  <p>The bits of this tag are interpreted as follows:</p>
  <ul>
  <li>1 The read is confidently mapped to the transcriptome</li>
  <li>2 This read's barcode, UMI, and feature combination was discarded in favor of a different feature with higher read support</li>
  <li>4 This read pair maps to a discordant pair of genes, and is not treated as a UMI count</li>
  <li>8 This read is representative for a molecule and is treated as a UMI count</li>
  <li>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</li>
  <li>32 This read was removed by targeted UMI filtering.</li>
  </ul>
  </blockquote>
  <p>In a real dataset, I have this distribution of xf values:</p>
  <pre><code>$ samtools view possorted_genome_bam.bam |  egrep -o &quot;xf:i:[0-9]+&quot; | sort | uniq -c
  66263599 xf:i:0
  99892363 xf:i:17
    245179 xf:i:19
   8283967 xf:i:25
  </code></pre>
  <p>It is clear to me that <code>0</code> are unaligned, <code>19 = 16+2+1</code> are discarded, <code>25 = 16+8+1</code> are kept (and used in the feature_barcode_matrix); but I do not understand what happens to the <code>17 = 16 +1</code>. They seem to be good reads, they are aligned on genes, yet they are discarded.</p>
  <p>One possible explanation from my reading of <a href="https://support.10xgenomics.com/single-cell-gene-expression/software/pipelines/latest/algorithms/overview#umi_counting" rel="nofollow noreferrer">this paragraph</a> is that the reads with <code>17</code> are PCR duplicates, thus ignored, whereas the reads with <code>19</code> 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.</p>
  
Tags: <sam><10x-genomics><cellranger>
Title: In CellRanger output, what are the reads with an xf:i:17 tag?
ThreadText: # In CellRanger output, what are the reads with an xf:i:17 tag?
  
  (Asked by: username_0 on 2022-11-04)
  
  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](https://support.10xgenomics.com/single-cell-gene-expression/software/pipelines/latest/output/bam):
  
  > 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](https://support.10xgenomics.com/single-cell-gene-expression/software/pipelines/latest/algorithms/overview#umi_counting) 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.
  
  **Tags:** sam, 10x-genomics, cellranger
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-04-11. Score: 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.
  
  > **Comments:**
  > **username_0**: 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  
  
  ---
  
  