Does Samtools Tview Hide Pcr And Optical Duplicates?

Question

[Matthieu Miossec]

I've noticed that one of my .sorted.bam files contains a read that does not show up on SAMtools tview. The bit flag associated with that read suggests it's an optical or PCR duplicate. Does anybody know if SAMtools tview hides these kind of reads by default or is something else potentially happening?

Answer 1

[Ashutosh Pandey]

In the old versions of samtools when pileup still existed, the default settings for pileup was to filter reads with bitwise flag 0X704.

So for pileup generation the following reads were not considered at all from the bam files:

1) 0x0400 (aka 1024 or "d") duplicate

2) 0x0200 (aka 512 or "f") failed QC

3) 0x0100 (aka 256 or "s") non primary alignment

4) 0x0004 (aka 4 or "u") unmapped

I assume tview may be following the same filtering strategy and not showing reads that are PCR duplicates, unmapped and non-primary alignments. This makes sense too because sometimes PCR duplicates may create visualization problem if there are large number of duplicates reads at a given position.

[Matthieu Miossec]

I haven't been in the game long enough to have used pileup (using mpileup) so that's actually quite enlightening. This is probably what's happening in tview. It certainly seems like the most plausible explanation to what I'm seeing at the moment. Thanks!

[Isaac Joseph]

I suppose there's no known way to get it to stop hiding such reads? (Perhaps something inherited from pileup syntax?)