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

<p>In the old  versions of <a href='http://samtools.sourceforge.net/'>samtools</a> when pileup still existed, the default settings for pileup was to filter reads with bitwise flag 0X704.</p>

<p>So for pileup generation the following reads were not considered at all from the <a href='http://samtools.sourceforge.net/SAM1.pdf'>bam</a> files:</p>

<p>1) 0x0400 (aka 1024 or "d") duplicate </p>

<p>2) 0x0200 (aka 512 or "f") failed QC </p>

<p>3) 0x0100 (aka 256 or "s") non primary alignment </p>

<p>4) 0x0004 (aka 4 or "u") unmapped</p>

<p>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.</p>
