text: user3669: EDIT: I do not want to make any modifications to the mapped reads, I simply want to ignore one read in a read pair if they overlap the same region.
  I used samtools depth to calculate the depth of coverage for samples in the whole Exome region using a GRCh37_ref.bed. These samples are sorted and duplicate marked. I ran this calculation on a few hundred samples to determine how much more sequencing needed to be done and found something interesting. Some samples had 100X coverage at 96,000,000 mapped reads and some samples had 100X coverage at 83,000,000 mapped reads. The samples that had 100X coverage at 83,000,000 reads had read pairs overlapping certain regions of the bedfile (read 1 was covering the same coordinates as read2 to some extent). 
  I then found out that samtools depth double counts these overlapped regions even though they are technically from the same molecule in sequencing and would be a duplicate bases in the read. See the image for an example:
  
  Each base in this Duplicate Overlap region is double counted when it shouldn't be. How do you guys deal with this duplicate overlap region when calculating coverage across a bam file?
  samtools (v1.7):
  samtools depth -a -b exome_targets_GRCh37.bed sample1.bam > sample1_depth.txt
  awk '{s+=$3}END{print s/NR}' sample1_depth.txt
  
  
  user492: Bases from overlapping reads of the same fragment provide extra information, as their base qualities come from different sequencing cycles on the sequencer. This information can be used by downstream tools. For example, the merging tool of USEARCH increases base quality scores of bases that match between overlapping reads. Depending on the context under which coverage information will be used in the future, it may be a good idea to "double-count" overlapping bases.
  
  user3499: One way to deal with this would be to first merge paired-end reads based upon their overlapping regions, and then map them and calculate the coverage. This way you're only counting once per unique sequence.
  Programs like SeqPrep, PEAR (Paired-End reAd mergeR), and fastq-join can do this fairly quickly. However, this isn't a perfect solution as the reads will not be joined unless they meet some minimum overlap criteria.
  
  user1310: picard CollectHsMetrics has the parameter PER_BASE_COVERAGE which take this into account.
  You can run it like this:
   $ java -jar picard.jar CollectHsMetrics \
        I=input.bam \
        O=hs_metrics.txt \
        R=reference_sequence.fasta \
        BAIT_INTERVALS=bait.interval_list \
        TARGET_INTERVALS=target.interval_list \
        PER_BASE_COVERAGE=base_coverage.csv
  
  BAIT_INTERVALS and TARGET_INTERVALS could be the same file. You will need to convert your bed file to it using picard BedToIntervalList.
  Another useful tool is mosdepth. 
  $ mosdepth --by regions.bed SampleName input.bam
  
  fin swimmer 
  
  user77: samtools depth is a simplified version of samtools mpileup, which handles overlapping regions by default. Since overlapping regions shouldn't be included in coverage calculations (after all, you're not covering a region twice) you can use samtools mpileup instead:
  $ cat foo.sam
  @SQ SN:1    LN:1000
  read1   99  1   1   50  50M =   46  95  ATTTAAAAATTAATTTAATGCTTGGCTAAATCTTAATTACATATATAATT  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<  NM:i:0
  read1   147 1   46  50  50M =   1   -95 ATTTAAAAATTAATTTAATGCTTGGCTAAATCTTAATTACATATATAATT  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<  NM:i:0
  
  $ samtools mpileup -Q 1 foo.sam | cut -f 1,2,4
  ...
  1   42  1
  1   43  1
  1   44  1
  1   45  1
  1   46  1
  1   47  1
  1   48  1
  1   49  1
  1   50  1
  1   51  1
  1   52  1
  ...
  
  I haven't shown the entirety of the output and you'd want to use the -aa flag to ensure that all bases are returned.
  Note that samtools mpileup is doing this internally by setting the base phred scores of overlapping bases in one of the mates to 0, which then get excluded due to -Q 1 (the default is -Q 13, which you'd want to change).
  As an aside, you probably don't need exactly correct values, only approximates. Given that, you can use bamPEFragmentSize from deepTools (or a similar tool from another package) to get the median fragment and read length, determine the median number of covered bases from that and use it to get a quite accurate approximation of the actual coverage (multiply the median fragment base coverage by the number of fragments and divide by the genome size). That may prove faster and close enough.
  
original_text: 3669: <p>EDIT: I do not want to make any modifications to the mapped reads, I simply want to ignore one read in a read pair if they overlap the same region.</p>
  
  <p>I used samtools depth to calculate the depth of coverage for samples in the whole Exome region using a GRCh37_ref.bed. These samples are sorted and duplicate marked. I ran this calculation on a few hundred samples to determine how much more sequencing needed to be done and found something interesting. Some samples had 100X coverage at 96,000,000 mapped reads and some samples had 100X coverage at 83,000,000 mapped reads. The samples that had 100X coverage at 83,000,000 reads had read pairs overlapping certain regions of the bedfile (read 1 was covering the same coordinates as read2 to some extent). </p>
  
  <p>I then found out that samtools depth double counts these overlapped regions even though they are technically from the same molecule in sequencing and would be a duplicate bases in the read. See the image for an example:</p>
  
  <p><a href="https://i.stack.imgur.com/7dkOV.png" rel="noreferrer"><img src="https://i.stack.imgur.com/7dkOV.png" alt="Duplicate Region"></a></p>
  
  <p>Each base in this Duplicate Overlap region is double counted when it shouldn't be. How do you guys deal with this duplicate overlap region when calculating coverage across a bam file?</p>
  
  <p>samtools (v1.7):</p>
  
  <pre><code>samtools depth -a -b exome_targets_GRCh37.bed sample1.bam &gt; sample1_depth.txt
  awk '{s+=$3}END{print s/NR}' sample1_depth.txt
  </code></pre>
   492: <p>Bases from overlapping reads of the same fragment provide extra information, as their base qualities come from different sequencing cycles on the sequencer. This information can be used by downstream tools. For example, the merging tool of <a href="https://drive5.com/usearch/manual/merge_pair.html" rel="nofollow noreferrer">USEARCH</a> increases base quality scores of bases that match between overlapping reads. Depending on the context under which coverage information will be used in the future, it may be a good idea to "double-count" overlapping bases.</p>
   3499: <p>One way to deal with this would be to first merge paired-end reads based upon their overlapping regions, and then map them and calculate the coverage. This way you're only counting once per unique sequence.</p>
  
  <p>Programs like <a href="https://github.com/jstjohn/SeqPrep" rel="nofollow noreferrer">SeqPrep</a>, <a href="https://sco.h-its.org/exelixis/web/software/pear/doc.html#cl-usage" rel="nofollow noreferrer">PEAR</a> (Paired-End reAd mergeR), and <a href="https://github.com/ExpressionAnalysis/ea-utils/blob/wiki/FastqJoin.md" rel="nofollow noreferrer">fastq-join</a> can do this fairly quickly. However, this isn't a perfect solution as the reads will not be joined unless they meet some minimum overlap criteria.</p>
   1310: <p><a href="https://broadinstitute.github.io/picard/command-line-overview.html#CollectHsMetrics" rel="nofollow noreferrer">picard CollectHsMetrics</a> has the parameter <code>PER_BASE_COVERAGE</code> which take this into account.</p>
  
  <p>You can run it like this:</p>
  
  <pre><code> $ java -jar picard.jar CollectHsMetrics \
        I=input.bam \
        O=hs_metrics.txt \
        R=reference_sequence.fasta \
        BAIT_INTERVALS=bait.interval_list \
        TARGET_INTERVALS=target.interval_list \
        PER_BASE_COVERAGE=base_coverage.csv
  </code></pre>
  
  <p><code>BAIT_INTERVALS</code> and <code>TARGET_INTERVALS</code> could be the same file. You will need to convert your <code>bed</code> file to it using <a href="http://broadinstitute.github.io/picard/command-line-overview.html#BedToIntervalList" rel="nofollow noreferrer">picard BedToIntervalList</a>.</p>
  
  <p>Another useful tool is <a href="https://github.com/brentp/mosdepth" rel="nofollow noreferrer">mosdepth</a>. </p>
  
  <pre><code>$ mosdepth --by regions.bed SampleName input.bam
  </code></pre>
  
  <p>fin swimmer </p>
   77: <p><code>samtools depth</code> is a simplified version of <code>samtools mpileup</code>, which handles overlapping regions by default. Since overlapping regions shouldn't be included in coverage calculations (after all, you're not covering a region twice) you can use <code>samtools mpileup</code> instead:</p>
  
  <pre><code>$ cat foo.sam
  @SQ SN:1    LN:1000
  read1   99  1   1   50  50M =   46  95  ATTTAAAAATTAATTTAATGCTTGGCTAAATCTTAATTACATATATAATT  &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;  NM:i:0
  read1   147 1   46  50  50M =   1   -95 ATTTAAAAATTAATTTAATGCTTGGCTAAATCTTAATTACATATATAATT  &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;  NM:i:0
  
  $ samtools mpileup -Q 1 foo.sam | cut -f 1,2,4
  ...
  1   42  1
  1   43  1
  1   44  1
  1   45  1
  1   46  1
  1   47  1
  1   48  1
  1   49  1
  1   50  1
  1   51  1
  1   52  1
  ...
  </code></pre>
  
  <p>I haven't shown the entirety of the output and you'd want to use the <code>-aa</code> flag to ensure that all bases are returned.</p>
  
  <p>Note that <code>samtools mpileup</code> is doing this internally by setting the base phred scores of overlapping bases in one of the mates to 0, which then get excluded due to <code>-Q 1</code> (the default is <code>-Q 13</code>, which you'd want to change).</p>
  
  <p>As an aside, you probably don't need exactly correct values, only approximates. Given that, you can use <code>bamPEFragmentSize</code> from deepTools (or a similar tool from another package) to get the median fragment and read length, determine the median number of covered bases from that and use it to get a quite accurate approximation of the actual coverage (multiply the median fragment base coverage by the number of fragments and divide by the genome size). That may prove faster and close enough.</p>
  